This is the application's global settlement module. If the settlement module is to be added to a given transaction, this checklist is to be used .
The settlement consists of three tables (grids). Each of these tables is managed by two modules: SETxxG contains the subpanel and everything needed to administer the subpanel; SETxxL contains the gridlines and everything needed to administer individual gridlines.
These tables are:
SETFOG/L: external fees to be settled with an external party and then to be billed directly to our customers
SETFEG/L: our fees charged to a single party
SETGLG/L: amounts to be booked
The Settlement module evaluates data from the whole business transaction. Under certain circumstances even associated fees may be claimed, depending on the availability of given messages, for example (only when a letter is issued is postage billed). For performance reasons, therefore, the Settlement module has its own special maintenance operations. Neither default values nor single lines from defaults should be used in Settlement maintenance.
If the whole Settlement is to be recalculated, the “AssertSetmod” rule is to be launched. Normally this rule is posted. “AssertSetmod” settings are made using “AddToPostQueue”.
Each Settlement module contains one or more MAC fields and each of these fields contains a checksum for all of the module's relevant incoming fields. If data contained in these fields is amended, only then is the relevant part of the settlement recalculated by executing the appropriate Recalc…-rules in that module. MAC fields are filled using default rules for the field.
SETMOD itself contains a field MACTRN. This can be filled using default values from business transactions. If the content of MACTRN is changed, the whole settlement is recalculated regardless of whether single incoming MAC fields have been changed, or not. Wherever possible, rules from business transactions should not retrieve data directly from “AssertSetmod”, instead a default for MACTRN should be used. This ensures that the settlement is only recalculated when relevant data has actually been amended.
Defaulting in the Settlement panel is carried out using rules whose names begin with “RegisterSettlement”. “AssertSetmod” automatically calls these rules in descending alphabetical order. Top of the list is “RegisterSettlementZZZ” from SETMOD itself, followed by “RegisterSettlementXX” from SETxxD modules available for each business sector and finally “RegisterSettlement” from the business transaction itself. Other “RegisterSettlement” rules have to be allocated with the relevant suffixes so that they can be sorted in the right order.
Normally, “RegisterSettlement” determines:
The methods to be called in RegisterSettlement are mostly located in SETMOD with the prefix “set”. The most complete list (including functions created in overlays) you get in TRADE2 module explorer. The methods are commented with active comments holding the function and arguments of the method. This info can be viewed as hint when moving over the rules in the rules section of the module explorer.
In the next sections some of the rules are described with the usual registersettlement rules they are called from.
Functions, that are usually called from RegisterSettlement in business transactions. :
| Function | Description |
|---|---|
| SetDspFlg | Defines the scheduling of the settlement. |
| SetDocAmt | Defines the document currency and the document amount in the settlement. |
| SetGlgDocAmt | Books the document amount - both sides by launching a function |
| SetGlgAmt | Books an amount to the general ledger (GL) of the settlement in order to settle fees |
| SetDspPolDft | Defines the default scheduling for the pool entries. Only required, if not 'D' (i.e. pool entries are advised as soon as possible) |
| SetmodSetRolCorFlg | Defines the appropriate flag for a role. If a 'non-empty value' (content, that is not empty) is defined, no settlement message is created, even if correspondence is available. It is usually used in 'RegisterDocument' functions. |
| SetCorChaFlg | Defines the correspondence fees flag (was formerly DFTDOCEOTFLG). “SetCorChaFlg” controls whether correspondence fees are settled in the respective transaction or not. It is called via a non-empty value and no correspondence fees are predefined (see “SETFEG.RegisterSettlementCorrCha”). In the following transactions no correspondence fees are predefined: xxxADD, xxxCAN (if 'Send Message' is empty), xxxCOM and PATxxx. |
| SetPtyBasics | Defines party info for the settlement. “PtsChgAssert” sets us (OWN) and the parties of the main contract in the settlement. If further parties should be available, “SetPtyData” is to be used in “PtsChgAssert”. |
| SetPtyAvbMt | Defines available MT message in the 'Payment' panel for a file (if the party is available in the settlement). |
| SetPtyAvailableRoles | Removes all parties, that are not OWN and where “ArgrolAllow” is not available in the roles in the settlement. Via subsequent calls of “SetPtyBasic”, new roles can be added later on. |
| SetPtyActPtaInr | Defines the party for predefining the account (if the party is available in the settlement) |
| SetPtyAddFepPtyInr | Defines an additional party, for which the roles take over the payment of the fees (if the party is available in the settlement). |
| SetPtyGllPty | Re-defines the role of a party whose fees are being paid by another party. |
| SetRolDspMdyFlg | If this function is set, all fees retrieved from FEP have to be settled in this transaction. |
| IsFeeCodSettled | Checks whether the fee FEECOD has bee defaulted before for the contract. The function is used for the fee defaulting. |
| SetSkipOpnChk | Switches off the check function comparing settlement amount with the open amount for the contract. |
Functions that are usually launched from 'RegisterSettlementXX' in any sector:
| Function | Description |
|---|---|
| SetConAmt | Defines the contract amount in the settlement |
| SetOpnAmt | Defines the open amount in the settlement |
| SetMaxAmt | Defines the maximum amount in the settlement |
| SetAmmAmt | Defines the maximum amendment amount in the settlement |
| SetAmeAmt | Defines the nominal amendment amount in the settlement |
| SetCliSetOpt | Defines the customer disposition option for the settlement |
| SetForSetOpt | Defines the disposition option of the foreign parties in the settlement |
| SetFeeCorRol | Defines the fee correspondent role in the settlement |
| SetFeeCliRol | Defines the fee customer role in the settlement. |
| SetChaTo | Defines the default role for the fees |
| SetFecRefDat | Sets the reference date for reading conditions |
| SetPtyGllPty | For parties that are copies of other parties (e.g. PRB), the fees of the original party are transfered to the settlement of the party used. This is a common method to reflect the party model from main to child contract as well as grouping roles on one side from our position together. |
| SetForSgn | 1 = foreign fees are added to the document amount -1 = foreign fees are subtracted from the document amount |
Some of them (those not changing in the runtime of the transaction) like SetForSgn are called from InitTransaction.
Functions that are usually called from the main modules (from InitTransaction or RegisterSettlementZZ:
| Function | Description |
|---|---|
| SetFepPntLev | Defines the number of the superordinated levels, for which the fee pool records are to be read. |
| SetRefDat | Defines the reference date for the settlement |
| SetMatDat | Defines the maturity date on which the settlement has to take place. It is usually called only in “liaallsettransaction” from LIAALL. “ArgMatDat” is the maturity date of the settled maturity. |
| SetAdditionalContract | Adds “Arggrp” to the predefined fee pool of the contract. Old fees are only possible for contracts with INR. |
| setFeeDirFlg | Defines the rule for allowing to settle the own fees. |
| setXrtDat | Defines the date on which exchange rates are to be read. |
Simple fee defaulting can be done in RegisterSettlement with calls of AddFeeData. A simple example is BETPAY, where in MyModelbank the fee BEFSET is defaulted if the documents are taken up and BEFHAN, if not. Please note that the fee not to be defaulted needs to be delisted by calling AddFeeData with an empty second argument.
Another example is RegisterSettlementCorrCha in SETFEG, counting the messages to default the correspondence charges. This is a general rule working in all transactions with settlement which may be deactivated by using the function SETMOD.SetCorChaFlg(see above).
Fees with the same fee code, but different values (e.g.: there are a number of assignments, each subject to a commission), can be calculated using “\SETMOD\SETFEG.AddTrnFee” retrievals instead of “addfeedata” retrievals. “\SETMOD\SETFEG.AddTrnFee” allows more info to be passed to the fee system (e.g. the condition to be used) compared with “AddFeeData”.
A discrete entry can be made using the index of the loop in the first argument. Here count and switch are handled differently.
Examples can be found in “registersettlementLiaZZ”- Calls in LIAALL and LIASYNP. In this rule \SETMOD\SETFEG.RemTrnFeeGroup is used to cancel old fees set. Thus no special call to cancel old entries is needed.
Commissions or interest calculations depending on a liability amount are not registered in registersettlement but indirectly in LiaallSetTransaction with calls of LiaallSetFeecod.
The “GetDSPFor768” function makes it possible to determine the disposition code for fees displayed in TAG 32 and 71B for MT768. In the event of a temporary settlement of fees, fees can be displayed with the disposition code 'S'.
If the fee planning is to be defaulted as 'Pool' in the settlement and the field disabled, the following lines have to be added to “RegisterSettlement”:
SETMOD.SETCLISETOPT (“P”)
SETMOD.SETFORSETOPT (“P”)
SETMOD.SETDSPFLG (“CG”, “DISABLE”)
SETMOD.SETDSPPOLDFT (“P”, “P”, “DISABLE”)
Some SWIFT messages (e.g. MTn99) do not have standardized tags into which settlement information can be transferred from the settlement.
There are two ways of dealing with this:
Example of usage in the transaction 'Common Messages' (xxTFRE):
In “RegisterSettlement” retrieve the sub “SetmodSetRolCorFlg”. In this case, an additional MTn90/ n91 message is generated, if a SWIFT message of the type 'Free Correspondence' (MTn99) is sent.
A central rule DefaultSFTMT controls which payment messages are created and can be customized for individual customers.
If an MT400 or an MT756 is to be issued, this has to be registered from the business transaction for the settlement module.
If necessary, the related payment message which instructs the settlement of the before mentioned advice MT message, is an MT202.
If an MT400 or an MT756 is to be issued, this has to be registered from the business transaction for the settlement module.
If necessary, the related payment message which instructs the settlement of the before mentioned advice MT message, is an MX pacs.009CORE.