Acknowledgments and transport

Every EDI dispute eventually asks the same question: did the partner get it? EDI answers in layers. A transport receipt proves a file arrived. A functional acknowledgment proves it could be read. Only a business response proves the content was accepted. Testers and key users who mix these up sign off flows that are not working.

Three layers of "yes"

The 997 and the 999

The 997 Functional Acknowledgment reports the result of syntax analysis for a functional group and its transaction sets. It answers group by group: AK1 names the group being acknowledged (functional identifier and group control number), AK2 names each transaction set, AK5 gives the set's result, and AK9 gives the group's result with counts. A minimal acknowledgment for Great Lakes' order group would look like this:

ST*997*0001~
AK1*PO*815~
AK2*850*0001~
AK5*A~
AK9*A*1*1*1~
SE*6*0001~

The 999 Implementation Acknowledgment does the same job with more depth: X12 describes it as reporting syntax and relational analysis against the full standard or an implementation guide subset. It is the norm for HIPAA healthcare transactions on version 005010; supply-chain partners such as Great Lakes still mostly use the 997. Both, in X12's own words, do not address the semantic meaning of the data.

CONTRL in EDIFACT

EDIFACT uses one service message, CONTRL (syntax and service report), for both jobs. The sender asks for it in UNB, or the interchange agreement requires it. Its segments report by level: UCI for the interchange, UCF for a group, UCM for a message, and UCS and UCD for the segment and data element in error. The action code says what happened:

• 8: interchange received. Only used for the optional first CONTRL that confirms receipt.
• 7: this level acknowledged after a full syntax check (and lower levels too, unless explicitly rejected).
• 4: this level and everything below it rejected.

The EDIFACT syntax rules are explicit that a CONTRL acknowledgment does not imply that the business content has been accepted, and CONTRL must not be used to report application errors.

Moving the files: VAN, AS2, SFTP

AS2 is worth understanding in detail because Contoso uses it with Great Lakes. Each side holds the other's certificate. The sender signs and encrypts the file and requests an MDN; the receiver decrypts, verifies the signature, computes a hash of what it received and returns a signed MDN that includes that hash. A signed MDN with a matching hash is strong, non-repudiable proof that this exact file arrived. On PO 7.5, the AS2 adapter and the EDI converter and separator modules come from SAP's B2B add-on for Process Orchestration; in SAP Integration Suite, the AS2 sender and receiver adapters and the AS2 MDN adapter play the same role.

Trading partner agreements usually set a time window for acknowledgments, for example a 997 within four business hours of receipt, and a window for the business response, for example an 855 within 24 hours of the 850. Middleware can report overdue acknowledgments: PO, for instance, correlates outgoing interchanges with incoming 997s by control number. An overdue 997 is an early warning, because it usually means the partner never received or could not read the file, and the business document it carries will not be processed either.

Where do acknowledgments show up in SAP? Mostly they do not: the 997 and MDN are handled and monitored in the middleware, where PO's message monitor shows functional acknowledgment status. Middleware can also report back to SAP with the STATUS message (basic type SYSTAT01), which writes statuses such as 16 (functional acknowledgment positive) or 17 (negative) onto the original outbound IDoc. Whether Contoso does that is a design decision; course sap-edi-204 returns to it.