• SAP MM学习笔记37 - 请求书照合中的 追加请求/追加Credit 等概念/ 请求书的取消


    有关请求书照合,之前学习了一部分,现在再来学其中的一些概念。

    其实这些概念也许并不常用,但是你又不能不知道,因为客户会问。

    有关请求书,贴一些以前学习的文章,以方便阅读。

    SAP MM学习笔记33 - 请求书照合中修改 带勘定设定Category(科目分配)的发票-CSDN博客

    SAP MM学习笔记35 - 请求书照合中的差额处理(发票扣减,受入)-CSDN博客

    SAP MM学习笔记34 - 请求书照合中的支付保留(发票冻结)_东京老树根的博客-CSDN博客

    SAP MM学习笔记36 - 释放支付保留的发票-CSDN博客

    下面来学习 这些概念

    ・追加请求

    ・追加Credit

    可以用来变更基于价格的更新。

    也就是说数量不变,价格变,也就是金额变。

    1,追加请求

    就是下面画面中的 3. 追加请求 Option。

    在已经处理完的取引(买卖,交易)中,仕入先发现钱要少了(比如运费比想象的高,原材料涨价了等),它就会来一张票再多请求一些。

    由于是已经处理完的取引,所以一般不会变更数量,只会变更金额。

    比如如下图所示:

    购买发注 50 个,500 EUR,已付款,交易完成

    购买发注 20 个,200 EUR,已付款,交易完成

    仕入先又来一张票,声称对于第二笔交易(20个),要每个多收 25 EUR。

    1-1,ME21N 购买发注

    50个

    20个

    1-2,MIGO 入库

    50个

    20个

    1-3,MIRO 请求书照合

    50个

    20个

    1-4,MIRO 请求书照合 追加请求

    仕入先又来了一张票,追加请求

    无法参照已经完成的票,比如这里只能参照购买发注票,70个中的20个,每个要加 25EUR

    注意,这里被支付保留了。

    我们在 ME21N 购买发注 页面也可以看到履历 追加请求。

     1-5,MRBR 查看支付保留状态

    追加贷借转记 也打X,不知道是啥意思。

    另一个是 价格差异,跟上述的 追加请求 的结果一致。

    我觉得后续就是 Leader审核,如果OK的话,可以手动解除,然后就可以进行后续的支付了。

    2,追加Credit

    就是下面画面中的 4. 追加Credit Option。

    在已经处理完的取引(买卖,交易)中,仕入先发现钱要多了(比如运费比想象的少,价格标高了等),就会发一张票退一些钱。

    当然,我觉得也有可能是我方发现对方钱要多了,出一张票给他们,让他们退款。

    由于是已经处理完的取引,所以一般不会变更数量,只会变更金额。

    其实和 追加请求 差不多,这里简单做个例子。

    如下图的第二个例子(下面那个)所示,

    购买发注 100个,入库50个,本来应该收500(50 x 10)EUR,但票上却是 800 EUR。

    第一个例子(上面那个),

    购买发注 100个, 入库50个,本来应收500(50 x 10)EUR,但票上却是 80个,800EUR。

    咱们这里做的是第2 个例子(上图的下面那个)。

    2-1,ME21N 购买发注

    购买发注 100 个。

    2-2,MIGO 入库

    入库 50个

    2-3,MIRO 请求书照合

    客户来了一张 50 个、800 EUR(正确的是 500 EUR) 请求书。

    这里显示支付保留。

    2-4,MRBR 查看支付保留状态

    价格差异。来了50个商品,却来收80个钱的发票(正常应该是 500 EUR,却收 800 EUR)。

    2-5,MIRO 请求书照合 追加Credit Memo

    仕入先来一个 追加Credit Memo,来退钱啦(TODO:为啥总觉得好像有点儿假呢)

    查看一下 购买发注 履历。

    50个收货上做了 追加Credit Memo处理。

    3,Credit Memo 和 追加Credit Memo 的区别

    如下图所示,是Credit 还是 追加Credit,就看这个票要调整什么。

    - Credit Memo :价格正确,数量错了,要调整数量

    - 追加 Credit Memo: 数量正确,价格错了,要调整价格

    理解是这么理解,其实挺不好记的,用户业务中使用的时候,能分清才怪呢。

    暂时也没有好方法记,就是我们常说的顺序 数量,金额,上面两个管数量,下面两个管价格。

    这个顺序也跟我们现实生活中发生的错误的几率类似吧,价格标错了的几率是不是挺少的。

    当数量标错了,要更正数量,就用上面两个;

    当价格标错了,要更正价格,就用下面两个。

    1 - 请求书

    2 - Credit Memo

    3 - 追加请求

    4 - 追加Credit Memo

    4,Credit Memo

    按上面理论,练习一下 Credit Memo。

    还是这张图,上面那个例子

    购买发注 100个, 入库50个,本来应收500(50 x 10)EUR,但票上却是 80个,800EUR。

    4-1,ME21N 购买发注

    100个

    4-2,MIGO 入库

    入库50个

    4-3,MIRO 请求书照合

    来了一张 80个 800 EUR 的票。

    支付保留

    4-4,MRBR 查看支付保留状态

    数量差异 30个。

    4-5,MIRO 请求书照合 Credit Memo

    因为要减少 80 -50 = 30个数量,所以明细中 输入减少的数量及对应的金额。

    购买发注履历 里查看一下。

    可以看到这里其实就是数量的调整,并不会如同 追加Credit Memo那样单列一条。

     MRBR里面,虽然还能查出来,其实已经满足支付解除条件了,只要运行一次解除即可。

    5,MR8M 请求书的取消

    有错误的请求书也是可以取消的。

    取消流程如下图所示。

    取消请求书之后,SAP将会同步生成 Credit Memo。

    同样,如果取消Credit Memo,将会生成 请求书。

    MR8M 请求书传票取消

     

    5-1,MR8M 请求书传票取消

    准备一下请求书照合票,比如下面这一张票。

    5105608902

    反对仕译理由(反向记账原因)

    比较常用的是以下理由:

    - 01 当期的反对仕译

    - 03 当期的实绩取消仕译

    下面来说说这两个东西的区别。

    当购买发注 100EUR 商品,并做完入库的时候,从 FI 科目来看,

    借方                       --             贷方

    ------------------------------------------------------

    在库 100                 /       入库请求假 100

    入库请求假 100      /       买挂金 100

    - 01 当期的反对仕译

    做反对仕译,所以 FI 票计上如下

    买挂金 100            /      入库请求假 100

    - 03 当期的实绩取消仕译

    做当期的实绩取消,所以 FI 票计上如下

    入库请求假-100     /       买挂金 -100

    不管是哪种,都能实现取消的效果,借贷平衡,但是如果从残高的角度看,

    - 01 当期的反对仕译

    科目计上上有残高数据(尽管是平的)

    入库请求假 100      /       入库请求假 100

    买挂金 100             /       买挂金 100

    - 03 当期的实绩取消仕译

    入库请求假 100      /       买挂金 100

    入库请求假-100     /       买挂金 -100

    100-100 = 0,所以残高为0。

    相当于

    入库请求假    0      /       入库请求假 0

    买挂金    0             /       买挂金 0

    科目计上上看,没残高了(相同科目的数值之和为0)

    FI 模块我也不太懂,简单来说呢,就是

    - 01 当期的反对仕译        --> 能留下痕迹,别人知道你做了很多错事儿

    - 03 当期的实绩取消仕译 --> 不能留下痕迹,别人就不知道你干的错事儿

    对最终付款没影响,但是对个人业绩考评可能会有影响,领导会觉得你一天到晚都在干啥呢??

    现场一般会倾向于用 - 01 当期的反对仕译 这种。

    因为 FI 那边一般都希望能留下痕迹。

    输入反对仕译理由,然后点保存

     

    这样就取消了请求书。

    至于显示的Message,手动决济财务会计票,不知道具体是指的啥意思。

     

    取消之后再取消,就不行了。

    看一下购买发注履历,已经取消掉了。

     

    双击 取消的请求书票,可以看到是一张 Credit Memo 的票。

     

    MIRO 请求书照合

    可以重新做正确的请求书照合了。

     

  • 相关阅读:
    【爬虫】用wget命令爬虫的简易教程
    贪心算法应用
    Spring 接口日志切片记录
    设计模式——原型模式
    Node-RED系列教程-26node-red操作mqtt代理节点
    vscode 打代码光标特效
    文本分析与加密
    前端性能优化
    LeetCode --- 1952. Three Divisors 解题报告
    我用PYQT5做的第一个实用的上位机项目(三)
  • 原文地址:https://blog.csdn.net/shi_ly/article/details/133827838