1 of 1 people found this helpful
Sales Invoices, Estimates and Purchase Orders generally all require the same basic data model--only the names change. Since you are discussing an Estimate, I'd set it up like this:
Estimates::__pkEstimateID = LineItems::_fkEstimateID
GoodsAndServices::__pkGASid = LineItems::_fkGASid
This assumes that you have standard rates/prices for each good or service you might list on an estimate. If these are values that you negotiate for each estimate, you wouldn't need the GoodsAndServices table as each record in GoodsAndServices documents a single item or service that you might list on an estimate or invoice including the hourly rate or item price charged for it.
You'd use a layout based on Estimates with a portal to LineItems to create an invoice and list the items required for that estimate. A value list formatted _fkGASid field can be used to select a Good or Service from the GoodsAndServices table with rates/unit prices looked up (copied) from that table into the line item record when you select something in the _fkGASid field.
A list view layout based on LineItems makes a good layout for printing your estimates as it will make for more flexible printing than an estimate printed from the Estimates layout. You can pull up a found set of the LineItems for a single Estimate and include fields from the Estimates table in the Header and Footer in order to produce the needed printed Estimate.
2 of 2 people found this helpful
With this many calculations, would you use calc fields (easier to see results, and cannot be easily modified)? Or would you use scripts to perform the calculations and set the fields (file size, and speed)?
I'd use look ups or auto-enter calculations to pull data from GoodsAndServices into Line items. I'd then use auto-entered calculations (with the "do not replace... check box cleared) to compute the line item cost with aggregate functions in Estimates to produce totals based on the listed line items.
Whether scripting or using calculations, the file size is going to be nearly the same. Speed will usually favor calculations over scripts in this context and is much simpler to set up and get correct results. You'll only encounter speed issues if you work with very large numbers of records--such as the line items for say 5,000 customers all at once in one big found set and then only for unstored calculations that have to re-evaluate each time you pull up a different found set.
Auto-entered calculations (with the check box cleared) and Stored Calculations are nearly identical in how they function as long as the referenced fields are all in the same record as they would when used to compute a line item cost in the line item record from looked up values. I prefer auto-entered over calculation fields for two rather technical reasons:
If you have to import this data into a new copy--to recover data from a damaged file or to deploy an upgraded version of your solution, 1) the auto-entered line item calculations will not re-evaluate and this makes for a faster import and 2) by not recalculating, if the current version of Filemaker is different from the one used when the line item was created, any bugs in the calculation engine that might exist in one version and not the other won't result in the value changing due to the import causing the field to recalculate.
Many versions ago, we saw historical data in calculation fields change on us when importing data created using an older version back when FileMaker 10 was the latest release because a rounding bug in a much older version had been corrected--and I've kept that memory in mind during my design work ever since.
All very good suggestions. I will implement all these! Thank you very much!