Entering content frame

Process documentation Cross-System Delivery (Intra-Company-Code and Cross-Company Code) Locate the document in its SAP Library structure


This scenario is available for when you want to perform a global or regional availability check (ATP check). It is often the case that not all stocks/plants to be checked are displayed in the SAP R/3 system where the sales order was created. You can perform an ATP check across SAP R/3 systems in the SAP APO system. You can also use the additional functions of the ATP check in the SAP APO system (for example, Rule-Based ATP Check). In particular, this contains a location determination where the system can determine plants not displayed in the sales order system. This scenario is therefore suited to situations where sales and shipping are represented in different SAP R/3 systems.

In comparison to the scenario Structure linkALE Third-Party Order Processing (2 SAP R/3, 1 SAP APO), the scenario here is more streamlined and more flexible when changes are made to the process flow. This is because the purchasing documents (purchase requisition and purchase order) are not created in the ordering system, and no sales order is created in the supplying system.

A cross-company-code delivery essentially exists where the selling company code in a sales order is different from the supplying company code, and the delivery to the customer takes place directly from the selling company code without a temporary goods receipt. An internal billing document is created between the company codes. The selling company code invoices the external customers. This process is also supported within cross-system flows of goods across system boundaries (see also: Cross-System Stock Transfer (Intra-Company-Code).

An intra-company-code delivery can only take place when the selling organization at header level of a sales document is assigned to a different profit center node from the delivering organization at item level, and the company code does not change. In this case you should perform a profit center settlement between the two profit centers. The intra-CC transfer price should by displayed in the sales order.

In this scenario, intra-company-code deliveries can become cross-system deliveries when the supplying plant is managed at item level in a different system than the sales system.


For more information on the technical integration between an SAP APO and an SAP R/3 system, see the documentation SAP APO – Advanced Planner and Optimizer -> Supply Chain Management (SCM) Business Scenarios -> Integration of SAP APO and SAP R/3.

Process Flow

The following diagram shows a cross-system delivery (intra-company-code) between two SAP R/3 systems with a joint SAP APO.

This graphic is explained in the accompanying text

  1. You create a sales order in the sales order system. On the initial screen, choose the order type and organizational data.
  2. On the order entry screen, enter the header data followed by the item data. You have two options:
    1. Enter you own plant (plant in the sales order system)
    2. Enter an external plant (from another SAP R/3 System within the business system group).

The input help shows you the possible plants, including the external plants (when you enter the relevant logical SAP R/3 system). The system can also automatically propose the plant on the basis of data in the customer master record, the material master record, or in the customer-material information.

The following restrictions are effective:

  1. In SAP APO, an ATP check is performed in accordance with the settings in the Check Instructions . For location replacements, a location can be found that is not known in the calling system (external plant). The plant found is transferred to the sales order system as a result.
  1. When the order is saved in the sales order system, the order is transferred to the SAP APO system using the SAP APO Core Interface. In the SAP APO order network, requirements are also created for the items in this order that have external plants (no requirements are created for these items in the sales order system).
  1. Any corresponding Temporary Quantity Assignments that were created during the ATP check in SAP APO, are completely deleted afterwards.
  1. You save the order in the sales order system.


  1. The IDoc Deliveryprocessing_execute, including the data from the sales order, is sent by the selling system to the shipping system.
  2. The IDoc is processed in the shipping system according to your settings in ALE Customizing.
  3. An Unchecked Delivery is created in the shipping system according to the delivery date set in the sales order. As in the integrated scenario, where you can create several deliveries for a sales order, in this scenario you can also create several unchecked deliveries for a sales order (split criteria). No unchecked deliveries are created for unconfirmed remaining quantities.
  4. The unchecked delivery is transmitted to the SAP APO system using the SAP APO Core Interface Model. The SAP APO system receives the number of the corresponding sales order item for each delivery item as a reference. The system then creates requirements for the unchecked delivery in the order network of the SAP APO system. Additionally, the requirements for the referenced sales order item are deleted.
  5. The system also creates a requirement for the unchecked delivery in the shipping system. The requirement in the unchecked delivery has a different MRP indicator than the requirement in the delivery (or category in SAP APO). Therefore, the unchecked delivery in the shipping system and in the availability check in the SAP APO system are displayed separately in the requirements overview. When you create the unchecked delivery, the system does not perform an availability check. The ATP check can also differentiate unchecked deliveries from deliveries. The unchecked delivery is included in the SAP R/3-ATP checking rule as a sales requirement. In the SAP APO system, the unchecked delivery offsets itself against the sales order requirement.
  6. The requirement in the unchecked delivery allows for local MRP in the shipping system.
  7. You convert the unchecked delivery into a delivery in the shipping system. The same checks are run as for conventional delivery creation.

In this scenario, the shipping system possesses the following limitations in contrast to the integrated scenario:

  1. An availability check is performed in SAP APO for the delivery. Any relevant changes are saved in the SAP APO system. Depending on the available quantity reported by SAP APO to the shipping system, the following processes can result in the delivery:

The delivery writes a delivery requirement in both the shipping and SAP APO systems. The requirements in the unchecked delivery are deleted from both the shipping and SAP APO systems.

  1. The delivery confirms the delivery quantities to the sales order. The system then updates the status and document flows for the sales order.
  1. You can perform all the follow-on functions, such as picking, packing, and goods issue as you would in the integrated scenario. All changes to the delivery are automatically reported to the sales order system.
  1. The billing document is created with reference to the order. The billing document index is written from the confirmation of the delivery to the order, when the delivery is posted for goods issue. If information is required from the delivery in order to create the billing document, where this information cannot be determined from the document flow of the relevant order, a BAPI is called synchronously for the billing document in the shipping system. This BAPI determines the data relevant for the billing document. The system determines the delivery data or values from accounting, or defines conditions.

Cross-Company-Code Processing

If you set your system up in such as way that the different plants are also in different company codes, then the delivery is relevant for intercompany billing.

The process described above changes, at the latest, when you post the goods issue in the shipping system and intercompany billing is triggered and sent to the sales order system for comparison.

This graphic is explained in the accompanying text

Other Scenarios

The following scenarios will still be supported:

Structure of the Complete Concept in Subprocesses



Leaving content frame