The check mode derived from the product master record and the business event determines the type and scope of the checks to be carried out. In addition, the check mode controls consumption using the forecast.
The SD (R/3) uses the requirements class of the requirement as check mode. As of R/3 Plugin 2000.1, the requirements class (via the strategy group in the material master) is transferred to the location-specific APO product master (tab page ATP). No plausibility check takes place.
Therefore, you should not enter any other check mode in the product master as the check mode in the product master must correspond to the requirements class from the R/3 System
(1) Through the MRP group or strategy group in the MRP view of the material's master record
(2) Through the item category and the MRP type in the MRP view
The item category is derived from the item category group in the Sales view of the material master record and from the order type of the sales document. Together with the MRP type in the MRP view of the material master record, the item category determines what requirements type is selected. The advantage of this method is that the selection of the requirements type depends on the business process (such as quotation, sales order, or repair).
Sunday, December 10, 2006
Solution-TimeZone-Issue in APO GATP Scheduling
Problem Description: (OSS Note 300951 describes a similar problem)
When orders are placed in R/3 for GATP-relevant materials, scheduling dates are calculated incorrectly. During backward scheduling, the Goods Issue Date and MAD are scheduled one day earlier than they should be. During forward scheduling, the Requested Delivery Date (confirmed date) is scheduled one day later (or earlier, depending on the time zones involved).
This is caused during the time zone conversion that occurs when R/3 sends schedule dates to APO and receives schedule dates back from APO.
**Assuming there are no working times maintained in R/3 for the Ship to Party Unloading Point calendar and the Shipping point -which means that only dates are considered. **
The R/3 interface recognizes that APO uses time, and sends time to APO.
1. For backward scheduling, the time used = 00:00:00.
(a) Just before sending the data, R/3 converts the Requested Delivery Date from the customer’s( Ship to Party) time zone to UTC, the time zone used in APO.
(b) APO calculates the MAD and Goods Issue date.
(c) When these dates are sent back, R/3 converts them using the Plant's time zone.
2. For forward scheduling, the time used = Shipping Point time.
(a) Just before sending the data, R/3 converts the Material Availability Date from the Plant's time zone to UTC, the time zone used in APO.
(b) APO calculates the Goods Issue date and the Confirmed Delivery date.
(c) When these dates are sent back, R/3 converts the Goods Issue Date using the Plant's time zone and the Confirmed delivery Date based on the Customer's (Ship to Party) time Zone.
The problem occurs when the customer and plant are in different time zones. Depending on the time zones involved, the date will be shifted one day.
Description of time conversion between R/3 and APO:
The interface of the SAP APO system is usually defined so that all dates are interpreted in the UTC time zone. This means that external OLTP systems (such as SAP R/3) supply scheduling data to the interface in the UTC time zone. The scheduling data is saved in the SAP APO system in the UTC time zone in the database. Note that applications within the SAP APO system may use a time conversion to display this scheduling data, rather than display it directly within the UTC time zone. However this depends on the Support Package status.
The dates within the SAP R/3 sales order and deliveries are dates in local time zones of the related objects. This means that dates within the time zone of the delivering plant are managed within the delivering plant.
The delivery date is managed in the time zone of the ship-to party.
Before they are sent to the SAP APO interface, the R/3 dates are converted from the local time zones to the UTC time zone. This conversion is based on the data stored in the time zone customizing. The time zone function is not generally available in R/3.
The time zones for the date conversion in the SAP R/3 system are determined for the plant according to the following priorities (Material Availability Date based on Plant Time Zone)
1. Time zone in the plant master data
2. Based on the region and country in the plant master data
3. Based on the country in the plant master data
4. Based on the region and country from the plant's address master data
5. Based on the country from the plant's address master data
6. Time zone of the system
The time zones for the date conversion in the SAP R/3 system are determined for the ship-to party according to the following priorities (Delivery Date based on Ship to party time zone)
1. Based on the zip code number and country in the customer master data
2. Based on the region and country in the customer master data
3. Based on the country in the customer master data
4. Time zone of the system
Example Scenarios in a Global Environment:
The following scenarios describe the specific problems that occur during backward and forward scheduling in different time zone situations.
A. Customer Time & Plant Time behind UTC ----- US
A.1 Customer Time( MST) ahead of Plant Time( PST)
1. Backward Scheduling: -1 day
Goods Issue Date and MAD always show 1 day backward
2. Forward Scheduling: +1 day
The requested delivery date is pushed 1 day forward when time is end of day
2. Forward Scheduling: -1 day
The requested delivery date is moved 1 day backward when the time is early in the day.
Forward Scheduling: 0 days
There is no problem with dates when time is later in the day
Customer Time& Plant Time ahead of UTC ----- Europe
B.1 Customer Time (EET) ahead of Plant Time (CET)
1. Backward Scheduling: -1 day
Dates are shifted 1 day backward (earlier).
2. Forward Scheduling: +1 day
The requested delivery date is pushed 1 day forward when time is late in the day
Forward Scheduling: 0 days
There is no problem with dates when time is earlier in the day.
B.2 Customer Time (CET) > Plant Time (EET)
1. Backward Scheduling: 0 days
No change in Scheduling dates
2. Forward Scheduling: -1 day
The requested delivery date is moved 1 day backward when time is early in the day
Forward Scheduling: -1 day
There is no problem with dates when time is later in the day.
SOLUTIONS:
There are 2 solutions. One of them requires a Modification to the standard SAP Code and the other requires a User Exit and Configuration of Time Stream Calendars in APO.
YOU CAN CONTACT ME FOR THE SOLUTION ON MY EMAIL ID: KUMAR.SCM2000@GMAIL.COM
When orders are placed in R/3 for GATP-relevant materials, scheduling dates are calculated incorrectly. During backward scheduling, the Goods Issue Date and MAD are scheduled one day earlier than they should be. During forward scheduling, the Requested Delivery Date (confirmed date) is scheduled one day later (or earlier, depending on the time zones involved).
This is caused during the time zone conversion that occurs when R/3 sends schedule dates to APO and receives schedule dates back from APO.
**Assuming there are no working times maintained in R/3 for the Ship to Party Unloading Point calendar and the Shipping point -which means that only dates are considered. **
The R/3 interface recognizes that APO uses time, and sends time to APO.
1. For backward scheduling, the time used = 00:00:00.
(a) Just before sending the data, R/3 converts the Requested Delivery Date from the customer’s( Ship to Party) time zone to UTC, the time zone used in APO.
(b) APO calculates the MAD and Goods Issue date.
(c) When these dates are sent back, R/3 converts them using the Plant's time zone.
2. For forward scheduling, the time used = Shipping Point time.
(a) Just before sending the data, R/3 converts the Material Availability Date from the Plant's time zone to UTC, the time zone used in APO.
(b) APO calculates the Goods Issue date and the Confirmed Delivery date.
(c) When these dates are sent back, R/3 converts the Goods Issue Date using the Plant's time zone and the Confirmed delivery Date based on the Customer's (Ship to Party) time Zone.
The problem occurs when the customer and plant are in different time zones. Depending on the time zones involved, the date will be shifted one day.
Description of time conversion between R/3 and APO:
The interface of the SAP APO system is usually defined so that all dates are interpreted in the UTC time zone. This means that external OLTP systems (such as SAP R/3) supply scheduling data to the interface in the UTC time zone. The scheduling data is saved in the SAP APO system in the UTC time zone in the database. Note that applications within the SAP APO system may use a time conversion to display this scheduling data, rather than display it directly within the UTC time zone. However this depends on the Support Package status.
The dates within the SAP R/3 sales order and deliveries are dates in local time zones of the related objects. This means that dates within the time zone of the delivering plant are managed within the delivering plant.
The delivery date is managed in the time zone of the ship-to party.
Before they are sent to the SAP APO interface, the R/3 dates are converted from the local time zones to the UTC time zone. This conversion is based on the data stored in the time zone customizing. The time zone function is not generally available in R/3.
The time zones for the date conversion in the SAP R/3 system are determined for the plant according to the following priorities (Material Availability Date based on Plant Time Zone)
1. Time zone in the plant master data
2. Based on the region and country in the plant master data
3. Based on the country in the plant master data
4. Based on the region and country from the plant's address master data
5. Based on the country from the plant's address master data
6. Time zone of the system
The time zones for the date conversion in the SAP R/3 system are determined for the ship-to party according to the following priorities (Delivery Date based on Ship to party time zone)
1. Based on the zip code number and country in the customer master data
2. Based on the region and country in the customer master data
3. Based on the country in the customer master data
4. Time zone of the system
Example Scenarios in a Global Environment:
The following scenarios describe the specific problems that occur during backward and forward scheduling in different time zone situations.
A. Customer Time & Plant Time behind UTC ----- US
A.1 Customer Time( MST) ahead of Plant Time( PST)
1. Backward Scheduling: -1 day
Goods Issue Date and MAD always show 1 day backward
2. Forward Scheduling: +1 day
The requested delivery date is pushed 1 day forward when time is end of day
Forward Scheduling: 0 days
There is no problem with dates when Order Entry Time is earlier in the day
A2. Customer time (PST) behind Plant time (EST)
1. Backward Scheduling: 0 days
No change in the Scheduling dates.
There is no problem with dates when Order Entry Time is earlier in the day
A2. Customer time (PST) behind Plant time (EST)
1. Backward Scheduling: 0 days
No change in the Scheduling dates.
2. Forward Scheduling: -1 day
The requested delivery date is moved 1 day backward when the time is early in the day.
Forward Scheduling: 0 days
There is no problem with dates when time is later in the day
Customer Time& Plant Time ahead of UTC ----- Europe
B.1 Customer Time (EET) ahead of Plant Time (CET)
1. Backward Scheduling: -1 day
Dates are shifted 1 day backward (earlier).
2. Forward Scheduling: +1 day
The requested delivery date is pushed 1 day forward when time is late in the day
Forward Scheduling: 0 days
There is no problem with dates when time is earlier in the day.
B.2 Customer Time (CET) > Plant Time (EET)
1. Backward Scheduling: 0 days
No change in Scheduling dates
2. Forward Scheduling: -1 day
The requested delivery date is moved 1 day backward when time is early in the day
Forward Scheduling: -1 day
There is no problem with dates when time is later in the day.
SOLUTIONS:
There are 2 solutions. One of them requires a Modification to the standard SAP Code and the other requires a User Exit and Configuration of Time Stream Calendars in APO.
YOU CAN CONTACT ME FOR THE SOLUTION ON MY EMAIL ID: KUMAR.SCM2000@GMAIL.COM
Subscribe to:
Posts (Atom)