Lesson 4 of 5
Document flow and downstream verification
9 min
Listen to this lesson
Each step in an SAP process creates or changes a document. Many also cause something to happen somewhere else: a goods issue posts to finance, a billing document sends an invoice to the customer, a goods receipt updates the purchase order history. These are integration points, and the documents they produce are where you prove the step really worked. A success message tells you a document was saved. It does not tell you the downstream result is right.
Marking integration points
When you read a process for testing, mark every step that produces a result outside its own document. Ask three questions: does it change stock, does it post to accounting, and does it send or receive anything to or from another system or partner? Each yes is a downstream check your test case needs.
- Does the step change stock?Yes → check the material document and stock overview · No → go on
- Does it post to accounting?Yes → check the journal entry accounts and amounts · No → go on
- Does it send or receive anything to or from another system or partner?Yes → check the output or message status and its content · No → the saved document is the result
| Step | What you see on screen | Downstream result to verify | Where to look |
|---|---|---|---|
| Create sales order | Order number saved | Price, tax, schedule line and credit status as expected; confirmation output sent | Order display; output status |
| Post goods issue | Delivery status changes | Stock reduced in plant 1710; journal entry for cost of goods sold at standard cost | Material document; its accounting document |
| Create billing document | Billing number saved | Journal entry with receivable, revenue and tax; invoice output to the customer | Document flow; accounting overview; output |
| Post goods receipt | Material document number | Stock increased; inventory and GR/IR posted; PO history updated | PO history; accounting document |
| Post supplier invoice | Invoice document number | Payable to Lakeside Components; GR/IR cleared; payment block if variance | Invoice display; journal entry |
Using document flow
SAP links documents into a chain. From a sales order you can display the document flow (in SAP GUI from VA03, or with the Display Document Flow app) and see the delivery, goods issue, billing document and accounting documents beneath it, each with a status. From a purchase order, the purchase order history in ME23N lists goods receipts and invoices. These are the tester's best tools for checking downstream results quickly, and for finding where a chain stopped.
Write the downstream checks into the test case as expected results, with values. Not "journal entry created", but "journal entry in company code 1710 debits cost of goods sold by $7,500.00 (50 × $150 standard cost) and credits finished goods inventory". Not "invoice sent", but "invoice output to Great Lakes Fleet Services in the agreed channel with the fleet contract number". Specific expected results turn a walkthrough into a test.
| Step | Vague expected result | Specific expected result |
|---|---|---|
| Post goods issue | Journal entry created | Company code 1710 debits cost of goods sold $7,500.00 (50 × $150) and credits finished goods inventory |
| Create billing document | Invoice sent | Invoice output to Great Lakes Fleet Services in the agreed channel with the fleet contract number |
| Post goods issue | Stock updated | Unrestricted stock of CMC-ALT-100 in plant 1710 falls by 50 |
Working out those values in advance is part of test design, and it often finds defects before anyone runs the test. When Priya calculates the expected revenue for a fleet order and finds the design document does not say whether the fleet discount applies before or after the freight surcharge, she has found an ambiguity that would otherwise surface as an argument during UAT. Ask the process owner, write the answer into the expected result, and the test becomes a check of an agreed rule.
Interfaces count too
Some downstream results leave SAP entirely: an electronic invoice to a customer, an advance shipping notice to a carrier, a payment file to a bank. Treat each as an integration point with its own check: did the message leave SAP, did the partner system receive it, and did it contain the right data? In test systems these partners are often simulated, so record which ones were real.
Downstream checks also include status changes on earlier documents. After goods issue, the sales order's delivery status should show the item as fully delivered; after billing, its billing status should show it as billed. A predecessor that still shows open work after its successors exist points to a partial quantity, a split or a copy control setting that did not behave as designed.
What would you do?
A Contoso tester's evidence for the billing step shows the message that billing document 90001877 was saved, and the test is marked passed. Opening the document flow, Priya sees no accounting document under the billing document. What is the right call?
- Integration points are steps whose results appear outside their own document: stock, accounting, output, interfaces.
- Ask of each step: does it change stock, post to accounting, or send or receive anything?
- Use document flow and PO history to check downstream documents.
- Write downstream checks as specific expected values.
- A success message proves a save, not a business result.
Check your understanding · not graded
Lesson check
1. In an order-to-cash test, which check best proves the billing step worked end to end?
2. Which step produces a journal entry for cost of goods sold?
3. Where can you see the goods receipts and invoices posted against a purchase order item?
4. Which is the better expected result for goods issue of 50 alternators at $150 standard cost?