SAP MM 标准采购组织的分配对于寄售采购订单收货的影响
SAP MM 标准采购组织的分配对于寄售采购订单收货的影响PO 4100004022 是一个寄售的采购订单,采购组织是CSAS, 工厂代码SZSP。采购信息记录也是有的,MIGO试图对该采购订单执行收货,系统报错:Purchasing info record not found in purchasing organization SZSP.详细信息,Purchasing info record
SAP MM Return to Vendor
设计方案的时候,要考虑各种情况,
SAP MM '独立/集中'等于1的MTS物料MRP运行后合并需求触发PR
SAP MM '独立/集中'等于1的MTS物料MRP运行后合并需求触发PRTest data独立与集中: 1 (仅个别需求)STO 1, 这是一个公司间STO,从国内生产基本转入香港贸易公司,2019-02-22: 100 PC.STO2,这也是一个公司间STO,从国内生产基本转入香港贸易公司,2019-02-22: 200 PC.MD02 去RUN MRP,MD04,去看MRP
SAP MM ME29N 试图取消审批报错 - Document has already been outputed-
SAP MM ME29N 试图取消审批报错 - Document has already been outputed(function not possible) -今天收到用户的一个问题,说他试图使用ME29N去取消采购订单的审批,系统报错 :Document has already been outputted(function not possible).项目上,完成审批的采购订单是不允许修
SAP MM 采购ERP顾问咨询费限制总金额的框架协议实现方案
SAP MM 采购ERP顾问咨询费限制总金额的框架协议实现方案【业务场景】采购部门与ERP咨询公司签订了一个框架协议,只规定不同级别顾问的人天费用,不限定这些不同级别咨询顾问的具体采购的人天数,但是框架协议有一个总金额的限制。然后每个月按咨询公司顾问实际人天数下达采购订单和付款,累计采购金额不能超过合同的总金额限制。【实现方法】创建一个金额合同,只规定不同资历顾问人天价格,采购数量不输入,如下图示
SAP MIGO 发货批次确定界面批次可用数量无穷大问题之对策
SAP MIGO 发货批次确定界面批次可用数量无穷大问题之对策本周收到业务的一个问题,MIGO投料的时候批次确定功能建议的数量不准确。在批次确定界面里,每个批次的可用数量都是无穷大,如下图示:由于笔者所在的项目是一个民营企业的项目,开发增强无底线无节操,无处不在无孔不入。所以笔者第一时间想着是不是有增强程序没有控制好,因为根据笔者的经验,SAP系统的标准功能不会出这么明显的问题。所以就去问项目一期
SAP MIGO 收货界面'批次'分类选项卡里不出现'分类'按钮之对策
SAP MIGO收货界面'批次'分类选项卡里不出现'分类'按钮之对策MIGO + 移动类型Z02收货界面,'批次'选项卡里,没有出现'分类'按钮,为啥,如何解决?修改如下配置,Z02移动类型的配置里 'CB'字段为空,将其改为4即可。再次执行MIGO + Z02收货,'批次'选项卡,分类按钮就看到了:2
SAP MRKO Error - For document type RE, an entry is required in field Reference -
SAP MRKO Error - For document type RE, an entry is required in field Reference -对于供应商100364,执行MRKO,不能成功!Error msg: For document type RE, an entry is required in field Reference1, OBF4,RE类型的财务凭证里,Refer
SAP MM 为MB51报表增加查询字段
SAP MM 为MB51报表增加查询字段 比如想按照’抬头文本’字段来查询, 找到‘凭证抬头文本’,勾选‘选择字段’即可,如下图: 2019-02-25 写于苏州市
SAP MM ME1M报表结果真的不科学?
SAP MM ME1M报表结果真的不科学? 深入研究后发现,不是SAP ME1M报表不科学,而是笔者对于SAP系统的认识有盲点。 经查,ME1M报表是可以显示PIR里维护的最新价格的。如下方式: 勾选‘Include discounts’选项。执行后,能显示最新采购价格了, PIR数据, 多个物料同时查询,也能达
SAP MM ME1M报表结果不科学?
SAP MM ME1M报表结果不科学? 做过SAP MM顾问的都知道,报表ME1M可以查询物料的info record列表,即是说可以以列表的形式批量显示多个物料的采购价格主数据。 但是这个报表有个不科学的地方是,当业务人员修改了采购价格主数据(采购信息记录里的net price), 报表却不能显示最新的价格,显示的还是老的采购价格。如下所示, 显示该物料价格是165
SAP MM MIGO界面里的'Delivery completed'标记
SAP MM MIGO界面里的'Delivery completed'标记 我们知道,采购订单行项目数据里有一个字段叫做‘Delivery completed’标记的。当业务人员完成全数收货,或者部分收货数量超过under delivery容差的话,过账后系统自动将该标记勾选上。 比如一个采购订单,订购数量100个;不足交货容差10%。如果仓库收货100个,或者
SAP MM 实施项目里Open PO 迁移思路探讨
SAP MM 实施项目里Open PO 迁移思路探讨 .序言. SAP项目上线前夕,除了静态主数据需要导入以外,可能还有一些动态数据,比如open的采购订单,open的销售订单等单据也要迁移到SAP系统里。 笔者所在的项目里,对于Open PO 的迁移,是MM模块里一件非常重要的工作任务。笔者通过参与这个项目,了解到客户global template中Op
SAP MM 根据采购订单反查采购申请?
SAP MM 根据采购订单反查采购申请?前日微信上某同行发来一个message,说是想知道如何通过采购订单号查询到其前端的采购申请号。笔者首先想到去检查采购订单相关的常用报表ME2L/ME2M/ME2N/ME80FN等,居然没有哪个报表能支持这个查询需求的。然后笔者从采购申请的相关报表着手,比如ME5A, 发现它是可以满足需求的。比如如下的采购订单, 该订单是由采购申请116763936
SAP MM MI01事务代码里的批次确定
SAP MM MI01事务代码里的批次确定 1 – 批次管理启用之后果 一个物料如果启用了批次管理,那么库存管理以及盘点等诸多事务里都需要在批次的层次上进行。 货物移动的时候,需要在界面上指定相关货物移动的批次号,否则系统不让成功过账:- 在出库的环节,比如201发货到成本中心的时候,可以根据后台设置的原则比如先到有效期先出库,先进先出等原则,由系统自动建议出货的批次
SAP MM 事务代码MI31之思考之续集
SAP MM 事务代码MI31之思考之续集 上周写了一篇文章,关于事务代码MI31之思考的,遗留了一个open的问题,说是抛砖引玉。文章发出来后,引起了同行们的关注与评论,有同行提醒说在事务代码MI31初始界面,有办法剔除那些没有账面库存的物料的。 笔者再次检查了MI31事务代码之初始界面,有新的发现: 点击按钮‘Acc.to Stck’, 勾选’Only
SAP MM MIGO + 311 针对预留单做转库不能修改目的地存储地点!
SAP MM MIGO + 311 针对预留单做转库不能修改目的地存储地点!一个标准的311转库操作界面,业务人员可以随意指定from storage location和dest storage location,如下图: 但是如果MIGO+311的转库操作,是针对一个预留单据来做的,MIGO界面就不是这样的了。比如如下的预留单据,就是一个311转库的操作预留单, 这个预留是将
SAP MM 事务代码MI31之思考
SAP MM 事务代码MI31之思考 1 - MI01之痛 多年SAP项目实施实践中,笔者之前对于SAP系统里盘点凭证创建(MI01)事务代码里的输入界面很是不爽: 第一,MI01输入了一行数据以后,回车,系统就隐藏了之前输入的数据,需要点击其它按钮或者菜单才能看到。这个很不方便啊,不管别人使用体验如何,反正笔者是很不爽!第二,MI01 界面里对于数据批量输入不太方便
SAP MM 采购申请单据ITEM数据里的Closed标记
SAP MM 采购申请单据ITEM数据里的Closed标记 笔者在SAP系统里发现,某个采购申请单据,已经全额数量的转成了采购订单, 其ITEM数据里的Closed标记并没有被勾选上,如下图: 我查了这个字段的帮助文档, Purchase Requisition ClosedFlags a purchase requisi
SAP MM 不常用事务代码之MBSL - Copy Material Document
SAP MM 不常用事务代码之MBSL - Copy Material Document 闲来无事的时候,笔者喜欢在SAP系统里捣鼓捣鼓。SAP设计的那些不常用/没关注过的事务代码,字段等,总能引起笔者的兴趣。 下午笔者在SAP系统里,偶然发现一个事务代码MBSL,用于copy material document的。 这个事务代码笔者之前还真没有注意过,也从未使用过。