When a global company has a period-end close, a great deal of coordination needs to occur among the independent locations to make sure that tight deadlines are met. Often, month-end issues and misunderstandings occur because of timing differences, including confusion over:

• When close activities should be performed
  
  
• Timing of batch job start times
  
  
• Reading timestamps for SAP transactions
  
  
• When a report output was created

Let’s look at an example of the confusion created by lack of clarity as to when reports and batch jobs were run in an organization with users in multiple time zones: A regional analyst calls the head office saying a report is wrong. The regional office has created a Report Writer extract, and it looks as if an allocation run has not completed. The head office investigates, looks at the batch job, and sees that it did complete. The head office runs the report and everything is all right. What happened? The regional site ran the report before the allocation run completed. However, the Report Writer report shows the local time in the header, and it looks as if the report ran after the allocation run.

Making sure the headquarters office and regional sites are clear on timing and time zones can help prevent this type of confusion. The risk of this type of error can be greatest for users who are relatively close — for example, U.S. Eastern Standard Time (EST) and Pacific Standard Time (PST). As times may vary only by a few hours, it’s easier to confuse local and system times.

Figure 1 shows a global close for a company with its headquarters office on the U.S. East Coast. The system time is EST. A regional company has a process going on during its daytime, which is overnight for the headquarters office. If a batch job run during the night at headquarters takes 20 minutes longer than normal, the subsidiary might run a report before the job completes and think an error has occurred. The region then calls the head office to investigate. The head office, suspecting that this is a timing issue, asks the region to send a copy of the report. The incorrect report is marked 07:00 a.m. 6-May. Knowing whether this is in local or system time assists in analyzing the problem.

Figure 1

Month-end close processes with local start times for a global corporation

As part of your general error analysis process, you should make sure that all reports output their runtime on all pages. Even if you do not have entities in many time zones, this is useful when you run the same report several times after making financial adjustments and are not sure which report has the latest set of figures.

The key to a smooth close is having a well-defined process with a clear timetable that has been distributed to all the key finance users. Users should clearly understand what their deadlines are for preparing financial data. The following eight tips can help smooth over problems you may encounter during close.

1. User Time Zone: Let’s start by looking at the Personal time zone field, which defines a time zone that represents a user’s home location. This setting is required, as the user may be located in a different time zone than the SAP system hardware. The system time zone represents the time zone that is the basis for SAP system transactions. Usually, this is the time zone of the company’s head office, which can be different than the time zone in which the SAP system is physically located.

Users can define their own local time zones in the user default settings via transaction SU3 (menu path System>User profile>Own data). Press the Default tab to see the time zone. Then the system can print the correct time. (See Figures 2 and 3.) The external format depends on the user settings for the date format. In this case, the user has selected the Japanese date format of YYYY.MM.DD.

Figure 2

Set personal time zone in user defaults via transaction SU3 for a user in Tokyo

Figure 3

Set personal time zone in user defaults via transaction SU3 for a user in New York

Sometimes users are not initially set up with the correct time zones, so do not assume a user in a region has the correct regional time zone. For example, a new user could be set up in a regional office with a copy of the user ID of his head office counterpart and end up with the head office time zone as the default time zone.

If you are a user located in the head office, the personal time zone does not present any problems for you. However, if you are located at a regional office, this can be an issue, because R/3 uses the Personal time zone setting to determine how the system behaves. For example, if the head office is in New York and the time is 10 p.m., May 25, and you are a user in Tokyo where the time is noon, May 26, you have different expectations of system behavior. Consider the case that May 25 is the last day of the fiscal period. In New York, a user expects transactions to post to period 07, while in Tokyo, a user expects transactions to post to period 08.

2. FI Documents (Default Document Date): For FI document entry (transaction FB01), the posting date is always a default based on the user’s local date (Figures 4 and 5). Say at the end of the day for a U.S. East Coast company that the posting date is 05/25/2003. The company’s Japanese counterparts, who are just arriving at work, would have a posting date of 05/26/2003 at that time. During most of the fiscal period, this is not an issue. However, at close, the difference can become a problem. During the close periods, all users should be careful of the posting date they use to ensure transactions are posted in the correct fiscal period.

Figure 4

Posting date defaults based on user time zone for a user in Tokyo

Figure 5

Posting date defaults based on user time zone for a user in New York

3. FI Documents (Entry Date): The entry date in the FI and CO document header is always in system time (Figures 6 and 7), regardless of the user’s personal time zone. This enables a consistent timestamp to be placed on all transactions so the correct order of transactions is recorded regardless of where in the world they originated. In the case of Figures 6 and 7, you can see that logistics transactions MB11 and VL02 take account of the Personal time zone setting, as well as FB01.

Figure 6

FI entry data is in system time for a user in Tokyo

Figure 7

FI entry data is in system time for a user in New York

4. Standard FI report header: Most standard FI reports, usually named RF****** (e.g., RFSSLD00) use a common header routine. You can apply SAP notes to show the local time zone together with the time zone code in the header so that the exact time is clear on the reports. Check SAP note 598133 and SAP note 452485. (See Figures 8 and 9.)

