Unshipping LineItems

[LaRetta]

Hi Everyone,

I've attached a small working file. As you know, searching through a 500,000 LineItem file can take time so I usually use GTRR to isolate LineItem records. During our shipping day, sometimes we find out a certain order (Invoice) needs to be unshipped and put into Pending (another portal window). 'Shipments In Process' appear in a specific portal window (Invoices Shipping Now). Because of back orders and other issues, my LineItems need to be flagged in various ways during the shipping process. So when an order is removed from a shipment day, those LineItems also need to be isolated and 'unshipped' as well.

If you check the graph you'll see how I've accomplished it; but I think it's clunky looking. Various LineItems are flagged for certain stock-pick lists; others for different types of pulls, etc. but I've kept the scripts simple for the demo. In truth it is more complex and includes checks for record-locking during the various flagging processes.

My graph is getting HUGE and COMPLEX because of all the multiple little TOGs I've created to run these types of processes and I'm looking for ways to cut down on my TOs. This is a prime example ...

Can this be accomplished more easily and even cut down on the TOs? If I can streamline this example, I might be able to apply it in many other processes as well. This is not a critical need issue. This is an attempt to further learn how to take advantage of vs. 7 and TOs. Ideas very much appreciated.

LaRetta

Orders.zip

[RalphL]

In this example it looks like the TO "Invoice Selected" is redundent.

[LaRetta]

Hi Ralph! Thank you for helping!

Of course the extra Invoice TO isn't needed. I failed to explain myself, I think ...

I was attempting to show that I already have an Invoices TO related to LineItems on Invoice Number -- in fact, I have many of them and I think it's ridiculous. But I'm unclear on how to STOP creating more and this is a prime example. I obviously need an Invoice TO called Invoices Shipping Now (my portal). But do I really need to add ANOTHER LineItem TO? God, I'm overflowing with them. And I have lines everywhere. My solution is fast ... but my graph is beyond ugly.

I have 5 invoice portals which display orders in various stages of completion. I'm hoping to use a global to hold the 'selected' invoice and GTRR to only ONE copy of LineItems to perform multiple functions since they ALL are related only on the Invoice Number. I don't want to create 5 LineItems TOs (one off of each Invoice portal TO). And since a User can only select one Invoice from one portal at a time (although all 5 displays on a layout), I'm hoping to use same script parameter and global in each one -- all jumping to the same LineItems -- hopefully one of the many ALREADY existing LineItems instead of adding new ones all the time.

I also realize globals can be accessed from anywhere - even unrelated tables. What I don't seem to get is how that translates in the graph ... and how the same global (in invoices??) can be used with several table occurrences.

I don't think I need a relationship at all between my portals and anything. If a global captures the Invoice Number (script parameter), I should be able to accomplish everything in the script without additional relationships, right? But GTRR needs a relationship. I don't want to perform Find in either Invoices or LineItems - they both are huge.

If this (seemingly) simple idea (storing the Invoice Number in a global and reusing the same Invoice to LineItem relationship) can sink in, I'll be able to clean up my graph even further. I hope this makes more sense. I think I'm beginning to grok vs. 7 ... and then I go blank again. It seems the more I figure out the less I know. I feel like I'm playing scrabble in my graph.

LaRetta

TO-handicapped in Oregon

[RalphL]

I have been using the Anchor - Bouy model for my graphs.

The Anchor is the TO for the layout. The Bouys are the TO's required by the layout. Each of these is a TOG.

This means there will be TO's pointing to the same table in many TOG's.

It may make the graph larger but each TOG's is much easier to understand and to work with.

Your sample file doesn't give enough to see the full picture. In pre 7 we often had more than one relationships between 2 files, so now we more than one TO.

Remember TO's are not tables.

When you say "5 invoice portals", are these all on one layout?

[LaRetta]

I almost snapped a picture of my graph but I'm simply too embarrassed (yep, a rarity). I doubt anyone has as much in theirs as I do. Three months ago, I had 9 LineItems TOs. I just counted ... I now have 22! I probably have 300 TOs in my graph easily and I've disconnected about 20 realizing I could structure certain things differently.

My graph? Contacts table with 50 TOs radiating from it (most on =). From the Invoice TO, again 50 TOs radiating from it ... various TOs for filtering mostly to GTRR to various LineItems. LineItems is a beast which I can only handle with GTRR. And I have 'specialty' TOGs (islands) for display of unique in portals and other special displays.

I've been frolicking in TOs for months ... adoring the ability to add them whenever I want them. Problem is ... this allows me to design without really thinking it through - and even a good thing can be overdone. It can also be a trap - don't think just plop another copy of a TO. It doesn't force growth and consideration.

