on 10-16-2008 11:22 PM
Hi everyone,
We have an issue with the POR in SUS. The steps to replicate the error are the following:
1. We create a PO. This is sent to SUS.
2. In SUS the vendor creates a POR for that PO. In this POR there is not any change. The vendor confirms the same quantity, the same dates, the same price.
3. The POR is sent to SRM.
4. In SRM, the POR is approved.
5. THIS IS THE ISSUE. A change in the PO is registed in SRM and it is sent a XML message from SRM to SUS. This new message makes that the vendor will has to create a second POR. This is incorrect because the original POR does not have changes.
Do you know how to solve this issue??
We are working in SRM 5.5.
Thank,
Ivá
Hi Khan,
We reactivated the WF and tested again. We have the following behaviors (in all the cases we started with a SC and with direct materials):
1st: One POR without changes (correct):
1. The PO is created in SRM and is sent to SUS
2. In SUS, the POR is created without changes and is sent to SRM
3. The PO in SRM is not modified and is not sent a new message from SRM to SUS after the WF WS14500001
2nd: One POR with changes and one POR without changes (correct):
1. The PO is created in SRM and is sent to SUS
2. In SUS, the POR is created with changes and is sent to SRM
3. The PO in SRM is modified and is sent a new message from SRM to SUS
4. In SUS, the POR is created without changes and is sent to SRM
5. The PO in SRM is not modified and is not sent a new message from SRM to SUS after the WF WS14500001
3rd: More than one POR with changes and one POR without changes (issue😞
1. The PO is created in SRM and is sent to SUS
2. In SUS, the POR is created with changes and is sent to SRM
3. The PO in SRM is modified and is sent a new message from SRM to SUS
4. In SUS, the POR is created with changes and is sent to SRM
5. The PO in SRM is modified and is sent a new message from SRM to SUS
6. In SUS, the POR is created without changes and is sent to SRM
7. The PO in SRM is not modified and is sent a new message from SRM to SUS after the WF WS14500001
The 3rd case, the steps 6 and 7 are an infinitive loop.
Do you think that is correct to deactivate the WF WS15400001??
RG,
Ivá
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi khan and manu,
My issue was solved. I had to deactivate the WF "WS 14500001". Do you know what it is the purpose of this WF??? When it is used??
Thanks,
Ivá
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi,
good to hear that the issue is resolved.
that workflow you are mentioning is for the purchase order response > which has come in to SRM from SUS> and is started --> if there is no difference between Purchase order and purchase order response..
but that is not the correct reason , even with the workflow activated --> system should not send out --> the changed purchase order out.
can you please check the output at the purchase order level -->can you see two output's for the same purchase order??
looks like there is an extra purchase order output that is geneated -->in your system and that is the reason for the changed purchase order send out...
Hi Khan,
My answers:
1) In all our tests happend the same
2) Yes, in SUS is the XLM message "PurchaseOrderChangeRequest_In"
3) the status changes from "Confirmed" to "In Process"
4) we have SP 11
Thanks,
Ivá
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi,
let me know the following things
1) does it happen with all the purchase orders?
2) is the XML message of the type 'PurchaseOrderChangeRequest_in?
3) what happens to the status of the purchase order in SUS? is it changed from 'confirmed' to 'changed?
4) what is your support pack?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.