How termination and termination requests work

Reasons on the contract

Table names carry the installation's own prefix in the database. The reasons of the contract form are stored in contract_term_reason_link (contract + reason unique; clause_ref, defaulting to the master clause; custom_text). Placeholders: {immediate_termination_reasons}, {termination_reasons}, {termination_clause_refs}.

Recording

1. Kind (termination_type): ordinary, immediate, mutual. Terminating party (terminating_party): principal, agent, both; for mutual it must be both, otherwise it is not allowed.
2. The end date cannot precede the notice date; only an active contract can be terminated.
3. For immediate termination, if the contract has selected reasons, at least one is required and only from those; on a legacy contract without reasons one of the built-in breach reasons (confidentiality, off-market, false data, unauthorised action, lack of cooperation, other).
4. A snapshot of the reasons goes into contract_event_reason (clause, name, text in the document language).
5. Effect: on the end date the contract becomes inactive, the brokerage rows end with reason terminated, the data room access closes; with a future date the rows end at the latest on the end date.
6. Document: termination template, one-sided (two-sided for mutual), document centre role termination.

Termination request

A request from the data room is stored in contract_event as event_type = termination, request_status = requested, with requested_by_user_id; it does not end the contract. In the admin the "Process" button opens the termination form (prefilled through the request_id parameter); after saving request_status = processed, processed_event_id, processed_by, date_processed. A further possible value is rejected. A request is not an event: the event list skips it.

Permissions

contract/contract + terminate, core modify permission and content scope. For the data room request the broker receives the document/dataroom + terminate function from the contract.