Creating estimates using a cost database saves manual entry work, ensures your numbers are coming from a good starting point, and standardizes data across the team that use the database. Here are some tips from the Beck Technology professionals regarding “starting from scratch” on building a new database:
Variables:
Make names as short and obvious as possible and use CamelCase
Example: OverExcav to be used for an Over Excavation waste factor… X*(1+(OverExcav/100))
Start as generic as possible and only add new variables as they are needed. (DESTINI Estimator is able to customize the question prompted to the user on the Questions tab in an assembly, so “Length” can get a ton of use in multiple assemblies.)
A variable can only be asked once in an assembly, no matter how many times it is used
If you need to ask Length of Wall and Length of XYZ as separate inputs, you will need two separate “length” variables
Length
WaterstopLength
Formulas:
Allows you to save your custom formulas to be added quickly to line items
Use a different nomenclature system to make it obvious when you are seeing it
FX_FORMULA_NAME or something similar
You CAN bury formulas inside of formulas but it can make it tricky to track down an errant variable down the line. One layer deep isn’t bad. Burying something within 4 to 6 layers of formula can be a headache.
FX_Area = Length * Width
FX_Volume = FX_Area * Depth / 27
Line item receives only the formula FX_Volume, and the user is asked about Length Width and Depth
Overall Comment: When building assemblies and designing the logic, test early and test often! You may think you have it figured out just right, but your test may show otherwise. Think of your assembly in “buckets”, and when you finish the first formula of a bucket, test it. If it passes your review, repeat that formula as needed for the items in that section. If it doesn't then revise, retest, and then move on.