Skip to Content

Procurement with Origin Acceptance

In import procurement, the buyer or purchasing organization typically negotiates with a vendor to accept goods or to take ownership of goods at the vendor premises. In other words, the buying entity takes the financial ownership of the goods at the vendor premises and is therefore liable to pay the vendor even though the goods have not yet physically arrived at the buyer’s location (plant/warehouse). In international commerce trading terminology it is called EX-Works procurement and recognized by the International Commercial Term (Incoterm) “EXW”.

Standard SAP provides the capability to use the Incoterm “EXW” in the purchasing documents such as purchase orders, contracts and/or scheduling agreements. Though SAP also has an inventory movement type (107) which can accept goods at the origin, the standard SAP solution doesn’t have end to end integration to use the Incoterm “EXW’, origin acceptance along with movement type 107. The lack of integration of the origin of acceptance functionality with the follow-on business processes (goods receipts, invoice postings and releases, vendor payments, MRP functionality and so on) requires some manual intervention at each business process step starting with the PO creation up to the invoice processing  in order to use it efficiently. Manual intervention in the business process can potentially impact the following areas:

Account Payable/Finance

Procurement

Material Requirement Planning

-Delay vendor payment

– In-transit stock ownership and financial posting in SAP system

-Uncertainty of delivery date/ownership from vendor

– Supplier performance evaluation

– Stock availability for use

– Over or under planning by MRP

The purpose of this document is to describe how to design and build the end to end procurement process for “origin at acceptance functionality” within SAP with additional configuration as well as custom development work which will allow for the avoidance of any manual intervention.

Below is the expected high level procurement business process flow regarding the concept of origin at acceptance:

Process Flow- Procurement by Origin Acceptance

Exw Work.jpg

GAPs in Standard SAP

When above described process mapped within standard SAP, following gaps occurs.

Gaps.jpg

How to Fix these GAPS

All of the above referenced gaps can be addressed with the below listed work: additional master data setup, configuration and custom development in SAP ECC. This can make procurement with origin of acceptance a seamless process avoiding any manual interventions.

Master Data Setting:

Master Data.jpg

Configuration

Perform below configuration activities to determine Movement Type 109 in IBD

1.       Configure new item category for inbound delivery:  Create new item category e.g. ZEL for inbound delivery and assign movement 109 for this item category.

IMG Path: SPRO->Logistics Execution->Deliveries-> Define Item Categories for Deliveries

Config1.jpg

2.       Define Item Category Usage:  Define new item category usage

IMG Path: SPRO->Logistics Execution->Deliveries-> Define Item Category Usage)

Config3.jpg

3.       Define Item category determinations in Deliveries: Define new item category determination (defined in step) during inbound delivery creation for combination of item categories.

Config5.jpg

          Repeat this step for all item categories defined in material master.

Custom Development

1.       Development to determine “Origin of Acceptance” in PO automatically

To default origin of acceptance indicator in purchase order, implement BADI  ME_PROCESS_PO_CUST      and      class      PROCESS_ITEM.In the BADI write logic to check incoterm at PO line item level and if it is “EXW”, set origin of acceptance indicator in PO (you can use other logic as well to set origin of acceptance indicator).

     

2.       Create Custom Table to Maintain Transportation Time:

        Create custom table to maintain transportation time for the combination of vendor, material, plant and incoterm. (Client may use other criteria based on business requirement). Include this table maintenance in one of the support role.

3.       Delivery Date in Purchasing Form Output:

        Modify Purchase order form output to read delivery date as below for procurement with origin acceptance scenario only.

                         If Inco term at PO line item level is “EXW” then

                PO Delivery date for line item = PO Delivery Date (EKPO- EEIND) – Transportation Time from custom tabbased on  vendor/material/plant/incoterm combination.

4.       Delivery Date in Purchasing Output by EDI: (Optional)

        This development is required only if procurement with origin acceptance is done with   EDI vendor. In this case, identify enhancement spot in outbound PO message type       ORDERS05 and apply same logic as mentioned in step 3.

5.       Delivery Date in ASN or order confirmation by EDI: (Optional)

                This development is required only if procurement with origin acceptance is done with   EDI vendor and vendor sends and vendor send order confirmation and advance shipping             notification by   EDI. In this case, identify enhancement spot in inbound PO confirmation                (Message type ORDRSP) and advance shipping notification (DESADV) and apply below   logic.

                Delivery date in order confirmation or ASN= Delivery date provided by vendor + Transportation Time from custom table based on vendor/material/plant/incotem combination

                Delivery date from order confirmation or ASN is used by MRP for planning purpose.

6.       Development to determine Movement Type 109 in IBD

                 Implement enhancement spot ES_SAPMV50A and object MM_INB_DEL_ITEM_CATEGORY and write logic to determine item category “ZEL” in IBD (inbound delivery) for origin of      acceptance scenario. In the logic, check inco term at PO line item level (EKPO-INCO1), if    it is “EXW” then select item category from table T184L for delivery type is “EL” and  usage “Z” and update in the field “XLIPS-PSTYV” (item category in inbound delivery).

