• SAP MM学习笔记31 - 已割当供给元的购买依赖


    上次学习了未割当供给元的购买依赖(未分配供应商采购申请),咱们本章来学习一下 已割当供给元的购买依赖如何处理。

    SAP MM学习笔记30 - 未割当供给元的购买依赖_东京老树根的博客-CSDN博客

    如下图所示,利用

    - 购买依赖割当一览(手动)

    - 从购买依赖的自动生成(自动)   ※ 这个用的最多

    来生成后续传票(比如这里就是购买发注)。

    1, 购买依赖割当一览(手动)ME58

    画面风格跟 ME57 非常相似。

    1-1,ME58 购买依赖的割当及处理

    购买依赖的割当及处理

    双击 割当购买依赖 图标

    这是 购买依赖 10013903 可能割当的 仕入先

     选中想要割当的仕入先,然后点 购买发注登录 按钮

    在 ME21N 里面根据 购买依赖 生成 购买发注

    将购买依赖 拖到购物框图标上,可以看到 仕入先(这里就是 购买契约)已经确定,并自动拷贝到 购买发注

    后续的发注,入库等就忽略了。

    2,从购买依赖的自动生成(自动) ME59N

    这个在现场用得非常多,咱们主要学习这个。

    要自动生成 购买发注票,对 购买依赖明细 来说,需要满足如下条件:

    品目Master    -  品目Master中,Plant级别上面,将 自动购买发注 Flg 设为ON

    仕入先Master - 仕入先Master(BP的购买Data)中,将 自动购买发注Flg 设为ON

    购买依赖明细 - 购买依赖明细 要割当济 供给元(比如 购买情报,契约,最终传票等)

    当然,如果是无品目明细,只要购买依赖明细 中设置了 评价额,那也可以。

    勾上了 仕入先,表示说该仕入先下面的品目有可能自动购买发注,

    勾上了品目,表示说该品目可以自动购买发注。

    两个必须都勾才能自动发注。

    做个练习。

    2-1,MM01 品目登录

    当然要是事前就准备好,那不做这一步也没问题。

    这里还出了个错误,说 自动购买发注 Flg 是必须项。(这个应该是Spro Customize做的)

    正好咱们也需要这个项目,就先不深究了。

    Msg 番号 00055

     2-2,品目的供给元割当

    这个有很多种割当方式,具体看如下文章。

    SAP MM学习笔记28- 供给元(供货源)决定_东京老树根的博客-CSDN博客

    SAP中 供给元决定的优先顺序如下:

    -  供给量割当

    -  供给元一览

    -  购买契约明细

    -  购买情报

    咱们这里就随便弄一个,比如供给元一览。

    1),ME01 供给元一览

    保存,照会

    不先弄 购买情报 是不行的

     2),ME11 购买情报登录

    输入 价格

    保存,照会

    3),ME01供给元一览

    回到 供给元一览,再次check,OK

     2-3,ME51N 购买依赖

    注意 仕入先 已经割当

    保存,照会

      2-4,ME59N 从购买依赖自动登录购买发注

    注意咱们这里 先勾上 Test实行

    这样就是测试一下,而不是直接就做自动转换

     购买依赖 10013905 好像没出来呀。

    注意咱们的条件:

    - 品目Master 自动购买发注Flg

    - 仕入先Master 自动购买发注Flg

    - 供给元割当济

     1),ME51N 购买依赖

    2),MM03 品目照会 双击上图品目Code打开

    自动购买发注 已设置

    3),MK03 仕入先 双击上图(ME51N)中的仕入先

    原来是仕入先99002 没有设置自动购买发注 Flg

     设定 自动购买发注 Flg 为ON,保存

    4),ME59N 再次Test实行

    这里面重点说一个东西:

    新规购买发注 里面,有很多选项,比如

    - 会社Code别

    - Plant 别

    - 购买依赖 别

    - 购买依赖明细 别

    这些都是什么意思呢?

    就是说,是以什么单位来 做一张 购买发注票。

    比如 会社Code别,就是以会社Code 为单位,把所有符合条件的数据给弄到一张票上。

    这个东西要慎重,为了check的时候清晰,最常使用的是 购买依赖明细 别

    只有这个 不把明细给统合了。

    比如 购买依赖 别 的话,因为发注号一样,它会把购买依赖的数条明细统合成一条发注。

    为啥不要统合呢? 这跟 Interface 有关。

    因为购买依赖的每条明细都可以删除,更新,被统合到一张购买发注票的话,后处理会非常麻烦。

    要是一条购买依赖明细对应一张购买发注票,那不就爱咋咋地了嘛。

    这次 购买依赖 10013905 就能显示出来了。

     A),购买依赖明细别

    为了测试 购买依赖明细别 ,我再做一条 购买依赖:10013906 有3条明细。

    ME59N 里面都显示出来了。

    现在把 Test实行 去掉,把购买依赖明细别 也勾上,然后点 检索 图标。

    看 购买发注 栏,每个明细都会生成一个 购买发注。

    B),购买依赖别

    再做一张 购买依赖票 10013907

    ME59N 从购买依赖自动登录购买发注

    这次 勾上 购买依赖别

    这不是一样的嘛!

    这说明,它其实还是是首先以 仕入先 为单位的基础上,

    其次再根据 设定的 购买依赖明细别Flg / 购买依赖别Flg 来决定发注票里面的明细

    购买发注票 的Header部分,有一个仕入先,

    也就是说,不同的仕入先,是不可能放到一张购买发注票上面的。

    就是不可能一张发注票 到 两家供应商买东西嘛。

    新规购买依赖。

    注意这里的 100-123,100-124 的仕入先都是 99002。

    再次做 ME59N

     

    这次看到两条 明细 都放到了一张 购买发注票里面了。

     

    现在,我们再来看一下同样条件下, 如果选 购买依赖明细的话,会怎么样。

    这次可以看到 如果 勾选 购买依赖明细别, 那么无论是否有些明细是 同一个仕入先,购买发注肯定是分开的。也就是一条购买依赖明细,一个购买发注票。

    这样购买发注票里面,只有一条数据,对后面的处理,处理起来极为方便

    所以在现场,大家一定要说服客户采用这种方式,否则将来会面临很大处理困难。

    比如测试的工作量也会剧增。

     

    5),总结一下

    假如 你的

    - 购买依赖是 MRP 自动生成的

    - 供给元是自动决定的

    - 仕入先 及 品目Master 中的 购买依赖发注Flg 都勾上了

    那么,ME21N的购买发注就可以自动做。

  • 相关阅读:
    MySQL进阶篇(3)—锁、InnoDB引擎
    动态规划课堂4-----子数组系列
    自动化测试的生命周期是什么?
    Java计算机毕业设计电力公司员工安全培训系统源码+系统+数据库+lw文档
    Tiktok 网络、网络
    on java8之复用
    getReader() has already been called for this request
    python每日一题【剑指 Offer 46. 把数字翻译成字符串】
    金蝶EAS本地WebService发布
    vue和react的区别
  • 原文地址:https://blog.csdn.net/shi_ly/article/details/132817284