大多数事务数据输入都是在SAP的数据库级别使用系统时间记录的。当用户在前端检查相同的日期时，应该将其转换为本地时间（不总是这样，您将在下面看到）。然后在sapfscm案例管理中，情况变得更加复杂，因为FSCM案例管理在数据库级别使用GMT时间而不是系统时间。我不是basis专家，不知道这是SAP故意制定的标准，大数据专业，也不知道这只是纯粹的定制配置，我将以一个信用案例（针对一个销售订单）为例，在SAP FSCM中检查各种相关对象和代码的不同时间戳

系统时间与本地时间

请注意系统时间与本地时间之间的差异。以我的登录为例，系统时区是EST，而我的时区是UTC+8。UTC+8时间比夏季系统的EST时区提前12小时。

1。表VBAK

中的销售订单创建时间首先，检查编号为0030411255的订单，该订单创建时间：

07-16-2020 12:59:41（美国东部时间）

是系统时间。如果将此EST时区转换为UTC+8时区，则时间为：

07-17-2020 00:59:41（UTC+8时间）

2。VA03的销售订单创建日期

检查VA03的创建日期，在这里我们可以看到其系统日期07-16-2020。

3.SCASE前端的DCD案例

根据此销售订单0030411255查找SCASE ID 30001190439（BP:0004664138，信用段：US01），大数据有什么用，创建时间为

07-17-2020 01:00:33 UTC+8时间

从系统时区转换为当地时区。（DCD案例创建晚于销售订单创建，此处延迟52秒）

4.DCD在案例表级别

在案例表SCMG\U T\U case\U ATTR，我们可以看到案例30001190439的创建时间是20200716170033。它既不是系统时间也不是本地时间，这里系统使用GMT时间（Scase屏幕上的时间源）代替！到目前为止，建站服务，所有3个时区都已涉及：

创建订单的EST时间（系统时区）：07-16-2020 12:59:41DCD病例的GMT时间（基线时区）：07-16-2020 17:00:33UTC+8时间（当地时区），用户在SCASE:07-17-2020 01:00:33

5.信用检查日志

让我们检查信用检查日志此DCD的时间，因为信用检查必须触发信用案例创建。我们通常使用UKM\u LOGS\u DISPLAY来查看信用检查日志的详细信息，在它的选择屏幕上我们应该使用什么时间？

因为是前端，所以应该是当地时间，北京大数据研究院，大数据培训，对吧？惊喜~系统时间到了！在搜索信用检查时，我们总是将日期/时间设置为一个过滤器，因为只搜索业务伙伴和没有日期/时间范围的信用段的检查历史记录非常耗时。因此，当您使用本地时间通过UKM\U LOGS\u DISPLAY搜索信用检查日志时，请小心。

6.Web服务消息日志

那么使用SRT\u工具的Web方法消息日志呢？在选择屏幕上使用系统时间？

不，SAP遵守我们这次的规则，当地时间！

由于在选择屏幕或表格级别使用错误的日期/时间而导致的日志丢失将导致错误的判断，并在用户要求您验证信用检查进度时降低您的效率。我花了很多时间才注意到这一点。如果你有相同的时区设置，我希望它也能帮助你。

不管怎样，这是一个奇怪和混乱的设置。如果有人知道这个时区设置的根源，请告诉我：P