Submit new product ideas for Watson Supply Chain solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.
Connect with users and IBM experts on the
B2B Collaboration Community
Submit ideas for other Watson Customer Engagement Products:
• Watson Marketing
• Watson Campaign Automation
• Watson Commerce
SWIFT De-Envelope splitting of good vs bad transactions
Product or Service: Sterling B2B Integrator 5.2.4
Component ID: 5725D0600
Operating System: Linux
PMR to support RFE raised for SWIFT Envelopes
When you define SWIFT/ISO20022 Envelopes (MX) you are able to define business processes that are triggered in the event of a compliance issue with an incoming file. The way that this works when a compliance error is found in an individual transaction is that the entire file/batch of transactions are rejected and are processed with the
error handling business process. This is entirely at odds and
inconsistent with the way in which the industry uses SWIFT/ISO MX
messages. Most clients would want only the non-compliant transactions to be processed by the error handling business process and that good transactions would be allowed to continue processing. B2B Integrator handles other standards in this manner where documents that fail compliance checking are treated differently from those that are compliant.
SWIFT was implemented in SI using the generic (de)enveloping services which only has an outer and an inner layer envelope. SWIFT just uses a single envelope containing a single message which is treated as a transaction.
MX messages will have different elements that customers may want to
split into groups and/or transactions. This would require a change to
the enveloping and compliance checking to enable customers to choose what to do, i.e.
i - Reject the whole file/batch batch if one or more transactions are
ii - Reject only the non-compliant transactions - good transactions are
allowed to be processed.
The implication is that an individual transaction which may be low
value may prevent processing of a much higher value transaction.
How will this idea be used?
What is your industry?
What is the idea priority?
Link to original RFE