SAP中服务性订单的替代解决方案

在SAP系统中有标准的服务性订单，可以详细的规划每个阶段的付款情况。如以SAP项目为例，可以分为需求调研、流程优化等几个阶段。每个阶段开始后都要付阶段性的款。通过SAP标准的服务性订单可以实现付款的跟踪。但是这个服务性订单配置和操作工作量比较大。在实际项目中，真正利用这个功能来操作服务性项目的案例并不多。在这里，笔者要给各位介绍的是一个替代方案。

一、业务介绍。

现在某个客户有这么一个需求。他们要求了一家咨询机构对企业的流程进行优化。这项工作大致可以分为需求调研、流程重组、业务培训、项目上线等四个阶段。这项业务总的金额为100万，其中合同签订后付30万、流程重组确认后付30万、业务培训后付20万、项目上线后付10万、上线三个月后付10万。

一开始笔者建议客户通过“服务性订单”来实现这个业务。不过客户反应说没有必要控制的这么严格。他们要求只需要控制总的费用即可。即花在这个项目上的总的金额不超过100万。了解用户的需求后，笔者最后建议用户通过框架性订单来实现这个需求。

二、采购订单管理。

在SAP系统的标准功能中，有一个采购订单类型叫做“框架型订单”，其是消耗性采购的一个衍生。不过这个功能一直被顾问或者用户所忽视。不过笔者在实际项目中，一般都会推荐用户采用这个功能。因为通过这个功能，可以在一定程度上实现费用预算的功能。而不用去启动SAP的费用预算流程或者服务性订单。

这主要跟国内客户的现状有关。国内企业的预算管理或者服务性供应商那个管理的现状，往往是只管粗，不管细。简单的说，就是只管最终的结果，对于中间过程控制的比较少。如果要用SAP的标准管理流程来管理这些业务，可能会适得其反。在这种情况下，采用框架采购订单来管理，相对来说可能更加合适。对于框架采购订单，主要要关注如下几个参数。

1、 有效期。

服务性项目一般都要有个有效期。如在一年内完成这个项目，总共金额是多少。如果是超期的话，则付款就会有问题。为此在采购订单上，需要输入一个有效期。在事务中需要注意的是，这个有效期往往不是项目结束的日期，而是最后一笔付款的日期。这中间会有一个类似质保期的时间段在里面。

2、 没有物料编码。

对于类似的服务，或者费用预算，往往没有物料编码。为此其从本质上来讲，是为某个成本中心采购。所以其走的是消耗性采购流程。在采购订单的科目分配类别中就要选择为成本中心采购。同时，又需要限制其总金额，就需要在账户分配中选择B限制这个参数。这两个参数结合起来，就表示为某个成本中心总共花费不超过多少的金额。

3、 期望值和限制值。

最后在采购订单上要维护一个金额。在标准功能中，框架型订单可以维护两个金额，分别是期望值和限制值。往往是期望值大于等于限制值。这两个金额有不同的作用。期望值一般是用来做审批用。其主要包含总的项目费用和可能会意外支付的费用，如项目做的好的话给项目实施方的奖励。而限制值就是实实在在需要支付的费用。在做采购订单的审批策略时，需要以期望值作为对象。

三、采购收货管理。

在标准功能中，框架性采购订单是不用收货的。在后台配置中，根据项目类别和账户类别对收货功能是禁用的。不过在实际项目中，可能需要对这个进行适当的调整。如以这个咨询项目为例，需要对项目的各个阶段进行验收。只有验收完毕后，才可以进行付款申请环节(发票验证流程)。

为了实现这个控制目的，就需要调整后台配置，启用框架性订单的收货功能。一般建议是复制相关参数，重新配置一个功能出来，而不建议对标准参数进行调整。启用收货功能后，每个项目环节完毕需要验收时，就在系统中做一个虚拟收货的动作。由于是费用性采购，为此收货后并不会形成库存，而是直接消耗到成本中心。这里需要注意的是，项目环节的验收工作需要在体外做，系统内只是记录验收成功这样一个记录。简单的说，就是用户凭验收合格的单据在系统里做一个收货的动作。如果验收不合格，就不做收货单据。如此的话，系统就不能够走后续的流程。

这里另外要强调一点。在框架性采购订单中，其默认的采购数量是1。为此在收货时，要根据付款的百分比，来输入收货的数量。简单的说，就是将采购数量当作是100%。然后根据各个阶段付款的百分比，来输入收货的数量。

当然，如果要启用框架性订单的收货功能，会涉及到后台配置或者简单的增强。在通过框架性订单来实现服务性采购或者费用预算的管理，这是一个非标准的功能。不过比起启用整个费用预算模块或者服务性订单来说，这点工作量并不是很大。

四、发票验证管理。

发票验证需要分两种情况，即需要区分是否收货。如果收货的话，则发票的金额会根据收货带过来。而不收货的话，其金额不会自动带出。笔者这里以标准功能为例，说明一下框架性订单的发票验证过程。

根据普通的消耗型采购不一样，如果没有收货，框架性采购订单在发票验证时是带不出金额的。普通的消耗型采购订单，如果没有收货，会带出采购订单的数量和金额。这个区别，在业务推进过程中，要跟用户重点强调一下。

在发票验证时，用户需要根据实际发票的金额或者管理层同意支付的金额为准，通过“科目分配”功能来输入金额。这里还有一个好处，就是可以更改成本中心。如果项目一开始不能够确认成本中心，直接记录的是公司的成本中心。后来确定需要对成本中心进行细分，就可以在这里更改。不过大部分情况下，不会对成本中心进行调整。

五、框架性订单的缺陷。

利用框架性订单来实现项目或者费用预算控制，其优势是非常明显的。其管理灵活、而且工作量明显降低很多。但是其缺陷也是显而易见的。即这个费用控制是粗放的。简单的说，其没有细化到项目或者费用的每个阶段，而是做一个整体的预算管理。

在实际项目中，是否要启用这个功能，主要还是看企业对预算管理的要求。如果只是一些粗放型的管理，即只是对结果的记录和控制，则使用框架性采购订单完全可以满足要求。如果要实现更加细致的管理(要中间各个环节的控制)，就需要考虑启用服务性采购订单或者费用预算来实现。当然，要启用这些功能，用户需要花费更多的时间和精力。毕竟天下没有白吃的午餐。