Watson Supply Chain Ideas

Use this form to submit an idea for a new product feature. The product team will review your input and provide status updates as decisions are made regarding the request.

Before you submit a new idea, please view requests that have already been submitted. If your idea has already been submitted, you can add comments or vote on the existing idea, thereby indicating your agreement with the idea. We may use this information to help prioritize development of new features.


Submit ideas for Watson Marketing and Watson Commerce products

SWIFT De-Envelope splitting of good vs bad transactions

Problem Details

Product or Service: Sterling B2B Integrator 5.2.4
Component ID: 5725D0600

Operating System: Linux

Problem title
PMR to support RFE raised for SWIFT Envelopes

Problem description
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
deemed non-compliant
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.
  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Dec 19 2017
  • Uncommitted Candidate
How will this idea be used?
What is your industry?
What is the idea priority? Urgent
DeveloperWorks ID DW_ID46910
Link to original RFE http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=46910
  • Attach files