Many Fortune 500 firms use SAP Advanced Planning and Optimization (SAP APO) as a global planning system across North America, Europe, Asia Pacific, and other regions. With the advent of globalization, technology enablers such as SAP APO and SAP ERP Central Component (SAP ECC) have helped usher in the era of central planning and local production. For example, it is now more economical to produce a raw material, such as an active ingredient in India, and air freight it to global formulation sites in Germany, the US, or Canada than to do it all domestically. You therefore need to consolidate supply and demand from all formulation sites using a global planning tool, SAP APO, while employing SAP ECC for production execution support. How do you operate SAP APO, along with SAP ECC, in multiple countries and across time zones?

I’ll explain how to manage this seemingly trivial but important parameter of time zones to operate a global planning system using an example company called ABC Limited. The screenprints are based on SAP Supply Chain Management (SCM) 5.0 and SAP ECC 6.0 systems as of August 2008. The system time triggers a start date and time for the scheduling of background processes using process chains or batch jobs. For more background, the online SAP help and SAP Notes are a good reference for SAP package-specific information. I will also discuss my experience with time zones during client SAP implementations over the last 10 years.

Business Scenario

ABC Limited has its headquarters in Frankfurt, Germany, and operations in Germany, Switzerland, the US, Canada, China, and India. The company uses a single instance of SAP APO for global planning and has two SAP ECC systems, one in Europe and the other in North America.

Frankfurt, DE (Central European Time [CET] time zone) hosts the SAP APO database server and the users are in Frankfurt, DE (CET), Basel, CH (CET), San Diego, US (Pacific Standard Time [PST]), Toronto, CA (Eastern Standard Time [EST]) and Pune, IN (Indian Standard Time [IST]). The SAP ECC database servers are hosted in Frankfurt, DE (CET) and San Diego, US (PST). The SAP APO planning systems works with the two SAP ECC transaction systems that create data, such as production orders. The SAP APO system uses Core Interface (CIF) to import data from the two SAP ECC systems. The company also uses scheduler software for batch job scheduling in SAP and non-SAP legacy systems.

To support this scenario, the SAP APO and SAP ECC systems need to be configured for time zones. The settings are similar in SAP APO and SAP ECC, but the primary system for master data is always SAP ECC. As the core interface, CIF transfers master data from SAP ECC to SAP APO. You need to configure the time zones and locations in SAP ECC first. There is no automatic synchronization of time zone settings between SAP ECC and SAP APO since the two database servers are in different locations, Frankfurt, DE, and San Diego, US. Ensure that the settings are replicated appropriately in the SAP APO system.

If the time zone is not populated for an object, such as plant, in SAP ECC, the SAP APO system calculates the time zone from the country (T001W-LAND1) and region (T001W-REGIO) and stores it in /SAPAPO/LOC-TZONE. Transaction data, such as production orders from SAP ECC, are transferred to SAP APO as per the time zone of the SAP ECC plant. If you change the time zone in SAP ECC, you must execute a new initial transfer of the master and transaction data via the CIF.

I will now examine the following topics about time zones to explain the technical and configuration parameters:

1. How the SAP system defines a time stamp

2. General settings that affect time zones

3. Configuration of time zones

4. User settings for time zones

5. Checking the time zone function

6. Calculation of an object’s time zone

7. Master data settings for time zones in SAP APO

8. Background job scheduling and time zones

1. How the SAP System Defines a Time Stamp

In my business scenario, a planner in Frankfurt, DE, creates a planned order in SAP APO with a local time of 3:00 pm (CET) on November 11, 2008. An SAP ECC user in Toronto, CA, (EST) then converts this to a production order at 11 am on November 11, 2008. How does the system store these events and the time stamp?

First, it uses a 24-hour clock with the local time of the object, in this case, the planned order, and does not support displaying times as am or pm to avoid confusion. A time zone code needs to be added to the local time stamp. For example, the planner in Frankfurt, DE, created the planned order in SAP APO at 15:00:00 CET.

Second, it is not enough to store only the time. You need to combine the date and time to create a time stamp. For example, the planned order creation time is 11 Nov 2008 15:00:00 CET.

Third, the time and date of any transaction or event converts from local time to Universal Coordinated Time (UTC) and is stored. For example, 11 Nov 2008 15:00:00 CET converts to 11 Nov 2008 14:00:00 UTC and is stored as 11.11.2008 14:00:00.

