Technical overview
The duplicate transaction case flow uses different flow, section, data page and data transform ruleset changes to bring a case to resolution.
DuplicateTransaction section
The DuplicateTransaction section adds a dynamic layout, which includes the Duplicate Transaction List section and a system message for displaying duplicate transactions. You configure the DuplicateTransaction section in the dispute matrix for the Duplicate transaction dispute reason, and the section contains both the editable read-only views. The DuplicateTransactionMain section displays the grid and the system message, and the duplicate transaction review view displays the selected duplicate transaction.
The following figure shows a sample table configuration in the DuplicateTransaction section.
D_GetDuplicateTransList data page
The D_GetDuplicateTransList data page fetches duplicate transactions using a report definition that finds the duplicate transactions by using the match criteria of transaction date, amount, recipient email, and confirmation number.
The following figure shows a sample configuration of the D_GetDuplicateTransList data page.
DuplicateTransactionRF flow
The DuplicateTransactionRF flow defines the flow that you use to resolve the case if a duplicate transaction is identified, or not found.
If a duplicate transaction is not found, then the case is resolved as Resolved-NoAction. If a duplicate transaction is identified, the system looks for a possible offsetting credit. If a credit is found, it is displayed in the Credited transaction review view, in which the user can review all credited transactions. If a corresponding credit is found, then the case is resolved as Resolved-CreditFound. If no credit transaction is found, then the case is routed for more research and final case resolution.
The following diagram shows an example of the DuplicateTransactionRF flow.
FinalCaseResolutionDupTran flow
The FinalCaseResolutionDupTran flow defines the flow for final case resolution with resolution choices of Resolved-Credited or Resolved-NoError. If the resolution outcome is to refund the sender, the case is resolved as Resolved-Credited, and accounting entries are triggered. If the outcome is that no error was made by the bank, the case is resolved as Resolved-NoError.
The following diagram shows a sample flow of the FinalCaseResolutionDupTran flow.
PreCustomerInterview and MapAdditionaDataQnA data transforms
In the PreCustomerInterview data transform, the MapAdditionalDataQnA data transform is called to map the transaction information on the questionnaire page, which loads the duplicate transaction list. The MapAdditionalDataQnA data transform references the D_GetDuplicateTransactionList data page.
The following figure shows a sample configuration of the PreCustomerInterview data transform rule.
PostCustomerInterview_DupTran data transform
The system runs the PostCustomerInterview data transform rule to map the selected duplicate transaction details to the selected DuplicateTransaction property.
The following figure shows a sample configuration of the PostCustomerInterview data transform rule.
Previous topic Zelle case workflow for duplicate posting Next topic Rules for when customers report duplicate posting