Lesson 5 of 5
Testing business partner maintenance
9 min
BP tests often stop at "the record saved". That proves almost nothing. The value of a BP lies in what it lets processes do, and the risk lies in what it lets people change. A good BP test set therefore covers maintenance, controls and downstream use, and its evidence is the change history plus the process outcome.
The BP test set
| Test | What to do | Expected result and evidence |
|---|---|---|
| Create customer | Create a fleet customer with general, FLCU00 (1710) and FLCU01 (1710 / 10 / 00) data | BP saved with the right grouping; sales order, delivery and billing succeed; journal entry posts to the right reconciliation account |
| Create supplier | Create a supplier with FLVN00 and FLVN01 for org 1710 | PO, goods receipt and supplier invoice succeed for the new supplier |
| Duplicate prevention | Try to create a BP with an existing tax number and similar name | Duplicate check shows matches (if configured); procedure leads to extension, not a new BP |
| Sensitive change | Change supplier bank details as a clerk | Supplier blocked for payment; payment proposal excludes it; change documents show old and new values |
| Confirmation | Confirm as a different authorized user; try to confirm as the same user | Second user can confirm; same user cannot; next payment run pays to the new account |
| Business blocks | Set purchasing block; set billing block | PO creation fails with a block message; billing is held |
| Authorization | Order desk user tries to change supplier bank details | Not permitted |
- MaintainCreate or change the BP with the roles and data for the test
- ControlCheck duplicate check, dual control and authorizations behave as designed
- Use downstreamRun the process that depends on the data: order, PO, invoice, payment
- Inspect evidenceChange documents, block status, documents and journal entries
Downstream proof
A customer BP is proven when an order, delivery, billing and journal entry for it work with the expected values: payment terms on the invoice, the right reconciliation account in the journal entry, the right tax determination. A supplier BP is proven when a purchase order uses the expected purchasing terms and a payment run pays the right amount to the right bank account. Payment tests are best run in the test system with the payment run in proposal mode first (in SAP GUI F110, or the Manage Automatic Payments app), checking that blocked suppliers are excluded and confirmed ones included.
Plan the test data carefully. BP tests change master data that other testers may rely on, and a bank change test blocks a supplier for payment until it is confirmed. Create dedicated test suppliers and customers for control tests, name them so their purpose is obvious (for example a supplier named for the dual control test), and agree with Priya which tester owns each. Reset or document their state at the end of each test cycle so the next cycle starts from known data. Record every BP number used in the test run, alongside the document numbers it produced.
What would you do?
Priya's team tested BP creation for 20 suppliers: all saved without errors. No purchase orders or payments were run with them. The process owner is asked to sign off supplier master data. What should happen?
- Test maintenance, controls and downstream use, not just saving the record.
- Prove dual control: payment block on change, different authorized confirmer, payment proposal behavior.
- Test business blocks for what they stop and what they must not stop.
- Evidence: change documents, confirmation records, block status and downstream documents.
Check your understanding · not graded
Lesson check
1. What best proves a new customer BP works?
2. How should a payment test for a changed bank account be run in the test system first?
3. Which negative test belongs in dual control testing?
4. Which evidence shows the payment block reacted to a bank change?