关于寄售PO收货时提报消息M7165的原因深度分析及处置办法的说明

关于寄售PO收货时提报消息M7165的原因深度分析及处置办法的说明

作者:袁云飞(AlbertYuan)- 微信号yuanalbert

以下内容均为原创,希望对初学者有一些辅助作用,本人主要从事MM/QM/WM的相关工作,不专业处请多多指点,十足干货,码字不易,且行且珍惜,你们的关注就是我努力的动力,转载请引用出处,感激不尽;

寄售业务,准确的讲应该叫供应商寄售业务,其实很多制造业企业都或多或少在使用,关于其业务方式优缺点及适用范围,我会在以后篇幅里专题给出;这里我们讨论一个在此业务模式下的一个小问题;

说是小问题,是因为小伙伴们如果做运维,基本是碰不上的,一旦碰上,那就有点尴尬了;但我还是经常遇到过,其实不是问题本身,主要是其内在关系和机理,我一直在寻找答案;最近有所收获,所以以此篇文章来给小伙伴们讲解说明一下;

M7165这个消息的内容是“Purchasing info record not found in purchasing organization &”;也就是信息在采购组织XXXX上没有找到;一般这个报错重现操作是:创建一个寄售PO,然后针对该PO做MIGO的收货记账;

该问题的表面原因很容易分析,就是你配置的工厂标准采购组织下,在收货时,没有找到对应工厂,采购组织,物料,供应商组合的寄售信息记录;
在这里插入图片描述
这里我们简单说一下这个看似普通的配置,标准采购组织是一定要分配给一个工厂的,标准采购组织主要用来针对,pipeline,consignment,以及stock transfer业务下系统自动确定一个对应信息记录的连接点存在;所以基于此,管道业务,转库业务也都会在上述情况下提报这个消息;

所以解决该问题很简单,先分辨是否此处的配置出现失误或没有配置对应采购组织,加上对应配置即可,如果不是这样,则完善对应采购组织下的寄售信息记录创建即可;

由于该配置是我们顾问初始构架系统的基础配置,如果配置问题,实在不应该,比较尴尬;所以小伙伴们常常是不会碰到这种问题的;一般是上述说明的第二种情况;

但深究其发生原理是我多年来养成的职业习惯(虽然没有什么卵用(* ̄︶ ̄));经过标准代码分析,其实这个M7165消息是硬编码(hard-code)到程序代码中的,修改SE91配置是没有任何作用的;

下面说下系统标准逻辑是如何进行判断的:

在MIGO针对寄售PO完成GR记账的时候,首选会去函数ME_SELECT_EKORG_FOR_PLANT寻找PO收货工厂关联的标准采购组织,一般就是在T001W表里搜索;这个和工厂-采购组织分配点T024W是不一样的哦;
在这里插入图片描述

  CASE i_index.
    WHEN 0.
      RAISE no_entry_found.
    WHEN 1.
      EXIT.                                                 "ok
    WHEN OTHERS.
      IF i_pipel EQ space AND i_umlag EQ space AND i_konsi EQ space AND
         i_standard EQ space.
        RAISE more_than_one_organization.
      ENDIF.
*   bei Pipeline, Umlagerung, Konsi und auf Wunsch
*   --> Default aus T001W
      IF t001w-werks NE i_werks.
        SELECT SINGLE * FROM t001w WHERE werks EQ i_werks.
      ENDIF.
      IF t001w-ekorg NE space.
        e_ekorg = t001w-ekorg.
      ELSE.
        RAISE no_default_found.
      ENDIF.
  ENDCASE.

随后将找到的采购组织结合相关信息一起,利用函数ME_READ_INFORECORD去搜索对应的寄售信息记录;这一些的处理操作都是在include: FM07MEP0里的form:pipeline_preis_ermitteln,里完成的;
在这里插入图片描述
如果通过函数ME_READ_INFORECORD没有找到对应的寄售信息记录,则MIGO里就会提报M7165的错误消息出来,记账被阻止;
在这里插入图片描述
OK,这个消息的出处基本上也就分析清楚了;不过小伙伴们可能疑问的更多的是,既然供应商寄售业务模型下,很多老师都说过,入库是不产生会计记账的,也就是说不需要任何价格来支撑,为什么在MIGO入库寄售物资的时候却需要检查寄售信息记录呢,而且是强制的;其实个人分析下,主要缘由是SAP认为虽然GR不产生会计记账,但由于寄售业务属于周期性谈价及供应商协同的采购理念范畴,能参与寄售业务的供应商,一般都是企业战略供应商,能支持长期的供应链端到端服务的;寄售业务正好匹配此类供应商要求的高效流转,统一结算,价格周期性变动且相对固定的特点;如果GR的时候连价格都没有谈定维护进入系统,何来高效的供应协同;所以个人觉得此点出发主要不是技术原因,更多应该属于管理范畴,因为寄售物资是处于随时随地都会发生物权转移的;

以上为本章所有内容,希望对小伙伴们有所帮助;

发布了33 篇原创文章 · 获赞 0 · 访问量 887

猜你喜欢

转载自blog.csdn.net/weixin_44853659/article/details/104036891
今日推荐