Configuring UD Codes, Catalogs, and Stock Posting Rules
Explains how UD code groups and catalogs are configured, how each code controls stock posting and follow-up actions, and how this configuration integrates with inspection lot origin and stock types.
Explanation
Configuring Usage Decision behavior starts with the QM catalog structure. Catalog type 03 is reserved for usage decision codes. Within this catalog, code groups are created to logically organize UD codes, typically aligned to inspection lot origin (for example, a code group for goods receipt inspections and a separate one for in-process or goods issue inspections), since the acceptable business decisions differ by context. Each code group contains individual codes such as accept, reject, accept under deviation, or scrap, and each code carries a short text and long text description that appears to end users during the decision step. The part that carries real business consequence is not the code text itself but the control indicators attached to it. In configuration, each UD code is linked to a stock posting rule that determines the target stock type: unrestricted use, blocked stock, or a movement toward scrap/quality stock retention. This linkage is what actually triggers the goods movement in the background when the UD is saved. If this mapping is incorrect - for example, an 'accept' code mistakenly configured to post to blocked stock - materials will be functionally unusable even though the decision text says accepted, causing confusion and production delays. Another configurable control is whether a UD code requires or automatically triggers creation of a quality notification. This is commonly used for reject codes: when a quality engineer selects 'reject - quality defect,' the system can automatically open a quality notification to start the CAPA (corrective and preventive action) process, pre-populated with lot, material, and vendor or work center data. This reduces the risk of a rejection being recorded without any corrective action being initiated. Some organizations make this mandatory for rejection-type codes and optional for minor deviation codes. Each inspection lot origin (e.g., 01 goods receipt, 04 in-process inspection during production, 05 goods issue) usually gets its own selected set of usable UD codes, because the business meaning of 'reject' differs: a rejected goods receipt lot might trigger a return delivery to vendor, while a rejected in-process production lot might trigger scrap posting or rework order creation. This is configured through assignment of code groups to inspection types or lot origins so that, at the UD screen, users only see the codes relevant to that lot's context - reducing user error. In S/4HANA, the underlying catalog and code group concepts remain consistent with ECC, but the UD is typically executed through Fiori apps rather than the classical GUI transaction, and the results/UD screen often shows a consolidated view of characteristic results alongside the decision entry, improving usability. Some organizations also leverage workflow-based approval for high-risk UD codes, requiring a second-level sign-off before the stock posting actually executes - this is an extension pattern built on top of standard UD processing rather than a universal standard capability, and its exact implementation approach should be verified for the specific system landscape rather than assumed. Testing UD configuration requires walking through each code group in a quality/test system: post a UD with each code, verify the resulting stock document, confirm whether a notification was created as expected, and confirm any certificate or output triggering behaves as intended. This validation step is frequently under-tested in projects, leading to post-go-live surprises during real rejections when the wrong stock posting occurs.
Real project scenario
In an automotive parts implementation, the client wanted three UD outcomes for goods receipt inspection lots: full acceptance, rejection with mandatory return to vendor, and conditional acceptance requiring engineering sign-off before use. The consulting team configured a code group specific to goods receipt lots with three UD codes, mapped 'reject' to blocked stock posting plus mandatory notification creation feeding the CAPA process, and mapped 'conditional accept' to a blocked stock posting as well, but with a required workflow step for engineering approval before a second, separate UD moved it fully to unrestricted stock. During testing, the team discovered the initial mapping of 'conditional accept' accidentally posted directly to unrestricted stock, which was caught during the stock document verification step before go-live.
Common mistakes
• Mapping a UD code's stock posting target incorrectly, causing accepted material to remain unusable or rejected material to become available • Reusing the same code group across all inspection lot origins without considering that acceptable business decisions differ by origin • Forgetting to test notification auto-creation behavior for reject codes, resulting in rejections with no CAPA trail • Not validating long text descriptions are clear enough for end users, leading to wrong code selection during time-pressured production decisions • Underestimating the effort to test every UD code and stock posting combination in a realistic test client before go-live
Best practices
• Organize UD code groups by inspection lot origin so users are never shown codes irrelevant to the lot's business context • Document and test the stock posting outcome for every UD code before go-live, not just the acceptance code • Make notification creation mandatory for reject-type UD codes to guarantee a CAPA trail • Keep UD code descriptions short, unambiguous, and consistent with how the business talks about decisions, avoiding overlapping meanings • Review UD configuration whenever new inspection types or plants are added, since posting rules may need origin-specific adjustment
Interview angle
Candidates are often asked how a UD code actually triggers a stock movement, since this reveals whether they understand configuration versus surface-level usage. A solid answer references the catalog type 03 structure, code groups per lot origin, and the stock posting control linked to each code, plus the optional automatic notification trigger for rejection scenarios. Mentioning the importance of testing each code's posting outcome before go-live signals practical project experience.