ALE Third-Party Processing (2 SAP R/3, 1 SAP APO) 
Purpose
The following functions are available with SAP APO in the scenario ALE
Third-Party Processing (2 SAP R/3, 1 SAP APO):
ATP Check
Rules-Based ATP Check (dependent on the material or customer, you can make settings in SAP APO to see from which location the goods should be delivered).
Shipment and Transportation Scheduling
A corporate group has a purely sales company without any production locations of its own. The delivery is made from a different company within the group. In this scenario, Sales do not care which plant is the delivering plant.
The scenario supports separate SAP R/3 systems for sales and delivery. When you create a sales order in the sales system, the system automatically creates a purchase order that is sent to the supplying system. A second sales order is generated from a purchase order in the supplying system. Because of this order, the delivery is made directly from the supplying system to the customer. The ATP check and location determination (rule-based ATP check) take place in SAP APO.
The rule-based ATP check confirms a quantity from a location (such as a distribution center) from the supplying system. Because the location does not exist in the sales system, this location cannot be returned to the sales system. For this reason, a location alias is returned to the sales system. You must maintain a vendor under the location alias name in the sales system.
Prerequisites
This is generally a cross-company-code scenario. If you only want to use one company code, you should take into account the possible effects in the area Profitability Analysis (CO-PA).
The company uses SAP R/3 systems (as of SAP R/3 4.0).
The company uses a SAP APO system (as of SAP APO 2.0). Note, that shipment and transportation scheduling in SAP APO is available as of SAP APO 3.0.
You are using a SAP APO System (as of SAP APO 2.0) in which the sales and supplying system for third-party order processing are assigned to the same Business System Group (BSG).
You are using a SAP R/3 Plug-In (as of Plug-In PI 99) in which you have created and activated integration models APO Core Interface for the sales and supplying systems.
SAP recommends transferring the data via the APO Core Interface by creating three integration models. Transfer the ATP Customizing settings once only, in a separate integration model. You do not need to transfer the ATP Customizing settings if you maintain the relevant settings subsequently in SAP APO. Use separate models to transfer the master and transaction data. The material must exist in a plant in the sales system.
For further information, see
Integration of SAP APO and SAP R/3.
- If the sales area is part of a condition for the rule-based ATP check, you must also use different keys in the sales and supplying systems for the various sales areas (sales organization, distribution channel, division).
Settings
Œ
Enterprise Structure and Master Data
Settings: ALE and EDI
Ž
Settings: Automatic Generation of a Purchase Order
Settings: Billing
Settings: ATP Check
Procedure
- You create a sales order (1) in the sales system. To do this, enter a plant (if you do not enter a plant, the system proposes one automatically from the master data). The material must be managed in this plant. For further information, see the section
Creating Sales Orders.
An ATP check is performed in SAP APO. If the product is not available in sufficient quantity in the plant on the desired date, or if you have made the setting Rule immediately, then an ATP check is performed according to the settings in SAP APO. The result is a location determination for which an ATP check is performed. Internally, the system creates a temporary quantity assignment that receives the persistency indicator Prepersistent. The system displays the result of the ATP check as a hierarchy showing, amongst other things, a list of locations (both external and your own plants). In the case of third-party business, you confirm the delivery proposal for the external plant. In SAP APO you have maintained a location alias for this location (see also section Setting Up Location Aliases for Third-Party Business). The location alias is transferred to the sales system.
For more information see
Global Availability Check
The system creates a subitem in the sales order. A purchase requisition is generated for the schedule line of the subitem. The vendor of the item is the location alias that was transferred from SAP APO to the sales system. You can see the vendor under Item Details: Partners. You can go to the purchase requisition by choosing the schedule line for the subitem. You can see the vendor here as well.
Save the sales order. The purchase requisition is written to the database, and the system creates a third-party purchase order with account assignment to the order. This is not relevant to SAP APO. A third-party purchase order means that the supplying system delivers directly to the customer. In SAP APO, the temporary quantity assignment receives the persistency indicator Persistent.
The purchase order is created using ALE, and is transferred to the supplying system using EDI. A sales order (2) is created in the supplying system. The ATP check is called for the sales order (2). However, a real ATP check is not performed. Instead, the temporary quantity assignment receives the persistency indicator Postpersistent. The sales order (2) is saved in SAP APO. This means that the temporary quantity assignment for sales order (1) is deleted, and the system generates a requirement for the sales order (2) in the liveCache.
The sales order is confirmed in the supplying system. The order confirmation (outbound from supplying system) is made using output control (EDI) and standard EDI from the sales system. The order confirmation is not essential. It is an additional function because the ATP check is being used in this particular scenario. However, if changes are made to the order there should be an order confirmation.
In the supplying system, you create a delivery (delivery, picking, packing, goods issue). An ATP check is performed in SAP APO for the delivery. A shipping notification is sent to the sales system. The shipping notification is not essential for this scenario; it is solely for information purposes.
A billing document (internal settlement) is sent from the supplying system to the sales system. The invoice receipt triggers the customer billing document in the sales system. This subprocess is dependent on the settings for billing document relevance. For more information, see Introduction to Invoice Verification.
Other Subprocesses
Changing Sales Order (1) in the Sales System
If the order quantity is increased, the system generates a new subitem. To do this, the system creates a new sales order in the delivering system. Any quantities that were not yet delivered are adjusted.
If the quantity is reduced or the date is changed, the follow-on processes are not adjusted.
SAP recommends that you do not reduce the quantity or change the dates in the sales order. This avoids inconsistent results.
You can only reject, but not delete, any third-party-business items for which a purchase order has existed. To reject a third-party business item, you must first set a deletion flag in the PO item. Only then can you reject the sales order item.
Changing Sales Order (2) in the Supplying System
You can make changes to sales order (2) in the supplying system. Changes at schedule line level cause an IDoc ORDRSP that transmits a new order confirmation to the sales system. The purchase order and the sales order (1) are not updated.
In sales order (2) you can set a rejection reason for each item. This reason for rejection is transmitted to the sales system using an IDoc ORDRSP. When the IDoc is received, the system issues an error message.
SAP recommends that you do not make any changes to sales order (2) which might affect the quantity or date. This can avoid inconsistent results with regards to the sales order (1).
Constraints
In ALE third-party order processing, quotations with allocation of requirements are not supported. The scenario where third-party order processing is triggered from a quotation, via rule-based ATP, and where this quotation is later converted to a sales order, is currently not possible.
Backlog processing
You cannot perform backlog processing for an item in the sales order (1) in SAP APO, if a sales order (2) has already been created in the supplying system.
If a sales order (2) already exists in the supplying system, you can perform a backlog processing in SAP APO only for the relevant item from sales order (2) in the supplying system. This could result in inconsistencies (see above under Other Subprocesses: Changing the Sales Order (2) in the Supplying System).
- Plant determination in the supplying system
The restriction described here only affects SAP R/3 3.1I. As of SAP R/3 4.0B, this restriction is no longer valid due to note 427972. When transferring the purchase order to the supplying system, the delivering plant determined by the rule-based ATP check is not transferred. However, the sales order (2) must be created using this delivering plant. If different delivering plants are possible for a product in the supplying system, then you must define a vendor in the sales system for each delivering plant. You need to make the following settings:
For each delivering plant (such as 2200), you need to create different vendor master records in the sales system. In the vendor master records, you must enter the sales system as a debtor. Each vendor master record should contain a different debtor number. You need to create debtor master records in the supplying system for the debtor numbers. The debtor master records in the supplying system must contain the relevant delivering plant (such as 2200) as the default plant.
- You must not perform rule-based ATP checks (location determination) in the supplying system for the sales orders that were created automatically by the ATP check (location determination) or by ALE.
For these orders, you should use an order type in the system in which no
business transaction is entered. You enter this order type in the EDI parameters for inbound processing for the sales order in the supplying system (see section Configuring EDI for Inbound Processing of Sales Orders).
- There is no cross-system document lock available.
- Since all communication, except for the ATP check call, is performed asynchronously, there can be problems with the sequence.
The sales order might already have been changed in the sales system (and therefore also the relevant
temporary quantity assignments in SAP APO), before the supplying system picks up the confirmation of the change. This causes incorrect confirmation schedule lines in the sales order in the supplying system.
SAP recommends creating the purchase order immediately and automatically (using workflow). You should not manually convert any purchase requisitions.
- When you post the sales order from the sales system to SAP APO and errors occur, the update call remains on the status With errors in the outbound queue of the sales system. The temporary quantity assignments do not receive the status Persistent, rather they keep the status Prepersistent. This means that a confirmation for the relevant sales order in the supplying system cannot be picked up from the SAP APO system.