Time zone overview

Abstract

This document describes the concept of time zone handling in M3 Business Engine.

Background

M3 Business Engine is a multi-local ERP system, making time zone handling a vital part of the solution.

Time zone overview

The time zone handling is divided into these areas:

Display and printing of time/date considering the time zone
Updating data in a database considering the time zone
Consider time zone differences for warehouse/logistic transactions
Time zone handling in API transactions.

For specific screens in M3 BE, there are places where time differences should be handled to support time zone differences. The analogy with traveling is quite good. When you fly from one time zone to another, you are normally only interested in at what (local) time you will arrive. Knowing that you will arrive in Chicago at 13:00 local time is sufficient. You do not really need to know the equivalent time in other time zones. This is also true for transactions and information in M3 BE - you are normally only interested in when a transaction is due in local time.

It is only when people working in different time zones are accessing the same data and making decisions based on their local time will the time zone conversion be needed.

Based on the above, we consider every warehouse in M3 BE to be working in the local time zone. Thus, everything that is planned and entered locally is also registered with local time values. For example, this means that the material planning (MITPLO) contains the local time for every warehouse. Manufacturing orders and planned operations are also planned in the local time and therefore referring to the warehouse time zone.

The &SYS time zone defines where the server is located in relation to UTC. Take note that for M3 CE, the server time is in UTC and therefore, &SYS should always be 0 hours from UTC. movexDate() and movexTime() are always considered to relate to the &SYS time zone. RGDT, RGTM, and LMDT are stored in the database in the &SYS (Example: these fields are always displayed as server times without conversion).

LMTS is a time stamp in milliseconds in the UTC time zone.

Limitations

Time zone handling has only been implemented in functions where it has been most needed. In many functions, it has not been implemented at all, as it is not required. In the finance area, for instance, date and time are often based on dates and times already defined in an invoice.

In display and printing of time, take note of these additional limitations:

Only RGDT/RGTM, SGDT/SGTM, and XLRD/XLRT can be converted.
Both date and time must be part of the view.
Drilling down to aggregated converted date/time is not possible.
Filtering and selection is only possible if both date and time are part of the filter/selection values.
For CMS100MI, the same limitations apply to configurable views.
For Ad Hoc, time zone conversion is not supported.

The printouts from M3 BE can be separated into these areas:

Internal lists and documents
External business documents.

For internal lists, the time and date printed at the upper right corner are time zone adjusted or adjusted according to the time zone difference between the server time and the user time. If a user in Japan prints an item list, this has the time and date converted from the system time to Japanese time. For internal documents like picking lists and goods receiving documents, whether or not a time zone conversion should be done is decided on a case-to-case basis depending on the printed data.

The external documents rarely include a time that is generated from the system time. Whether these documents should be time zone converted or not is considered on a case-to-case basis.

Time zone setup

To handle the time zone requirements, time zone definitions are made in these areas in the system:

User (MNS150/MNS151)
Warehouse (MMS005)
Division (MNS100)
Customer (CRS610).

The time zone that is used is retrieved in this hierarchy:

User per company/division (MNS151)
General user record (MNS150)
Division (MNS100).

The warehouse in (MMS005) is connected to a 'Place of loading' in (MMS008), which is connected to a time zone. The warehouse time zone is to be regarded as the local time zone used for planning transactions in that warehouse.

The division in (MNS100) is connected to a default time zone. This is the highest hierarchy possible for definitions of time zones.

The customer in (CRS610) is connected to a time zone. This is an indirect connection, like the warehouse connection. The customer is connected to a delivery address in (CRS002), which is connected to a 'Place of unloading’ in (MMS008), in its turn connected to a time zone. The customer delivery address time zone is used to calculate the shipment date and time based on the required delivery date and time requested by the customer.

Display and printing of time considering the time zone

As explained above, 'Entry date', 'Entry time', and 'Change date' are expressed in the system time.

A time and date displayed in the system are much like amounts: You must define the unit to be used, for instance USD 15 or SEK 200. A time or date should therefore, if presented correctly, always be followed by 11:00 CET or 17:12 PAC. Since we do not use a unit for every time and date displayed in M3 BE, the following rules apply instead:

When entering a function where time zone converted fields may occur, we will always display the user time zone.

By using the function key F13 parameters, the user can override this by defining his/her own time zone to use in a specific function. If there is a value defined in this field, this time zone will be used instead as a default when the program is launched.

In order for the user to know which time zone a person is viewing without having to display this in a field on the screen, a prompt function has been introduced. The prompt function serves two purposes:

It will use/highlight/flag the time zone currently used in the display.
It will display the available time zones to choose from if the display of another time zone is desired.

To activate the prompt and to signal to the user that time zone conversion is possible, a button in the UI is used.

For configurable list views, the system date/time can be displayed in the user's time zone. To do this, select the 'Time zone conversion' check box for the system time field in 'Field Group. Display Permitted Fields' (CRS109). This enables you to position, select, and filter on the converted system date/time.

Updating data in a database considering the time zone

When updating data in M3 BE, the system date will be used as the creation/last maintenance date.

Consider time zone differences for warehouse/logistic transactions

Logistic transactions in M3 consider the time difference between time zones when the transactions are planned and displayed in the system.

For some transactions, M3 must consider the fact that there might be a time difference between two physical locations involved in the transactions. The best example of this is a distribution order that has a very short lead time. Planning this and including a time zone difference is part of the solution.

Example: A distribution order is planned to leave Stockholm at 15:00 using air freight. It is scheduled to arrive in the Helsinki warehouse 2 hours later (the distribution lead time is 2 hours). Since the time zone difference between Stockholm and Helsinki is one hour, the receiving time for the distribution order in Helsinki will be 18:00–one hour is "lost" when going east.

Dates and times relating to a warehouse are normally stored in the database using the time zone of that warehouse. When a user enters a date/time for a warehouse, it is usually implicit to the user that the date/time relates to that warehouse. Therefore, no time zone conversion of the entered data is required.

Time zone and APIs

An MI share the same behavior as an interactive program, or it is assumed that the user is reporting in the time zone connected to the geographical reference of the transaction. This differs depending on which type of transaction that is used. For instance, if the user is reporting an MO, it is assumed that the geographical reference is based on the warehouse to which the MO belongs. Knowing which time zone that is used in a specific transaction is very difficult, so the following can be of help:

Use DRS045MI, where you can ask which time zone that is used for instance for a specific warehouse. You can also get back the time zone difference related to UTC.
Some MI program transactions contain a UTCM parameter. By activating that parameter, it is assumed that all times, both in and out, are expressed in the UTC time zone.
The geographical reference should be clearly described in the MI metadata.