Error: Problem occurred in receiver agreement

[Former Member]

Hi All,

DeliveryScheduleConfirmation_Out message from SNC system is to be sent to ECC sytem.

For this we are trying to map this to ORDRSP.ORDERS05 IDoc.

Problem:

The message is failing in PI, with the error :

No standard agreement found

Problem occurred in receiver agreement.

But the receiver agreement is in place, as same receiver agreement is used for other scenarios also.

Also if we test the scenario in test configuration, with the payload of same message.Then it is able to find same reciever agreement.

I have already done cache refresh and tried recreating the agreement..

Request you to please help.

Regards,

Aditi

[former_member617132]

As this is very old post, but many of us might have faced this issue...

The general solution is that you can check the ID parts properly, generally the problem persist there as we miss some small things over there

As per my skill set ,the issue "No agreement found between the objects" may also happen because of some other reasons also.

i will say, give a check in opposite flow of the objects..

1) This issue may happen if u have altered anything in DT MT, from your ESR part, general ignorance from the Developer side is that they alter MM/OM but not the SI,which must be done even with dummy change followed by activation of the objects.

2) This may also happen because some object with the same name has been created earlier and    has been deleted partially(means not activated after deletion in change list)

3) you may re-start you java engine,in few cases it also helps

4) Clearing the Cache levels may also help some times( SLD also)

5) Also you can check for the services...

[Former Member]

Hi All,

In the repository part of this scenario,  We have created the graphical mapping under Z_XXX Software component and for that we have used DeliveryScheduleConfirmation_Out interface from namespace http://sap.com/xi/SNC/Global and SWC SNC 7.0 as Outbound interface  and ORDRSP.ORDERS05 also imported under same SWC as inbound interface.

Now if I remove this operation mappiing from interface determination. And instead of reprocessing the message, if we send in new confirmation.Then the receiver agreement error changes to

<SAP:Stack>Error: MSGGUID 8C124250BC32EC4AE1000000AC131B34: Tag MESSAGEHEADER found instead of tag IDOC BEGIN=</SAP:Stack>

    Regards,

    Aditi

[emir_morillo2]

Hi, I resolved this error.

I had an difference between the structure del SI and the structure the MM.

As I change one MT and adjust the MM but not the SI.

I adjust the SI and the problem was resolved.

Regards,

Emir Morillo.

[gagandeep_batra]

Hi aditi,

can you check for other scenario that use same sender and receiver are working fine?

and also check namespace for defined objects also.

you can try for restart java engine also.

Regards,

GAGan

[Former Member]

Hi Gagan,

Same receiver determination is used for other scenario also, and it's working fine there.

Regards,
Aditi

[udo_martens]

Hi Aditi,

do you have exactly a receiver agreement for:

• Sender Business System: BS_Sender
• Receiver Business System: BS_Receiver
• Inbound Interface: DeliveryScheduleConfirmation_Out
• of Namespace: http://sap.com/xi/SNC/Global

(there might be a missconfiguration, i suspect that because Business Systems BS_Sender/BS_Receiver are not named like usually productive system are called - and DeliveryScheduleConfirmation_Out sounds more like a outbound interface)

Compare these values pedanticly with the values you got from receiver agreement.

If you find there a missmatch then search a "missleading" receiver determination / interface determination, which may be had overwritten your configuration, it might be not associated to any scenario.

Regards,

Udo

[Former Member]

Hi Udo,

DeliveryScheduleConfirmation_Out is the outbound interface and ORDRSP.ORDERS05 is used as inbound interface.

Regards,

Aditi

[udo_martens]

Hi  Aditi,

ok, and your error message says:

<SAP:Stack>Problem occurred in receiver agreement for sender -BS_Sender to receiver -BS_Receiver,http://sap.com/xi/SNC/Global.DeliveryScheduleConfirmation_Out: No standard agreement found for , BS_Sender, , BS_Receiver, http://sap.com/xi/SNC/Global, DeliveryScheduleConfirmation_Out</SAP:Stack>

Oops, it is searching fo a receiver agreement containing an inbound interface DeliveryScheduleConfirmation_Out. Check SXMB_MONI: I presume, DeliveryScheduleConfirmation_Out was found as inbound interface. There must be an "old" interface determination annoying your process.

Regards,

Udo

[former_member190624]

Hi Aditi ,

Did u used any condition in receiver determination ?

Regards

Hari.

[Former Member]

Hi Hari,

No condition is used in Receiver Determination.

Regards,

Aditi

[MichalKrawczyk]

Hi,

is there any other message? usually it has a bit more like :

No standard agreement found for... and details here...

>>>>I have already done cache refresh and tried recreating the agreement..

can you check if the cache notifications from ID are green too - just in case?

Regards,

Michal Krawczyk

[Former Member]

Hi Michal,

The exact  error is:

  <SAP:AdditionalText>No standard agreement found for , BS_Sender, , BS_Receiver http://sap.com/xi/SNC/Global, DeliveryScheduleConfirmation_Out</SAP:AdditionalText> 

    <SAP:Stack>Problem occurred in receiver agreement for sender -BS_Sender to receiver -BS_Receiver,http://sap.com/xi/SNC/Global.DeliveryScheduleConfirmation_Out: No standard agreement found for , BS_Sender, , BS_Receiver, http://sap.com/xi/SNC/Global, DeliveryScheduleConfirmation_Out</SAP:Stack>

     And all the notifications in cache status overview are in green.

     Regards,

     Aditi

[Former Member]

Hi Aditi,

Please crosscheck all your configuration objects and try to reactivate.Also go through below links it may be helpfull for you.

http://scn.sap.com/thread/1896424

http://scn.sap.com/thread/1689669

Regards,

$HRI

[rajasekhar_reddy14]

Delete receiver agreement and create it once again.

[MichalKrawczyk]

Hi Raja,

>>>I have already done cache refresh and tried recreating the agreement..

he already did that

Regards,

Michal Krawczyk