Inventory Management uses this process in such a way that the goods issue posting is divided into two parts that run in separate systems. Posting the GI document in the supplying plant results in a message to the receiving plant. The receiving plant then performs a complementary posting. The physical goods receipt takes place as usual.

When using batch processing, the following prerequisites must be fulfilled:

• Both the original and target systems have the same batch definition level.
• The batch definition level is either the material or the client.
• An ALE scenario exists for materials and classes (characteristics).
• Unique batch numbers exist cross-system.
• Batches can only be changed in their original system when they are not decoupled. From an organizational point of view, this must also lead to the batch status being changeable in a local SAP R/3 system. For example, this is impossible when transfer posting to a new batch and results in further actions, for example, relabeling containers, palettes and so on.

• Stock change transfer price to stock
• Internal expense to internal sales
• Internal clearing account to stock change transfer price.

• Account determination in a purchase order for an intra-company-code transaction must be different from account determination in external transactions. Automatic GR/IR account clearing is required in both one-system and two-system situations.
• The stock in transit must be visible in the receiving profit center.
• The system must send a shipping notification at goods issue in one-system and two-system situations.
• You need to create an invoice document for the internal and external trading statistics for cross-boundary deliveries as well as for customs purposes.
• GR/GI slips are created.

The delivery triggers the goods issue in the issuing system.

The call contains the stock transport order data known in the delivery, including the PO item and the logical system of the recipient.

The transaction (quantity and value updates) is selected using the movement type:

You determine the movement type according to the schedule line category in Sales and Distribution. The goods issue for a cross-system stock transfer must be different from the integrated transaction. This is achieved by adding a new movement type.

You post quantities and values at goods issue in the same way as a goods issue for a sales order. That is to say, the quantity is posted in the supplying plant and the value is adjusted to that of the stock account. The offsetting posting is made to a clearing account. The known data from the delivery is copied to Accounting to balance the account where necessary.

The system creates a message to the appropriate receiving system for all items with reference to a cross-system purchase order. The system does not perform any validity checks on the recipient’s data before posting begins. Incorrect Customizing results in the update being terminated.

If a goods issue has receiving plants in different logical systems, an IDoc is sent for each system.

In order that the goods receipt is able to use the values on the receiver side, you must add the values used to post the goods movement, in particular the transfer prices, to the IDoc.

The logic for recognizing the profit center switch functions as follows: At goods issue, the system recognizes that the profit center of the issuing plant is different from the profit center of the receiving plant. The system derives the profit center node from the relevant profit center.

The IDocs sent by the issuing plant trigger the goods issue postings in the receiving plant.

The goods receipt is posted in the receiving system using the IDoc. The interface receives the data from the goods issue in the supplying plant. The following processes now run at the recipient:

• The system finds the update control for the GR part of the posting.
• The goods movement is posted with the new movement type.
• During valuation of the goods receipt, the system might, where necessary (UB logic), refer to the values (legal value and the value from the parallel valuation type, if you are using the transfer price function) from the IDoc.
• The PO history is updated. The PO history is updated with the material document number from the second part of the GI posting. The GI document number is not stored in the supplying plant, because there is no way to display this document.
• In two-step procedures the goods receipt is posted to the stock in transit.

You can only reverse this goods issue for the PO using the cancellation transaction in SD. You cannot reverse the GI in Inventory Management.

The material document that is automatically created in the receiving system cannot be canceled. This reversal is triggered by the sending system (the actual reversal of the GI document takes place there) and transmits the data, including the reversal movement type, to the receiving system. No actual reversal is posted in the receiving system, because the material document number of the original document does not exist in this system. This scenario is applicable for cases where you use the two-step procedure (with stock in transit).

The shipping notification is required in the receiving system due to its relevance for MRP. In this way, for example, a change in delivery date determined at goods issue is sent to the receiving system using the shipping notification. The shipping notification can also be used when posting the GR batches.