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.