Lesson 6 of 6
Choosing the framework and signing off EDI output
8 min
Listen to this lesson
In a converted system, "which framework?" is a design decision per application object type, and it has consequences for EDI partners. Contoso made its decision in the SD and procurement streams with Theo's team at the table, and you will likely face the same discussion.
Questions that decide it
- Does the application support the EDI channel with the message format your partners need, in your release? Check its documentation and prove it in a sandbox.
- Do you send anything by ALE today (medium A)? Output control will not carry it.
- How many partners and output types would need retesting, and can the partners test in the same window?
- Are there custom NAST programs or forms that need rebuilding?
- What is the migration plan for in-flight documents? The activation setting applies to documents by their creation, so mixed populations appear for a while.
Contoso's answer was pragmatic. Billing moved because invoices needed new email templates and Fiori output handling, and Great Lakes' 810 could be retested inside the billing test cycle. Sales documents, deliveries and purchase orders stayed on NAST because they carry Great Lakes' 855 and 856, four aftermarket customers' 855s and Lakeside Components' 850, and none of them gained anything from a switch during the conversion. The decision group recorded the split with a review date after hypercare, when the move to SAP Integration Suite forces a partner retest anyway.
Testing EDI output
An EDI output test has three parts, and each needs evidence. The determination part proves that the right documents get EDI output and the wrong ones do not: a Great Lakes order gets BA00 by medium 6, an aftermarket customer's order does not. The generation part proves the IDoc is created with the right partner, message type and content. The delivery part proves the partner received a readable file. Negative tests matter as much as positive ones: an incomplete order must not send an 855, and a changed order must send exactly what the partner's guide expects.
| Test case | Expected result | Evidence |
|---|---|---|
| Complete order for Great Lakes | One BA00, medium 6, status 1; ORDRSP IDoc status 03; 997 accepted | Output screen, IDoc number, PO message ID |
| Incomplete order for Great Lakes | No BA00 until the order is complete | Determination analysis showing the requirement |
| Order for a non-EDI customer | Print or email output, no medium 6 | Output screen |
| Delivery 80001234 goods issue | One LAVA, DESADV IDoc status 03 | Output screen, IDoc number |
| Invoice 90001877 | EDI and EMAIL items, no PRINT item; INVOIC IDoc collected and sent | Output items, IDoc number and status history |
| Order change after confirmation | Behavior per Great Lakes' guide (changed 855 or none) | Output screen, partner confirmation |
Contoso's EDI output test cases for Great Lakes Fleet Services.
What would you do?
The SD stream proposes moving sales documents to output control two weeks before go-live, so that order confirmations can use a new email template. Great Lakes and four aftermarket customers receive 855s by EDI. What should Grace's decision group do?
- Choose the framework per application object type, weighing EDI dependence against the need for new output features.
- Check EDI channel support, ALE use, partner retest effort, custom programs and in-flight documents before switching.
- Test determination, generation and delivery, including negative cases, with evidence for each.
- Contoso keeps EDI-heavy objects on NAST until the post-hypercare Integration Suite move, when partners are retested once.
Check your understanding · not graded
Lesson check
1. Why did Contoso keep sales documents and deliveries on NAST at go-live?
2. Which test proves that an incomplete Great Lakes order does not send an 855?
3. What must the sign-off evidence show for each EDI output type?