If the Remove SOV restrictions option is selected in the Business Process Setup window (General tab), then multiple Payment Application type BPs can be configured for a Project/Shell and multiple Payment Application BP records can be routed, at any time, for a commit.
Note: You can go to the Base Commit Setup section for setting information.
Example
First, the user creates the contract record CON-001 and sends the contact to a step that creates Schedule of Values.
Then, the user creates a Payment Application BP record PA-001 and sends the BP record to the next step for approval. At this point the BP record is in progress (in-flight).
Then, the user creates a second Payment Application BP record PA-002 and sends the BP record to the next step for approval.
Then, the user tries to create a second Payment Application BP record for the same Contract CON-001.
An Alerts icon (
) is displayed and when the user clicks the icon, information about pending payments and negative change orders is presented.
Unifier does not block the creation of the second Payment Application BP record PA-002, but informs the user that a Payment Application BP record is pending on the contact.
If the Remove SOV restrictions option is deselected in the Business Process Setup window (General tab), then only one Payment Application type BP can be configured for a Project/Shell and only one Payment Application BP record can be routed, at any time, for a commit.
After a Payment Application has reached the terminal step, if you open an in progress (in-flight) BP record, Unifier notifies you that the SOV has been refreshed.
After the system refreshes, Unifier retrieves the latest information, from the SOV. At run time, whenever you open a draft, or an in-flight, payment record and accept the SOV merge alert the data element (which has the "Do not get latest SOV values when merging" checked in uDesigner) will not get refreshed with the latest updated values from SOV.
Before SOV merge, payment grid for data element 'Unit price/gallon' which has 'Do not get latest SOV values when merging' checked.
All the fields populated from the SOV will be updated based on the latest SOV.
All formula fields, in the Payment Application Detail Form, defined using fields from SOV, will be re-evaluated.
Example
There are two Payment Applications P1 and P2. P1 has reached the terminal step. P2 is in progress (in-flight).
User has not yet accepted the task. Upon accepting the task, the system will refresh the SOV and inform user with an alert.
When the user changes to Payment Application BP, an alert icon appears on the window. Click the Alerts icon () to see any pending payments, and negative change orders, associated with the selected reference commit. The Alerts icon is available for both Workflow and non-Workflow BPs and might appear after a selection for the contract record is made.
User has accepted the task, and SOV has changed because of another payment. When user open this record, system will perform an SOV merge, and inform user with an alert.
If the user has left P2 open, and P1 has reached terminal status and P1 has impacted the SOV used in P2, then when the record P2 is sent to the next step, system will refresh the SOV and throw an alert to the user stating that the SOV has changed.