你好

在不知道有关确认过程的详细信息的情况下，很难说出此问题的根本原因。

您要使用哪笔交易过帐确认？ 用户是否可以手动更改货物移动？ 如果这总是发生还是仅发生一次？

此致

Caetano

附加了屏幕截图，并且多个条目是针对一定数量的物料的

对于所附的屏幕截图数量63.605仅具有一个条目，而105.065的数量有19个具有相同文档编号的条目。

系统为什么如此运行

此致

Sagar

从MRP2视图中取出反吹指示器（" 1"-始终反吹）以解决这些问题。 确认失败后，批处理作业将永远不会将条目发送给COGI。

感谢您的快速反馈

如前所述，这是一次性的问题（仅发生过一次），这对于分析来说是更典型且更困难的事。
让我们再试一次，以找出此问题的根本原因。

您可以分享（或）分析以下要点吗？
因为形成您之前分享的屏幕快照，我无法找出很多未解决的问题。.

生产订单抬头数量？
确认数量是多少？
订单是否一次完整确认（或多次确认）？
此订单是否存在取消确认？
此订单是否发生任何发货/收货冲销
在"有记录的货物移动"命令中，所有过帐的文件是什么？ （订单的）
根据计算要过帐的正确COGI数量是多少？
实际过帐的COGI是什么？
是否发生了主数据更改，或者 COGI组件（或）抬头材料？
所有COGI发布是否由Background Job（或某些）由任何特定用户ID完成？
什么是COGI发布日期和时间？ id？
在报告此问题之前和之后，此组件在COGI中过帐的库存位置是什么？
该组件是否存在退货（或）拒绝？
是否有任何批次 在此报告的发布日期和时间期间，工作失败了吗？

需要查找并检查这种罕见情况的所有可能和可能的情况
对于给您带来的不便，我们深表歉意，因为这并不是所报告问题的确切原因

感谢您的理解，如果您有任何反馈意见，请与我联系。
最好的问候：拉贾（Raja）

将确认指标从" 2"更改为" 1" 在路由/操作中使用的控制键。 即使发现短缺，也不会多次运行相同的确认。 并且您只会在COGI中获得一个条目。

谢谢，
Srini