Lesson 3 of 5
Running P2P end to end, including exceptions
12 min
End-to-end execution means one business transaction flows through every step, with the real roles, in the right order, and every hand-off is checked. For Contoso that means a requester, a purchaser, an approver, a receiving clerk, an accounts payable clerk and a payment run, each played by a tester with the business role that person will have in production.
Preconditions
- Master data: Lakeside Components as a business partner with supplier roles for financial accounting and purchasing, purchasing info record with price $42, source list if used, rotors CMC-RTR-200 with purchasing and accounting views for plants 1710 and 1720.
- Organization: company code 1710, purchasing organization 1710, purchasing group 001, plants and storage locations 171A and 172A.
- Configuration transported and frozen for the cycle; MM and FI periods open; number ranges available.
- Test users with production roles, including an approver for the workflow and a user without approval rights for negative tests.
- Output going to a test mailbox, never to Lakeside's real address; payment files going to a test bank channel, never to the real bank.
- RequesterRequisition for 1,000 rotors, plant 1710, delivery in two weeks; released, since it is over $10,000
- PurchaserConverts to PO 4500000201 at $42; PO goes into approval
- ApproverApproves in My Inbox; output to the test mailbox
- Receiving clerkPosts goods receipt for 1,000 into 171A
- AP clerkEnters Lakeside's invoice for $42,000 with reference to the PO
- Payment runProposal, review, payment; payment document and test file
Capture evidence at every step
The test log for an end-to-end case is a chain of document numbers: requisition → PO → material document → invoice document → payment document, plus the journal entry for each posting. Record each number when it is created and check the expected results for that step before moving on. If step 3 is wrong, steps 4 and 5 are testing on a broken foundation.
| Step | Document | Evidence to keep |
|---|---|---|
| Requisition | 10000456 | Item details, follow-on PO number |
| Purchase order | 4500000201 | Approval history (approver, time), output log |
| Goods receipt | 5000000488 | Material document, journal entry, stock before/after |
| Supplier invoice | 5105600123 | Invoice document, journal entry, payment block field, due date |
| Payment | 1500000077 | Payment proposal list, payment document, cleared supplier item |
Evidence chain for P2P-02. Document numbers are fictional.
Exceptions are where defects hide
Happy paths usually work by the time user acceptance starts. Exceptions do not. Contoso runs these exception flows end to end, not as isolated steps:
| Exception | How to trigger it | What to check |
|---|---|---|
| Approval rejected | Approver rejects PO 4500000202 with a reason | PO not output; purchaser notified; PO can be changed and resubmitted |
| Price block | Invoice at $43 per rotor | Invoice posted with payment block; not paid; released after confirmation; paid next run |
| Quantity block | Invoice for 520 after receipt of 500 | Blocked; resolved by credit memo or further receipt; then released |
| Return to supplier | Return PO for 30 defective rotors (returns item), goods return, credit memo | Stock -30; credit memo reduces the payable; GR/IR consistent |
| Service with entry sheet | Service PO for maintenance; entry sheet created and approved; invoice | Invoice refers to the approved entry sheet; expense on the cost center |
| Duplicate invoice | Enter Lakeside's invoice with the same reference twice | Warning or error from the duplicate invoice check as configured |
Exception flows run end to end.
Returns follow the BMK pattern SAP Learning describes: in the basic variant the return PO uses a standard PO type with the returns item indicator set, the goods return is posted against it, an outbound delivery is optional, and the credit memo is entered with the supplier invoice app. An advanced variant uses its own order type with a mandatory outbound delivery. Test the variant Contoso configured, not both.
- Day 1Requisitions and POsHappy path and approval cases; rejections
- Day 2ReceiptsFull, partial and return receipts in plants 1710 and 1720
- Day 3InvoicesMatched invoices, variance invoices, duplicate attempt, credit memos
- Day 4Releases and servicesBlock releases; service entry sheets and service invoices
- Day 5Payment run and reconciliationProposal, payment, GR/IR and supplier balance checks
When a step fails
If a step fails, stop the chain there. Log the defect with the document numbers created so far, the expected and actual result and the user and role that ran the step. When the fix arrives, rerun from the failed step with fresh documents where possible, and rerun earlier steps only if the fix touched them. Record which documents belong to the failed run and which to the retest, so the evidence chain stays readable. Do not repair test data by hand to keep going: a manually corrected receipt or invoice hides exactly the behavior the test was supposed to prove.
What would you do?
On Day 5 the payment proposal includes the price-blocked invoice from P2P-04, which nobody has released yet. What should Priya's team do?
- Run P2P end to end with the real business roles, checking each step before the next.
- Keep the evidence chain: every document number and journal entry.
- Run exceptions end to end: rejections, blocks, returns, services and duplicates.
- Route test outputs and payment files to safe test channels.
Check your understanding · not graded
Lesson check
1. What makes a P2P test end to end?
2. What is the evidence chain for an end-to-end P2P test?
3. In the basic return to supplier variant, how is the credit memo entered?
4. A blocked invoice appears in the payment proposal. What should the tester do?