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

2017-11-11 浏览

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

一、业务介绍。

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

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

二、采购订单管理。

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

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

1、 有效期。

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

2、 没有物料编码。

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

3、 期望值和限制值。

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

三、采购收货管理。

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

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

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

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

四、发票验证管理。

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

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

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

五、框架性订单的缺陷。

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

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

免费注册