V4 - Formula Update Timing

Discussions concerning general integration topics.

Moderator: Phil Barton

Post Reply
BHinote
Posts: 10
Joined: Fri May 08, 2015 5:51 pm

V4 - Formula Update Timing

Post by BHinote »

I have discovered an issue that pertains to a Formula defined under the "Order Contacts\Fee Transfer Ledger" field.
The following Formula is assigned to the Escrow and Title Contacts, Fee Transfer Ledger Field when the order is opened.

If ( {{.Owner{Contact}.IncludeOnRevenueReports}} = True ) Then
'R' + FormatDate('%Y2', SystemDate()) + FormatDate('%M2', SystemDate()) + '_' + SubString({{Order.Number}}, 1, 6)
EndIf

When Pending Ledger Transfer is changed to Posted, the result of the above query is assigned to the "Transferred to" field of the Transfer In section. As far as I know, this has been working as expected and should be applying the correct result for the System Year and Month the Fee Ledger is being posted in...

However, it has been recently discovered that the Result of the Formula is not resolving the Current System Year and Month and I have not determined why.
If I go look at the Order Contact, either E or T, the value of this formula "Always" reflects the Correct value for the System Date and Time, but this does not carry forward to the Ledger Transfer.
The only way I have found to get it to be correct is to open the Formula, change it, change it back and then Post the Ledger. This time the formula value is correct and all is well...
As far as I am concerned, I do not see a reason why the Formula Result should not continue to update to the Current Date Value every time he Fee Ledger is being Posted...

What is causing it to not update when applied?

Thank you,
Brian
Phil Barton
Posts: 54
Joined: Wed Sep 24, 2008 2:37 pm
Location: Raleigh, NC
Contact:

Re: V4 - Formula Update Timing

Post by Phil Barton »

The formulas act just like any other rule in that they will only update if something that the formula is dependent upon changes. So, in the case of the formula you have posted, unless the Owner, IncludeOnRevenueReports, and/or Order.Number properties change, the formula will not be scheduled to re-run. Now, you may be wondering why it doesn't change when the date changes due to the SystemDate() call. The rules do not take a dependency on external events such as date/time changing, etc. Only values of the entities changing cause the rules to schedule and run.
Phil Barton
Software Architect
SoftPro
BHinote
Posts: 10
Joined: Fri May 08, 2015 5:51 pm

Re: V4 - Formula Update Timing

Post by BHinote »

I understand what you are saying, but do not understand the following results:
1. Every Time I open the Title or Escrow Contacts, this Value reflects the Current Year and Month for this value. (i.e. Presents itself as the Correct Value.)
2. However, when I open the Ledger Transfer and change the value to Posted the value assigned to the Transfer is some Prior Period of time...

Although I would like to see the Value change to match the current point in time, I does not make sense that the Value Changes when looking at the Contact Screen, but does not when applied to the Transfer...
I would expect them both to reflect the same Value...
BHinote
Posts: 10
Joined: Fri May 08, 2015 5:51 pm

Re: V4 - Formula Update Timing

Post by BHinote »

Phil Barton wrote:The formulas act just like any other rule in that they will only update if something that the formula is dependent upon changes. So, in the case of the formula you have posted, unless the Owner, IncludeOnRevenueReports, and/or Order.Number properties change, the formula will not be scheduled to re-run. Now, you may be wondering why it doesn't change when the date changes due to the SystemDate() call. The rules do not take a dependency on external events such as date/time changing, etc. Only values of the entities changing cause the rules to schedule and run.
Phil,
Is there any way to add a condition that will always change? (i.e. Adding a test of a field that changes every time the user opens the order or something along these lines.) I am sure adding "AND 1<>2" will do nothing for this because 1 and 2 are not SoftPro Fields.

I need the Ledger Transfers to use the current representation of the Ledger Construct, especially when the Value does show the current result every time they Look at the Escrow or Title Contact... It just does not provide the current value in the Register...

Thank you,

Brian
Phil Barton
Posts: 54
Joined: Wed Sep 24, 2008 2:37 pm
Location: Raleigh, NC
Contact:

Re: V4 - Formula Update Timing

Post by Phil Barton »

Is there any way to add a condition that will always change? (i.e. Adding a test of a field that changes every time the user opens the order or something along these lines.) I am sure adding "AND 1<>2" will do nothing for this because 1 and 2 are not SoftPro Fields.
That's not something you can (or should) do. The rules are reactive, meaning that a rule runs when something that it depends upon has changed. This is limited to properties of entities (i.e. Sales price, name, etc.). So, when a property is changes and the rule (or formula, in this case) sees that it relies on that property, the rule/formula will be scheduled. As before, anything that is external to the entities (i.e. system clocks, permissions, profiles, etc.) do no cause rules to run when they change.

Another property of the rules is that they are always seeking a stable state. By that I mean that they are trying to get to a state where, after a change, no more rules get run. When it is persisted, and subsequently used in the register in your example, it is in that stable state. Putting something in the formula will always change would put the rules in a perpetual running state. This would result in the application (client and/or server) becoming unresponsive. Additionally, as a side effect, any closed orders could potentially become modified when opened merely for inspection.

If the functionality you're trying to implement is common functionality that will be used on all orders, you may want to consider custom rules using Python.
Phil Barton
Software Architect
SoftPro
BHinote
Posts: 10
Joined: Fri May 08, 2015 5:51 pm

Re: V4 - Formula Update Timing

Post by BHinote »

Phil,
Time has got away from me and I am finally getting back to your response... First let me thank you for taking the time to respond.

I agree and understand that all Formulas should strive to reach a stable state, so they do not continue to run when they are no longer needed or unnecessarily.
The only reason why I am trying to find a gimmick, to force the value to be updated, is because it is not consistently reflecting the Current Year & Month when the Ledger Transfer is being posted.
If the Contact, containing the Ledger Transfer Formula, was originally added to the order last month (12/2015) and the Transfer is done this month (01/2016) it cannot be posted to Last Months Ledger. (i.e. Our Ledgers are processed, reconciled and closed monthly.) This must be dynamic, as users have created major issue when they manually assign the Ledger... The strange thing is that my original formula works every time the contact is opened and viewed. It is just not applied when posting the actual transfer...
I will have to do some digging into Python and Business Rules...

Thank you,

Brian
BobRichards
Posts: 1377
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: V4 - Formula Update Timing

Post by BobRichards »

In case you are tempted, please do not tie Custom Order Rules (CORs) to Register or ProTrust events/queries. Like business rules, the same COR may fire multiple times for any dependency change. However, since they are very fast and you do not even realize this happens.

CORs are designed as simple ways to add new business rules to the order and should only interact with the ProForm order model (items in the Field Code Browser) and a few cached/in-memory objects (such as IProfileManager).

NEVER perform any long action in a Custom Order Rule such as server or database calls or call interfaces that MAY do this. If you do, the user experience will become slow and/or erratic.
Bob Richards, Senior Software Developer, SoftPro
Post Reply