Cross-System Delivery (Intra-Company-Code and Cross-Company Code)
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 ALE 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.
The following are system prerequisites for implementing cross-system deliveries:
- SAP R/3 Enterprise Core
- PlugIn 2001.2
- SAP APO Rel. 3.0A
Customizing Settings for Cross-System Deliveries)
- You must have made the settings for transfer prices in Customizing (see also:
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.
Maintain Partner Profile Manually. In the sales order system, maintain the message type Deliveryprocessing_execute as the outbound parameter for the logical system of shipping processing. Maintain this message type as the inbound parameter for the logical system of the sales order entry.
- In ALE Customizing for the partner type (LS – logical system), set the IDoc Deliveryprocessing_execute. To do this, choose the step Basis ®
Application Link Enabling (ALE) ®
Modelling and Implementing Business Processes ®
Partner Profiles and Time of Processing ®
The following diagram shows a cross-system delivery (intra-company-code) between two SAP R/3 systems with a joint SAP APO.
- You create a sales order in the sales order system. On the initial screen, choose the order type and organizational data.
- On the order entry screen, enter the header data followed by the item data. You have two options:
- Enter you own plant (plant in the sales order system)
- 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:
- To process items with external plants, you require an active integration model. There is an additional input option for external plants when you maintain the CIF model.
- You cannot use any discounts in kind.
- Configuration with external plants is not possible.
- You cannot use valuated or non-valuated sales order stock.
- Make-to-order production is not supported.
- You cannot make account assignments of costs or revenue from the sales order.
- Scheduling agreements for the component supplier industry (see also in the SAP menu: Logistics ®
Sales and Distribution ®
Scheduling Agreement ®
Create; with type LZ) and customer requirements (see also in the SAP menu: Logistics ®
Production Planning ®
Demand Management ®
Customer Requirements ®
Create) are not supported for external plants.
- The indirect document flow is not available for any self-programmed evaluations. The SAP standard system is not affected by this.
- Immediate order are not possible for items with external plants.
- The batch management requirement must be defined across plants.
- Business area determination from plant-division (rule 001 in Customizing for business area account assignment) is not possible for external plants.
- Region, county, and city of the external plant are not used in rules-based ATP.
- Shipping points and storage locations cannot be defined for external plants, and can therefore not be made default values in the sales order.
- The factory calendar is not recognized for external plants in the sales order system. Within shipment and transportation scheduling (that can also be performed in SAP APO), the system takes into account the SAP APO calendar for the issuing location (plant). The work times/shifts of the shipping point are also not recognized. These can be mapped using the part-day maintainable SAP APO calendar.
- The customer number is not known for external plants, and can therefore not be used for material groups and any related pricing.
- The MRP type is not known for materials in external plants, and can therefore not be used for assigning and checking schedule line categories in the sales order.
- The item in the order must also have a requirements type for external plants (determination using the item category and the initial MRP type).
- The requirements from external plants are not visible in the sales order system (stock/requirements view).
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.
- In SAP APO, an ATP check is performed in accordance with the settings in the
- 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).
Temporary Quantity Assignments that were created during the ATP check in SAP APO, are completely deleted afterwards.
- Any corresponding
- You save the order in the sales order system.
- The credit limit check in the order is only possible if the relevant data from the supplying system exists, i.e. goods issue data, statistics and so on. Cross-system statistics can only be realized using customer exits.
- Shipment and transportation scheduling must be active. Otherwise, you must subsequently maintain this data manually in the sales order.
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.
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.
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.
The requirement in the unchecked delivery allows for local MRP in the shipping system.
You convert the unchecked delivery into a delivery in the shipping system. The same checks are run as for conventional delivery creation.
- The IDoc Deliveryprocessing_execute, including the data from the sales order, is sent by the selling system to the shipping system.
- The IDoc is processed in the shipping system according to your settings in ALE Customizing.
In this scenario, the shipping system possesses the following limitations in contrast to the integrated scenario:
C (no partial deliveries permitted).
You cannot reschedule or backorder process third-party items and unchecked deliveries in the shipping system.
- No discounts in kind.
- No credit limit check in the delivery.
- Statistics updates of order data using the delivery are not realized.
- A complete delivery does not take place because of the complete delivery indicator. A complete delivery must be processed using delivery groups and the partial delivery arrangement
- 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:
- Everything available
- Reduced quantity
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.
- The delivery confirms the delivery quantities to the sales order. The system then updates the status and document flows for the sales order.
- 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.
- 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.
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.
The following scenarios will still be supported:
ALE Third Party Processing (2 SAP R/3, 1 SAP APO)
- Rule-Based ATP Check (SAP R/3 and SAP APO)
Structure of the Complete Concept in Subprocesses
Shipping and Transportation Scheduling
Creating and Changing Sales Orders
Performing Deliveries Using Unchecked Deliveries
Process from the Accounting Perspective