Issue with Extended CREMAS05 Idoc

[Former Member]

Hi All,

I am working on standard ECC sourcing integration, interface is: supplier data.

We are receiving CREMSA.CREMAS05 standard Idoc from ECC and posing Supplier data to Sourcing.

In addition to this there was a requirement to post vendor contact data to Sourcing from ECC.

As the first name and last name were not coming in standard CREMAS05 Idoc, we have added one optional Z segment having first name and last name to standard Idoc, and added extension to standard Idoc ZCREMAS05.

Now our partner profile looks like

Msg Type : CREMAS

Basic Type : CREMAS05

Extension Type : ZCREMAS05

In PI : for vendor cotact interface, we have done ESR development using new Idoc CREMAS. CREMAS05. ZCREMAS05

Now, whenever CREMAS Idoc is triggered from ECC, its coming to PI with root node as ZCREMAS05, therefore our custom vendor contact
interface is executing successfully however standard vendor interface is failing as its configured with CREMAS05 Idoc not the std one.

What setting is required in ECC or PI so as to eliminate this issue?

Thanks,

Ruchi

[ambrish_mishra · Accepted solution]

Hi Ruchi,

<standard vendor interface is failing as its configured with CREMAS05 Idoc not the std one.>

Did you mean not the custom one ?

What is the error you are getting ?

In case, you are trying to use the standard IDoc type/message type (with new extension ) for existing Supplier data interface, it won't work since Message type has changed. So you need to use, the custom IDoc for the existing interface.

Hope it helps!

Ambrish

Message was edited by: Ambrish Mishra

[Former Member · Accepted solution]

Hi Ambrish,

Standard interface is the one which is delivered by SAP.It is using CREMAS.CREMAS05 Idoc and mapping it to Supplier proxy structure.

The custom vendor contact interface, which we have developed is using CREMAS.CREMAS05.ZCREMAS05 in ESR.

In ID, Receiver determination is configured with CREMAS.CREMAS05 with one reeciver Sourcing system.

In interface determination, 2 OM are configured, one std and one custom.

Whenever CREMAS05 Idoc is triggered from ECC, its received in PI with root node as <ZCREMAS05>.

Std Interface is failing with mappind error on root node, while custom interface is executing successfully as its configured in ESR with CREMAS.CREMAS05.ZCREMAS05.

We can not configure std interface with CREMAS.CREMAS05.ZCREMAS05 Idoc as it is non editable.

Please guide how can we resolve this issue.

Thanks,

Ruchi

[ambrish_mishra · Accepted solution]

Hi Ruchi,

You will have to change the mapping for the standard supplier proxy interface to use CREMAS.CREMAS05.ZCREMAS05 at source side and change configuration objects with CREMAS.CREMAS05.ZCREMAS05 since the message type has changed.

For mapping, you can use a feature Correct Structural Inconsistencies to change the mapping. Configuration change should not take more than 5 mins

Hope it helps!

Ambrish

[Former Member · Accepted solution]

Hi Ambrish,

As you said, in ESR for I have copied std interface MM and OM, I have done design with CREMAS.CREMAS05.ZCREMAS05.

in ID, I have did config using the above Idoc itself.

Now there are 2 config present in ID:

one set of RD,ID,RA,CC for CREMAS.CREMAS05 Idoc.

and other one RD,ID, RA with CREMAS.CREMAS05.ZCREMAS05, which is using this newly created above OM.

Now when the Idoc is triggered from ECC, its going to std RD only, not the one with ZCREMAS05.and in turn failing in msg mapping(the std one CREMAS05).

Please guide.

Thanks,

Ruchi

[ambrish_mishra · Accepted solution]

Hi Ruchi,

You have to delete the old RD, ID and RA objects for CREMAS.CREMAS05 Idoc and test.

Hope it helps!

Ambrish

PS: If the old objects are transported to QA and other environments, then you have to keep a tab of this deletion list and transport it later so that the objects are deleted in the landscape.

[ambrish_mishra · Accepted solution]

Hi Ruchi,

One thing I misunderstood. Message type is the same but there is an extension. But you still need to delete the old objects and work with new objects (new RD, ID etc) and new mapping with extension because the same sender CREMAS.CREMAS05.ZCREMAS05 should cater to 2 inbound interfaces.

Hope it helps!

Ambrish

[Former Member · Accepted solution]

Hi Ambrish,

Thanks for your replies.

In ID, configuration worked with CREMAS.CREMAS05 only.

In ESR, I did config with ZCREMAS05, however in ID it is with CREMAS.CREMAS05 Idoc only, as Idoc is received in PI as CREMAS.CREMAS05 as sender interface.

Now both the interfaces are executing successfully.

Thank you all.

I am closing this thread.

Regards,

Ruchi

[former_member189420]

Hi Ruchi,

Is the standard CREMAS also being sent to PI? Is it failing in PI?

If this is only the issue with ECC then you should be able to handle it with standard msg type in outbound parameters.

What is the error message you are getting and where?

Best Regards,

Anand Patil

[rajasekhar_reddy14]

If extended IDoc generated newly added fields in IDoc(we02) and these fields were not visible in PI then issue with meta data,as satish suggested import meta data once again and import IDoc structure once again.

make sure that partner profiles configure for extended IDoc.

[Former Member]

Hi Ruchi,

Please delete the existing meta data in PI(Tcode IDX2) and reimport the new Idoc and try to perform the mapping for that added field.

Thanks,

Satish.