Figure 8

Standard FI report header showing user time zone for a user in Tokyo

Figure 9

Standard FI report header showing user time zone for a user in New York

Note that this company has further modified the header to show the system name and client on the left side. This is useful when you are testing reports across systems, so you don’t become confused between production and development system results.

5. Report Writer/Painter reports: In your custom Report Writer/Painter reports, you can set up the header text to show both local and system time, as shown in Figures 10 and 11. Here you select the fields from the standard variables pop-up menu, which is available in transaction GR32. To modify a report, go to Texts and select the header, footer, or other text as appropriate. In the text editor, press the standard variables button to get the pop-up:

Figure 10

Report Writer report with both system and local time in the header

Figure 11

Definition of header fields for Report Writer

The system time zone is not available as a variable, but you can hard-code it in the header. It should never be changed after the system becomes productive, because all previously stored times would become invalid — e.g., creation time for an FI document.

6. Batch Jobs: When you define batch jobs with transaction SM37, the start time is always in system time, regardless of your user time zone. (See Figure 12.) Make sure regional users are aware of this, as their batch jobs may start at unexpected times. This also applies to all times recorded in the batch job log. R/3 gives the appearance that batch jobs can be scheduled using local time, as the F4 help pop-up for time has a button that allows a time zone to be selected. However, this does not affect the batch job runtime.

Figure 12

Batch job start times and job log times are always in system time

The time set for the batch job is system time, which is affected by changes between Daylight Saving Time and Standard Time. As Japan, for example, does not have Daylight Saving Time, a change in the system time to account for daylight saving has an impact. Users in the home region do not experience any difference because their daily schedule adjusts for Daylight Saving Time.

When scheduling batch jobs for regions, keep in mind that it makes very little difference for the head office if a job runs at 1 a.m. or 2 a.m., but it has a large impact for regions where this is the middle of the day.

7. Timestamps in custom reports: Timestamps can often cause problems in a regional office that go unnoticed in the head office. A regional user may receive a report in the middle of the day marked 3 a.m. Is this a report that ran at 3 a.m. local time and got stuck in the print queue, or is it a report that ran recently with a head office timestamp? If you want times to be printed out in custom ABAP reports, decide whether to use local or system time, and let the programmer know the specifications. The programmer can use the SY-TIMLO, SY-DATLO, and SY-ZONLO fields to show local time and the SY-DATUM, SY-UZEIT, and TTZCU-TZONEDEF fields to show system time when programming an ABAP report.

Most companies have ABAP standards so that all reports have headers with runtime, report name, user name, etc. Check if your standards take account of time zone settings. Ideally, both local and system times with time zone codes should be printed in the report header.

If you need to perform time zone conversions in your custom ABAP reports, a programmer can use the WRITE f TIME ZONE tz syntax in ABAP to perform the conversion for you, or the programmer can use one of the following function modules: TZ_GLOBAL_TO_LOCAL, TZ_LOCAL_TO_GLOBAL, TZ_LOCAL_TO_SYSTEM, or TZ_SYSTEM_TO_LOCAL. Ask your programmer to review function groups TZN*, using transaction SE37, for more time-related function modules.

8. Configuration: Configuration for time zones is in the IMG. Usually, the user does not need to change these settings. If you are missing entries in these tables, look at SAP note 198411, which leads you to an SAP download and references to many related notes.

The configuration for time zone selection based on geographic location (transaction STZGC) is used to automatically populate the time zone in the customer master, vendor master, and other business objects that use central address management. (See Figure 13.) The customer or vendor time zone is used in many modules to determine the time of service delivery. In the Service Management module, the customer’s local time is displayed in a service order so that the user knows when a customer can be contacted. (See Figure 14.)

Figure 13

Time zone field autoatically populated based on country, region, and postal code

Figure 14

Customer's local time displayed in service order

Rohana Gunawardena

Rohana Gunawardena heads the SAP practice division at Exium Inc. Exium is a leading business and technology consulting firm that enables companies to achieve their strategic business goals. Exium specializes in delivering superior IT solutions using ERP systems, with a special focus on SAP products. Rohana has been working with SAP since 1992. During his career he has assisted multiple clients on detailed system correction projects, such as correcting inventory balances, controlling area reorganizations, retrospectively activating group currency, and optimizing inter-company accounting transactions. He has spoken at many SAP conferences and has published more than 20 articles in Financials Expert, SCM Expert, and SAPtips on various aspects of SAP. His presentations have focused on Financials module selection, the order-to-cash process, global rollouts, business segment reporting, cross-module integration, and the financial impact of SCM transactions. Rohana is widely acknowledged as a leading SAP expert. Rohana is a Fellow of the Institute of Chartered Accountants in England & Wales. Previously Rohana has worked with the consulting practices of Accenture, Deloitte, and PwC.

Rohana will be presenting at the upcoming SAPinsider Financials 2018 conference October 16-18 in Prague. For information on the event, click here.

You may contact the author at Rohana@Exium.com .

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