SAP SUS-退货PO对账单问题的完美解决方案(升级版）

经过测试，虽然在前台无法将退货订单改成协同的模式，但是退货订单仍然可以在ERP的后台把采购订单的确认控制和确认回执改成和协同的单据一致，并且和能够协同的采购订单一致，可以在SUS做确认(因为标准功能不支持，实际上都是通过在增强的地方直接修改表，而无法通过函数修改内表再按标准程序更新表数据）。

通过增强直接改表

因此，相对于前一个文章的思路。新的思路是：
在退货采购订单时提交时，检查供应商是否协同，如果是协同，讲退货采购订单的确认控制改成 允许确认的类型（EKPO-BSTAE），需要回执(EKPO-KZABS)打勾.

修改的地方地方也要做上述的处理。否则标准程序会自动清空该两个字段的值。
然后达到如下的效果：

然后其他的用标准功能即可实现采购退货PO对账。

增强的位置找了好几个地方

最后才找到上面的位置坐增强处理.
来自SRM系统下的协同PO单，因为在SAP里面不能自动触发创建IDOC传输。有个自定义函数专门用于处理传输问题。在POSTED里面XXXIM ME PURCHDOC POSTED里面，对来自协同供应商的PO单（含退货单）自动触发传输。

20230410补充
退货订单改成需要确认以后，冲销退货收货时，SAP的系统报告，消息号M7328错误，
因此此消息号M7328影响较多，不能通过修改消息号的属性跳过。因此，只能另外想办法解决。

退货订单确认之后，导致161的移动类型无法冲销（EKBE-ETENS供应商的确认序号）。而修改了EKBE-ETENS之后允许冲销之后又无法重新收货。给出两个解决方案：
1）、做个小工具，专门处理退货PO的冲销问题。用户碰到问题时找到内部顾问处理；
2）、当用户做162的移动类型时，直接清空EKBE的EKBE-ETENS和EKPO的确认回执KZABS=’’和确认控制bstae=’’，之后的所有操作和普通的没有差异。 建议使用第二种方案。
此种方案的好处是，维持了供应商SUS界面的业务完整性。但是发生过退货业务的PO单
的前台的完整性被破坏。影响报表的准确性（自定义的采购执行报表）