内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

大带宽_企业邮箱软件_年度促销

2021-07-10 17:04 出处:欧普曼云计算 人气: 评论(0

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

系统时间与本地时间

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

1。表VBAK

中的销售订单创建时间首先,nba大数据,检查编号为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遵守我们这次的规则,当地时间!

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

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

,采购返利
分享给小伙伴们:
本文标签: 带宽企业邮箱软件年度促销

相关文章

评论

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

签名: 验证码: 点击我更换图片

评论列表