Overview
- The benefits of detecting inbound duplicate transactions are shown in the following list.
- Avoid double posting.
- Increase customer satisfaction.
- Avoid costs.
- Reduce analyst labor.
- Reduce research and adjustments.
- Reduce risk.
- Reduce liability.
- Track historical data.
- Determine from where and from whom duplicates are coming.
- The benefits of preventing outbound duplicate transactions are shown in the following list.
- Avoid reputation damage and extra fees.
- Higher trading partner satisfaction.
- Avoid costs.
- Reduce analyst labor.
- Reduce research and adjustments.
Administrators and business analysts can use a browser-based administration console to access Duplicate Detect without special client software. Cultural preferences for time zones, dates, and language are configurable, so users can be in multiple locations or geographical ares from the product installation location. Console features are provided for business analyst tasks along with typical user and product administration. The business analyst reviews potential duplicate documents and views reports, while the administrator sets up users, grants permissions, and configures runtime properties.
Applications or components, which are checking to determine whether a document that is being processed is a duplicate, send a message that contains key information about the document to Duplicate Detect. Messages can contain information on an individual document or a group of documents as a unit of work (UOW). Duplicate Detect compares the information to document messages that were already processed. An administration console provides access for configuring Duplicate Detect and for the business analyst to evaluate potential duplicate documents.

Applications that check for a duplicate document send a Duplicate Detect XML message to the Duplicate Detect inbound JMS queue. The message contains key metadata about the document to be checked, for example, account number, routing number, and dollar amount. Duplicate Detect receives the message and compares the message contents to previously processed messages. If the key metadata matches a previously processed message, the document that is represented by the message is identified as a potential duplicate. A status message is sent back to the JMS queue of the originating client. An administration console allows the business analyst to retrieve the images for the potential duplicate document and the previously processed document. After the analyst determines whether the document is a duplicate, a reply message is sent to the originating application.
The criteria for the document formats that are allowed for a namespace is determined by a common set of key criteria. Each client is able to extract from the document. Supplementary element values are specific to each document format. Supplementary element names are the same in a namespace for all formats in the namespace. But, the interpretation of the values by the business analyst is specific to the document format that is being reviewed. To aid client development, a Java™ SDK provides the client with the necessary utilities for creating and reading the Duplicate Detect messages. A Payments namespace sample, provided with the product, can be modified or used as a template for creating other namespaces.
Namespace definitions are captured in a Duplicate Detect namespace XML document that is stored in the Duplicate Detect database. Each namespace has its own set of database tables for storing the key values specific for that namespace.