SAP S/4HANA SD common mistakes
SAP S/4HANA SD · Understand the traps and how to avoid them.
Answers customer-master questions using ECC transactions and tables (XD01/XD02, KNA1/KNVV) and describes the customer as an object maintained separately from the business partner.
Most preparation material and hands-on experience comes from ECC, where the SD customer master stood alone; in S/4HANA the Business Partner is the leading object and customer-vendor integration is always active.
What to do instead
Anchor every customer answer on the BP: create and maintain with transaction BP (or the Fiori 'Manage Business Partner' app). Customer data lives in BP roles FLCU01 (Customer, which holds the sales area data) and FLCU00 (FI Customer, which holds company code data). The BP grouping controls number range and field status, and CVI maps the BP number to the customer number used in SD documents.
Creates a business partner with only the Customer role, then cannot explain why company-code-dependent fields are missing or why subsequent FI postings do not appear.
BP roles look like cosmetic flags, but each role unlocks a different data segment; SD documents only need the sales-side role, while financial postings need the FI role plus company code data.
What to do instead
Map data segments to roles: FLCU01 plus a sales area assignment, giving sales office, sales district, customer group, customer pricing procedure, shipping conditions and delivering plant for order processing; FLCU00 plus company code data (reconciliation account, payment terms) for accounts receivable. Also check partner function determination (sold-to, ship-to, payer, bill-to) on the same BP.
Investigates why an order item produces no delivery by checking the delivery relevance of the item category or the sales document type instead of the schedule line category.
Delivery relevance is controlled at schedule line level, so a schedule line category that is not delivery-relevant (for example a make-to-order or availability-check-only schedule line) blocks the item even though the item category looks correct.
What to do instead
Trace in this order: schedule line category delivery relevance, then order-to-delivery copy control at header, item and schedule line levels, then delivery item category determination (delivery type + item category group + usage). Confirm with the delivery creation log instead of guessing.
Assumes that if the order header copies to the delivery, all items will appear there, and never checks copy control at item or schedule line level.
Copy control is maintained per document-type pair at three levels; a missing or deactivated item or schedule line entry quietly drops items, and rejected or delivery-blocked items are not copied either.
What to do instead
Verify the complete document-type pair in copy control at header, item and schedule line level, and read the delivery creation log. A partial or empty delivery is a copy-control, rejection or block symptom, not a delivery-type problem.
Debugs a missing or wrong price by re-checking condition records only, without verifying which pricing procedure was determined.
The pricing procedure is found from sales area plus customer pricing procedure (from the BP sales area data) plus document pricing procedure (from the sales document type); if that combination is not maintained, no procedure is assigned and often no hard error is issued.
What to do instead
Run the pricing analysis in the document to see whether a procedure was determined at all, then check the three determination columns together. Remember the customer pricing procedure sits in the customer's sales area data in the BP, not in the condition record.
Assumes a missing condition record always raises an error, or that every condition type in the procedure is searched in access-sequence order until a record is found.
Conditions are optional unless the procedure marks them as mandatory; an access sequence stops at the first successful access, and exclusion groups or requirement routines can deactivate condition types, so a 'missing' price may be intended behaviour.
What to do instead
Read the procedure top-down for each condition type: access sequence, condition tables and their key fields, requirement routine, exclusion group. Use the pricing analysis per condition type to see which access failed and whether a condition was excluded by an exclusion group.
Expects every completed delivery to appear in the billing due list, and treats pro forma or order-related invoices as if they always posted to financial accounting.
The due list only proposes documents with an open billing status that are not blocked and, for delivery-related billing, that have the goods issue posted; the billing type settings determine whether FI is updated at all.
What to do instead
Check the chain explicitly: billing relevance of the delivery type, PGI status, billing block or credit block, billing status on the delivery, then the due list selection. Read the billing type to see whether it is a pro forma document without FI posting or a real invoice.
Answers that an incorrect invoice is corrected by changing or deleting the billing document.
Posted billing documents are financial documents: change restrictions apply to relevant fields, and a document that generated an accounting document cannot simply be deleted.
What to do instead
Use VF11 to create a cancellation invoice with a reversal reason and date, which reverses the FI document and restores the billing status of the source documents. A credit memo is a separate billing type for commercial corrections, not a substitute for cancellation.
When delivery creation fails on shipping point determination, looks in the delivery type or in the customer's general data instead of the actual determination inputs.
The shipping point is derived from shipping conditions (BP sales area data) plus loading group (material master plant data) plus plant (order item); a missing loading group or shipping condition breaks the chain.
What to do instead
Check in order: plant on the order item, loading group in the material's plant data, shipping conditions in the customer's sales area data, then the determination table entry for that combination. Confirm the resulting shipping point has the route and lead-time data needed for scheduling.
Treats post goods issue as a purely SD step, so cannot explain why PGI is refused or why stock is reduced but no accounting document appears.
PGI creates a material document and an FI document; it needs available stock, a determinable storage location and MM account determination, plus serial numbers or handling units where relevant, so any missing piece blocks or incompletely posts the goods issue.
What to do instead
Diagnose by symptom: refused PGI points to stock or availability, storage location, serial numbers, credit or delivery block; a material document without an FI document points to MM account determination (transaction keys such as BSX and GBB) and to period or fiscal year status. Note that billing revenue accounts come from a separate determination (VKOA).