Skip to Content
avatar image
Former Member

PO not getting transffered to ECC from SRM.


In SRM we are creating shopping carts for two vendors. The shopping carts are getting saved without any error.

For one vendor the PO is getting transferred to ECC. But for one vendor it is not getting transferred to ECC.

For the vendor where it is not getting transferred to ECC we get the message that "In case of evaluated receipt settlement, please enter tax code". But when we created a catalogue PO in ECC with same details as of SRM, the PO was created in ECC and the tax code was copied automatically.

What can be the possible reasons that one PO is getting transferred into ECC and the other is not.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Aug 03, 2009 at 10:01 AM


    Please enter the tax code for the vendor in the shopping cart and save and then check.



    Add comment
    10|10000 characters needed characters exceeded

    • Hello Nandan,

      How is your tax calculation done ? In R/3 or in SRM ?

      See your customizing in SPRO:

      SAP implementation Guide -> Supplier Relationship Management -> SRM Server -> Cross-Application Basic Settings -> Tax Calculation.

      As you can create manually a PO in R/3 without any problem, i think you have a BAdI implemented for your tax calculation.

      Check conditions in corresponding method.



  • avatar image
    Former Member
    Feb 07, 2013 at 12:52 PM

    Hi Nandan,

    I have a similar issue that the tax code derived in the SRM is being overwritten from the tax code in ECC, is there any way to skip this.

    your response will be really appreciated



    Add comment
    10|10000 characters needed characters exceeded

    • If NAVS condition records maintained in ECC, then it will be used for all types of PO, catalog items, goods/service PO (created from SRM SC) and direct PO in ECC.

      I implemented same design for one of my client and working successfully. We are using SRM catalog, goods/service/limit functionality and direct PO in ECC or from SCM.

      In case if above solution is not suitable for your requirement, you can talk developer to enhance BAPI (BAPI_PO_CREATE) to get tax code from SRM SC and bypass default tax code determination from NAVS condition records.

      If you ask for my suggestion, then i would say better to use only one method (NAVS condition records) to default tax code in PO for all scenarios (why to do additional development work, when std method is available). Just remember default tax code in PO, is only default, buyer still have an option to change tax code in PO directly. My experience is, after getting default tax code from any methods (NAVS or BAPI etc), buyer needs to change tax code oftenly in PO due to many reasons.