Knowledge Paper - Third-Party Ordering Process

Contents

1. Overview 2. Sales Order 3. Purchase Requisition 4. Purchase Order 5. Special Functions

o o o
6. Notes

5.1 Delivery Address 5.2 Sales Order Update from Within Purchase Order 5.3 Adoption of Data from Sales Order in Purchase Order

1. Overview

Third-party order processing (for direct-to-customer delivery/drop shipment) is triggered when a sales order containing a third-party item is created. When this occurs, the system automatically generates a purchase requisition item of the category "third-party" for each delivery schedule line of the sales order item. This requisition item is converted into a purchase order (PO) item. Depending on the confirmation control key, the quantities/dates in the sales order are confirmed when the PO is created or an order acknowledgment is maintained.

If you create a third-party item without referencing a requisition generated from a sales order, this is not third-party order processing in the foregoing sense: a matching-up of the data between the SD sales order and the purchase order cannot be carried out in such cases!

2. Sales Order
In the standard system, the sales order item for the third-party process has the item category TAS (this is found automatically if the item category group BANS has been set in the material master, or it can be changed manually). In the standard system, the schedule line category CS is found for the item category TAS. It is specified in Customizing for the schedule line category CS that a purchase requisition (type NB) with the item category '5' (third-party) and account assignment category 'X' is generated. The number of the requisition that is generated can be displayed via the delivery schedule lines in procurement. If a PO is generated from this requisition, it can be seen in the document flow for the SD sales order (Environment --> Document flow). Confirmations from the PO can be seen in the form of new lines with confirmed quantities on the delivery schedule screen.

3. Purchase Requisition
The requisition is generated via the function module ME_REQUISITION_EXT. An important characteristic is that the field EBAN-ESTKZ (creation indicator) contains a 'V'. If a third-party requisition is created in dialog mode, this field does not contain the indicator 'V' - that is to say, this is not a third-party process in the sense defined. A source determination process is carried out at the time of creation. The purchase order units found during this process are adopted! The account assignment, containing the number, item, and schedule line of the sales order, cannot be changed in the requisition. The account assignment is the 'pointer' between the requisition and the SD order!! Since Release 4.6, the delivery address cannot be changed either. The address of the goods recipient (ship-to party) from the SD order is adopted as the delivery address (caution: this can be located both at header and item level in the SD order). There is a requisition item for each delivery schedule line in the sales order!

4. Purchase Order
Purchase order items generated from the above requisitions contain EKPO-STATU = 'V'. The delivery address comes directly from the sales order (see LMEPOF3T MEPO_ITEM_FILL_ADDR) and cannot be changed (as of 4.6, Note 204190). Neither can the account assignment be changed; here too it is the 'pointer' between the PO and the sales order. In the standard system, the account assignment category is 'X', with KZVBR = ' '. Since the account assignment is located at item level, you must not convert several third-party requisitions into a single PO item, otherwise the update of the sales order is liable to fail! (Note 452929). An 'actual' goods receipt does not take place with regard to a third-party item. The 'WEPOS' indicator is not set for the item categories 'S', but can be set manually. The posting of a GR results merely in a value update here. The entry of a vendor invoice can be made dependent on the prior entry of a GR. In the third-party process, this only makes sense if you wish to prevent the customer from receiving an invoice before having received the goods. A goods receipt should be recorded when the vendor reports the outward delivery. At the time of saving, the document flow and confirmations are updated in the SD order. If problems should arise on the SD side due to changes (e.g. the customer has been blocked), an error message is issued here first! In the case of third-party items generated without reference to a 'third-party requisition', i.e. the item category 'S' is merely entered manually, there can be no update between SD order and purchase order. Here, for example, the delivery address is not read from the sales order - it must be entered manually (mandatory field).

5. Special Functions
5.1 Delivery Address
As mentioned above, as of Release 4.6 (Note 204190), the delivery address in the PO can only be changed via the sales order. The delivery addresses in the sales order and purchase order should be identical. Prior to 4.6A, it was possible to maintain the delivery address in one document independently of the other. A possible consequence of this was that the goods did not arrive at the location desired by the customer! A change in the recipient's (ship-to) address in the sales order directly updates the delivery address in the requisition and PO when posted. This is implemented in FV45EFMA_BESTELLUNG_SICHERN --> FM ME_PUR_DOC_POSITION_CHANGE.

5.2 Sales Order Update from Within Purchase Order

In principle, two types of information in the sales order are updated when the PO is saved: document flow and confirmations. In both cases, this is effected in MM06EF0B_BUCHEN. Document flow with: CALL FUNCTION 'SD_DOCUMENT_FLOW_INIT' PERFORM sd_fluss_vorbereiten. Prepare Post Initialize

CALL FUNCTION 'SD_DOCUMENT_FLOW_SAVE_PO' Confirmations with: PERFORM sd_aend_vorbereiten USING processed_flag. IF NOT xvbepek[] IS INITIAL. Post CALL FUNCTION 'SD_PURCHASE_CHANGE_ORDER'

Prepare (xvbepek)

Whether/when the confirmations are updated in the sales order depends on the confirmation control key in the PO. If no confirmation control key has been entered, the SD order counts as acknowledged when the PO is created. If a confirmation control key has been entered, an order acknowledgment (AB) must be entered to acknowledge the SD order (see coding in im sd_aend_vorbereiten, Notes 549583, 401058.

5.3 Adoption of Data from Sales Order in Purchase Order

Purchase order unit of measure: The PO unit from the sales order is only adopted if no source of supply is found. If a source is found, the PO unit is adopted from that source. Example: A customer wants 6 pc ..., the requisition generated finds a source of supply with the PO unit 'box'. On the Purchasing side, this information is relevant; the PO is created with the unit 'box'! Conversion factors between base UoM and purchase order unit: These can be entered explicitly in the sales order. They are only adopted in the PO if product quantity/active ingredient management is active (Note 390242).

6. Notes
A number of FAQ notes are available, particularly in SD, describing system behavior in the third-party process:

0488725 0481600 0498162 0549365 0549583 0549818 0549972 0550192 0550362 0550388

FAQ: FAQ: FAQ: FAQ: FAQ: FAQ: FAQ: FAQ: FAQ: FAQ:

Temporary quantity assignments in global ATP Import data in Purchasing Third-party order processing in Purchasing Scheduling for third-party and individual POs Order confirmation status of 3rd-party and individual POs Billing status for third-party items in sales order Rejecting third-party or individual PO items Changing third-party and individual PO items Special problems in the case of third-party and individual POs Customizing of third-party and individual POs