7.       Supplier Evaluation:

        Update your supplier evaluation program to calculate delivery score for procurement    with origin acceptance as below (Generally Supplier evaluation program is customer     specific therefore program details not provided)

        If PO line item has inco term “EXW”, then target delivery date as

        Target delivery date= Delivery date from PO (EKPO-EEIND) – Transportation Time from custom table based on vendor/material/plant/incoterm combination

        Actual Delivery Date= EKEB-BUDAT (Delivery date with ref to PO posted by movement type 107) by using PO# and where EKBE- BWART= 107

        Compare target delivery date actual delivery date and assign delivery score appropriately.  

8.       Update security profile

        To allow buyer to post good receipt for procurement with origin at acceptance by using TCode MIGO and movement type 107.

Value Addition/Benefit and Impact

Ø  Seamless end to end integrated process without manual intervention

Ø  Actual delivery date communicated to vendor and actual physical goods receipt date used by MRP

Ø  Origin acceptances by movement type 107 have following impact on MM, FI and LIV.

FI Impact

MM Impact

LIV Impact

ü  Accounting document generated

ü  Origin acceptance date recorded

ü  Item placed in valuated blocked stock

ü  Not available for use

ü  Invoice block removed

ü  Invoice available for payment as per agreed term prior to taking physical control of the items

Ø  Actual good receipts by movement type 109 have following impact

FI Impact

MM Impact

LIV Impact

ü  No financial documented posted

ü  Physical goods receipt date recorded

ü  Goods available for use

ü  No Impact

Possible to monitor goods accepted at origin and current stock status by using report MB5OA

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Warren Nash

    Purshottam, only had a quick read, but you have creatred a nice resource.  Incoterms are a big issue especially for imports/exports for comnpanies using SAP.  There is just constant “heated” discussion between the purchasing and accounting departments over when goods should be receipted and when the financial impact should be felt in the stock GL account.

    (0) 
  2. Nilesh Kshatriya

    Hi Purshottam..

    Excellent presentation..

    Functionality of Acceptance at Origin is very much clear after reading your document.

    Thanks for sharing the same.,

    keep posting..

    Regds,

    Nilesh

    (0) 
  3. Darren Schmidt

    Hi Purshottam,

    Great document, we use 107 process heavily for our items moving globally from Vendor to Freight Forwarder to site. One thing that is not clear to me is why in the PO history for a 107 the Amount in LC is 0 where for other MVT types it is the Value received?

    (0) 
  4. Neil Huang

    Hi Purshottam,

            Great document. In my last project i done this situation,but not with BAPI,i find a SAP note to display the field ‘original acceptance’.

    (0) 
  5. Vikrant Mahalle

    Hello Sir

    Really this a very precise and to the point document.

    Thanks a ton for sharing knowledge.

    Only one thing I wanted to ask here is , After following this process , when we will post 107 movement for certain quantity , are we able to see the quantity and amount in MIRO.

    I am asking this because when I am trying to post MIRO against line item posted with 107 movement type it is asking me to enter quantity and amount manually.

    Can you please guid with your expertise.

    Thanks

    Vikrant

    (0) 
  6. Loren Schmidt

    We are receiving ASN to create Inbound Delivery; and, I have tried to set confirmation control key to allow autoGR to movement 107 with option 3.

    However, the AutoGR does not seem to be happening.  Any suggestions on where I should look?

    I can do a MIGO manually and get the GR to post with reference to Inbound Delivery. The only field I touch when doing manual MIGO is to check the ‘Item Ok’ field.  Could this be the problem for AutoGR?

    (0) 
  7. Thomas May

    Having done all this config after doing 107 movement in migo, then creating the the inbound delivery, it picks up movement type 109 but adds in a check box which says not relevant for movement so when you complete the inbound delivery by posting goods receipt it looks like its done it but it doesnt move stock and on the inbound delivery it does it to a service which the PO isnt, has anyone got any clues

    (0) 
  8. Jokin García Escudero

    Hi Purshottam,

    Great document!

    I’m trying to do a Pro and Cons comparision between your proposed solution and the alternative solution ofo changing the planned delivery date and the GR processing time.

    In that alternative solution, the ‘planned delivery date’ would be decreased,excluding the , transport time from the exworks site to the plant site. And the ‘GR processing time’ would be increased with that transport time from the exworks site to the plant site.

    With that alternative solution, the final MRP dates are fine and there is no need to change the PO form or the EDI documents.

    It would be great to have your opinion about that  alternative solutions, Pro & Cons.

    thanks a lot for your help.

    Jokin

    (0) 
  9. mohammed jaffer

    Hi Experts

    I have one question. So we go a 107 on receipt of goods overseas. Goods Arrive and are delivered to the warehouse. What if there are issues with the items? Discrepancies? Is there any solution where by we can indicate to the customers the items are physically at our warehouse but blocked or cannot be used?

    If we do a 109 after a 107 that means the items are ok to be used

    We cannot do a 108 and then a 103 cause our finance pays vendors when our logistics team does a 107

    (0) 
  10. David Bragg

    We are using the 107/109 SIT functionality and also Material Ledger with Actual Costing.  Our issue is when the 107 movement happens from the shipper, it is for QTY=100 @$10 each, or $1,000.  This is owed to the vendor at shipped weight.  We pass title at shipping point.  But when goods arrive, there is shrinkage and only 95 units arrive.  We still owe $1,000, but we need the stock quantity to be reduced to 95.  Our cost should now be $10.50 each.  How can we handle this shrinkage automatically instead of an inventory adjustment to reduce quantity, and another MR22 adjustment to put the money back against the remaining 95 units?

    (0) 

Leave a Reply