When the R/3 system uses a different time zone than the CRM system, then there might occur incorrect confirmation dates and times.
When the R/3 ATP check is used and when the order is exchanged from CRM with R/3. The following restrictions need to be considered when this process is setup in the system:
a) The R/3 ATP check itself can only confirm for a date but no time, so the returned confirmation time is 00:00 UTC. So when the CRM system sets the requested date to 03-April 09:00, and the ATP check can confirm the quantity for this date, it return the confirmed date 03-April 00:00 (UTC).
b)The R/3 system does does not handle dates in timestamps, so when the R/3 sends dates back into CRM there is no information to which
time zone this date refers.
General Information about the process:
There are 4 different time zones that are relevant for the sales order data exchange:
1. time zone of the CRM system
2. time zone of the R/3 system
3. time zone of the business partner master data of the ship to party
4. time zone of the RFC user in R/3, which is used by transaction SM59 for calling ATP in the R/3 system.
Internally the CRM stores dates (timestamps) in time zone UTC. For displaying data on the screens, CRM takes the time zone of the ship-to
party (if it is maintained and customized in the dates profile as reference object 'ship-to'), or the CRM time zone (if the reference object is 'system'), and converts the timestamp from UTC to this time zone.
In contrary to this, the R/3 system stores the schedule line dates in the time zone of the R/3 system. So it is necessary to convert the schedule line dates during order exchange.
The standard process looks like this:
* In CRM a sales order is created.
* If CRM 4.0 is used then automatically the requested delivery date and time is determined on header level and copied to item level when a product is entered.
* The requested delivery date (in UTC) is passed to the ATP service if the ATP check is active.
In case of:
- R/3 ATP (CRM 4.0) the date is passed to R/3, an availablity check is done and the confirmation date is returned to CRM.
The ATP check itself can only confirm for a date but no time, so the returned confirmation time is 000000 UTC.
If the precise (minutes exact) delivery and transportation scheduling is activated in R/3, exact times are returned for the schedule line dates. If an ATP check is involved, the delivery and transportation scheduling is still based on the material availablity date which is still only exact by dates and
not by times. The delivery and transportation scheduling takes into account also the time zone of the RFC user. To have correct
scheduling dates in CRM, the RFC user in R/3 needs to have the time zone 'UTC'.
Different time zones for the R/3 plant are not supported.
- ATP in APO can confirm the exact time if it is after 12:00 (UTC).
Confirmations before 12:00 UTC have to be mapped to 12:00 UTC due to internal restrictions in APO.
* The determined confirmation dates from the ATP service are converted back into a timestamp and put into the schedule lines.
* The schedule lines in the CRM order are displayed either in the CRM time zone, or, if maintained, the time zone of the ship-to party.
* Now the CRM order is saved and passed over to R/3. During the sales order upload, the schedule lines dates (requested delivery date,
confirmation date, goods issue date, loading date, transportation date, delivery group dates etc) are converted to the time zone of the
system in which they were determined. For example, if ATP was done in APO and APO returns as the reference time zone EST, then the dates
are converted to EST before being sent over to R/3. In case of the local R/3 ATP, the dates are converted to the R/3 time zone.
When only an ATP information scenario is used and not local ATP or the APO direct update szenario, only the requested delivery date is
converted and send to R/3, and the confirmation and scheduling dates are determined once again in R/3.
* If the dataexchange is customized to use a szenario X, Y, Z or A which makes the R/3 become the leading system, or when the R/3 ATP check is
used, then the schedule lines of the R/3 are sent back to CRM and a conversion of the R/3 time zone to the CRM time zone (or if maintained, the time zone of the ship-to party in CRM) is done.
Workarounds and solution:
a) It is recommended to propose the requested delivery date in CRM not in a more precise way than R/3 ATP can handle it. Because R/3 ATP confirms to 00:00 UTC, it makes sense to have the requested delivery date in CRM also set to 00:00 UTC (or the equivalent time in the CRM time zone).
If the confirmation date or time which is returned by the R/3 ATP check should be influenced, then the BADI CRM_AV_CHECK_APO_01
with method CHANGE_APO_RESULT_CRM_FORM can be used.
b) In table SMOFPARSFA in CRM you have to maintain the parameter TIME_ZONE_OLTP as described in note 566206. Then the CRM system
interprets the dates that are coming from R/3 (in the salesorder data exchange) to be in this time zone and converts them correctly
into the CRM time zone.
You can aslo have more ideas related to CRM