嗨，马特，

我们已经使用My Timesheet v3大约一个月了，我可以确认该应用程序远不是稳定的，更不用说没有错误了。

遇到了一些问题/烦恼，但标准尚未解决：

• 在输入作业时没有任何形式的验证。 仅在根据分配内容提交时间条目时执行检查。
• 通常会忽略时间记录配置文件中的配置
• 来自记录的警告消息被视为错误，因此无法保存修改
• 输入/调整多个时间记录时 当服务返回错误时，可能会保存一半的更改，而另一半则不会保存。 更糟糕的是，下次您按下 Submit 再次处理正确的记录时。

我不知道分配概念是否适用于所有情况， 但是在我们的用例中，希望用户在时间条目中输入成本对象的组合，因此这是一个方便的功能。 也可以基于自定义逻辑（通过管理分配工具）导入分配，这也很有用。 我接受这些改进，但不以牺牲整体可用性为代价。

我的建议是暂时离开v3，如果仍然可以选择尝试v2版本。 在升级到新应用之前，我们已经使用该软件多年，没有任何重大问题。

BR，
Gábor

附录：四年前，我在 https://answers.sap.com/questions/11671755/index.html 。 我可以说团队日历确实对我们来说是正确的非工作日，并且前端和后端服务器中的时区配置都是正确的。

未解决 但是，今天我发现了有关起因的主要线索。 这是时区问题！ 具体来说，我的时间表日历控件中似乎存在一个错误，该错误错误地读取了某个地方的时区设置。 尽管服务器时区已正确配置为PST，但它将所有工作时间都解释为UTC，然后在显示日历时，会将这些时间"转换"为浏览器的时区（PST），这会导致7个小时的偏移（因为 "现在是夏令时。"

当我将本地PC的时区更改为UTC时，日历控件会正确显示非工作时间。

我会三倍和三倍地 -检查Fiori前端服务器和ECC后端服务器中的时区设置（是，包括运行TZCUSTHELP），并且所有设置均正确。 我们整个组织（包括我们的时间服务器和域控制器以及所有工作站）都位于PST中。

其他日历控件（例如我的团队日历）没有此问题， 甚至我的时间表的其他部分都没有此问题。 只是我的时间表日历显示。

我找到了批准时间表 2799201 ，但无法解决该问题。

作为一个更新，我遇到了一些 大量客户事件在SAP支持下开始，但是我们走不通。 我也一直在与其他K-12客户进行讨论，但找不到任何实施过此应用程序的人。 他们正在使用较旧的版本（Fiori之前的版本）或第三方替代产品，或者他们的员工提交纸质时间表，而管理员则通过CATS在后端输入数据。 在这一点上，我们的旧Web Dynpro Java ESS应用程序记录工作时间比Fiori 我的时间表v3 更具功能性和先进性（并且有效，底线）。

有没有人实施过此功能，特别是对于只输入负数或例外时间的免税/受薪员工呢？

你好马特，

我们一直在尝试设置Fiori Timesheet V3的试用版，到目前为止，我们遇到的所有问题都是创建作业时遇到的各种错误。

• 输入分配时不验证。 仅在根据分配内容提交时间条目时执行检查。
• 在创建分配时，字段的下拉列表与员工的"人员子区域分组"不一致，因此没有"检查"以确保输入正确的信息。
• 保存分配时出现错误，没有提供有关错误原因的详细信息
• 使用有效的截止日期和起始日期创建的分配将继续显示为灰色，好像未激活一样。

我注意到您的帖子发布于2019年7月，所以我只是想与您一起检查一下您的公司如何通过工作分配解决这些问题，因为我们还引发了许多SAP事件，但是SAP提供的每种解决方案都有新的原因 问题。

谢谢

曾琳达

在我们这边部署应用程序是一个更大的项目的一部分 而且我们没有资源进行深入的测试。 所以 这些问题已经在生产使用中出现了 来不及收回，但为时已晚 需要立即采取行动，因此我们决定 尝试在内部解决它。

幸好 大多数都可以解决 从ABAP一侧（通过 利用应用程序的 巴迪 并调整OData 通过隐式增强的服务类） 现在它可以在可接受的水平上运行了。 虽然 我必须承认，这需要很多努力。

后 所有 我有点被SAP欺骗了 其质量的客户。 但 让我们 只希望 他们会花时间把它变成功能正常的产品 最终。 ：-）