The time stamp has a different external and internal representation. The external representation is from the user settings, and the total output length is 19 characters. For example, DD.MM.YYYY <separator> hh:mm:ss (31.12.2008 15:00:00) or MM/DD/YYYY <separator> hh:mm:ss (12/31/2008 15:00:00).

Internally, the system creates a 14-character time stamp (eight characters for date and six characters for time). It is possible to sort the time stamps correctly when stored based on date (year-month-day) and time (hour- minute-second). A time stamp takes the form YYYYMMDDHHMMSS. Table 1 lists some of the system fields for the date and time.

SAP and other software packages, such as MS SQL server, use UTC as a reference time. UTC replaced Greenwich Mean Time (GMT) on January 1, 1972 as the main reference time scale and does not change with Daylight Saving Time (DST). The system can compare times and use them in calculations by converting all local times to UTC. For faster conversion from local time to system time, the time zone function is fully integrated into the SAP system kernel. Table 2 lists some of the time zone tables in the ABAP Dictionary.

2. General Settings That Affect Time Zones

After completing the installation of an SAP system, make some basic and important General Settings in Customizing in the transaction code SPRO. These settings, such as country codes, currencies, and units of measurement, affect all modules, including time zone. The Define Countries in SAP APO and SAP ECC systems and Insert Regions are especially relevant for time zones as you use the two codes in Maintain Geographical Assignments of a time zone. States or provinces are defined as regions. Review these regions to ensure all your states have defined time zones and can be defined at the country- region level.

3. Configuration of Time Zones

You can perform the master configuration for the time zone function in an SAP system in Customizing in transaction code SPRO. This is spread across three nodes: how to maintain system settings, a new time zone, and geographical assignments.

In the Maintain System Settings node, you need to activate the SAP Time Zone function and fix the system time zone based on the location of the database server. In the second node, you define the time zones and DST rules. Any offsets from UTC can be defined here. In the third node, Maintain Geographical Assignments, you assign time zones to the country or region defined in general settings (Figure 1).

Figure 1

Time zone general settings in transaction SPRO

Maintain System Settings

The technical parameters based on hardware are set at this node and are client independent. The system time zone is the time zone of the database server, which you can use to interpret the local time of a system and convert it into UTC (Figure 2).

Figure 2

System settings in transaction STZAC

The database server has a time zone and UTC offset similar to your PC operating system. If the operating system has incorrect time zone settings, the SAP system time will be incorrect as well, as it uses the date and time from the operating system. Refer to SAP Note 118508 (Time settings in the operating system) for details.

DST changes cause grief to many firms because the servers need to have a start and stop for the hardware. At the end of DST, a time interval (generally one hour) occurs twice (“double hour”). Some companies need to have a downtime of two hours, from 2:00 am (DST) until 3:00 AM (standard time), to take care of their DST transition. Refer to SAP Note 102088 (Reducing downtime when changing from summer to winter time) for details. For heterogeneous system landscapes, or if you are not sure when your servers are switching from DST to standard time, refer to SAP Note 398374 (Problems when converting summer time<-> winter time) on how to transition to DST time.

Consider using UTC as your system time zone and, if possible, for end users. The UTC does not consider DST and remains unchanged during summer. You can apply the UTC time zone with no DST rules as a solution so the database server does not need a downtime. Users can set their profile with the CET time zone that uses UTC+1 and the DST rule to interpret the local time. This can also help you run batch job schedules more efficiently during the DST swap, as I explain later in this article.

If there is no address or the address has no time zone or country/region, you may use the User’s Default Time Zone field. I will later provide the example of an object, plant master, to show how the system determines the time zone through a sequence of four steps. For global installations of SAP, use the time zone the majority of users prefer, EST, as the default time zone.

It is not necessary to use the third flag, Time Zones Active, because the SAP kernel now runs the time zone function. Specific time zone objects (time zones and DST rules) can be activated or deactivated in transaction code STZBC.

So far so good, but how do you check for errors? The Basis team can run the ABAP report TZCUSTHELP after installation of a SAP system (Figure 3). Input the current local time, validate the time zone setting for the operation system, and check that the output UTC date and time are correct. The UTC offset is defined in seconds, for example 18000 = five hours behind. You can also check the operating system settings or the system time zone to remove the errors.

Figure 3

Output of ABAP report TZCUSTHELP

How to Maintain or Create a New Time Zone

SAP pre-delivers the standard time zones, DST rules, and so on, but recommends that you check the time zone and DST rules as they change due to national or regional laws. Refer to SAP note 198411 (Current data and information about time zones) to update time zones.

