Inside Track
Heber Allred zzTakeoffProperties at Takeoff Level or Item Level
Sometimes it feels like this (below) when we're trying to decide whether specific properties belong at the takeoff level or at the item level. In an attempt to simplify certain use cases in zzTakeoff, we're working on some changes that would allow a takeoff to also be an item if the user chooses (without the need to separately add child items to get material quantities). For example, attaching a Price Each and/or SKU directly to a takeoff (causing it to become both a takeoff & item at the same time). This works great for users who don't use assemblies (with child items) because they can just apply a Cost Each (such as per SF) and get a price.
We're experimenting with the idea that when you start a takeoff (such as an area), by default the Cost Type is Assembly which is the current behavior (assuming the Cost Total and Price Total will be calculated by totalling up child items). But if you want to treat the takeoff directly as a Material you can change the Cost Type to "Material". Then the "Materials & Labor" panel would disappear (which is only needed to add child items), and you would just see a Cost Each and other Item properties directly at the takeoff level, etc.
An area with Cost Type "Material" selected. Now the takeoff is operating also as an item (and would not allow applying child items to it).
What are we trying to solve?
1. Some of our users don't use assemblies. Some users want the takeoff measurement itself to be a window, door, bush, etc. (instead of just a measurement) and having to add a child item to represent the materials adds an extra step for these users. In our original architecture, we originally wanted to force all items to be children of the takeoff, to cleanly separate the geometric measurements from the material quantities.
2. Easy price per SF without adding a child item
When a takeoff is operating as an assembly, it would auto populate Cost Each, Price Each, Price Total, etc. based on the child Items. When a takeoff is operating as it's own item, you could then edit these properties directly.
Behind the scenes, there are various challenges that we are working through to make sure the reports can still slice/dice/group/sort all the data properly. We're experimenting to see if we can make this all work smoothly. We're open ears if you have any thoughts.
Good stuff on a Saturday afternoon @Heber
I’m a user who prefers assemblies as containers for resources or items/parts (MLESO) under a parent QTO. I would prefer if the assembly can be a standalone QTO type if need be or plug into a parent QTO container and trigger input prompts when added under a parent or suppressed if I take care of those inputs via report spreadsheet in bulk.
In my mind, there would be multiple assemblies or even just individual items under the parent QTO. I would expect those assemblies and/or parts (items) under the parent QTO item to inherit calculation or input data to create additional calculations based on either the combined parts under an assembly or just a standalone part. The complication I would run into back in PS days is being overwhelmed with input prompts (that would be clunky if the default view weren’t set to “input only” window) at the QTO level that weren’t always required. That’s when I learned to just add assemblies and parts à la carte to a QTO which triggered input boxes to come up only after asking as a child under QTO or assembly. Some off the shelf QTO templates with assemblies and parts worked out, but again the overwhelming input anxiety was always tough.
I’m also at a point where some projects do just require a simple QTO with a unit rate with little to no calculations or inputs. Which is what I feel your post above is touching on and going to solve. I’ve tried to explore some workarounds within zzQTO to accomplish the same result but spreadsheets…
So, for me what I’m looking to solve is 1 of 3 things if I were to rely on a QTO software to also estimate for me:
- ROM (back of pickup napkin #’s) - a simple unit rate at the QTO level. Ex. $4/sf * QTO.
- Unit price - more of a costbook (ex. RS Means) approach of MLESO unit prices to build up the QTO w/o MH’s, widgets, etc being accounted for. This may involve more than just a $/sf cost at the QTO level and just drop down at 1 child level from QTO parent.
- Hard bid - this would be the most granular to me as I need to rely on company in-house costing archives (work/crew/production history), quotes from vendors or in-house profit centers, and tighter control over markups. The MH’s are critical, the widgets matter lev level and need to be quantified, the of detail could get down to construction materials (lumber, nails, screws, etc). This scenario would be 2-5 levels from the parent QTO with an assortment of:
- Child individual parts (2nd level)
- Child assemblies (2nd level) that have an assortment of child parts/items (MLESO) (3rd level)
- Child QTO’s under the main QTO (2nd level) that rely on parent QTO calc’s/inputs to feed either assemblies or parts (3rd level), and there is an assembly more parts/items (4th level).
When I get the time, this is how I plan to sort out my system because it’s what works for me and how I have assortment of spreadsheets set up currently, but I’m always a student and eager to learn better, faster, stronger, more…
This would be an awesome option. I have found myself needing just a single TO w/out adding items. My big ask is for the ability to add a multiplier to the take off QTY. For example with painting, if we are painting both sides of the wall we want to see the TO QTY doubled. This sounds like it could a soulution.