Integrating Paper Confirmations
The following functions are available for integrating paper confirmations:
• | Generation of PDF confirmation with QR code (based on MsgId) |
• | Integration of any PDF confirmation received in Calypso: PO confirmation or Counterparty confirmation |
• | Indexation of Incoming Confirmation with PO confirmation if possible based on QR code |
• | Enrichment of the Incoming Confirmation |
• | Identification of Process Issues |
• | Matching Manager: Side by side view, Insert PO’s signature and resend the confirmation to the counterparty (depending on cases) |
These functions allows performing the following scenarios:
• | Bilateral Confirmation. Confirmation are exchanged, each party of the trade send his own confirmation. Confirmation received is Counterparty confirmation. |
PO receives the counterparty confirmation by fax or email (PDF confirmation in attached file) and reconciles it with its own confirmation.
• | Unilateral Confirmation/ PO sender. PO sends the confirmation generated to the Trade Counterparty. Confirmation received from Counterparty is PO confirmation returned signed. |
PO generates and sends the confirmation. Counterparty has to return it signed for approval. A QR Code is inserted in the footer of each page of the confirmation. It is the matching key.
• | Unilateral Confirmation/ PO receiver. PO does not send any confirmation, confirmation received is Counterparty confirmation. |
PO has to verify and send back the Counterparty confirmation with its authorized signature(s). PO generates a confirmation to create a BO Message and BO Matchable Object.
1. Setup Requirements
1.1 Domains Values
Domain "PDF.PageNumber": Value = true.
Default is false.
Domain "QRCode.Pdf": Value = true.
Default is false.
Domain "messageType":
Value = CountersignedConfirmation
Value = IncomingPaperConfirmation
Domain "incomingType":
Value = Confirmation
Comment = IncomingPaperConfirmation
You can run Execute SQL with the file "<calypso home>/client/bin/dbscripts/core/PaperSchemaData.xml
" to add the following domain values, or add them manually:
Domain | Value |
---|---|
formatType |
PaperConfirmation Ⓘ [NOTE: Make sure that Comment = application/pdf to specify the MIME type] |
paperFormat | |
PaperConfirmation.ActivateGenericCommentSave | true |
MatchingContext | Paper |
MatchingContext.HandlerName | Paper |
paperConfirmation.sendHeader | DefaultCoverPage.html |
paperConfirmation.sendMessageType | CountersignedConfirmation |
1.2 QR Code
The PO generates and sends its confirmation with a QR code. The QR code is inserted automatically to all PDF paper confirmations. The QR code is always present but only used as matching key for scenario "Unilateral Confirmation/ PO sender".
• | QR code corresponds to the Message Id |
• | QR code is inserted on each page of the confirmation, by default on bottom left footer |
You can modify the default behavior by adding the following domain values:
The values can be:
• | TOP_LEFT |
• | TOP_RIGHT |
• | TOP_CENTER |
• | BOTTOM_LEFT |
• | BOTTOM_RIGHT |
• | BOTTOM_CENTER |
The values can be:
• | AllPages |
• | FirstPage |
• | LastPage |
• | FirstandLastPage |
1.3 Outgoing Message Confirmation Setup
Make sure that the format the outgoing message confirmation is PDF.
Example:
1.4 Outgoing Message Confirmation Workflow
Example of outgoing trade confirmation workflow: Message type = Confirmation.
Specifically, to handle scenario "Unilateral / PO Receiver", on VERIFIED-AUTO - PROCESS-ACKED - UNMATCHED transition, we generate a BO Message which is eligible for Matching (creating a Matchable Object), but this confirmation is not sent to the Counterparty. PO has to countersign the counterparty confirmation.
You can set the attribute “watermark” on the outgoing confirmation to recognize that case.
You can also use the static data filter
1.5 Countersigned Confirmation Message Workflow
Example of Counterparty confirmation countersigned workflow. Message type = CountersignedConfirmation (DV).
1.6 Incoming Paper Confirmation Message Workflow
Example of Incoming message workflow. Message type = IncomingPaperConfirmation.
Static data filter DuplicateIssue:
1.7 Matching Context
You need to define a matching context with Context Type = Paper and Handler = Paper.
2. Integration Process
You can import paper confirmations using the Import Message engine or using the scheduled task MESSAGE_MATCHING.
2.1 Using the Import Message Engine
The Import Message engine manages the integration of the incoming message from email or fax.
We have 1 advice for 1 BO Message:
• | 1 BO Message / 1 Advice corresponding to the confirmation: fax excluding the front page, 1 email attachment – N email attachments create N BO Messages. |
• | 1 generic comment attached to the BO Message corresponding to the front page or the email body. |
Property File
The Import Message engine requires a property file named "Calypso_paperconf_config.properties
".
Sample property file:
jms.modetypeclass=org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url=queue provider URL
jms.url=queue provider URL
jms.queue.connectionFactory=ConnectionFactory
input.queue.name=queue name
FROM_MAIL_TO_CALYPSO.queue.ackType=auto
FROM_MAIL_TO_CALYPSO.queue.transacted=true
FROM_MAIL_TO_CALYPSO.queue.persist=true
Standard Format
We provide a standard format (XML) to integrate in the ImportMessage queue.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PaperConfirmation>
<base64representation>representation of the pdf file in base 64</base64representation>
<contact>sender@contact.com</contact>
<contactType>EMAIL</contactType>
<fileName>No FILE</fileName>
<format>pdf</format>
<receiver>receiver@contact.com</receiver>
<receiverType>EMAIL</receiverType>
<textMessage>body text of fax or email</textMessage>
</PaperConfirmation>
Engine Configuration
You can configure the Import Message engine using the Engine Manager in Web Admin (name PaperConfirmationImportMessageEngine, class com.calypso.engine.advice.ImportMessageEngine
).
Set the attribute Config = PaperConfirmation
2.2 Using the Scheduled Task MESSAGE_MATCHING
You can also use the scheduled task MESSAGE_MATCHING to import the confirmation manually.
Task Attributes:
• | ExternalMessageType - PaperConfirmation |
• | Paper Format - pdf |
• | Paper Contact Type - Contact Type of the sender. |
• | Paper Contact - Contact Value corresponding to the contact type above – Manual entry. |
• | Paper Text Message - Body message of the fax or email – Manual entry. |
• | Paper Receiver Type - Contact Type of the Receiver. |
• | Paper Receiver - Contact Value corresponding to the contact type above – Manual entry. |
2.3 Process Details
When integrating Incoming Messages, the following checks are performed:
• | If we cannot find a Contact mapped with a legal entity: |
– | Sender not recognized: message attribute “ProcessIssue=SenderUnknown” |
– | Receiver not recognized: message attribute “ProcessIssue=ReceiverUnknown” |
• | If the QR Code is readable, we automatically index with an outgoing message and propagate to enrichment fields: the PO, the Trade Counterparty and the product type. |
If the QR Code is not readable, message attribute “ProcessIssue=QRCodeUnreadable”
If the QRCode is not an integer, message attribute “ProcessIssue=QRCodeNotUsable"
• | If the message is integrated several times with the same QRCode, “ProcessIssue=Duplicate” |
[NOTE: Setting the trade keyword 'Send Date' to retrieve the sending date of the message Linked ID in the confirmation template.
3. Matching Manager
3.1 Case where QR Code is Readable
This case correspond to scenario "Unilateral / PO sender".
• | Incoming message is linked to 1 Outgoing message |
• | AMEND/CANCEL case, confirmation generated by Calypso, New Message Id + MessageLinkId (and then QR Code modified) |
Initial Outgoing message unmatched or under investigation: action Supersede to move in another status (“DISCARDED” for instance)
At integration, as QR code is readable, Incoming message is enriched automatically with message attributes which correspond to matching keys.
Example:
PO generates and sends confirmation with QR Code.
The Counterparty will confirm by sending it back with its signature. At integration, the QR code is recognized. Both messages move automatically to mismatch status. You need to manually match the messages using the Matching Manager, see below.
When QR code is recognized, all message attributes are set by default on the BO message of the incoming: Trade Id, PO, Trade Counterparty, Product Type, Product Sub Type, Trade Date
In this example, incoming message id 209005 is matched with Outgoing message id 208528.
Body Message of the fax or email is stored as a Generic comment / Text Message Comment Type.
In Matching Manager:
Outgoing and Incoming are linked and moved automatically to mismatched status.
You can click to open a side by side view to compare both confirmations. Even if the messages have been linked automatically, you need to check:
• | If there is no manual comment(s) added on the confirmation |
• | The authorized signature(s) |
3.2 Case where QR Code is Unreadable
If the QR Code is not readable, an exception is raised for the message with message attribute Process Issue = QRCodeUnreadable.
According to the Message workflow, you can enrich the BO message using the action ENRICH. It brings up the Enrich Incoming Message window that gives you the possibility to enrich matching keys. The * identifies the mandatory fields to be enriched, in order to be eligible on matching.
Mandatory Enrichment: PO/Counterparty/Product type to make the message eligible for Matching. A popup window will alert you if enrichment data are missing.
Enrichment data are saved as message attributes:
The incoming message moves to ALLEGED status and is now eligible for matching.
Specifically for scenario "Unilateral / PO Receiver", the outgoing message has a watermark.
On the Incoming message, additional actions are available: insert signature with different choices, zoom in and zoom out, remove the signature.
You can also send chaser messages as needed.