Released on May 9, 2020
When an estimate has the ‘Database of the estimate’ feature enabled, you can instantiate the rows of the database of the estimate in your minutes so when you make changes to an article or a set in the database of the estimate, changes are immediately reflected in all instances.
The drawback is that the referenced rows exist only in one place: in the database of the estimate so they must have same values in all fields for every instance.
Only the quantity field and fields used to calculate the quantities can differ. Of course, you can also tell the fields manager that some fields are hosting row oriented so they can be inputted in the minutes (in the minute row which host the instance of the rows). But only one row is available in the minutes when you reference a set (the heading row).
So, if you want to use a formula which references a field from the WBS, you cannot because the value in the WBS could be different for several instances of a line of the database of the estimate. That would result in different calculated values which couldn't be stored because physical rows are only in the database of the estimate, not in the minutes.
However, it would be convenient to display such figures. E.g.: you want to input a factor at WBS level and calculate a cost in your minutes or if you want to multiply the total cost of the minute by the WBS quantity to see the result in a column of the minutes.
To do this, you would use a formula like:
When doing this with the database of the estimate activated, you get the following message when you compute selling prices:
You can now avoid this message by telling the fields manager that the field receiving the formula is used only for display purposes in the minutes:
With this, you get figures properly calculated in your minutes. They are calculated “on the fly” to display correct results. Of course, they are not stored to the database when it’s impossible (when rows are children of sets defined in the database of the estimate)
Using such fields, you can use any formula involving the WBS and you can also create columns having formulas depending on theses columns.
Of course, these dependent columns must also be qualified as ‘For Display Only’.
A ‘For Display Only’ column can be used only in the minutes view. You cannot consolidate data from it in the overhead, in the WBS, in the data sources of the B.I. or in the report generator. In the B.I or in the report generator you can still use your own calculated column to get similar result.
It was already possible to achieve this before this new implementation but that was not safe: We had a special option to simply remove the warning message:
That was not safe because it was still possible to use the results in the overhead and WBS as consolidated figures. These figures were wrong. So, we highly recommend to uncheck that box and set your columns as ‘For Display Only’ instead.
We’re working at bringing a recommendation message when closing the fields manager when this flag is checked.
So far, these new ‘For Display Only’ columns work fine when an estimate uses a database of the estimate. Soon we’ll adapt so that you can also use such fields when WBS tasks are linked together. The problem is similar meaning that child tasks are instances of parent tasks.
Possible compatibility concern: We didn’t want to create a new format for QDV files to handle the new 'For Display Only' flags. So, when you use the new flag in an estimate using the new version of QDV and open your estimate in an older 7.18 or 7.19 version, the columns becomes 'No' for 'Not Allowed' so they are no longer displayed in old versions. If you edit the fields manager in older versions, the flag 'No' will be stored so you won't see these columns in new versions either.
When, in the layout of the minutes you had more than 55 free fields or a lot of material and workforce set of fields, QDV posted an error message at computing time. The problem occurred only when special columns were used to compute the quantities (Formula_for_Quantity, Throughput_Pace, Local_Throughput, Quantity_Factor, etc.)
To address this issue, we had to rewrite a significant part of the calculation engine.
To make sure it remains stable for most users who don’t use these features, the new code is executed only when special columns are used to compute the quantities.
This change should result also in faster calculations when such fields are involved. Please let us know if you see problems with this new implementation.
The recently added column Quantity_For_Evaluation didn’t properly refresh when attempting to display the figures from the Quantity_For_Evaluation_WBS (in headers of sets and orphan rows)
When copying data from an estimate having no Formula_for_Quantity field into an estimate having such field, as a result we had nothing in the Formula_for_Quantity field and values in both Evlauated_Quantity and Quantity fields.
This was a big confusing. So now, when you carry out such copy operations, the Evaluated_Quantity field is converted into a value in the Formula_For_Quantity_Field. If the Evaluated_Quantity field is blank, the native Quantity field or its replacement field are also set to blank.
So, the formulas being in Formula_For_Quantity field always have the priority over figures being in other fields. This is safer.