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
  • Customer’s order date
  • Delivery dates - local (planning date, departure date, requested date and confirmed date)
  • Delivery dates - at final destination (requested date, confirmed date)
  • Approved date (delivery order)
  • Invoice date (customer order invoice)
  • Return date (customer order returns)
  • Entry date and change date (no 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

  • Server and company headquarters in the UK (GMT/UCT)
  • Sales division in Tokyo, Japan with local invoicing and accounts receivable
  • Date and time in the UK are March 30, 2003, 11:30 p.m.
  • Date and time in Tokyo, Japan are April 1, 2003, 7:30 a.m.

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:

  • Invoice date (in accounts receivable and on invoice document): April 1, 2003
  • Accounting date: April 1, 2003
  • Sales statistics date: April 1, 2003.

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

  • Server and company headquarters in the UK (GMT/UCT)
  • Sales division in Los Angeles, USA with local invoicing and accounts receivable
  • Date and time in the UK are April 1, 2003, 12:30 a.m.
  • Date and time in Los Angeles, USA are March 31, 2003, 5:30 p.m.

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:

  • Invoice date (in accounts receivable and on invoice document): March 31, 2003
  • Accounting date: March 31, 2003
  • Sales statistics date: March 31, 2003.
Related topics