Released on September 21, 2022
A new ‘Custom Mode’ is now present in the calendars definitions. The mode can be set to ‘Standard’, which means that the periods will be shown as the type of calendar rule them (Month, day, week, …).
On the other hand, choosing a ‘Custom‘ gives the choice to define up to 7 rows with a formula in each.
The formulas must be input in the locale of Excel (in French in the above example) and the system will keep them automatically in English.
The third mode is ‘Mixed’ where both the standard rows and the customs rows are used (standard rows first and custom rows after).
Exporting and Importing a calendar will keep these values.
In the example above, the formulas are written with the row where they will be placed as a reference, like the ‘Semaine’ row:
They are written for the first column of the period (they will be adjusted if necessary after) and for the rows that will be present (here, the ‘Mixed’ mode has been used).
When using set of fields of type MATERIAL, the cost per unit is the ‘RealCostPerUnit’ column whereas for the other type, it ‘CostPerUnit’ column.
If some article or set in the database of the estimate have changed, the estimate has to be computed again. User can now do this automatically when answering the message box.
When a virtual article was imported using “Import Set”, if the virtual article contained a replacement field the latter was not imported. This is because, when you import an article from any database, the replacement field always has priority over the native field. This is normal because a field having a replacement field has a formula and cannot be written for this reason. So, when in a database you have both a native field and its replacement field, the replacement field is taken into account. That was not the case for virtual articles in sets.
BTW, we canceled the change brought to 7.22.997 "Recording sets from the minutes: we recently brought a change to the user interface of the “Record set” function (CTRL+H). We displayed the replacement field only when a field had a replacement field. However, that was wrong because we recorded the replacement field to the set database instead of the native field" because now you can push to a virtual article both fields (native and / or replacement). The priority is taken into account at importing time.