Configuring UD Catalogs, Code Groups, and Selected Sets
Learn how usage decision codes are structured through catalogs, code groups, and selected sets, and how this configuration drives which decisions inspectors can select and what happens afterward.
Explanation
The usage decision is not a free-text field; it is built on SAP's catalog framework, the same structure used for defect codes, causes, and tasks. Catalog type '03' is reserved for usage decisions. Within this catalog type, code groups are created to logically bundle related decision codes, and individual codes within a group represent specific outcomes such as Accept, Reject, Accept with Deviation, Accept for Rework, or Scrap. Each code carries a short text, long text, and a set of control indicators. The most important indicators are: whether the code triggers stock posting to unrestricted-use stock, blocked stock, or another movement type; whether it is flagged as usable (some codes may be deactivated after a process change but retained for historical inspection lots); and whether it requires a follow-up action such as creating a notification. A code can also be flagged so that once selected, no further changes are permitted to certain result fields, reinforcing the idea that a UD closes the inspection. Selected sets bring configuration and runtime together. Rather than exposing every code group to every inspector, a selected set filters which code groups and codes are available for a particular inspection type, plant, or material grouping. This means a raw material incoming inspection might see codes like Accept, Reject, Return to Vendor, while an in-process inspection at a different plant might see Accept, Rework, Scrap — even though both draw from the same underlying catalog type '03'. Selected sets are assigned in configuration and can also be influenced by user exits or business rules for more dynamic behavior in some implementations, though core standard behavior relies on static assignment via configuration. A critical design decision is how granular to make code groups. Too few codes force inspectors into ambiguous choices and produce noisy downstream reporting (e.g., everything ending up as generic Reject). Too many codes create decision fatigue and inconsistent usage across shifts or plants. A well-designed catalog typically groups codes by decision family (accept variants, reject variants, rework/deviation variants) and keeps text short and unambiguous, often supported by long text guidance for less experienced inspectors. Another configuration point often missed is code deactivation versus deletion. Because historical inspection lots reference specific codes, codes should never be deleted once used in production; they should be deactivated so reporting and audit trails remain intact while preventing future selection. This is especially important in regulated industries where historical UD codes must remain traceable for years. Finally, catalog and selected set changes are transportable configuration objects. Changes should go through the same transport and testing discipline as other customizing, including regression testing of existing open inspection lots that may reference the old selected set assignment, to avoid inspectors suddenly losing access to codes mid-process.
Real project scenario
During a rollout to a new plant, quality engineers requested plant-specific usage decision codes distinguishing 'Reject – Supplier Issue' from 'Reject – Internal Process Issue' to improve root cause reporting. The team created a new code group under catalog type 03, added the two codes with distinct stock posting behavior (one triggering a supplier quality notification, the other an internal deviation notification), and built a new selected set restricted to that plant's incoming inspection type. During UAT, testers found that existing open inspection lots created before the change still pointed to the old selected set, causing confusion; the team documented this as expected behavior and communicated a cutover date so only new lots used the updated codes.
Common mistakes
• Deleting used usage decision codes instead of deactivating them, breaking historical traceability • Creating overly broad or overly granular code groups without analyzing downstream reporting needs • Assigning the same selected set to unrelated inspection types, exposing irrelevant codes to inspectors • Failing to test selected set changes against already-open inspection lots before go-live • Not documenting which code triggers which stock posting behavior, leading to inconsistent expectations across plants
Best practices
• Design code groups around decision families with clear, unambiguous short texts • Use selected sets to scope codes appropriately by inspection type or plant rather than exposing the entire catalog • Deactivate obsolete codes rather than deleting them to preserve audit history • Document stock posting and follow-up behavior for every active code in a central reference • Test configuration changes against existing open inspection lots, not just new ones, before transporting to production
Interview angle
Interviewers may ask how usage decision codes are structured and how you would design a catalog for a multi-plant rollout, or how you would prevent inspectors from selecting an outdated code after a process change. Strong answers reference catalog type 03, code groups, selected sets, and the deactivate-don't-delete principle for auditability.