客户订单处理中的时区管理

结果

每个日期从用户和/或地理位置的角度、以与其上下文相关的时区中表示。

目的

当公司在全球许多不同的国家设有分公司时，能够管理不同的时区是很重要的。时区管理使位于远程位置的用户能够在本地查看和解释客户订单。

方法

可以在订单输入期间查看和建议的日期，或通过 API 或自动作业自动创建的日期将转换为相关时区。

以下类型的日期使用时区转换：

• 订单日期
• 客户的订单日期
• 交货日期 - 当地（计划日期、启运日期、要求日期和确定日期）
• 交货日期 - 最终目的地（要求日期、确定日期）
• 批准日期（交货订单）
• 发票日期（客户订单发票）
• 退货日期（客户订单退货）
• 输入日期和更改日期（无时区转换）。

订单日期

根据订单的分厂的时区初始化订单日期。在分厂的主仓库中的负载地点的时区用于提供建议用。例如，如果销售代理商位于作为分厂一部分的位置，则订单日期将反映该位置的实际时间。

客户的订单日期

如果客户未输入或发送日期，则以与订单日期相同的方式初始化日期。这意味着必须保留客户的日期，以便能够跟踪客户的订购流程历史记录。

交货日期 - 本地

与货物或服务的交付相关的日期，根据在交货仓库处装运位置的时区显示和存储。此逻辑涵盖的日期包括计划日期、启运日期、要求日期和确定日期。这意味着必须以在它们实际发生的时区表示预期的活动。

交货日期 - 在最终目的地

根据在交货地址处或客户卸货地点的时区，显示和存储在客户时区中表示的日期。此逻辑涵盖的日期包括要求日期和确定日期。这意味着必须以在它们实际发生的时区表示预期的活动。

批准日期（交货订单）

根据在交货地址处或客户卸货地点的时区，建议并显示批准日期。这意味着必须以在它们实际发生的时区表示预期的活动。

发票日期和会计日期

根据订单所在的分部的时区，对发票和会计日期进行初始化和建议。这意味着，当在时间段结束必须管理账户关闭时，每个分部能使用其本地时区。因此，所有财务交易必须与分区地/财务时区相关。

退货日期

根据在接收仓库处装载位置的时区，显示和存储与交货的货物或服务的返回相关的日期。这意味着必须以在它们实际发生的时区表示预期的活动。

输入日期和更改日期

输入和更改日期是时间戳，并根据系统的时区进行初始化和存储。这意味着可以跟踪数据库更新的历史记录和顺序，而不考虑输入或更改的来源。

情景

M3 服务器位于欧洲而在日本开票

• 服务器和公司总部在英国 (GMT/UCT)
• 销售分部在日本东京，具有本地开票和应收账款
• 英国的日期和时间是 2003 年 3 月 30 日的晚上 11:30。
• 日本东京的日期和时间是 2003 年 4 月 1 日的上午 7:30。

日本用户发出发票。建议的发票和会计日期是 2003 年 4 月 1 日，该日期是日本销售分部的当地日期。开票完成后，将使用以下日期：

• 发票日期（在应收账款和发票单据上）：2003 年 4 月 1 日
• 会计日期：2003 年 4 月 1 日
• 销售统计日期：2003 年 4 月 1 日。

M3 服务器位于欧洲而在美国开票

• 服务器和公司总部在英国 (GMT/UCT)
• 销售分部在美国洛杉矶，具有本地开票和应收账款
• 英国的日期和时间是 2003 年 4 月 1 日的凌晨 12:30。
• 美国洛杉矶的日期和时间是 2003 年 3 月 31 日的下午 5:30。

美国用户发出发票。建议的发票和会计日期是 2003 年 3 月 31 日，该日期是美国销售分部的当地日期。开票完成后，将使用以下日期：

• 发票日期（在应收账款和发票单据上）：2003 年 3 月 31 日
• 会计日期：2003 年 3 月 31 日
• 销售统计日期：2003 年 3 月 31 日。