Documentation - DOKA-NG (Functional availability is per selected plan)

“Temporary Settlements” are completely advised settlements of the application, stored permanently and to be used later as a basis for a definite (final) settlement.

Preliminary settlements are prepared using the Default “Settlement” Panel. In the upper part of the settlement panel, it is defined whether the settlement in question is preliminary ('temporary') or definite ('final'). The selection of the settlement type applies to all settings made on the panel (own and third-party fees/commissions), irrespective of the role in question. For instance, it is thus not possible to carry out a direct settlement to a party within a preliminary settlement. A preliminary settlement is always assigned to a contract and may involve a number of parties.

The following example from daily banking practice is intended to explain the concept of preliminary settlements:

SWIFT distinguishes between an MT n90 (Advice of Charges) and an MT n91 (Request for Payment of Charges). The n90 is sent to the account holder by the bank managing the account and contains the charges that are directly charged or credited to the account holder.
The n91 is used to request the payment of fees from the receiving bank, i.e. the sending bank informs the receiving bank of the fees incurred and provides particulars in n91 as to where the funds are to be transferred.

Both messages can be generated in the business transactions “Fee Settlement” (xxTFEE) available in each business sector. In the fee settlement transaction, the field “Settlement Type” is blank and to be edited. The user may choose between a final and a temporary settlement.

In the case of a final settlement, 'Settle now' ('X')' is suggested as a possible disposition. If selected, the data recorded defaults to a booking line in the 3rd grid of the settlement panel and, if there is a direct account (disposition type 'DAD'/ 'DAC'), a settlement message is generated on the Message Panel. If the recipient has a BIC and an Authenticator, then an n90 will be generated. Genuine posting entries are generated when processing a final settlement. This can also be identified, for instance, by the posting entries being reflected in the customer account and the bank's income accounts on the Booking Panel.

If the user selects settlement type 'temporary', then instead of the disposition 'Settle now' the disposition 'Settle temporary ('S')' is proposed. The booking line in the 3rd grid of the Settlement Panel contains the reference 'temporary' in red letters, and a settlement message in the form of an n91 is generated on the Messages Panel if the receiver has a BIC and an Authenticator. In the case of an n91, the sending bank therefore issues the receiver with an invoice containing all settlement information and showing in what way this “invoice” is to be paid. This information is displayed to the settlement party in message format; the actual posting to the accounts only occurs at the time of the final settlement.

Own or third-party fees included in a preliminary settlement can optionally be advised (disposition 'Advise now') or only noted internally (disposition 'Store in Pool'). The latter are saved to the fee pool. Fees advised are fixed elements of the final settlement and can only be settled with a final settlement generated in the process. Internally noted 'Pool' fees can be settled independently at any time.

Another example of a temporary settlement can be found in the transactions “Send, Accept and Settle Documents” in the field of export and import documents and in the transactions “Accept and Settle Documents” in the field of export and import collections.
If the set of documents is a 'usance' set of documents, then a temporary settlement is also generated for the above mentioned transactions when the documents are taken up. This serves to provide the receiver with all settlement information as early as when the documents are taken up, even if the final settlement is made on maturity at a later date. The output of settlement information is made in the outgoing messages.
When the set of documents is settled on maturity, the temporary settlement is taken up and finally processed. Only then are the actual posting entries generated along with the relevant payment messages (e.g. an MT400 or an MT756).

One more example for temporary settlement is in Settling a Clean Payment in outgoing clean payment. In case a payment has to be recorded/booked but requires some additional authorization for final settlement of payment. Then a temporary settlement can be booked, which does not generate any payment messages and also no accounting entries are booked. Upon receiving the additional authorization, final settlement can be booked, which generates the relevant payment messages and also accounting entries are posted/booked.

Access to the preliminary statements at a later date is effected using transaction Temporary Settlement Selection from the menu. In this transactions, temporary settlements can be displayed, selected or deleted.

When starting a transaction which can load final settlements (is defined in the transaction profiles in Maintaining Entity Group Transaction Profiles (DBIETP), it is checked whether a temporary settlement is available for the current contract. If applicable (not yet settled) temporary settlements are found, a message is displayed, inquiring whether this/a temporary settlement is to be taken up. If the message is confirmed, this temporary settlement will be taken up directly. If the message is not confirmed, the transaction will be started without the taken-up temporary settlement.

In technical terms, the picked up settlement serves only as a “Template” for the final settlement. All data in the old settlement might be modified. Which of the old data is really changeable or will be re-defaulted and which of the old data has to be settled exactly as entered in the temporary settlement is defined in the installation-specific logic.

If a temporary settlement is picked up and a final settlement is created from it, the processing data of the temporary settlement (SEP) stored under a contract is actually stored. Nevertheless, a repeated pick-up is possible. This function is required if a party (on maturity of the contract) wants to finally settle a possible financing falling due with the other parties.

If no lines are created in the Settlement table, then the system displays a warning and the temporary settlement cannot be saved.

Temporary settlements are also displayed in the Info system transactions. A table with the temporary settlements (SEP) stored under a contract will be displayed in the panel “SEP Info” in that case.