SD常见流程一览

超、凢脫俗 2022-03-02 01:28 351阅读 0赞

## SD常见流程一览 ##

(2013-07-12 14:15:28)

![sg_trans.gif][]转载*▼*

<table> 
 <tbody> 
  <tr> 
   <td>标签：&nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=sap&amp;by=tag" rel="nofollow">sap</a></h3> &nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=sd&amp;by=tag" rel="nofollow">sd</a></h3> &nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=%CF%FA%CA%DB%B6%A9%B5%A5&amp;by=tag" rel="nofollow">销售订单</a></h3> </td> 
   <td>分类：&nbsp;<a href="http://blog.sina.com.cn/s/articlelist_3506718455_2_1.html" rel="nofollow">SAP实施</a></td> 
  </tr> 
 </tbody> 
</table>

想写点关于流程设计的东西，想来想去发现没法写。为啥？因为都是跟企业实际业务来的，哪怕是同样的行业，不同企业做法不同，流程就不一样。所以只能来盘点一下SD的常用流程，顺带说明一下适用范围了。但是实际上给企业设计流程，方式是跟博主所写的东西是相反的，博主这写的是什么流程适用于什么业务，而给企业实施的时候，应该是看这个业务应该用哪个流程更合理。

先罗列一下这些流程，然后再一一叙述。

正常销售、正常退货、第三方销售、跨公司销售、独立采购、寄售、免费赠送。基本上这些就是最常见的流程了，当然还有一些不太常用的流程没有列举进来，如果有比较特殊的，后面再补充。

在展开说明之前再啰嗦两句，SD的所谓“流程”，基本是体现在销售订单行项目上，基本上它控制了大部分SD的流程走向和主要功能，反而在销售订单上面没有什么体现功能的地方，基本上就是用来做些大类区分，确定一下交货、开票类型，参与一下定价、输出确定，打打酱油。

好了开始挨个数落。

正常销售，嗯……很正常的赶脚![SD常见流程一览][SD]，其实就是适用于销售-交货-开票这种最常见的流程，MTO也好，MTS也好，都是一样，有了库存就可以出库了。MTO就是要有个订单库存，给PP传递个需求。

正常退货。这个不太正常，为啥呢？因为SAP给的正常退货订单，那是一手退货，另一手退钱的，billing是基于SO开的，所以呢标准的RE类型会带上一个billing block，意思是只要有人给解锁，钱就可以退，货啥时候退进来无所谓，不影响你退钱。这个跟国内大部分的退货要求是不一样的，大部分都要求退货入库以后才可以做退货开票。这样一来除了要把billing改成交货相关以外，还需要配置VTFL从退货交货类型到退货开票类型的复制控制。SAP标准的是没有这个复制控制的。

说到VTFL再多说两句，SAP的T-CODE实际上是很有规律的，只不过是坑爹的德语规律，V一般代表销售，A是销售订单，L是交货单，F是开票。所以VTFL这个事务码其实表示了：销售(V)复制(T我猜的)开票(F)交货(L)，也就是从交货到开票的复制控制。其实我就记得这一个，其他那几个就靠推导了，订单到交货，那就是VTLA，订单到开票，那就是VTFA，不信你试试……

言归正传，该说第三方了。第三方（行项目类别TAS）、独立采购（行项目类别TAB，也叫按单采购）、跨公司（工厂与销售组织不在一个公司代码下）这仨一起说了吧。其实就是三角贸易的三种情况，前提都是一个，就是先有客户订单，再有公司间往来。客户、销售公司、供货公司三方。

这里面如果供货公司先把货发给销售公司，再由销售公司给客户，那就是独立采购或者叫按单采购，采购进来是销售订单库存，只为该客户采购的。使用这个流程，一定注意是先有客户需求，再发生采购，而且一定是单独为这个客户采购的，这样一来订单的成本就是采购价，而不是货物移动平均价或者标准价。

如果供货公司直接把货发给客户，那么：如果供货公司跟销售公司同在SAP的一个Client，就可以做成跨公司销售，否则就第三方销售。这两个流程在国内企业里面一般是不会启用的，为啥？因为账上没有货物进出。被X友、金X坑害的国内财务，固定思维就是要卖东西就必须有物料，必须做出入库，再不济就拿出税法来说明，或者干脆说这个没法跟税务解释。遇到这种情况，博主只能说，认了吧，有简单的你不做，你就喜欢复杂的，那你们搞SO-PO玩吧……当然，还是要尽量说服客户去尝试尝试的。也有企业搞个折中方案，通过独立采购的PR，转一个STO出来，再对STO做收发货，省不了几个事，折腾呗。如果要做跨公司销售，一定记得公司间是缺少一步凭证的，就是销售公司对供货公司的应付财务凭证。这个凭证手工做可以，但是通过不太复杂的EDI配置就可以做成自动的，没啥风险，还是自动的好。

寄售呢，有4个动作，翻译成中文以后不知所云，所以还是用英文来说。Fill-up/pick-up这俩是正反的一对，Issue/Return这俩是正反的一对。寄售是干啥？说白了就是免费铺货，卖多少结多少，不卖不结。结算也不是随时卖随时结，而是约定一个期间，对这期间内发生的销售一起结。所以呢，在Issue或者Return之前，可能做了无数的Fill-up/pick-up，这俩其实就跟MB1B没啥太大区别，库存移动，从你的库存地放到客户寄售库存，或者拿回来。而Issue呢，其实就是你跟客户结算后，把库存从客户那出掉，跟客户收钱。在博主做项目的过程中，发现用户最不好理解的是这个return。这个Return呢，是说你已经跟客户结算了，结算后，客户的客户（也就是最终客户）发生了退货，这个退货是退到你客户那的。嗯，很绕口。举个栗子：

这个是初始的状态

企业库存  寄售库存      结算数量

100       0             0

做了Fill-up 100，结果就是

企业库存  寄售库存      结算数量

0         100           0

然后这期间，寄售客户可能每天都在销售给最终客户，但是只要企业不跟他发生结算，这100个库存就会始终挂在寄售客户下面。

做了30个Issue

企业库存  寄售库存       结算数量

0         70             30

下次结算时这个客户说了：我的客户给我退了5个，我一个也没卖出去。这时候就只能做5个Return

企业库存  寄售库存       结算数量