CIF是APO和ECC之间的标准接口，用于传输主数据（单向）和事务数据（双向）。但通常由于一些主数据问题，事务数据无法流入目标系统，导致通常所说的CIF队列。这将阻止后续的数据流，但SAP提供了后处理选项。把它想象成一辆卡车，它在公路上捡起你的死车，为了安全把它移走，也为了清理公路，让交通继续前行。后处理做同样的事情—它将记录放入后续分析和纠正措施中，即在处理了潜在原因后重新处理队列。但是，怎么成为淘客，对于给定的产品位置组合，每个订单都会创建后处理错误记录，原因与本博客中提到的自动CIF Delta对账记录非常相似。
根据业务的重要性和重要性，生产支持团队成员每天至少进行一次后处理错误审查、评估，并准备因果因素报告（主要是主数据问题），在批量运行期间，我的一个客户每天至少两次，周末4次。这种对后处理记录的分析实际上是非常乏味和重复的。大多数情况下，因果因素是已知的，但您仍然需要遍历每个队列来评估因果因素，然后将其汇总到一个报告中。
因此，开始思考如何自动执行定期的CIF后处理记录分析。自定义报告程序的高级设计体系结构，它将读取APO和ECC之间的CPP错误记录（两种方式），然后查找相关qRFC生成的应用程序日志，从映射表中提取错误类并匹配根本原因以生成摘要报告。此摘要报告输出是按产品-位置-交易数据对象类型-CIF错误类型组合，合肥大数据，按订单按产品位置和交易数据类型聚合的单个CPP记录。作为改进总结报告，还添加了Excel附件，直接从APO系统发送电子邮件。
解决方案设计简单-根据产品和位置的选择屏幕执行自定义程序，宁波大数据，通过产品位置对象类型（事务数据类型）聚合的相应ECC逻辑系统读取CPP错误记录。接下来，对于每个唯一的组合，读取相应的应用程序日志，以根据qRFC事务/LUW ID（匹配为日志的外部ID）读取日志详细信息。从日志详细信息中的错误消息中提取错误应用区域和MsgNo，然后用于读取映射ZT，以确定解释文本，并最终将数据显示在nice ALV输出中，这些数据可以下载/生成Excel文件或作为附件发送到特定用户或通讯组列表。
整个过程的关键是将由应用程序支持团队管理的自定义映射表，一旦出现新的错误记录，应用程序支持团队将分析这些错误记录，并使用适当的解释测试添加它们。这里是定制映射表的示例结构
接下来让我来介绍一些用于构建定制程序的关键标准技术对象。
通过维护逻辑系统到业务系统组的分配的SAPAPO/V\u BSGSET视图来确定是否打开了后处理。字段CIF\u ERRHDL\u MODE值可以为空或S:Strict（终止错误）表示CIF queue error在SCM queue Manager/SMQ2中生成记录（因此不生成后处理记录），而1:post processing of error是必需的，因为它表示处理过程中的CIF queue error未挂起，状态为SYSFAIL，记录可用在CIF后处理中进行分析，并在采取纠正措施后进行再处理。
因此在此基础上确定了SMQ2或/SAPAPO/CPP1的CIF误差。注：如果由于多个连接的逻辑系统而有多个条目，则应考虑SAP ind.标记为"X"的条目。
下一步按每个对象类型（如计划订单、库存转移申请）的产品位置组合对后处理错误进行排序。由于订单元素不同，同一产品位置对象类型可能出现多个错误，但只要错误文本相同，就不需要分析每个订单元素。错误记录的qRFC事务ID很重要–因为它作为外部ID字段传递到应用程序日志选择屏幕以读取日志详细信息。应用程序日志读取可以使用ECC中的CIF显示程序CIFQEVO2和APO端的/SAPAPO/CIF\u QUEUE\u EVENT2来完成。如果有两组应用程序日志可用，则跳过子对象文本=错误处理（技术名称EH）的日志。与LUW ID匹配的其他应用程序日志需要提取以进行进一步处理。
下一步通过匹配应用程序区域+Mesg从映射ZTable的应用程序日志详细信息中搜索CIF错误文本。否，考虑交易类型+位置类型+位置组合。可以在事务类型（根据下面给出的R/3对象类型映射到单字符值）和位置中使用通配符值。但是，位置类型将不会是通配符，必须使用有效值（如1001（工厂）、1002（直流）、1007（MRP区域）、1010（客户）、1011（供应商）进行维护。自定义表将首先使用通配符值进行维护，然后是更具体的值。这是为了允许对相同的后处理错误消息、相同的事务类型但不同的位置/位置类型使用不同的解释文本。对于XC023无活动集成模型等一般消息，可以针对不同的交易类型（如销售订单对采购需求/采购订单对计划订单）设置不同的解释文本
最后构建ALV报表输出，淘客返利，表头如下。在电子邮件选项的情况下，创建Excel文件并附加到发送的电子邮件。
系统流程：APO到ECC或ECC到APO
总错误计数：nnnnn（所有错误计数之和）
