上一篇学习了请求传票（发票）的拷贝管理。
SAP SD学习笔记21 - 请求传票的数据流（拷贝管理）-CSDN博客
本章继续学习 SAP SD的内容。
目录
以下是详细内容。
1，VF04 - 一括请求处理（开票到期清单）
现实应用当中，不会来一单就开一个发票出去的，大家都是统一集中处理。
比如下图所示，尽管 5/12, 5/14, 5/15, 5/17 都有发票要开，
但是统一集中处理，比如先处理5/15到期，且受注先是C1的部分，
那就会集中开 5/12,5/15，且受注先是C1 的一共 3 张请求票。
具体是在哪里做的呢？
SAP标准的话，就是 VF04 - 一括请求处理。
这里除了上面说的 请求开始日的范围，受注先的范围，还有对象传票的其他范围，比如
- 选择对象传票：出荷关联
这里 VF04 说的是Online的批处理，以前在下面文章里也说过：
SAP SD学习笔记05 - SD中的一括处理（集中处理），出荷和请求的冻结（替代实现承认功能）_sap vl06g-CSDN博客
那么如果是后台的批处理是哪个呢？
2，VF06 - 请求的Background Job登录
这个画面和 Online处理 VF04 有点儿像
但是也有不同的地方，比如
- Job开始日：设定Job的执行日期时间
- Job割当（分配）：设定执行对象范围的
比如 每100张发票放到1个Job里处理，第二个100张放到另一个Job里处理等等
以防止某一个Job处理过多内容
3，现场更倾向于用 Add-on 来批量处理请求书登录
上面讲的 VF04 ，VF06 这种批量执行的，其实在现场大家都不怎么用。
那大家都用什么呢？
都用Add-on来做的。
为啥大家会比较倾向于用Add-on来做呢？
就是因为标准（VF04，VF06），只要是受注或出荷票有了，然后它就认为满足条件就给登了请求书，然后就会开始进入付款流程了。
但是其实，现实中有时虽然已经有了受注票或出荷票，被还会被认定为还不到付钱的时机。
比如，如下图的第3种情况，更进一步细分为
- 1 通过 受注 登录 请求书
- 2 通过 出荷传票 登录 请求书
具体例子呢，比如你们酒店买了一大批的洗衣机和空调，然后你的票其实分为上面的1 和 2 两种。
1 就是安装服务， 2 就是实物（洗衣机和空调）。
然后货先到了，但是安装人员还没到，或者即使到了，但是还没安装完成。
这种时候，如果是从标准（VF04，VF06）来看呢，因为受注票和出荷票都已经有了，SAP就会认为可以登请求书了；
但是从业务来说，安装还没完成，也没法检查安装完之后是否合格，所以就不想先付款。
像这种更为细节的请求书生成条件，SAP标准是很难做的，所以各现场就需要根据自己的需求做
Add-on来实现。
Add-on里面实现自己的业务逻辑就灵活多了，在登请求书之前，根据你的业务去check一下所有相关联的东西，确保所有条件都满足了才真正去登请求票。
那你说那干脆出荷票生成请求书，受注票生成请求书分开来得了呗。
那后面当你查账的时候又很不方便，毕竟它们其实是一拨的嘛。
- 没弄好之前，我暂时都不付款，等你都弄好再说
- 都弄好之后，我验收也没问题，再一起在一张票上付所有款
就这些琐碎的业务逻辑，SAP标准不会给你做的，它也不知道你的具体业务。
当然，一般来说也不会变化太大，大部分都跟标准差不多，
所以Add-on 可以参考标准，先把那些内容都拷过来，然后加一些你自己的业务逻辑即可。
4，请求传票的实际情况与实现方式
4-1，一括请求传票
像下面这种，在现实当中是很常见的。即
- 多张受注
- 多张出荷传票
- 一张请求书
现实中，几乎所有公司的商业模式，都是月末结账，
即把本月的所有请求书给统合到一张请求票上，然后拿给客户让客户统一付款。
那你说要怎么实现呢？
是把所有请求书都给统合到一张请求书上吗？
咱们以前一直强调一个观点，那就是逻辑要简单化。
比如系统当中，最好是一个受注，一个出荷，一个请求书，这种1对1的关系是最Simple的。
上面虽然最终态要统合，但是不意味着真的要在系统里把所有票给出力成一张请求书。
其实目的就是最终要统合成一张请求书给客户而已是吧。
所以大家的一般实现方式是这样的：
- 系统里面还是单纯的一张张请求书
- 做一个Add-on来统合所有请求书到一张票上，其实都不能叫请求书了，可以称之为帐票
- 月末运行该Add-on来统合系统中所有单张的票成为最终的一张票，然后直接邮给客户收款。
这样做的好处就是，系统里面的数据处于"简单化"状态，
万一将来需要Cancel，或者需要订正处理起来就会很方便。
所以说，像上图所示，最终请求书里面包含本月所有数据这种情况，只会存在于课本中，理想中，
在现实中，大家不会那么干的，太麻烦了，几乎都是通过Add-on来实现统合。
即系统中各种票都是分散的，然后再用Add-on给客户打印一个统合的请求票。
4-2，自带请求书分割
首先这种统合与分割，在现场都是几乎不用的，这种逻辑，一般也是只存在于课本中。
如下图，原始的受注票有两张，因为出荷先 - C1 相同，所以就给统合成一张出荷票；
然后又因为支付条件不同，所以收钱的时候，又给分开成两张请求书。
单纯从逻辑上说，出荷先（交货地点）因为跟支付无关，所以确实可以合并，技术上也能做到。
下面再说说分割方式。
分割的方式可以有多种多样，比如
- 下图中是根据品目Group进行分割
- 上面的图是根据支付条件进行分割
- 还可以根据其他条件，比如利润中心(原价Center)等进行分割
分割是怎么实现的呢？
- 其实就是利用 VBRK-ZUKRI 字段管理请求书Header(抬头)的 分割条件。
意思就是这个用于分割的字段里面的值发生了变化了，就新生成一张票。
上面说了在现场如何自带分割请求书。
但是在现场没人用这种东西，后患无穷。
现场大家都用下面这种，受注--》出荷传票--》请求书，这种1对1。
如果需要统合，比如上面的 4 - 一括请求传票，需要月末结账，要把某客户的所有请求书给统合到一张票上，也不是直接统合，而是通过一个Add-on，另作一张帐票而已，数据本身还是分散的。
5，VF24 - 请求书一览（发票清单）
上面 4 里面说用Add-on 来讲分散的请求书给统合到一张票上。
其实SAP 本身也有这种东西，即VF24 - 请求书一览的WorkList。
SAP Menu > Logistics > 贩卖管理 > 请求管理 > 请求传票 > 请求书一览
SAP为啥提供这种功能呢，如下图所示，其实是SAP想把一些票给合并起来，然后给打个折（割引）或做一些其他动作。
想法是挺好的，客户能把欠款都一起付了的话，那就给打点儿折儿，
但是这种功能在现场基本不用的，该付多少钱就付多少，无需讨价还价，这样大家做生意都轻松。
VF24 - WorkList编集 - 请求书一览
这个Tr-cd 的目的是把既存的请求书给合并到一起。
这个和 VF04，VF06 不同，VF04，VF06 是把未生成的请求书给一括(统一)生成了。
下面来简单看一下VF24 的用法。
5-1，数据准备
第一条数据：
- 受注：13382
- 请求书：90038110
第二条数据：
- 受注：13383
- 请求书：90038109
5-2，VF24 - 个别请求传票
打开 VF24，就可以检索出来下面这两条数据
选中之后，点 Simulation 图标
显示模拟的结果
点返回图标，然后点 个别请求传票
这个好像不太行，因为尽管我选了多条，但是全请求书一览明细 画面里面，怎么只显示其中1条？
点返回
5-3，VF24 - 一括请求传票
点 一括请求传票
这次直接就把Select(S) 列给置为 1 ，而且也自动保存了
5-4，VF23 - 请求书一览照会
回到 请求书 0090038109
参考执行前的请求书，发现多了一行请求书一览 0090038111
<参考-请求书一览执行前>
再看 请求书 0090038110
参考下面的执行前的请求书，发现同样多了一行 0090038111
<参考-请求书一览执行前>
到 VF23 看一下该请求书 0090038111
里头确实包括两个请求书
下面来看一下 个别请求传票是什么意思。
准备两条数据：
1 - 受注：13384、请求书：0090038112
2 - 受注：13386、请求书：0090038115
VF24 - 请求书一览
两条都能检索出来
选中2条，点 个别请求传票 按钮
哎，只显示其中1条哈
这回只选中其中1条
然后再点 个别请求传票 按钮
感觉这个按钮好像只能处理1条啊
这回选2条，然后再点 个别请求传票
直接点保存按钮
还挂了还
算了，这个功能本身就不怎么用，我就不继续调查了
5-5，总结
以上就是VF24 - 请求书一览的大致功能。
它可以把已经存在的请求书给合并起来。
但是，在现场大家都不用这个东西，因为用标准合并的结果跟我们想象的结果有很大差别的。
在现场大家比较常用的方式如下
- 受注 --》出荷 --》请求 保持 1对1 ，把这个数据保存起来
- 月末的时候用Add-on 打印一张月结的统合票，发给客户请款
本篇主要讲了请求一括处理方面的内容：
- VF04 - Online 一括请求处理
- VF06 - Background 一括请求处理
- Add-on 处理批量请求书登录
- SAP提供的标准 一括处理与请求书分割，以及现实中的运用情况
- VF24 - 请求书一览
当然，上面讲了一大堆，其实在真实项目当中很难满足各自的需求，现场几乎没人用标准功能。
请求书（发票）是跟钱相关的功能嘛，大家当然会睁大眼睛的。
所谓林子大了，什么鸟都有，各大公司都有自己的需求，SAP也很难做到都符合大所有家需求。
这个GAP呢，也导致几乎没人使用标准功能，而会使用Add-on来精细的控制生成条件。
以上就是本篇的全部内容。
更多SAP顾问业务知识请点击下面目录链接或我的博客主页
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
