Time zones in SAP Sourcing and CLM

[vikram_shanmugasundaram]

There are many areas within Sourcing where time zones are configured, such as, System Properties, Company, User Account, Supplier, Supplier Contact, etc. These time zone settings can be overridden based on user’s locale. For instance, a default time zone may have been defined on the Company record, so all the objects created under that company, such as user accounts will inherit the time zone from the Company. However, it can be overridden by setting the time zone on the individual user account.

Setting up the time zone on the Company and User Account can be done via the UI and is pretty self explanatory. In this blog I will focus on 2 time zone related system properties that are configured at the system level.

The system properties are:

Bundle: system  Property: system.default.timezone

Bundle: system  Property: system.master_timezone

system.default.timezone

Sourcing application uses this system property to set the default time for Company, Supplier, etc. For instance, during initial setup of the system when the Company record is created and if the time zone for the Company is not specified, the system sets a default time zone based on the time zone setup in the system.default.timezone system property. The values for this system property should be in java time zone that JVM can understand. You can find the list of time zones in the Time Zone value list (external id: time_zone). Most of the commonly used time zones should be in the Time Zone value list, however, if a particular time zone you are looking for is not listed, it can be added.

system.master_timezone

This is a very important system property which is used by Sourcing to store the dates and times in the database. In a new Sourcing system, this system property is not set by default and the system will use the application server’s time zone. It assumes the application server and the database server are in the same time zone. If the application server and the database server are in different time zones and if this system property is not setup, you will see an error message in the Sourcing logs.

As a best practice, it is recommended that this system property is created as system user and the value is set to the Database server’s time zone.

What happens when the database server is moved to another time zone?

It is not uncommon for an organization to move their database servers hosting the Sourcing application to a different data center which may be in a different time zone. If this happens, there are certain critical steps that should be taken in order for Sourcing to function normally. These steps must be applied immediately after the DB migration has been completed and before Sourcing application is released to the end users.

The steps are as follows:

1. Take back up of the original DB copy. This is needed in case you need to revert back to the original state.
2. Pick a few sourcing events and write a select statement to get the CREATED_AT time for those events and save the results of the query. This will be used to validate data in Step 6.
   • Sample Query:
     1. SELECT DISPLAY_NAME, CREATED_AT FROM FCI_RFX_DOC WHERE UNIQUE_DOC_NAME IN ('RFP-00001-2012', 'RFP-00002-2012')
     2. SELECT DISPLAY_NAME, CREATED_AT FROM FCI_CONTRACT WHERE UNIQUE_DOC_NAME IN ('MA-001-2012', 'MA-002-2012')
3. Open DbImporter and run the time zone script as system user. Note: Details on time zone script is covered later in this blog.
   1. 
4. Once DBImport has been completed, check to make sure there no errors
5. Start Sourcing, login as system user and update the value of the system.master_timezone system property to the time zone of the database server
6. At this point, you can run the same SELECT query from step 2. Compare the CREATED_AT time stamps from step 2 and 6 and make sure it has updated in the proper offset.

Time zone script

The first step would be to obtain a copy of the time zone script Convert_DB_TimeZone.xml. A sample file can be found in fciinstall.jar\com\sap\odp\install\misc\tz_convert. The fciinstall.jar will be in the lib directory under Sourcing home directory.

The content of the sample Convert_DB_TimeZone.xml is below:

     <?xml version="1.0"?>

     <dbsetup_project name="Convert Database TimeZone">

          <bundle>

               <actions>

                    <ConvertSchema>

                         <arg key="converter" value="com.sap.odp.install.misc.tz_convert.TZConvert"/>

                         <arg key="fromTz" value="GMT"/>

                          <arg key="toTz" value="GMT"/>

                    </ConvertSchema>

               </actions>

          </bundle>

     </dbsetup_project>

The only values that should be changed are the value attribute of fromTz and toTz. These values should be java time zone values. For example, if the database was originally in Boston, MA and was moved to UTC time zone, the file would have to be updated as below:

     <?xml version="1.0"?>

     <dbsetup_project name="Convert Database TimeZone">

          <bundle>

               <actions>

                    <ConvertSchema>

                         <arg key="converter" value="com.sap.odp.install.misc.tz_convert.TZConvert"/>

                         <arg key="fromTz" value="UTC"/>

                          <arg key="toTz" value="America/New_York"/>

                    </ConvertSchema>

               </actions>

          </bundle>

     </dbsetup_project>

Notice that fromTz and toTz vaues are reversed. This is currently a known issue and will be addressed in one of the later releases.

***IMPORTANT***: The time zone script should NOT be run more than once. If the script is run with incorrect time zone values or if it is run more than once, fixing it is not easy. So it is recommended that before running the script, check with SAP Support team to make sure your settings are correct. Also, it is recommended that the time zone script is first tested in a non productive system before attempting it in productive system.

Hope you found this blog useful.

1

2.