The Functional Specification (FS / FSD) is the document a functional consultant owns: it translates a business requirement into a design an ABAP developer can build against, unambiguously. This is a complete worked FS for the tiered-pricing enhancement whose ABAP you can already read on the SAP-design page — document control, business requirement, field mapping, processing logic, message handling, authorization, test scenarios and sign-off. Every design point carries a requirement ID, and the same IDs reappear in the test table, so the whole chain from requirement to code to test is traceable end to end.
Related objects: pricing procedure config V/08 (condition ZTIR), custom scale table ZTIR_SCALE, and the revenue-account determination VKOA that receives the priced value downstream. No standard SAP object is modified.
Corporate customers buy across several related accounts (a parent and its branch “siblings”). The business wants the price tier to reflect their combined volume, not each account’s volume in isolation — and it wants to maintain those tiers itself, without a developer, every time the commercial team re-negotiates.
As-is. Standard condition records price each sold-to on its own. A customer splitting the same order across three branches lands in a lower tier on each, so they overpay versus the deal that was agreed — and disputes land in AR as short-payments and credit notes.
To-be. A pricing enhancement pools the customer’s sibling volume, resolves the correct tier from a business-maintained scale table, and returns that price to the standard pricing engine — leaving billing and revenue postings untouched.
Requirements register — click an ID to trace it through the design and tests:
Tip: the same R-tags appear on the processing steps (§4) and every test case (§7).
Trigger. The routine is called by the pricing engine during sales-document processing (VA01 / VA02) for every line carrying condition type ZTIR, via VOFM value formula 601 assigned in V/08.
Field mapping — where each value comes from and where it lands:
Processing logic — each step links to the line in the delivered ABAP:
The tier scale lives in ZTIR_SCALE, not in the ABAP. That is a deliberate call: it satisfies R3 (business maintains tiers with no transport) and keeps the enhancement thin — the code resolves and applies a tier, it never defines one.
Each scenario maps back to a requirement, and to the executed sub-unit tests and defect log on the delivered system.
This is a sample Functional Specification authored as a methodology exercise. The enhancement it describes is real — I designed and delivered the equivalent tiered, sibling-aware pricing on XeerSoft Cloud ERP — and the FS is written in the exact format an SAP project uses so it’s developer-ready. The object IDs, T-codes, RICEFW classification and test structure are the genuine SAP mechanism; the document is a proposal artifact, not a delivered SAP production object.
See the delivered track record behind it — 6 capabilities, verified →