前几日用户发来求助邮件,说用MIR7做完预制凭证后,想过账时系统提示一个错误信息“凭证XXX无法进一步处理”错误,错误号为M8422。
查了半天,发现是这么回事。
A采购订单,创建于09年7月,09年8月的时候由于系统调整,这个PO对应的定价过程有过调整。其中和发票校验相关的一个定价条件在定价过程中的位置被移动过了。
到了前几日,用户做预制凭证了,保存后得到一个预制凭证号。接着并没有马上过账,可能去走审批流程了。就在这个过程中,有用户取消了这个PO的审批通过,然后修改了一些数据后又再次审批通过了。
在这种情况下,当用户想对之前创建的那张预制凭证记账时,系统就报了之前所说的那个错误信息。
其技术上的原因是,在当时建立预制凭证时,系统中PO的定价过程还是原来的样子,MIR7在将PO行项目信息拷贝到RSEG里去的时候,参考了相关定价条件在表KONV的STUNR字段的内容,当时这个字段的值是31。 拷贝到RSEG-STUNR里。
但是,当用户重新Release那个PO之后,定价过程被重新确定, 相关定价条件在表KONV的STUNR字段的内容改为70了。这个时候,再去对那个预制凭证进行记账时系统会校验RSEG的STUNR和KONV的STUNR是否一致,如果不一致就无法处理。
教训:对于这种跨业务模式的PO,修改的时候千万谨慎。
查了半天,发现是这么回事。
A采购订单,创建于09年7月,09年8月的时候由于系统调整,这个PO对应的定价过程有过调整。其中和发票校验相关的一个定价条件在定价过程中的位置被移动过了。
到了前几日,用户做预制凭证了,保存后得到一个预制凭证号。接着并没有马上过账,可能去走审批流程了。就在这个过程中,有用户取消了这个PO的审批通过,然后修改了一些数据后又再次审批通过了。
在这种情况下,当用户想对之前创建的那张预制凭证记账时,系统就报了之前所说的那个错误信息。
其技术上的原因是,在当时建立预制凭证时,系统中PO的定价过程还是原来的样子,MIR7在将PO行项目信息拷贝到RSEG里去的时候,参考了相关定价条件在表KONV的STUNR字段的内容,当时这个字段的值是31。 拷贝到RSEG-STUNR里。
但是,当用户重新Release那个PO之后,定价过程被重新确定, 相关定价条件在表KONV的STUNR字段的内容改为70了。这个时候,再去对那个预制凭证进行记账时系统会校验RSEG的STUNR和KONV的STUNR是否一致,如果不一致就无法处理。
教训:对于这种跨业务模式的PO,修改的时候千万谨慎。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1605/viewspace-659566/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/1605/viewspace-659566/