Configuring Picking Relevance, Storage Location Determination, and PGI Posting Logic
Explains how picking relevance, storage location determination, and PGI account posting are configured and how they interact at delivery item level.
Explanation
Configuring picking and PGI behavior correctly requires understanding three interlocking configuration areas: delivery item category control, storage location determination, and automatic account determination for goods issue postings. Each of these determines whether, where, and how a delivery item can be picked and posted. First, picking relevance is controlled through the delivery item category, which is derived from the sales document item category and the delivery document type combination. Within item category configuration for deliveries, a field controls whether the item is relevant for picking. Items such as standard stockable materials are picking relevant, while text items, value-only items, or certain service items are typically not. This setting works together with the goods movement status group, which determines whether the item participates in inventory-relevant PGI processing at all. Consultants must check both settings together: an item can theoretically be goods-movement relevant without being picking relevant (e.g., very simple storage locations where confirmation and PGI are effectively combined into a single confirmation step), though in most standard scenarios the two go together for stock items. Second, storage location determination decides which storage location supplies the delivery item, which directly determines where stock will be reduced at PGI. Standard determination logic typically considers a combination of shipping point, plant, and storage condition (or a similar rule table), sometimes layered with a picking storage location determination rule that considers the combination of shipping point and plant only, or plant and storage condition. If no explicit rule matches, the system falls back to the storage location maintained in the material master's plant-specific sales/plant data, when available. Getting this determination wrong is one of the most common production defects: deliveries pointing to the wrong storage location either fail at PGI due to zero stock, or worse, post correctly but distort inventory visibility across warehouse zones, causing replenishment planning errors upstream. Third, PGI account determination follows the standard automatic account determination logic used broadly in MM/FI integration: it uses a combination of chart of accounts, valuation grouping code, account modifier tied to the movement type (typically differentiating normal goods issue from cancellations or free-of-charge goods issue), valuation class of the material, and transaction key (commonly the goods issue key associated with the movement type, often referred to by its transaction key such as GBB with account modifier VAX or VAY depending on whether the assignment is order-related or delivery-related without a cost object). Correct configuration here ensures that when PGI executes, it automatically debits Cost of Goods Sold and credits Inventory using the right general ledger accounts without any manual intervention, keeping the process touchless from a finance posting perspective. Beyond these three areas, intermediate consultants should also understand delivery split and batch determination interplay: if automatic batch determination is active for the material, PGI cannot proceed until a batch is determined and picked (either manually or automatically), and storage location determination must be consistent with where that batch physically resides. Similarly, partial picking (confirming less than the full delivery quantity) is allowed depending on configuration and will cause the delivery item to reflect an under-delivery, which downstream billing configuration must be able to handle (e.g., billing based on picked/goods-issued quantity rather than originally requested quantity). Understanding these dependencies is essential before touching the actual account or storage configuration nodes, because a change in one area (like tightening storage location determination) can silently break processes that depend on flexibility elsewhere (like partial picking across multiple locations).
Real project scenario
During an S/4HANA Private Cloud implementation for a distribution business with multiple storage locations per plant (bulk, fast-pick, and quality-hold areas), the initial storage location determination rule defaulted every delivery to the bulk storage location regardless of the picking area actually holding fast-moving stock. This caused repeated PGI failures for high-velocity SKUs that were physically stored only in the fast-pick area. The consulting team implemented a refined determination rule based on shipping point and storage condition, tagging fast-moving materials with a distinct storage condition indicator in the material master, which corrected automatic determination without requiring manual storage location overrides by warehouse staff.
Common mistakes
• Configuring storage location determination rules without validating against actual physical inventory distribution across locations, causing false PGI stock-shortage errors. • Assuming a picking-relevant flag alone controls PGI eligibility, while ignoring the separate goods movement status group setting. • Hardcoding a single storage location in the material master as a fallback and then forgetting to update it when a business adds new storage areas. • Misconfiguring account modifiers for goods issue movement types, leading to postings hitting the wrong Cost of Goods Sold or inventory account. • Not testing partial picking and its interaction with billing quantity rules, resulting in billing document creation errors after partial PGI.
Best practices
• Validate storage location determination rules against real physical stock distribution before go-live, not just master data theory. • Keep account determination configuration reviewed jointly with FI/CO teams since it directly affects P&L postings at PGI. • Document which item categories are picking relevant versus goods-movement relevant in a single reference table for support teams. • Test partial picking and batch determination scenarios explicitly in UAT, since they frequently surface only under real warehouse conditions. • Avoid overly rigid storage location rules that block legitimate multi-location fulfillment for the same material.
Interview angle
Interview questions at this level often ask candidates to explain how the system decides which storage location a delivery item draws stock from, and how that connects to the accounting postings at PGI. Strong candidates can name the layered fallback logic conceptually (shipping point/plant/storage condition based rules, falling back to material master storage location) without over-specifying exact SAP transaction codes, and can explain automatic account determination in terms of valuation class, movement type, and transaction key rather than only naming table names. Ability to connect a configuration decision to a downstream operational failure (like PGI stock shortages) demonstrates practical project experience.