By "buttons" you really mean layouts. The advantage of different layouts is they can be based on different table occurrences.
Tabs are nice if you're collecting data around a single "type" of information.
Customer Info and Quotation Templates should be on different layouts.
On the Customer Info layout, you may want tabs for things like "Contact Info" "Past Orders"
Hope that helps.
various pages like Customer info, Quotation template, Order template, packing slip, Projects etc..
I think there is a misconception: each of these entities will belong to (or more to the point, be) a different table. You can see from the relationship
Table --< TO --< Layout --< Tabs
that a layout can have many tabs (or tab objects), but each tab (object) belongs to one layout, and thus, to one TO/table.
So you cannot use a single tab object to switch between tables / layouts (though you can place portals to different related TOs into different tabs).
1 of 1 people found this helpful
No, but you can use the popvers to save time from "traveling".
Tabs can show you related data for one customer, so you could see:
- Invoices Due/All
- Shipping Addresses
Those would all come from different table occurrences that are tied to your customer. And from the orders tab you can take the user to a new layout with a button to create a new order.
Hope this helps.
Some of the pages you mention (pages like Customer info, Quotation template, Order template, packing slip, Projects etc..) sound llike they would be for the purpose of printing, which would obviously need to be separtate layouts designed for that purpose. If you investigate and experiment you will no doubt come up with mixture. But since you are now using FM13 don't confine yourself to tabs only; investigate slide controls and popovers also.
1 of 1 people found this helpful
And keep in mind that there can be overhead from adding things to tabs, which can have an impact on network performance, which is even more dramatic with WAN than LAN connections.
Placing portals in mutliple tabs can trigger record-caching from multiple tables. Avoid placing portals on any layout where they're not needed. This will improve network performance in the long run. It may not seem to make any difference when testing on a local machine, but it can be dramatically different on a live network.
Thank you all for your suggestion. So if I understand , I should create buttons which would send me to a different table/layout for let's say "order entry" and the same for writing a quotation and tie them all with the relationship etc.
Then I could have a "tab" in the customer layout just to view the data that was entered in the quotation for this particular customer but not to be used to make a quotation for the customer. Kind of what Agnes has in her reply. Am I explaining this properly ?
nbellisario wrote, in part:
Then I could have a "tab" in the customer layout just to view the data that was entered in the quotation for this particular customer but not to be used to make a quotation for the customer.
More typically, since you will eventually have multiple quotes for repeat customers, you would want a tab in the customer screen showing a list of their quotes in a portal, with buttons in each portal row which go to a layout for the details of that specific quote, rather than one quote's details in a customer tab.
Or if you're in FM 13 you can just add a popover to show the quote details
from the selected portal row.