PROBLEM: It is common to have complex business logic in a field's auto-enter calc that is allowed to overwrite itself. As we move to reduce reliance upon unstored calculations to overhead, field with stored auto-eneter calcs are more common. Unfortunately, when the Scripting Engine needs to modify or reset this value (via a Set Field/Replace), there are two primary methods to do so, and both are not ideal:
1) The Source Field needs to be re-triggered via the inclusion of a separate trigger global field within that calc, and then the record modified to change that trigger field, to force the data to change.
CON: This introduces other logic and schema solely for the purpose for re-evaluating the calc.
2) The Script's Set Field/Replace calculations need to have a copy of the Source Field's Calculation inserted into them, that way they can set the field to the same value it would set itself.
CON: This duplicates a stale version of the Calculation formula within the Script Engine, that must be remembered and manually changed any time the Source Fields auto-enter logic needs to be changed by the business.
BENEFITS: The a new function whose purpose to provide a field's now current calculated result would answer this need. The function would calculate the fields resulting value at runtime, based upon it's Calculation or auto-enter settings, as if they were evaluated at this moment, but without modifying the field's current value. Some use cases/benefits are:
- Makes systems more resilient to change by allowing key business logic to only be kept in one place.
- Reduces errors and time spent ensuring updating fields with the values they should have, but somehow were not triggered.
- Developers more easily able to set fields to their a new "correct" value in a straightforward way, use the function instead of trigger fields or duplicating business logic into Scripting layer.
- New Capability to evaluate the result BEFORE applying it to the field actual data and losing that data.
- New Capability to scripted-ly validate results prior to applying them.
- New Capability to tell user (via tooltip or message) what will happen before a change is made.
ALTERNATIVE: A function that actually returns the calculation text itself, to be used in a subsequent Evaluate ( function ) might also be nice -- but I could see certain locked solutions not liking exposure of script calculation formulas, whereas the method suggested below only returns the result of said calculation.
GetFieldCalculationResult ( fieldname )
Returns the value that would be assigned to the field as if its Calculation were re-evaluated at this moment, or an Auto-Enter which was set to "Allow Overwrite" and the field was re-triggered, or a Static default auto-enter option such as a "0%" needed to be reset into the fields value. This would allow the developer to obtain the result the field, as it is currently defined via calculation within it's schema, without the change actually being made to the field's data. This may be used by the script engine to set a field to it's current value without a trigger field.
fieldName - the name of a field in the current context to be evaluated.
Data type returned:
The field name must be in the form tablename::fieldname to specify a field that exists in a table different from the current table.
FieldCalculationResult ( "Phone Number" ) returns "888-555-2234" which is the department's default phone number even though the field currently is blank or has a different value.
FieldCalculationResult ( "Accounts::Current Balance" ) returns "301.94" since it added all "current" invoices, even though the value of the field is currently "10.20".