Here are some tips from the Beck Tech pros, from the perspective of “starting from scratch” on a new database:
Variables:
1) Make names as short and obvious as possible and use CamelCase
a. Example: OverExcav to be used for an Over Excavation waste factor… X*(1+(OverExcav/100))
2) Start as generic as possible and only add new variables as they are needed. We are 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
3) A variable can only be asked once in an assembly, not matter how many times it is used
a. If you need to ask Length of Wall and Length of XYZ as separate inputs, you will need two separate “length” variables
i. Length
ii. WaterstopLength
Formulas:
1) Allow you to save your custom formulas to be added quickly to line items
2) Use a different nomenclature system to make it obvious when you are seeing it
a. FX_FORMULA_NAME or something similar
3) 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.
a. FX_Area = Length * Width
b. FX_Volume = FX_Area * Depth / 27
c. Line item receives only the formula FX_Volume, and the user is asked about Length Width and Depth
Overall Comment:
1) When building assemblies and designing the logic, test early and test often! You may think you have it figured out just right, but the test in Estimator shows otherwise.
a. Think of your assembly in “buckets”, and when you finish the first formula of a bucket, test it.
b. If it passes your review, repeat that formula as needed for the items in that section
c. If not, revise, retest and then move on