We've been seeing a lot of PO Change messages being sent from our SRM system, which turn our to be caused by the PO Response message we are receiving from the remote Ariba Networks system. As soon as a difference is detected between the received message and the original PO in SRM, the PO Change message is sent.
With the help of SAP support, we have found that the only change is in the Schedule line, specifically in the StartDateTime and EndDateTime fields. And this is where the fun starts.
We are only processing regular PO's with Ariba Networks. These PO's have a delivery date... no time. When we send the PO as an XML message to PI, during the mapping to XML the date from the PO is somehow converted into a date/time/timezone format: 2013-05-15T03:00:00-08:00
This message is received in Ariba Networks and there the supplier has to enter a delivery date. Once again, just a date. If the supplier in this example enters 15-05-2013, matching our delivery date and not changing it, this is then sent to PI. PI in turn has to convert it back to the date/time/timezone format, which it can't since it doesn't have any information on the original PO and the default RFC functions like BBP_PD_PO_GETDETAIL will only return the delivery date.
Leaving the field empty is seen as a change. Making up a time/timezone will almost never match the value in SRM and is therefore seen as a change. The logic in SRM that makes up the time/timezone is not a function that can be called in custom coding. We will never be able to replicate the date/time/timezone in SRM, so every PO Response will be treated as a change. Basically we're screwed... and I can't imagine we're the first client to encounter this problem.
What option am I overlooking here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.