Time Zone Management in Customer Order Processing

This document explains how dates and times are expressed and interpreted in the customer order process when using multiple time zones.

Outcome

Each date is expressed in a time zone relevant to its context from a user and/or geographical location perspective.

Purpose

When a company has branches in many different countries worldwide, it is important to be able to manage different time zones. Time zone management enables a user in a remote location to view and interpret customer orders locally.

How

Dates that can be viewed and proposed during order entry or dates that are created automatically via APIs or auto jobs are converted to a relevant time zone.

These types of dates use time zone conversion:

Order Date

The order date is initialized according to the facility’s time zone for the order. The time zone for the place of load in the facility’s main warehouse is used to provide the proposal. For example, if a sales agent sits at a location that is part of the facility, the order date will reflect the actual time at that location.

Customer’s Order Date

If a date is not entered or sent by the customer, the date is initialized in the same way as the order date. This means that you must keep the customer’s date in order to be able to trace the customer’s ordering process history.

Delivery Dates - Local

The dates that relate to the delivery of goods or services are displayed and stored according to the loading location’s time zone at the delivering warehouse. The dates covered by this logic include planning date, departure date, requested date and confirmed date. This means that you must express anticipated activities in the time zone where they actually take place.

Delivery Dates - At Final Destination

The dates expressed in the customer’s time zone are displayed and stored according to the unloading location’s time zone at the delivery address or the customer. The dates covered by this logic include requested date and confirmed date. This means that anticipated activities must be expressed in the time zone where they actually take place.

Approved Date (Delivery Order)

The approved date is proposed and displayed according to the unloading location’s time zone at the delivery address or the customer. This means that you must express anticipated activities in the time zone where they actually take place.

Invoice Date and Accounting Date

The invoice and the accounting date are initialized and proposed according to the division’s time zone where the order is placed. This means that each division can use its local time zone when it must manage book closings at the end of a time period. All financial transactions therefore must relate to the divisional/financial time zone.

Return Date

The dates that relate to the return of delivered goods or services are displayed and stored according to the loading location’s time zone at the receiving warehouse. This means that you must express the anticipated activities in the time zone where they actually take place.

Entry Date and Change Date

The entry and change dates are time stamps and are initialized and stored according to the system’s time zone. This means that you can track the history and the sequence of database updates regardless of the source of entry or change.

Scenarios

Invoicing in Japan when the M3 Server is Located in Europe

A Japanese user releases an invoice. The proposed invoice and accounting date is April 1, 2003, which is the local date at the Japanese sales division. When invoicing is completed, these dates are used:

Invoicing in the US when the M3 Server is Located in Europe

The American user releases an invoice. The proposed invoice and accounting date is March 31, 2003, which is the local date at the US sales division. When invoicing is completed, these dates are used:

Related topics