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

If a contract (e.g. an import L/C) has to be changed detrimentally for the beneficiary, the beneficiary has to accept this amendment, otherwise it is not effective. These types of amendment are, for example, reductions of amount and maturity or changing the description of goods, that describe a better quality or a tighter/additional inspections. Usually the foreign bank forwards the request of amendment to the beneficiary, but does not have to make sure, that an acknowledgment actually has to be returned. Normally, the beneficiary has coordinated the amendment with the importer beforehand and thus there is no need for him to send an acknowledgment again, so that usually no acknowledgment is returned. According to the currently valid rules and for this kind of acknowledgments of amendments, there are no deadlines set, so that usually with the next presentation of the documents an implicit acceptance for the amendment can be identified.

In order to complicate these circumstances, additional amendment requests can be submitted after an amendment request to be confirmed, but before the explicit or implicit confirmation of the other party has been received.

A big challenge in handling such amendment is, that the underlying contract cannot be changed without the confirmation has been received. Thus, on each additional amendment of the contract the bank clerks have to be informed, that there are, for example, unconfirmed amendment requests available.

Within the scope of an amendment request, the incoming information can be subdivided in two main areas. On the one hand there is information, that can be mapped directly to certain fields and on the other hand there is automatically processable information, for example, amount changes or new maturities. These information is transported via SWIFT into separate field tags and can therefore be processed automatically. Otherwise there are unstructured freetext information that, for example, describe in plain text in a SWIFT field tag, how the contract is to be changed. These freetext information can contain arbitrary data (e.g. specifications for replacing specific paragraphs in the good's description or additional conditions). In contracts waiting for confirmation, the way to implement these freetext information is a problem that cannot be solved, as the basic contract, into which the texts are to be implemented, cannot clearly be identified.

In order to achieve a formally correct representation in such a situation and which can also be handled smoothly in case of rejection, the following solution solutions are implemented in the application:

1. Amendments, that do not require confirmation of the other party and which is received when no confirmation is expected, are processed in the amendment transactions (xxxAME transactions). The respective amount, liability and text changes are done within the contract and the new state is stored instantly.

2. Amendments, that do require confirmation or normal changes, that are to be processed, if a confirmation of the other party is expected, are processed via the request of amendment transactions (xxxRAM transactions), which register a respective xxxAME transaction.

3. On every additional modification under a contract that is waiting for a confirmation from the other party (where a not yet closed xxxRAM transaction is still pending), the user is notified, that an unconfirmed request of amendment is at hand.

4. If, for example, the implicit confirmation or the rejection is identifiable at the presentation of the documents, the clerk can quickly process the actual amendment in advance by taking up the pending xxxAME transaction or he can notify the other party about the rejection of the amendment request via a common message. Subsequently, the currently present transaction (in this case the presentation of the documents) is processed.

4.1. In the event of confirmation the structured data fields as well as the one unstructured freetext of the original amendment request are inserted in the respective fields of the xxxAME transaction. Thereby the structured amendment information is automatically stored in the respective target fields. The distribution of the freetext information (where required) to the respective text fields for the description of goods, the documents, etc. is processed not until now when handling the xxxAME transaction, as now the underlying status is definitely clear.

4.2. In the event of rejection a common message transaction (xxxFRE transaction) has to be handled instead of the registered xxxAME transaction. This can be done by re-routing the registration to xxxFRE and subsequent taking-up of the registration or via manual start of the xxxFRE transaction and deleting the registration manually.

4.3. Where an incoming message is received from beneficiary advising his acceptance/rejection, the said message can be rerouted in SPTROU to xxTFRE (in case of rejection) or to xxTATT (in case of acceptance), to store the incoming message. In case of acceptance, the user can pick up the registered xxTAME transaction to process the amendment. While in case of rejection, take up the rerouted xxTFRE, to process the common message and delete the auto registered xxTAME. When rerouted to LxTFRE, the correspondence type is defaulted to 'Acknowledgment' to send a MT730 with tag 72 being defaulted with the codeword /BENREJ/ or a letter equivalent with the same content.

5. In the context of sent amendment requests in an amendment (via xxxAME or xxxRAM) it can easily be pointed out (in case this is required in the specific installation), that there are still pending amendment messages. However, the underlying contract is not yet stored, i.e. neither the amounts and the date fields are changed, nor the desired textual changes have been incorporated into the contract.

6. The outcome of this is, that each amendment request, even if it is rejected, is counted in the application and an amendment number will be assigned to it. The work and the handling of an amendment has been coming up, even if the request of amendment was rejected by the other party.

This means, that the actual work of incorporating a complex amendment into an L/C is NOT done after receiving the amendment, but the incorporation of the amendments (especially into the texts) is done not before the amendments have been accepted. An important side effect of this procedure is, that even if multiple amendments are on the way and not all of them will be accepted but some will also be rejected, each single amendment can be accepted and updates the contract. It is also important, that the updating/storing of the contract needs to be traceable and clear. The messages that have been created in the meantime will never contain not yet accepted (and possibly subsequently rejected) numbers or texts.

In this case, however, it has to be considered, that must be pointed out in external correspondence, that there exist pending amendments, as long as pending xxxRAM requests exist.

When an existing Export L/C is linked to a Transfer L/C or a Back-to-Back L/C, the amendment of the master L/C may lead to an amendment of the transfer L/C or Back-to-Back L/C. This is supported in the application by the following:

• When linked to a Transfer L/C, upon saving of the transaction Advise an Amendment an auto-registration is automatically stored for the transaction Request of Amendment if the triggering transaction under the export L/C was also a detrimental amendment (i.e. Request of Amendment).
• If the triggering transaction under the Export L/C was a LETAME (Advise an Amendment), then an auto-registration is stored for the transaction Amending.

• When linked to a Back-To-Back L/C, upon saving of the transaction Advise an Amendment an auto-registration is automatically stored for the transaction Request of Amendment if the triggering transaction under the export L/C was a detrimental amendment (i.e. Request of Amendment).
• If the triggering transaction under the Export L/C was a LETAME (Advise an Amendment), then an auto-registration is stored for the transaction Amending.

Any amendments to the contract amount are intentionally not copied into the Transfer L/C or the Back-To-Back L/C. When picking up the auto-registration, amount changes in the parent contract will be listed in the “unmapped fields” and can then be copied manually by the user.