For SAP Basis 6.40 and higher, you need to execute the report TZCUSTIM to upload the time zone data into your system from a local PC file. Then execute report TZONECHECK to check for inconsistencies (Figure 4). The settings are client dependent and need to be checked for all clients in SAP ECC. In certain cases, you may need to create a custom time zone using a series of five steps as explained at https://help.sap.com. There may be errors for country and region that you will need to fix in the time zone configuration settings, as shown in Maintain Geographical Assignments.

Figure 4

Output of report TZONECHECK

How to Maintain Geographical Assignments

Time zones in country/region are defined in the next node. The general settings that define the country and region codes come together here to assign the time zone. Time zones in country/region are modified in transaction STZGC, or from the IMG, choose SAP NetWeaver>General Settings>Time Zones>Maintain Geographical Assignments (Figure 5).

Figure 5

Time zones in country/region in transaction STZGC

In these nodes, select geographical assignments at country, regional, or postal code level. Be sure to use the country key that SAP provides when assigning a country to a time zone.

Many countries, such as Canada and Australia, have multiple time zones. It is important to review and update the time zone under the IMG node Time zones in country/region to EST or PST. If a region is absent, the default time zone of a country may be incorrect. For example, the EST default time zone may be applied to Vancouver, British Columbia, instead of PST. Refer to SAP Note 1156567 (geographical assignment of the time zones for Canada).

4. User Settings for Time Zones

After the Basis team creates a user ID, the user profile assigns a time zone. If the user profile does not select a time zone, the system uses the default time zone defined in system settings. For example, a user in San Diego, US, will see the Germany CET time in the SAP APO Production Planning (PP)/Detailed Scheduling (DS) planning board. It is very important to update the system to the correct time zone as most people are more comfortable in seeing their data in local time, such as PST, rather that UTC.

Review your SAP user profile from System>Administration>User profile>Own data. Check your time zone in the Personal Time Zone field on the Defaults tab. Update the personal time zone if it’s incorrect, and also verify the system time zone (Figure 6).

Figure 6

Change personal time zone

The update of the PC clock (Figure 7) is not sufficient to update the SAP user profile. For example, a user traveling from a New York project site to San Francisco needs to update his SAP user profile in addition to the PC operating system clock. The same concept applies to the operating system of the database server that needs to have the correct time zone of GMT-5.00 with DST. If you are using a DB2 database server, refer to SAP Note 353529 (DB2/390: Switching from daylight to standard time) for details. Depending on the specific operating system, you might need to update the time zone and DST rule.

Figure 7

PC clock with DST update

5. Checking the Time Zone Function

Use the user settings above and system parameters to check the time zone function in your system. From the SAP main header menu, choose System>Status. When you correctly configure the time zone function, SPRO configuration, and user profiles, the usage data section of the system status dialog box correctly displays system time and local time. If you are in a different time zone than the system, the usage data displays the user’s time zone, local time, and local date if the local date — for example, 03.09.2008 — is different from the system date, 04.09.2008 (Figure 8).

Figure 8

System status with user time

6. Calculate an Object’s Time Zone

Objects in an SAP system are master data, such as plant/location master or work center/resource. You must adhere to certain prerequisites to determine the time zone for an object. Refer to https://help.sap.com and search for “Determination of an Object’s Time Zone” for details. To determine the time zone for the object, the SAP system follows a series of decision rules:

• Check the object's time zone attribute first.
  
  
• Check the object's country and region attributes.
  
  
• Check the object's country data (a required field).
  
  
• If the system cannot determine the object's time zone through the first three steps, it uses the default time zone of the system's database server.

In my scenario with ABC Limited, I used the example of the plant in Toronto. I populated the time zone attribute as EST and this is accepted in rule (Figure 9). If this is absent, the system checks the country and region attributes, Canada (CA) and Ontario (ON) for example, and calculates EST as the time zone. Otherwise, the system uses the default time zone for the country, such as EST.

Figure 9

Specify the time zone

7. Master Data Settings for Time Zones in SAP APO

The SAP APO time zone settings are spread across master data objects, such as calendar, plants, and resource master. They affect transaction data like planned orders or production orders that have been created. Take care to define time zone only when required, as master data can be used across locations and time zones.

• Time stream or calendar is defined with the transaction code /SAPAPO/CALENDAR in SAP APO.

