Currently, I have a modelled calculation like
RoundAccounting([../Input/MinutenLG1_1]*36.73/60, 2). The hourly rate is 36,73€. I would like to have the option to change that hourly rate, but NOT by adapting it in each document separately, but to have a centralized storage of those factors which I can call and adapt within the running application and then upon having changed those factors, directly apply the newly defined hourly rates on all document in the DB.
Something along the line of this:
Pressing the button opens a Modal where the current hourly rates can be adapted and upon accepting that, all values in the overview are recalculated.
Hey @jasper-silent-root,
should the results then really be persisted on the Untersuchung-document?
Or would you only persist the NumberOfHours per Untersuchung and then compute the Gebühr and Preis on-the-fly?
One way with modeling could be the CDM approach. You would just need to link all your Untersuchungs-documents to a specific Rates-document. Then you can compute on the fly (to have an updated Overview and Form. The Untersuchung-document should then not contain the Gebühr, so you dont have consistency errors.)
With this approach you could also have different Rate-documents. Your Rates probably change over time but you probably do not want to change the rates of old Untersuchungen. So this could give you a handle for versioning.
With the new Data Services Approach you get the results also synchronously, but you would not be able to Sort or Filter by Gebühr or Preis.
If you need all the data in the Untersuchung-document, you could try Mapping.
This keeps it modelable as well.
You can model the Fee Calculations and their conditions in the Precomputation Step.
You can also model the “Rates” Document and Form model you need for the enduser UI and use the Rates entered/ persisteted as second source of your mapping.
When the rates are change, you would go thru all the Untersuchung-documents that need to be updated and call the mapper (Untersuchung-document and Rate-document are the two sources and you get the new Untersuchung-document as filled target).
Since the data is then persisted in the Untersuchung-document, you can then also Filter and Sort on Gebühr and Preis in the Overview.
The use case would be that all calculated values in the thick lined box in all documents would be recalculated according to the values set in this Modal (this includes a few values from the overview, like "Gebühr).
Yes, but the question is: Do you want to persist the calculated values or recalculate them on-the-fly when loading the overview/form.
Persisting:
- fast loading
- long saving (apply new rates on all Untersuchung-documents → synchronously?)
- custom recalculation code needed (modelable with Mapping)
- Sort and Filter of Data Services Query API works
on-the-fly
- loading is slower
- virtually no time needed for persisting (only the Rates-document is persisted)
- all values are always up-to-date. no consistency problems (what happens if the recalculation code fails halfway?)
- modelelable with CDMs (Only the Button to dispatch a new Activity to show a specific Rates-document and trigger overview reload is needed. Rest can be modeled with CDMs and in the AppModel)
- Sort and Filter of Data Services Query API does not work on the calculated Fields
I don’t know yet what we would prefer in this case, but with your answer we have enough to go on to decide our path. Thanks a lot!
