经过测试,虽然在前台无法将退货订单改成协同的模式,但是退货订单仍然可以在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单
的前台的完整性被破坏。影响报表的准确性(自定义的采购执行报表)