If a customer places an order with a decentral sales center (using either a dialog or EDI), then a sales order is posted in the decentral system. This results in a purchase requisition which is used to automatically create a purchase order for the central shipping in the materials management module in the decentral system.
The vendor, "central shipping", receives the purchase order in the usual way using EDI (an incoming order in SD).
After checking the order a confirmation is sent to the decentral sales system and this becomes the basis for an order acknowledgment for the customer.
The various message flows are shown in the graphic below.
Decentral Sales - Central Shipping
1. Incoming Order in Decentral Sales
The sales order is entered in the SD system via either a dialog or EDI. (Standard input).
There is a new ALE item category for ALE. This is used when an order arrives to automatically create a purchase requisition and thus a third-party order in MM for the items required
The item category group is specified in the material master. This determines the material purchase orders that are sent to the central shipping.
Sales and distribution cannot perform synchronous availability checks and credit limit checks decentrally. The sales order does not get confirmed when it is first created.
The following status fields are used in the sales order:
VBEP Table (schedule line status):
no ALE schedule line
schedule line not yet confirmed by MM
schedule line confirmed by MM
VBUP Table (item status):
no ALE item
item not yet confirmed by MM
schedule lines partially confirmed by MM
all schedule lines confirmed by MM
VBUK table (header status):
not relevant to ALE
not yet confirmed by MM
items partially confirmed by MM
all ALE items confirmed by MM
A line in the status screen shows the confirmation status for the ALE items (not confirmed, partially confirmed, fully confirmed).
2. Purchase orders in the decentral system
Based on the sales order, either a third-party order or a standard purchase order is created and the account is assigned. A third-party order means that shipping delivers directly to the customer. The type of order that is created depends on the schedule line type in the sales order.
The purchase order is created using a purchase requisition. First the purchase requisition is created from the sales order, then an event is started which creates the purchase order. The event is triggered only if there is at least one ALE item category in the sales order.
The Customizing for the sales organization has been extended in Release 3.0, so that the purchasing organization, purchasing group, vendor and order type can be determined for the purchase order.
Determining the vendor
If there is just one shipping system, the vendor is assigned to the sales organization.
If there is more than one vendor (shipping system), the vendor is determined from the fixed vendor in the purchasing information record or in the source list. This means that there cannot be more than one vendor for each material.
A customer exit has been implemented to cover the case in which there is more than one vendor for a given material. It allows the customer to employ his own logic for determining the vendor for each purchase requisition item. This customer exit is also used to allocate a contract number and a contract item to the purchase order item, so that a contract release order is created.
2a. Changing a purchase order in the decentral system
Changes to a sales order (quantities and deadlines) are sent to the shipping point as purchase order changes as follows:
If schedule lines have been changed in the sales order, the corresponding purchase order items and the purchase requisition items are also changed.
If new items or schedule lines are added to the sales order, then new purchase requisition items are written. These lead to new purchase orders.
The changed schedule lines are given the status ‘not yet confirmed’, which they retain until the confirmation from the vendor (shipping system) arrives.
Note the following in connection with order confirmations:
The first order confirmation from the central shipping point marks the decentral order as confirmed.
If a second change is made to a schedule line before the first change is confirmed, then the first confirmation will also set this schedule line status to ‘confirmed’.
3. / 3a. Outgoing purchase orders
The purchase order is sent as in the case of cross-system purchasing /sales.
Messages between the decentral sales and the central shipping are sent asynchronously but immediately the update is made. This can be set in the message control.
A material cannot be ordered from different decentral shipping systems (except by using a customer exit). However, it is possible to specify (for example, in the item category) that when a material purchase order is being processed, the local warehouse should be checked first to see if the sales order can be met there. If the material is not available locally, the item category is changed and a purchase order sent to the shipping point responsible.
3b. Incoming orders in the shipping system
The incoming orders arrive via the EDI input in the SD system.
In this scenario the customer’s purchase order number is lost (data passed in the decentral system from SD to MM, and data sent from the decentral sales to the central shipping).
4a. Order confirmation - sent from shipping
The order confirmation is sent via the message control, transmission medium "6" (EDI). The changes that are marked as such are changes to either the quantity or the deadline.
4b. Order confirmation - arrival in the decentral system
The order confirmation is sent via the standard EDI communication to the decentral MM. In Release 3.0 confirmations without corrections (full confirmations) are the only ones that are automatically imported. Changes have to be processed manually.
5. Order confirmation in the decentral system
If the central shipping has confirmed the purchase order, the schedule lines in the sales order are automatically confirmed in SD. This happens both for a full confirmation and for a partial confirmation of the purchase order.
6. Order confirmation to the customer
Once all the schedule lines and items have been confirmed, the status for the sales order is set to "confirmed" (status definition - see point 1 "incoming order").
The conditions in the message control for the confirmation print (message type BA00) have been extended in Release 3.0, so that only fully confirmed orders are confirmed.
7. Delivery, shipping notification, delivery note
For a standard purchase order, the delivery is sent to the decentral sales system, as in the "cross-system purchasing/sales" scenario.
For a third-party order, the delivery is sent to the customer. The customer also receives a message along with the delivery, sent as usual through the message control (for example, in printed form, as a fax, EDI etc.).
A shipping notification is sent to the decentral sales. The shipping notifications are sent using the message control, transmission medium "6" (EDI).
8. Initiating the invoice
Posting the shipping notifications in the decentral system for the ALE case causes the invoicing of the notified quantities to be initiated for third-party orders.
The technical procedure is as follows: when the shipping notification is received, a goods receipt is created for the purchase order; an accounting document is created, but the stocks are not changed.
The following has to be set in the Customizing of the R/3 sales and distribution:
The plant, storage location and movement type must be specified for the goods receipt posting for the purchase order; these are specified separately for each sales organization.
The setting for "invoiced quantity equal to the goods receipt minus the quantity already invoiced" must be made before the entire delivery can be invoiced.
9. Invoice to the customer
After the shipping notification has been received, the invoice is created in the decentral system and is sent to the customer using normal procedures (either letter mail or EDI).
Invoicing between the systems proceeds as in the scenario called "stock transfer between distributed systems".