Enhancement Release 8.0 - Dealing with Contracting Mistakes

Open

On APEXA, the variety of contracting features available can lead to parties unintentionally making errors in the contract hierarchy, accidentally adding an incorrect package or occasional signing issues. Previously, the only option available to clients was to deny the contract entirely. The new functionality, however, will allow users to handle these scenarios more efficiently.

Reset or Cancel the Contract 

Enhancement requests: SD-30179, SD-14099, SD-14404, SD-28545, SD-25063, SD-1016

• The "Reset contract" and "Cancel contract" buttons can be used on a contract with a "Pending" status. These buttons must be utilized with caution as their actions are irreversible. 

• These actions are only visible to the party who added the contracting package to the contract. That party does not need to be the current party on the contract to execute either of these actions, but the contract cannot be ‘locked’ at the time. However, if current party on the contract is a Carrier, the actions will be greyed out until such time as the Carrier sends the contract backwards to the MGA. When the action is executed, that party will become the current party on the contract.

• Only users with a role that includes the ‘Reset Contract’/’Cancel Contract’ permissions will be able to cancel or reset a contract.

• When you reset a contract, all actions previously performed on the contract will be reverted. Roles will need to be re-selected; a new contract package will need to be added and a system generated comment will be added to indicate that the contract was reset and by whom.

• A task can be built off the 'Reset' or 'Cancel' action by building a trigger on the 'Comment Type' drop down under the Contract>Search by selecting the value of 'Reset' or 'Cancel'. This should be used in tandem with the Added Within (Days) filter.

• In order to maintain the integrity of dependent/facilitating contracts and active relationships in the system, a contract cannot be canceled without first cancelling/terminating or denying dependent contracts. If there are dependent contracts, the user will be presented with a pop-up to indicate which contract(s) must first be cancelled with direct links to those contract(s). The only exception is if there is a duplicate contract with the same hierarchy, the duplicate can be cancelled as it not required to support the dependency.

Example:

            Contract ID                 Hierarchy                                     Cancellation

                   5                          Carrier>MGA>Corp>Advisor      Can be cancelled anytime

                   4                          Carrier>MGA>Corp                     (5) must be cancelled first as it cannot exist without (4)

                   3                          MGA>Corp>Advisor                    (5) must be cancelled first as it cannot exist without (3)

                   2                          MGA>Corp                                  (3), (4) & (5) must be cancelled first as they cannot exist without (2)

                   1                          MGA>Advisor                              Can be cancelled anytime as it is not required to build (3), (4) or (5)

• Once the contract is cancelled, it is searchable and visible to implicated parties on the system. Similar to a denied contract, the contracting relationship between the parties will be terminated and a system generated comment will be added to indicate that the contract was cancelled and by whom. The system will not send any notifications to the parties regarding the cancellation.

• For partners using the CITS API, cancelled contracts will not be part of the feed, as these contracts serve no business purpose.

Remove a Package (Enhanced)

Bug ticket: SD-26368

• Fixed – Users can now remove a maintenance or requirement package added by mistake to an ‘Active’ contract, even if the bottom party has started to fulfill it.

• Once all of the requirements associated with the package have been completed, the package can no longer be removed.

Areas to Test

• Reset a contract at various phase of the workflow

  • Contract roles are reset

  • Contract package is removed

  • Comments are maintained

  • Reset comment is recorded

  • User Permissions work as expected

• Cancel a contract at various phases of the workflow and with different contracting hierarchies

  • Contract is cancelled

  • Dependent contracts are identified

  • Cancellation comment is recorded

  • Contract is still searchable

  • User Permissions work as expected

• Maintenance Requirement Package can be removed

  • Package can be removed when some requirements have been fulfilled

  • Package cannot be removed when all requirements have been fulfilled