
Cross-System Stock Transfers (R/3 Purchasing, APO, R/3 Shipping)
Purpose
In this scenario,
Stock Transport Orders or delivery schedule lines under a Stock Transport Scheduling Agreement are created for the ordering plant, which are then transmitted to the supplying plant. This supplying plant is located in another R/3 system.A purchase order can simultaneously contain items with plants belonging to the same company code as the supplying plant and items with plants belonging to another company code.

Previously, you had to use document type UB (stock transport order) for stock transfers within a company code and document type NB (standard purchase order) for cross-company-code stock transfers. Now you can use any document type. You do not necessarily have to use document type UB and item category U.
SAP recommends that you use document type NB.
The following graphic illustrates the process flow for cross-system stock transfers using APO.
Prerequisites
APO
The participating R/3 systems must be assigned to a business system group in Customizing for the Advanced Planner and Optimizer (APO) via Basis Settings
® Integration ® Business System Group ® Maintain Business System Group .
If you are not using APO, no availability check and no shipment scheduling can be carried out. For this reason, the desired delivery date is transmitted to the supplying system (instead of the realistic delivery date).
Ordering and Supplying Systems (R/3)
Accounting
For further information on processes in Profit Center Accounting, see
The Process from the View of Profit Center Accounting.
The posting lines that belong together in the supplying and receiving systems are generated with the same assignment number. This allows item-exact automatic
For more information, refer to the documentation for
General Ledger Accounting (FI-GL).
Materials Management
The material master data must exist in both systems. The Purchasing data must have been maintained in the ordering system and the shipping data in the supplying system. The plant-dependent data need only exist for your own plant.
You have defined the account assignment for the transaction GBB (Offsetting entry for inventory posting) in Customizing for Materials Management under Valuation and Account Assignment
® Account Determination ® Account Determination Without Wizard ® Configure Automatic Postings:Ordering System (R/3)
The supplying plants must have been created as vendors in the ordering system.
Vendors and delivering plants that are in other R/3 systems are assigned in Customizing for Enterprise Structure under Definition à Logistics General à Define, Copy, Delete, Check Plant à Define Plants for Cross-System Goods Flow. In addition, the logical system is specified.

Please note that the supplying plant is not assigned in the vendor master record.
In the ordering system, a delivery type is assigned in Customizing for Purchasing under Purchase Order à Stock Transport Order à Assign Delivery Type/Checking Rule.
A customer master record is assigned to the ordering plant in Customizing for Purchasing under Purchase Order à Set Up Stock Transport Order à Plant. The customer number is transmitted to the supplying system.
Process Flow
The stock transfer occurs cross-system, that is, the ordering and supplying plants are in different systems and/or clients. If you are using APO, then in this example, MRP-relevant data from the purchase requisition, purchase order, unchecked delivery, delivery, goods issue, and goods receipt are transmitted to APO. (Steps 1 and 2 are optional.)

If supplying plants have been determined as sources of supply in the R/3 system, no
APO can determine further supplying plants over and above those determined in the R/3 system. The supplying plants are chosen on the basis of the availability check.
If a rule-based ATP check is carried out in APO, the APO can also return plants that are not known in the ordering system, i.e. which have not been defined as plants for cross-system flows of goods in Customizing for the Enterprise Structure.

If you generate purchase orders in your R/3 System and are using APO, both an availability check and shipment/transportation scheduling are carried out in APO. That is to say, if you are using APO, a realistic delivery date is passed on to the supplying system. Otherwise, the desired delivery date is transmitted.
As soon as you save the order in the ordering system, it is transferred to the APO system via the APO Core Interface. The purchase order appears in the product view as a requirement.
In APO, requirements are also created for the items in this purchase order when the issuing plant is in a different R/3 system (No requirements are created for these items in the ordering system).
You can use any document type in the stock transport order.
In the case of a cross-company-code stock transfer, either an info record is necessary for price determination purposes or the price has to be entered manually.

Shipping data is not determined in the ordering system because this data is located in the supplying system.
If the supplying plant of the purchase order is located in a different system, an IDoc (DELIVERYPROCESSING_EXECUTE) is generated and transmitted to the supplying system when the purchase order is saved or changed. An IDoc is also generated if a purchase order is changed. The unchecked delivery is adjusted in accordance with the change.
A requirement for the unchecked delivery is generated in the supplying system. This allows for local requirements planning in the supplying system.

