LB12 — Change Posting Change Notice in Classic WM

LB12 changes an existing posting change notice, the WM document that is generated whenever an Inventory Management posting change (batch reclassification, stock type change, blocked-to-unrestricted, and similar) requires a corresponding physical move of stock between bins, storage types or storage units inside the warehouse. The PCN carries no stock movement by itself - it is a request document. The structural fact that explains most confusion around it: a posting change notice is stored as a category of transfer requirement, using the same header and item structures as an ordinary transfer requirement, and it only becomes a real movement once a transfer order is created against it, either manually or by a background job. LB12 can change quantity, storage unit, target storage type or target bin, but only while the PCN is still open. Once a transfer order already exists for it, the PCN is effectively locked from a movement perspective and editing it through LB12 changes nothing that will actually happen on the floor.

LB12 sits between the moment an Inventory Management posting change is posted and the moment a transfer order is created for the resulting warehouse move. It is reached for when a PCN points to the wrong destination bin, the wrong storage type, or carries a quantity that does not match what should physically move, and the correction has to happen before the transfer order is generated - either by a background job that periodically converts open PCNs, or manually via a transfer order creation transaction. It is not used to correct a movement that has already been executed; at that point the fix is on the transfer order or through a new posting change, not on the original PCN. LB12 is used far less often than the equivalent create and list transactions, because most PCNs are converted automatically within minutes and rarely sit open long enough to need correction.

In SE16, pull LTBK for the PCN number and warehouse number to confirm document category and status (open vs converted). Cross-reference LTBP for the same document number to see the destination storage type, bin and quantity that were saved. Then check LTAK/LTAP filtered on the reference field pointing back to the transfer requirement number - if a transfer order already exists there, the change made in LB12 will not be reflected in LQUA. Finally compare the quantity on LTBP against the originating MSEG line to confirm IM and WM are not out of step.

Classic WM, including LB12, is unchanged functionally on S/4HANA where classic WM is still in use for a given warehouse. There is no dedicated Fiori app for changing a posting change notice; the GUI transaction remains the entry point. Warehouses that have migrated to embedded EWM do not use LB12 at all - the equivalent correction happens on the warehouse task or posting change process inside EWM, which is a structurally different object model, not a renamed version of the PCN.

Functional WM problem in the first instance. ABAP involvement is only needed if a custom BAdI or user exit is determining the destination storage type or bin automatically and producing wrong proposals. Basis involvement is limited to checking the schedule of the background job that converts open PCNs into transfer orders. A good handover includes the PCN number, warehouse number, whether a transfer order already exists against it, and the originating material document number.

LB11 is the create transaction for the same document and is the natural starting point for understanding what fields exist before troubleshooting a change. LB10 lists open transfer requirements and is the fastest way to find a PCN number when it is not already known. LT01 is where the correction actually has to go once a transfer order already exists against the PCN. LS24 confirms current bin stock to check whether the movement described by the PCN has actually happened. LX02 is useful when the underlying discrepancy turns out to be a stock inconsistency rather than a document error.