如果你读过我以前的博客，那么你就知道如何创建一个定制报告程序，根据映射表自动分析APO中的CIF后处理记录，并从阻塞的队列/记录中提取错误消息号。在本博客中，我将概述对程序所做的进一步增强，以使其更健壮、更有效地移交给常规业务用户。

早期的逻辑有应用程序日志中的错误行，提供了必要的详细信息，如用于确定解释文本的消息编号。这很好，但很多时候错误行没有提供所需的详细信息。事实上，错误（红色交通灯）条目后面的成功（绿色交通灯）条目包含相关数据，商城建站系统，如实际导致问题的位置产品。下面的截图展示了一个很好的例子，我们将在这个博客中进一步关注。此错误是在将库存调拨申请转换为TLB订单并传输到ECC以创建库存调拨订单时产生的。但由于采购信息记录中没有价格维护，通信云，这一CIF记录被卡住了，没有价格维护，就无法创建库存转移单。错误记录显示根本原因信息，但不提供下一行中有问题的材料工厂组合，如何租用服务器，这实际上是一个成功记录。

另一点需要注意的是，CIF申请日志中的任何记录最多可以有4个变量，定义为&1到&4。在上面的例子中，&1=N（新），&2=Stock Transfer Order，&3=Material value，finally&4=Plant value。因此，如果我们可以从应用程序日志中的CIF错误记录中的第二个记录中提取第三个和第四个变量值，那么CPP记录分析是正确和可靠的。为了实现这一点，我设计了所谓的二次检查——不用担心命名的语义。原来的检查逻辑是"primary"，所以这个增强的逻辑必须被命名为"secondary"。

自定义表被增强，包括一个名为secondary check的指示符，以及另外两个字段，一个包含APO的事务链接和连接的ECC系统，手游返利折扣，如图所示。注意，用于二次检查的解释文本具有所选变量，这些变量的值是从匹配的CIF应用程序日志错误记录中动态填充的。为偏移值添加另一个字段，例如上面示例中的"1"，表示从错误记录中偏移1条记录，以确定需要提取其变量值并将其传递给解释文本的记录。APO和ECC Txn Link字段将与一个与错误类型最相关的APO和ECC系统事务一起维护。在对话模式下，如果用户不仅看到解释文本，而且可以访问最相关的APO和连接的ECC系统事务，以采取纠正措施或查看数据，这是非常有益的。产品位置组合与Planning Version=000一起传递给APO事务，因为只有活动版本数据通过CIF传输到ECC。同样，产品位置组合通过RFC从APO传递给ECC事务，作为物料-工厂组合。

在分析多行TLB订单后，还有一个难题，即只有一个产品可能导致整个库存转移订单从创建时就被卡住。这是一个很好的例子——产品E4LW400000的净价缺失，导致整个TLB订单转移到ECC，以便为多个产品（项目）创建库存转移订单。通常情况下，客户报告会列出所有其他产品CIF错误记录，因为未找到不正确的净价。因此，另一个脑筋火花后，二次检查指标是加强到一个新的值M表示多重匹配是必要的。在这种情况下，程序只会将不匹配的解释文本报告为"无问题"，并将动态解释文本仅放在实际存在问题的产品位置上。

生成的自动CPP记录分析报告增强输出结果如下所示，淘客群，解释文本清楚地提到大多数情况下无问题并正确突出显示有根本原因的条目。

对于每一行，仅在对话框模式下添加两个以上的列，以提供APO和ECC事务代码的超链接。

客户SAP架构师和关键业务用户也非常赞赏此增强功能，因为他们也可以访问此自定义代码（只读）报告，使他们能够在没有看到计划更改转移到ECC时快速检查CIF中是否有任何内容卡住，反之亦然。业务部门无需等待或提出帮助台/服务台通知单，就可以让生产支持团队查看CIF队列/后处理记录。