SD Sales Documents Part 5: Architecting Sales Document Landscapes — Governance and S/4HANA Migration

📌 KEY POINTS
✅ A global template should use a small canonical set of document types (standard order, rush, free-of-charge, returns, credit/debit memo request, contracts) with fixed meaning in all countries.
✅ A new document type is justified only by different control (numbering, follow-on types, checks, blocks, procedures) — not by reporting, which can use order reason or other fields.
✅ Each document type pulls a chain of dependencies: item category assignment, copy control, pricing procedure determination, output, incompletion, number ranges, authorizations.
✅ Brownfield migrations are the moment to rationalize legacy document types — mapping many legacy types to few S/4HANA types.
⚠️ Every extra type multiplies test cases and support effort in every rollout wave.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–4 covered document categories, configuration, flow and control. This part is the landscape view.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CANONICAL SET

• Template types: ZOR standard, ZSO rush, ZFD free-of-charge, ZRE returns, ZCR/ZDR credit/debit memo request, ZCQ contract, ZDS scheduling agreement.
• Same key = same behavior in every country.
• Local variations via order reason, sales area, customer data or condition types.

━━━━━━━━━━━━━━━━━━━━
▶ 2. WHEN A NEW TYPE IS JUSTIFIED

• Different follow-on documents (delivery/billing type).
• Different numbering (legal requirement), checks, blocks, incompletion.
• Different item category determination or copy control.
• Not justified: reporting, different printouts (output parameters), different approvers (use workflow/status).

━━━━━━━━━━━━━━━━━━━━
▶ 3. CONVENTIONS AND DEPENDENCIES

• Naming convention and number range plan per document category.
• Dependency matrix per type: VOV4, VTAA/VTLA/VTFL, OVKK, output, VUA2, OVAZ, PFCG.
• Change requests evaluated against the matrix.

━━━━━━━━━━━━━━━━━━━━
▶ 4. S/4HANA MIGRATION

• Inventory legacy document types with volume in the last 2 years.
• Map to canonical types; retire unused ones.
• Open documents: migrate only open orders/contracts, mapped to new types.
• Adapt interfaces (IDoc/API order type mapping) and reports.

━━━━━━━━━━━━━━━━━━━━
▶ 5. GOVERNANCE

• Design authority approves new types with a written control difference.
• Regression test suite per canonical type across order-to-cash.
• Periodic review of usage — deactivate unused types.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. List business processes and map them to canonical types.
2. For each requested exception, document the control difference.
3. Build the dependency matrix and regression tests.
4. In migration: analyse legacy usage, map, retire.

✅ CHECKPOINT: every document type in the template has a documented purpose, owner and dependency list.

A brownfield conversion found 64 sales document types in the legacy system, 23 of them with no documents in two years and 18 differing only in the printed form or a report filter. The architect mapped them to 11 canonical types, using order reasons for reporting differences and output parameters for form differences. Interfaces received an order-type mapping table during a transition period. Regression test cases for order-to-cash dropped by about 60%, and later rollout waves reused the canonical types without new custom ones.

• Creating a new document type for every reporting or printing variant.
• Letting countries define local types with different meanings for the same key.
• Migrating all legacy document types 1:1 to S/4HANA.
• Adding a type without its full dependency chain.
• No regression tests per document type.

• Keep a small canonical set with fixed meanings.
• Justify new types only by control differences.
• Maintain a dependency matrix and regression suite.
• Use migrations to rationalize legacy types.
• Review type usage periodically and deactivate unused ones.

Questions: "How would you design sales document types for a global template?", "When do you create a new document type?", "How do you handle legacy document types in a migration?"
Strong answer: small canonical set with fixed meanings, new types only for control differences (follow-on types, numbering, checks, item categories), reporting via order reasons and printing via output settings; dependency matrix and regression tests; legacy rationalization by usage analysis and mapping during migration, with interface mapping.