The requirement for the unchecked delivery has different Material Requirements Planning (MRP) indicators (or
The unchecked delivery item can only be changed through the associated purchase order.
The unchecked delivery is not displayed in the PO history in the ordering system, but it appears in the supplying system as a requirement in the
Stock/Requirements List.The unchecked delivery is transmitted to APO via the APO Core Interface model. The number of the corresponding order item is transmitted as a reference to APO for each delivery item. The unchecked delivery appears in the product view as a requirement. Here, the requirement for the corresponding order item (category BS-ABR) is replaced by the requirement for the unchecked delivery (category ULIEF).
The same checks that are run during regular delivery creation are also run here.
When you convert the unchecked delivery to a delivery, the availability check takes place either in the supplying R/3 system or in APO (if you use APO):

If you are using APO, then an availability check will be carried out for the delivery in APO, and the relevant changes will be saved. Depending on what APO reports back to the supplying system regarding the available quantities, the following processes occur in the delivery:
-
Everything available-
Reduced quantityDeliveries are shown in the supplying system in the stock/requirements list, and in APO in the product view. The requirement for the corresponding unchecked delivery is replaced by the requirement for the delivery.
You can also perform subsequent functions like picking and packing, just like you would in an integrated system. Any changes you make in the delivery are automatically reported to the ordering system.
An IDoc (PO_UPDATEPOHISTORY) is sent to the ordering system, which updates the PO history with the delivery data in the course of inbound IDoc processing.
If an unchecked delivery item exists for a PO item, the latter cannot be deleted.

In the supplying system, you can display the underlying purchase order from within the delivery via
In the ordering system, you can display deliveries in the supplying plant from within the purchase order via RFC.
In contrast to the integrated scenario, the following restrictions apply in the supplying system for this scenario:
During inbound IDoc processing, a material document is generated in the ordering system (so-called WA2 posting). The item text of the material document in the ordering system (WA2 posting) contains a reference to the material document of the WA posting in the supplying system (WA1 posting). This reference contains the logical system, the material document number, the material document year, and the item.
If a goods issue has receiving plants in different logical systems, an IDoc is transmitted for each logical system.
A reversal of a goods issue for a stock transport order is effected exclusively using the reversal transaction of the Shipping function via Logistics Execution

The movement type of the goods receipt depends on the Delivery Type. The delivery type is now determined at item level.
Previously, the delivery type was determined from the document type and the supplying plant. A purchase order can now contain intra-company-code and cross-company code items with different vendors.
Separate movement types are used for cross-system stock transfers. The new movement types for the supplying system start with 6A (WA1 postings) and those for the ordering system with 6B (WA2 postings).
In the case of a cross-system stock transfer, the keys for the movement types maintained for the integrated transfer are reassigned.
Movement Types in the Case of a Goods Issue for an Intra-Company-Code Stock Transfer (Previously Document Type UB)
Movement type |
Function |
6A1 (corres. to 641 – Transfer to stock in transit) |
Two-Step Procedure: Goods issue with UB logic (stock in transit created at recipient, immediate value posting) |
6A2 |
Reversal of 6A1 |
6A7 (corres. to 647 – Transfer to stock in transit) |
One-Step Procedure: As 6A1, except that the goods receipt line (movement type 101) is automatically generated, so that the GR is posted simultaneously with the goods issue. |
6A8 |
Reversal of 6A7 |
Movement Types in the Case of a Goods Issue for a Cross-Company-Code Stock Transfer (Previously Document Type NB)
Movement type |
Function |
6A3 (prev. 643 – Transfer to cross-company) |
Two-step procedure :Goods issue with NB logic. The stock is posted against a consumption account (posting key GBB) and is not inventory-managed in any system until the time of goods receipt. However, it can be identified on both a quantity and value basis by the report for displaying stocks in transit. |
6A4 |
Reversal of 6A3 |
6A5 (prev. 645 – Transfer to cross-company) |
One-step procedure :As 6A3 in one-step procedure. |
6A6 |
Reversal of 6A5 |

If you set up your systems in such a way that the different plants also belong to different company codes, the delivery is relevant with regard to internal intercompany billing. This means that internal billing is triggered not later than at the time the goods issue is posted in the supplying system.
The goods receipt for the stock transport order takes place with reference to the purchase order. The system checks at item level whether the goods issue is booked out of stock in transit and posted to unrestricted-use stock (previously with document type UB) in the course of the stock transfer or whether, in the case of the cross-system stock transfer, a standard goods receipt involving the GR/IR account takes place.
Restrictions
Please refer to the
Restrictions that apply to this scenario.