I keep saying to myself, "Remember your POV (point of view)" but heck, I no longer know WHERE I am. If I open my graph, I feel instantly exhausted. And I go nuts trying to keep them all straight or even FIND them. I realize TOs aren't tables and take little (or no?) FM resources but if I keep up at this rate, I'll need to start double-stacking them. I can circle several TOGs and move them as groups but since they all are attached to Contacts on one end and LineItems on the other, I can't even move them without skewing my lines and turning it into a spider's dream!! An FM engineer saw my graph and said it would be very fast ... that kept me going in that direction. Fast maybe, but a headache!

The anchor theory based upon Layout? You have my attention. Most of my TOs are to isolate sets of records (replace Finds) and then I display on the main Contact or Product layout etc. Rarely do I base a layout on a TO other than the original base table. Maybe I have it backwards!? 5 Invoice portals are on one layout (based upon Shipping table). Originally they were in one portal and color coded. But I needed counts and summaries based upon each invoice grouping and Management wanted to see them on one layout side-by-side (and they select a row to jump to that specific invoice also).

I envision using globals - a clean, organized graph with few lines. I'm doubting everything I thought I've learned and I feel like I'm having a vs. 7 mid-life crisis. Is there help for me? With my graph, I mean? I realize I'm beyond help in many other ways.

Update: Oh yes, these same Invoice portals are also in popup windows for regular staff to view individually. Different layouts but based upon same Shipping table.

LaRetta

[Ugo DI LUCA]

Hi,

As Line Items is the central "archive" of any business solution, it doesn't seem to be contradictory to have plenty of Line Items TO at first glance.

Though it doesn't have to be redundant at all, and from what you describe, you seem to be confusing "Points of View" and "Data display", which in my opinion causes your current confusion.

If you want to picture it differently, then at first think of a 6 faces rolling dice and the different ways of seeing it. The dice doesn't change indeed, but what you see from one side is different from what you see from the top or from any other angle.

Even if this dice was transparent would the views be different and it would be easier to move around the dice to see the other part than trying to interpret what you can see by transparency from your current position.

I went with another image the other day in a session I organized for some students in Paris.

Imagine your database is the Sears Tower and it now gets more approaching to our current scenarios. Not only should we get different Point of Views from the West, East, North, South, Ground or Sky, but the result would be different if your eyes get a focus to the 10th floor, the 30th or that 5th window at the 42nd floor. You didn't changed the Point of view but you adjusted the focus to this particular floor or/and window.

Changing Point of View is the result of moving from one point to the other. The Tower didn't changed. You have to give the user the good transportation means to do it quickly without getting caught into traffic. One choice could be to enter the building from the North Entry and get out from South Exit, but it is much more common to move around the building, if you ever needed to get a temporary Point of View.

Back to the original dice/cube appoach now, multiple windowing in FM7 not only allows to target this office cube on that 5th window on the 42nd floor. You can even go to the one that is just behind or several partitions away, using a door or rotating each cube to get there.

This is where FM7 new relational design and where the developer choices on database partition come to play, as you would have to determine wether it would not be better to move your user on the other side of the building if ever this office cube has a window from that Point of View or not...

Data display now is a way to arrange your views, so that your eyes react as Tables, drawing a vertical line starting from this 42nd floor down to the Ground, or that you've chosen to go horizontally on the whole visible windows from this 42nd floor. You may even arrange this views as 3D elements by viewing the 42nd floor from the 4th window from South deep inside the building up to the North, or obviously with any possible foundset you've chosen. You may flag any possible office cube with "blinds" if needed too.

Form view would get a focus in each of the offices and rooms of the Sears Tower, and even there you may have chosen to rotate the element as a cube so that you can see each corner of the room if needed.

To conclude with this strange comparisons, there is no need to give the user the same accomodations and facilities in all Point of Views, and always keep into mind that this chinese proverb that says "It is is close to the wall that you better see the wall" is false.

So, if only this was clear (as I realize theory is not my best), once you have the structure and partition, you would decide on views and displays, but it doesn't have to be redundant. Just dynamic and transparent enough so that you exactly know where you can go from any Point of View.

[RalphL]

Five portals means five relationships, i.e., TO's.

The anchor is normaly the base TO. Take a look at the file I attached at:

http://www.fmforums.com/threads/showflat...true#Post157818

[LaRetta]

Ralph, Ugo - thank you for taking the time to respond. I've been considering your posts (and your demo, Ralph) for a few days now and you've added dimension to my understanding and decreased my insantiy a bit. I've been creating some demo models of it and layout-based TOGs make more sense than my existing model.

Much appreciated!

LaRetta