Entering content frameProcess documentation Cross-System Stock Transfers (R/3 Purchasing, APO, R/3 Shipping) Locate the document in its SAP Library structure

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.

Note

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.

This graphic is explained in the accompanying text

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 .

Note

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.

Background documentation

The posting lines that belong together in the supplying and receiving systems are generated with the same assignment number. This allows item-exact automatic Clearing of the clearing account.

For more information, refer to the documentation for Structure link 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.

 

Note

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.)

  1. You generate Purchase Requisitions in your R/3 System and carry out a source determination process if necessary.
  1. If you are using APO, a source (location) determination process and then an availability check are carried out for these requisitions in APO.

Note

If supplying plants have been determined as sources of supply in the R/3 system, no rule-based ATP check (location determination) is carried out in APO. Only an availability check is performed.

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.

  1. A stock transport order is created from the purchase requisition in the ordering system.

Note

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.

Note

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.

  1. An unchecked delivery is created in the supplying system on the basis of this IDoc.

A requirement for the unchecked delivery is generated in the supplying system. This allows for local requirements planning in the supplying system.

Note

The requirement for the unchecked delivery has different Material Requirements Planning (MRP) indicators (or categories in APO) from the delivery. The unchecked delivery can be taken into account separately from deliveries in the supplying system and in APO when carrying out the availability check. Unchecked deliveries are displayed in the stock/requirements list in the supplying system with the MRP indicator UnchDel, and in APO in the product view with the category ULIEF.

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).

  1. In the supplying system, unchecked deliveries are converted into one or more deliveries.

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):

Note

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 quantity

Deliveries 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.

Note

In the supplying system, you can display the underlying purchase order from within the delivery via Remote Function Call (RFC).

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:

  1. When the Goods Issue is posted in the supplying system (so-called WA1 posting), the ordering system receives an IDoc (GOODSMVT_SAPCREATE), whereupon the PO history for the underlying purchase order is updated in that system.

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 ® Outbound Process ® Goods Issue for Outbound Delivery ® Post Goods Issue ® Reversal. It is not possible to reverse such a goods issue in Inventory Management.

Note

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

 

Note

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.

 

  1. Where appropriate, a shipping notification is entered in the ordering system.
  2. In the ordering system, the Goods Receipt is posted and the PO history for the associated purchase order updated.

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.

 

 

Leaving content frame