VD51 — Create Customer-Material Info Record

VD51 creates a customer-material info record: a link between one sold-to customer, one sales organization and distribution channel, and one material, storing the customer's own material number (KDMAT), order unit, delivery priority, default shipping plant, minimum delivery quantity and a partial delivery indicator. The structural fact that causes most confusion is that this record is entirely optional. Nothing in standard order processing requires it. It only comes into play when the customer's material number is used to identify the material, most commonly on inbound EDI orders and IDoc-based order creation, or when someone explicitly wants a customer-specific default for delivery priority or partial deliveries. Consultants coming from a materials-master mindset sometimes assume it is required master data comparable to a customer master record extension; it is not, and its absence is silent, not an error, unless something downstream is coded to demand it.

Reached for during customer onboarding when the customer will send orders referencing their own material numbers, typically via EDI, IDoc, or a customer portal that captures the customer's part number rather than the vendor's. Also used when a specific customer needs a different shipping plant than the material's default, a different delivery priority than the sales order type default, or a permanent partial-delivery agreement recorded at the customer-material level rather than negotiated order by order. Not used for pricing (that is condition records via VK11) and not used for general customer master extension (that is XD01/XD02). If the customer never quotes their own material number and needs no per-material shipping override, this record is simply never created and nothing breaks.

Run SE16 on table KNMT filtering on KUNNR (sold-to), VKORG and VTWEG, and either MATNR or KDMAT depending on which direction the mismatch is suspected. If an inbound EDI order failed on material determination, take the exact customer material number from the IDoc segment and search KDMAT for that literal string, checking for leading zeros, case, and trailing spaces, since KNMT lookups are exact-match. If the record exists but the order still failed, check the sales org and distribution channel on the record against the sales area actually used on the order; a record maintained for the wrong distribution channel will not be found.

The customer-material info record and VD51 behave the same way on S/4HANA as on ECC; the underlying table and the logic that reads it during order and IDoc processing are unchanged. There is no distinct Fiori app in common use that replaces this transaction; mass maintenance is more often handled through upload tools or the classic transaction rather than a redesigned UI. Consultants should not expect a functional change here between releases.

Functional SD master data ownership, usually sitting with the order-to-cash or master data team rather than a dedicated basis or ABAP concern. A clean handover for an EDI mapping failure includes the exact customer material number as it arrived in the IDoc segment, the sales area used on the order, and a screenshot or SE16 extract confirming whether a matching KNMT record exists.

VD52 is the change transaction for the same object and is where most day-to-day corrections happen once a record already exists. XD02 and the customer master maintenance path are worth reviewing to understand the boundary between customer-wide data and this sales-area-and-material-specific record. VA11 is a useful next stop to see how the info record's defaults actually surface, or fail to surface, in inquiry and order creation. VK11 is worth comparing against as a structurally similar but functionally distinct master data object, since both are keyed combinations that default values into the order but neither is mandatory.