Lesson 3 of 6
Checkpoints at boundaries
9 min
Listen to this lesson
An end-to-end test that only checks the last screen is a test you cannot debug. If Contoso's supplier invoice does not post, the failure could sit in any of eight steps across three systems. A checkpoint is an objective, observable proof taken at a hand-off: something any tester can look up and confirm without asking the person who did the previous step.
Good checkpoints come in three kinds. A document checkpoint proves that the expected document exists with the expected values: purchase order created, delivery created, goods receipt posted. An interface checkpoint proves that a message left or arrived and was processed: the IDoc reached a success status, the integration flow completed, the inbound message created its document. A financial checkpoint proves that the accounting effect is right: the journal entry exists, the amounts and accounts match expectations, the GR/IR account clears.
| Document checkpoint | Interface checkpoint | Financial checkpoint | |
|---|---|---|---|
| Proves | The expected document exists with the expected values | A message left or arrived and was processed | The accounting effect is right |
| Contoso P2P-01 example | Goods receipt posted against the inbound delivery | Inbound invoice message created the supplier invoice | GR/IR for the PO item nets to zero |
| Evidence | Document number and status | Message or IDoc number, final status, document created | Journal entry numbers and amounts versus expected |
Procure-to-pay with an external supplier portal
Contoso orders rotors CMC-RTR-200 from Lakeside Components through a supplier portal. Purchase orders leave SAP S/4HANA, pass through SAP Integration Suite and reach the portal; the supplier's confirmation, shipping notification and invoice come back the same way. The flow below marks each boundary.
- Purchase orderBuyer in purchasing group 001 creates the PO for plant 1710; output is triggered.
- Outbound messagePO sent as an IDoc or API call, mapped in SAP Integration Suite, delivered to the portal.
- Supplier confirmationLakeside confirms date and quantity; the inbound message updates the PO confirmation.
- Shipping notificationInbound message creates an inbound delivery for storage location 171A.
- Goods receiptWarehouse posts the receipt against the inbound delivery; inventory and GR/IR are updated.
- Supplier invoiceInvoice arrives from the portal and is posted or parked against the PO.
- PaymentPayment run pays the open item; the bank file goes out.
| Hand-off | Checkpoint | Where to look | Pass evidence |
|---|---|---|---|
| PO → output | Output record processed successfully | Output overview of the PO | Output status successful, timestamp |
| SAP → middleware | Outbound IDoc passed to port, or API call accepted | WE02 / WE05, or the outbound log | IDoc number and success status |
| Middleware → portal | Integration flow completed | SAP Integration Suite: Monitor, Integrations and APIs | Message ID, status completed |
| Portal → SAP (confirmation) | Inbound message posted, PO confirmation updated | WE02 / BD87, or AIF monitoring | Inbound IDoc status, PO confirmation tab |
| Portal → SAP (notification) | Inbound delivery created | Inbound IDoc, then document flow of the PO | Inbound delivery number |
| Receipt → finance | Material document and journal entry | Material document display, accounting documents | Inventory and GR/IR amounts equal PO quantity times PO price |
| Portal → SAP (invoice) | Supplier invoice posted, not just received | Inbound IDoc or AIF message, then invoice display | Invoice document and journal entry |
| Payment → bank | Open item cleared, bank file created | Payment run log, supplier line items | Clearing document, file reference |
Checkpoint table for Contoso P2P-01. Each row is one hand-off.
Interface checkpoints in practice
For IDocs inside SAP S/4HANA, WE02 and WE05 display IDocs by date, direction, message type and status, and BD87, the status monitor for ALE messages, groups them by status and lets an authorized user reprocess them. Learn the status texts your interfaces reach on success; for many inbound IDocs the success status is 53, "application document posted," and 51 means the application document was not posted. Do not treat "IDoc received" as a pass. The checkpoint is the business document it was supposed to create.
Where interfaces run through SAP Application Interface Framework (AIF), /AIF/ERR (Monitoring and Error Handling) shows messages per interface with their logs, and /AIF/IFMON (Interface Monitor) gives the overview. In SAP Integration Suite, the Monitor area shows message processing per integration flow; how much step detail you see depends on the log level set for the flow. SAP Cloud ALM Integration & Exception Monitoring can correlate messages across components and search by a business attribute such as an order number, provided the component exposes that attribute.
Remember that most interfaces are asynchronous. A message can sit in a queue, wait for a batch job, or retry several times before it fails for good. Write the expected timing into the checkpoint ("inbound delivery exists within 30 minutes of the portal confirmation") so a tester knows the difference between "not yet" and "failed." Also decide who is allowed to reprocess a failed message during a test. Reprocessing in BD87 or AIF can be the right fix for a temporary error, but it must be recorded; a scenario that only passed after a silent reprocess has a hidden defect.
- Did the message arrive within the expected time?Yes → next · No → not yet or failed? Check the queue, the job and the retry status
- Did it reach the success status, such as 53 for many inbound IDocs?Yes → next · No → status 51 or an error means the application document was not posted
- Does the business document exist with the right values?Yes → next · No → fail; "IDoc received" is not a pass
- Was it reprocessed to get there?No → pass · Yes → record who reprocessed and why; investigate the hidden defect
Reconciliation closes the loop
The last checkpoint in any chain should be financial. For P2P-01, the goods receipt and the invoice should net to zero on the GR/IR account for that PO item, and the supplier line item should be cleared by the payment. For an order-to-cash chain, the billing document should have its journal entry, and the receivable should clear when the payment arrives. A process that "worked" but leaves an open GR/IR balance has a defect.
Write the expected values before the run, not after. If Contoso orders 200 rotors at an agreed price, the tester should know in advance the inventory value the goods receipt should post, the invoice amount including tax, and the payment amount after any cash discount. Comparing actual against expected is what turns a reconciliation into a test; reading the numbers afterwards and deciding they "look right" is not. The same applies to order-to-cash: for Great Lakes Fleet Services, write down the expected net value, tax, revenue account and receivable before Maria creates the order.
- Expected values writtenInventory value, invoice with tax and payment after discount for 200 rotors, before the run
- Goods receiptDebits inventory, credits GR/IR at PO quantity times PO price
- Supplier invoiceDebits GR/IR, credits the Lakeside payable
- GR/IR checkNets to zero for the PO item; an open balance is a defect
- PaymentClears the supplier line item; amounts compared with expected
- A checkpoint is objective proof at a hand-off that any tester can look up.
- Use document, interface and financial checkpoints; end every chain with reconciliation.
- An inbound message counts only when it has created or updated the business document.
- Record the document or message number and status at every boundary as evidence.
Check your understanding · not graded
Lesson check
1. An inbound invoice IDoc exists in WE02. Is the invoice checkpoint passed?
2. Which transaction is the status monitor for ALE messages?
3. What is the best final checkpoint for Contoso's procure-to-pay chain?
4. What does SAP Cloud ALM need in order to find a message by order number?