Sailing the ATP storm
ATP integration between APO and R3 is a mess. Whenever possible, following this simple recipe avoids many problems:
1) Don't set any restriction on receiving hours at the customer
2) Change the default requested time in sales orders to some normal value like 9 am.
In sales order the proposed delivery time can be changed on exit MV45AFZZ, in userexit_move_field_to_vbep. For stock transport orders it can be changed in BADI ME_PROCESS_PO_CUST.
1) Don't set any restriction on receiving hours at the customer
2) Change the default requested time in sales orders to some normal value like 9 am.
In sales order the proposed delivery time can be changed on exit MV45AFZZ, in userexit_move_field_to_vbep. For stock transport orders it can be changed in BADI ME_PROCESS_PO_CUST.
Labels: atp
posted by pvl at 6/09/2006
6 Comments:
Both the tips were good. But I am not very sure why did u give the second tip. Please explain the significance.
I would be really happy if you could reply to my email id. ankurgupta83@yahoo.com
Cheers
The point is that by default ATP sets the availability time to the earliest possible time. So if you do not set any restrictions you will get many orders confirmed to 00:00:00. The problem is not the 00:00:00, but the fact that the requirement is set in the edge of the constraint time space. Even if you set receiving times between, for example, 9:00 and 17:00, ATP will try to put the requested time at 9:00 (still the edge of the constraint time space).
So if there is some change backward, since the time is already at the edge, the day will shift. What can make the backward change? Well, first of all, rounding problems. I've
seen many cases where the time changed to 23:59:59. Also the summer/winter daylight saving times (there seems to be some integration problems in this area). Also you can see that there are many "corner cases" by reading OSS 443500 (oss link through the hotoss site).
And the main point: why put the requested time at the edge? For many business it is the same to have 10:00 or 9:00 in the requested time. So a shift in the time is not problematic. But a shift in the day can be very dangerous since the material availability date that is the key information for the planning of the transports.
So if you change the requested time to a point in the middle of the interval you will be less vulnerable to the shift problem.
Regards,
pvl
Hi there, not sure if this relates directly to this thread however I am hoping you may be able to help:
We are looking to move a client across from R3 ATP to APO GATP. Within the R3 environment the client currently makes extensive use of Route Schedules. These Route Schedules are referenced during the standard R3 ATP check.
With Route Schedule functionality in R3 you can specify for a given Shipping Point / Route (and even down to Ship-to) relationship that, for example, Good Issue can only happen every Tuesday at 8.00am. In this way if you have a truck that runs a certain route each Tuesday then any orders for customers on the route have their delivery dates confirmed based on the fact that Good Issue can only occur on Tuesdays at 8.00am.
We are unable to identify within APO GATP functionality how to replicate the R3 Route Schedule functionality and cannot identify any SAP instruction on this either in the online help or in OSS messages.
The link below provides information regarding the functionality provided by Route Schedules but we cannot identify any documentation that clearly defines a logical replacement for this functionality in APO GATP.
I have been researching Dynamic Route Determination functionality which looks to be component of TPVS that GATP can utilize, however we are concerned at introducing more complexity than is required by heading down the TPVS path, and we are unsure in any case based on the documentation whether it will meet the requirement. Further the client is still on R3 45b, Dynamic Route Scheduling requires atleast R3 46c.
Can you provide any insight to whether Dynamic Route Determination would be an effective replacement for the R3 Route Schedule functionality.
I have also identied functionality in APO with similar terminology as the R3 Route Schedule ie Schedules, Itinerary's etc (refer second link to SAP Help below) but this functionality looks to relate to TPVS optimiser only and not to ATP Scheduling.
Link to R3 Route Schedule Help:
http://help.sap.com/saphelp_47x200/helpdata/en/dd/560de1545a11d1a7020000e829fd11/frameset.htm
Link to APO Schedule Help:
http://help.sap.com/saphelp_scm50/helpdata/en/50/0751465f2163438e478889b1e52794/frameset.htm
Thanks,
Hi Paul,
Scheduling in APO is mainly done with condition tables you create for pick, load, transport and unload times. Here is the link for the documentation
http://help.sap.com/saphelp_scm50/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/frameset.htm
It's not a one to one match, but since APO allows more configuration possibilities it should not be a problem to migrate from R3.
The only special case I remember is that if you use transport times with calendars defined in the R3 routes you have to model your transport times in APO using transportation lanes.
Hope I could help.
Regards,
Pedro
Paul, Pedro,
At my current customer we're actually using the APO scheduling using condition techniques. It's indeed very flexible, due to the conditions. And using some userexits (APOSC002) it is possible to replace current calendars by your own.
However scheduling using the condition technique doesn't allow you to use hub-and-spoke logic. For example using different holiday calendars per country in your route.
I've investigated configurable process scheduling, but that's to be used only in transportation and shipment scheduling. Have any of you investigated this dynamic route determination in TP/VS?
Thanks,
Arjen
Hi Arjen,
Yes you are right, with APOSC002 we can set calendars and do all kinds of hacks on the scheduling. Thanks for making reference to that exit.
I think (but never tried it) that you can model the hub with dynamic route determination. By using very large transport capacities you get the scheduling results and make the transportation constraints irrelevant.
Regards,
Pedro
Post a Comment
<< Home