嗨，

在PCR中，您将使用运算符ADDMB将时间类型添加到SALDO表中，并且该值太大而导致溢出。

转储，您应该能够看到导致问题的PERNR（甚至日期）

如果您为该雇员运行PT60直到上一个日期，并查看SALDO表 您可能会获得关于违规工资类型的指导。

您可能无权访问此工资类型，但是当您单击"调试"按钮并且调试器加载时，如果您得到转储，则可以在 offendin'collect'语句，并准确查看导致该问题的工资类型/值

bg

使用t-code st22访问ABAP错误日志，执行程序， 通过双击来选择错误日志，将光标放在错误日志的任何部分，然后使用野外眼镜查找" PERNR"，以识别产生错误的员工。

如上所述 通过 Brendan Gibbons ，该问题与表SALDO中的溢出有关。

检查员工的主数据和时间条目以查看是否可能是该问题， 并通过t代码PT_CLSTB2检查员工现有的时间评估结果集群（特别是表SALDO），以查看它是否可以帮助您确定问题的根源。

谢谢 响应，

在HR最终用户为所有员工输入（DOFF）后出现此错误，此错误在运行PT60时显示给少数员工

我知道产生此错误的员工 ，但是如何克服这个问题。

感谢

嗨，

SALDO用于保持月份类型时间的最新累积。

这些累积可以是 逐月滚动以提供年度累积，并且如果需要，可以跨年滚动以累积更长的时间！

时间类型的属性确定是否逐月滚动。

如果一个人的时间在足够长的时间内一直累积到某个时间类型，那么它最终将变得"满"，并且您会得到您所描述的转储。

您的问题很可能是 是由于时间执行中PCR的逻辑缺陷所致。

您提到了DOFF。 我不知道这是什么，但是如果您对如何处理有特定要求，那么问题可能出在那些实施中。 （这是假设HR已正确输入到系统中）

您将需要与谁支持您的时间架构进行对话，因为它更可能需要更改。

问题 这里是特定于您的实现/要求的，因此对于这里没有您的系统知识的人来说，不可能给出明确的答案。

bg

DOFF表示每周休息，由于假期，HR最终用户已为所有员工输入此班次，为期7天，之后这是某些员工在运行pt60时出现的问题

谢谢