AFPO table — Production Order Item Table

One row in AFPO represents one item of a production or process order, identified by order number and item number. For a standard discrete production order there is normally a single item, POSNR 0001, describing the material to be produced, its plant, the planned order quantity, and the unit of measure. Process orders can carry multiple items when co-products or by-products are configured, each getting its own POSNR. AFPO also carries the goods receipt quantity accumulated so far, the storage location and batch the receipt is expected to go into, and, for make-to-order or project stock scenarios, the link back to the originating sales order item. It does not hold operations, components, or costs; those live in separate order tables joined through the order number.

Always restrict on MANDT and, in almost every real query, on AUFNR or a range of AUFNR built from AUFK selection first, since AFPO on its own has no date or plant-only entry point that is selective enough. Selecting by WERKS and MATNR alone scans every order ever created for that material in that plant, which on a mature production system is a large and slow read. If the requirement is to find orders for a material, go through AFKO or a status-based selection first and use AFPO only to pull the item quantities and batch once the order number is known. Do not assume POSNR 0001 always exists in isolation without checking the header status, a technically completed or deleted order still leaves its AFPO row in place.

Symptom: the goods receipt for a production order looks smaller than what was confirmed on the shop floor. Selection: read AFPO for the order number and item, compare WEMNG against PSMNG to see the received quantity versus the planned quantity, then cross-check AFRU for the same AUFNR to see the confirmed yield quantity. A gap between AFRU confirmed quantity and AFPO WEMNG points to a goods receipt that was never posted or was posted with a quantity variance, not a confirmation problem.

AFPO remains a standard transparent table in S/4HANA with essentially the same structure and role it had in ECC. There is no compatibility view replacing it for general use, and custom reports built against AFPO continue to work. What changes in S/4HANA is more the surrounding process, since order creation and confirmation flows are increasingly exposed through Fiori apps that write to the same underlying tables, so the data in AFPO is unchanged even where the transaction used to create it looks different.

Production planning and shop floor control own questions about AFPO content, since order quantities, batches, and storage locations are PP configuration and master data outcomes. Where KDAUF and KDPOS are involved, the sales order link is a joint question between PP and SD, because the demand that created the order originates on the sales side.

AFKO is the order header AFPO always joins to for dates, order type, and status. AFRU carries the confirmations posted against the order and item. RESB, reached via the header reservation number, holds the components. MAST connects the order material to its bill of material. Orders are created and changed through the standard production and process order transactions, and confirmed through the shop floor confirmation transactions, all of which write to AFPO indirectly through the order framework rather than by direct table update.