cancel
Showing results for 
Search instead for 
Did you mean: 

multiple contract creation in ECC from a single GOA

Former Member
0 Kudos

Hi Experts,

I am working on a solution regarding to GOA in SRM - Contract in ECC creation and i am wondering about the following scenario:

Create 1 GOA in SRM 5.0 for a central/global purchasing organization and when the appropriate BADI going to transfer it into ECC, it creates contracts for all company codes.

At my current client they use GOA but until now they created 1 GOA for a specific p.org and the BADI transferred (and created) contract in ECC for the specific company code (they donu2019t have kind of central/global purch organization unit in ppoma). In the future they would like to create GOAs which are usable for all companies, but instead of creating (and changing) them manually (N GOA in SRM for N contract in ECC) they want to have an automatism.

Does any of you have any experience on this? That would be really good if you can share with me some high level overview about concept.

Thanks in advance for your help!

Best Regards,

Attila

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member183819
Active Contributor
0 Kudos

1:1 Only possible.

SRM contract number should be same a ECC contract.

Former Member
0 Kudos

Hi,

Yes, but we have the following business scenario:

GOA is created in SRM which should apply for all companies: GOA is created against a central/reference p.org (currently no central p.org is created). Then it transfers to ECC as contract and PO can be made against this contract. But it could be possible that some companies will require for example different price in the contract...

So centraly agreed contract does not seems very usefull because if i change any price, it will apply to all companies.

I'm thinking about the usage of contract hiearchy (i know, hiearchy is only for SRM) and with some extra development in order fulfill the requirement, but i would like to know how the others managed this requirement.

Do you have any experience/advice on this?

Regards,

Attila

former_member183819
Active Contributor
0 Kudos

Hi

it may possible in SRM 700 CCTR

The new function called "GROUPING"

ACTIVATE GROUPING LOGIC FOR LOCATION IN GOA in SPRO

Central contract is created with one line item that is distributed to one back-end system but three locations or with three line items distributed to one back-end system but three locations:

Without grouping logic activated, three back-end contracts would be created:

With grouping logic active, only one back-end contract is created:

the above facity is not available for SRM 5.0 GOA ONLY FROM SRM 700

Former Member
0 Kudos

Hi,

Let me correct if i am right:

- Central Contract -> new concept of SRM 7.0. 1 contract which is visible and usable from ECC and SRM as well. (not available in SRM 5.0 - agree)

- GOA -> it exist in SRM 5.0 for sure! (we are currenlty using it for ECC procurement).

The solution what you are mentioned is good...but as you said only for SRM 70...we are in SRM 5.0 and we need solution for here. Do you have any idea?

Currently i am thinking about a new solution based on "standard" functionalities: if a GOA need to be created for mulitple company, it has to be populated in Header distribution (all company will have the same contract header). It item detail all the required information need to be poupulate in SRM (i.e.: item 1 for p.org1/comp.cod1; item 2 for p.org2/comp.cod2).

When this is done, the BADI need to check the informatoin in SRM GOA and create contract according to that -> in this case 1GOA is created, but the 2 items for totally different p.org/comp.code, the BADI needs to create 2 different contract in ECC (i would like to avoid using reference purchasing organization in ECC!

Thanks in advance!

Best Regards,

Attila

former_member183819
Active Contributor
0 Kudos

Assume that you have done by massaging the BADI.

it gives great difficult when you do revising the contract .

so it gives trouble for the Buyer community.

since contract can be revised when it is going to expire . dont put axe in your leg .

wait for srm 700 and migration and do implement group logic and more over issues can be supported by SAP too.