The field Time Zone is optional, but I recommend that you leave it blank. Leaving the field blank allows you to use the calendar in different locations across time zones (Figure 10). The disadvantage of not selecting a time zone is that you cannot correctly model the DST changes in summer and winter; however specifying it can lead to other issues, which is why I don’t recommend populating it.

Figure 10

Populate the time zone

When you create a new plant or developmental component (DC), you can then assign the calendar to the location for production or shipping purposes (Figure 11). The selected location will then apply to all products shipped from that location or for any resource masters defined at the location for producing finished goods.

Figure 11

Assign the calendar

Specify the Location time zone, EST for Toronto for example, on the General tab of the location master (Figure 12). You can use the Location to calculate the time difference of the time zone relative to UTC and the DST difference. The resource masters/work centers (master data created to define machines) created at this location inherit this time zone. If you make changes to the location time zone later, it affects all the resource masters assigned to that location.

Figure 12

Location time zone

• Resource master data is created with the transaction code //SAPAPO/RES01 or APO>Master Data>Resource> Resource.

Figure 13

Production Process Model (PPM)

Define the time zone for display, and then choose either Time zone of location, Local time zone of user, or All times displayed in UTC. If you are working on a truly global model across continents, use All times are displayed in UTC to ensure that all your planners across the globe are using the same reference point (Figure 14).

Figure 14

Master Data – Supply Chain Engineer

8. Background Job Scheduling and Time Zones

Background jobs are used extensively for operating an SAP APO system and often run at different times for each region, such as Europe or North America, when users are not logged on to the system. You can execute background jobs to, for example, load data to an InfoCube, generate a statistical forecast, or execute Supply Network Planning heuristics for a large amount of data. You can create these jobs as batch jobs using transaction code SM36 or as process chains using transaction code RSPC. Refer to my article “Step-by-Step Guide to Create and Use Process Chains in APO” in Volume 5, Number 4 of SCM Expert at www.SCMexpertOnline.com. In either case, schedule the job to run in the background at a certain date and time.

Some questions may come up when you’re setting your system to perform these background jobs: Will the system use the local time or the system time to run the job? What happens to the start time when DST changes start in Europe or North America? All background jobs use the system date and time to start the job. This is the database server time, not the local time. You can create the job using transaction code SM36 and then release it to start at the system time as shown at 22:00 CET (Figure 15).

Figure 15

System date and time to start the job

In my business scenario, Frankfurt, DE, (CET) hosts the SAP APO database server. I therefore need to run background jobs at 17:00:00 CET for the users in Europe (CET) and at 22:00:00 CET (16:00:00 EST) for the users in North America (EST). Batch windows are getting smaller. For example, North American batch jobs have to finish before users in Asia log in. Therefore, the jobs need to be scheduled closer and run faster.

To add to the complication, DST changes come in March and November in many countries that observe DST. The recent changes in 2007 from the US administration as a result of the Energy Policy Act of 2005 have moved up the start of DST. DST now starts on the second Sunday of March in the United States and Canada, but Europe has not changed its start time. This changes the gap between when North America and Europe start DST from two to three weeks.

In one of my global SAP APO projects, after two months of a smooth go-live in January, the batch jobs for users in Boston, MA, started strangely by running one hour late in March. It took my team a few hours to find the reason. The SAP APO database server was based in Frankfurt, DE, with CET as the system time zone. The normal time difference was six hours between CET and EST. However, during the intermittent period when DST kicked in for North America, the time difference became five hours. The jobs started running late by one hour, and the start time had to be manually moved up by one hour during the intermittent period. Once DST kicked in for Europe, the time difference was back to six hours, and the job had to be rescheduled to the original time.

Manoj Ambardekar

Manoj Ambardekar has more than 20 years of IT and manufacturing experience with firms such as IBM, Infosys, PricewaterhouseCoopers, and Siemens Information in the CPG, brewing, and process industries. He has more than 14 years of experience with SAP APO and SAP ECC with specialization in logistics. He has played multiple roles as functional and technical lead as well as project manager. He has implemented SAP applications at more than 12 large- and medium-sized projects since 1998. Manoj is a chemical engineer certified in production and inventory management (CPIM) from APICS – USA, and holds a master’s of engineering (industrial) degree from B.I.T.S. in Pilani, India. Manoj works on both large and SME clients to implement SAP as both a configuration SME in APO/ECC PP-MM/Solution Manager and project manager/team lead. He specializes in supply chain management solutions using software such as SAP APO, SAP SCM, SAP ECC, SAP Solution Manager, and business intelligence for North American clients.

You may contact the author at manoj_bits@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.