![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' Initialize
PERFORM sd_fluss_vorbereiten. Prepare
CALL FUNCTION 'SD_DOCUMENT_FLOW_SAVE_PO' Post
Confirmations with:
PERFORM sd_aend_vorbereiten USING processed_flag. Prepare (xvbepek)
IF NOT xvbepek[] IS INITIAL. Post
CALL FUNCTION 'SD_PURCHASE_CHANGE_ORDER'
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:](https://image.slidesharecdn.com/thirdpartyknowledgepaper-100519072204-phpapp01/85/Third-party-knowledge-paper-3-320.jpg)
Third party knowledge paper
- 1. Knowledge Paper - Third-Party Ordering Process Contents • 1. Overview • 2. Sales Order • 3. Purchase Requisition • 4. Purchase Order • 5. Special Functions o 5.1 Delivery Address o 5.2 Sales Order Update from Within Purchase Order o 5.3 Adoption of Data from Sales Order in Purchase Order • 6. Notes 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.
- 2. 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).
- 3. 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' Initialize PERFORM sd_fluss_vorbereiten. Prepare CALL FUNCTION 'SD_DOCUMENT_FLOW_SAVE_PO' Post Confirmations with: PERFORM sd_aend_vorbereiten USING processed_flag. Prepare (xvbepek) IF NOT xvbepek[] IS INITIAL. Post CALL FUNCTION 'SD_PURCHASE_CHANGE_ORDER' 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:
- 4. 0488725 FAQ: Temporary quantity assignments in global ATP 0481600 FAQ: Import data in Purchasing 0498162 FAQ: Third-party order processing in Purchasing 0549365 FAQ: Scheduling for third-party and individual POs 0549583 FAQ: Order confirmation status of 3rd-party and individual POs 0549818 FAQ: Billing status for third-party items in sales order 0549972 FAQ: Rejecting third-party or individual PO items 0550192 FAQ: Changing third-party and individual PO items 0550362 FAQ: Special problems in the case of third-party and individual POs 0550388 FAQ: Customizing of third-party and individual POs