SAP管理软件系统框架合同业务的实现及相关注意事项解析

框架协议是指与某一供货商签订的长期采购协议，供应商按某些特定条件提供物料或服务，要求在一定时间内提供一定数量或一定金额的货物或服务。
框架协议可分为合同(Contract)和计划协议(Schedule agreement)
采购合同(Contract)
合同当中并没有包括具体的交货时间和交货数量，这些信息需要在后续订单中(Release Order)体现。
合同分为数量合同和价值合同。
n            数量合同MK规定供应商在指定时间内必须提供某种物料或服务的数量总值。
n            价值合同WK规定供应商在指定时间内必须提供某种或多种物料或服务的金额总值。
合同项可以指明采购的单一工厂，也可以为一个采购组织下所有工厂采购(central agreed contract)。对于Central agreed contract，供应商可以是整个法人团体，每个工厂可以向该团体的不同公司采购，运用合作伙伴功能实现。这样，就能为每一个工厂定义不同的条件(conditions)，如：运费。
在合同中可以使用特殊项目种类M和W。
n            M用在有相同采购价格，但不同物料编号的情况下。在合同项中不输入物料编号，只输入物料描述，物料组，数量和单位。但是在后续采购订单中必须指明具体的物料编号。
n            W用在同属于一个物料组但是有不同的采购价格的物料。在合同项中输入物料描述和物料组，但不输入价格。在物料号和价格后续订单中输入。W只能用于价值合同。÷
n            对于M和W，在后续订单中输入的物料编码必须输入合同中输入的物料组，如果物料没有在主数据中维护，则需要指明分配帐户(如：成本中心)。在后续订单(Release Order)中，订单类型不能再是M或W，从合同拷贝过来的话，必须手工删除。
计划协议(Schedule agreement)
计划协议的优势
使用计划协议可以缩短系统处理次数，减少纸面作业。一个计划协议可以取代一系列离散的采购订单和合同执行订单(Contract release order)。计划协议可以使自己的库存保持在一个较低的水平并且能让供应商在这个计划协议周期内更有效的管理和分配他们的资源。
计划协议可以有或者没有后续的计划行发布(Scheduling agreement releases)
n            有发布计划
标准的计划协议类型是LPA。只有计划协议做了计划行发布之后，才会把交货计划以文件形式传递给供应商。这种类型的优势是可以在一段期间内用户能监控这个计划行的发布情况。计划行发布有2种形式：
1）预测交货计划(FRC)：一种长期的采购计划，一般以月或者周为单位
2）及时交货计划(JIT)：近期对某物资比较精确的数量需求，一般以日或者小时为单位。一般用于密集型的生产企业。
n            没用发布计划
标准的计划协议类型是LP。在计划协议生成之时就把计划协议传递给了供应商。没有后续的发布计划行了。
Example for Scheduling agreement：
Scenario: 公司近期由于某大宗订单，急需在1周时间生产一批产品，考虑到工厂的产能和目前的库存，需每天采购一万公斤钢材。
1.         创建计划协议ME31L。
截止时间为1周之后，采购10000002物料50000KG，每公斤2.5元(数据纯属虚构)。
保存。因为类型为LPA，所以不会外发给供应商。
2.        IMG->Material Management->Purchasing->Scheduling agreement-> Maint. Rel. Creation Profile for Sched. Agmt. w. Rel. Docu.
这里给每个工厂定义Creation profile, creation profile决定了发布计划行的生成规则
General parameters: Changed or next date
Creation periodicity: Daily
3.         给计划协议分配creation profile: ME32L。
Menu->Item->More functions->Additional data
在Output Control输入Creation profile和JIT indicator
4.         维护计划行交货计划：ME38
在一周的5个工作日平均分配每日10000KG。
5.         定义Message output: MN10
Output Type: LPJ1 (SchAgRel-JITDelvSche)
6.         发布JIT计划行： ME84  
这样就正式向供应商发布的采购交货计划，供应商到货之后就能用MIGO对该计划协议收货了。
7.         可以用ME39查看计划协议的发布和交货情况。
我们都知道，作为全球企业管理软件与解决方案及市场的领导者，SAP管理软件系统，一直都受到国内企业管理者们的青睐。可以说，当前SAP管理软件系统存在大量的用户群体。与此同时，对于那些采购量巨大的国内企业用户来说，在日常的工作中可能会经常存在框架合同的业务。例如：减速机，钢材等等。在今天的文章里，软件直销网小编将就框架合同业务在SAP管理软件系统中，如何实现及相关的注意事项进行一些简单的介绍。总体方面而言，框架合同基本上是SAP管理软件系统的标准功能。当然，也会根据企业的实际情况做一些后台配置和开发。


一，业务场景还原 　　国内的某生产企业，其主要的原材料就是钢板。企业为了降低采购成本，通常情况下都会与钢材企业签订框架合同。当一年的采购量达到多少时，可以以比较优惠的价格来进行购买。对于系统来说，就主要关注两方面的内容。一是价格，二是采购量的累加。具体来说，又可以分为二种情况。

　　其一：物料是指定的，例如某个料号一年的采购量是多少。这要求企业用户在制定框架合同时，要指定具体的料号。在实际工作中，这有一定的难度。很少有企业能够做到这一点。

　　其二：针对某个物料组或者物料类型的，如某类产品的一年的采购量是多少。这又包括两种情况。一是这类产品的价格是相同的;另外一类是产品的价格不同。如果价格相同，则采购订单可以直接从框架合同中获取价格。如果不同，则还需要根据实际情况在采购订单中维护价格。

　　在SAP管理软件系统中，又将合同分为数量合同和价值合同两种。数量合同是以采购数量为基数进行核算的。而价值合同则是以采购的金额为基数进行核算。笔者从事的项目中，大部分是以采购数量为对象，核算的口径以物料组为单位。在后续的描述中，笔者的业务背景就是按照这类来叙述的。下表示笔者对SAP框架合同的一个简单总结，能够在一定程度上帮助大家理解框架合同的整体业务。


　　合同类型说明参数（类型/I）

　　价值合同某一类产品（物料组相同）一年买多少钱（价格相同）数量-M

　　某一类产品（物料组相同）一年买多少钱（价格不同）数量-W

　　数量合同某一类产品（物料组相同）一年买多少数量（价格不同）数量-M



　　二，基础数据的设置

　　在做需求调研时，如果确定企业有框架合同的业务，则在基础数据规划时，就需要特别注意。因为在物料基本数据的物料组设计时，就跟框架合同相关。像上面笔者描述的业务，如果有根供应商签订框架合同，一年的某个类别的采购量达到多少时，可以获得优惠的价格。那么这个物料组的设计就特别有讲究。在实际工作中，可能会存在如下几种情况。

　　一是不管是什么产品，只要是向这家供应商购买，只要金额或者数量达到一定的规模，就可以得到优惠的价格。此时物料组定义时，就要定义的比较大一些。然后再通过外部物料组来进行细分。因为在SAP系统的标准功能中，是通过物料组这个参数来进行核算的。

　　二是即使向同一家供应商购买，其产品也是分类别的。如笔者遇到过一家生产企业，其钢板往往分为厚板，中板，薄板三种。在跟供应商签订框架合同时，会指出三种板一年的采购量分别达到多少，可以得到何种优惠的价格。此时就需要将板材的物料组分为这三类。然后在创建框架合同时分被以这三个物料组为对象。

　　笔者再次强调一下，框架合同跟物料组是息息相关的。如果企业存在框架合同的业务，那么在需求调研和蓝图设计时，物料组这个参数要认真对待。否则的话，很容易返工。


　　三，框架合同类型和参数的选择

　　SAP的框架合同有好几种类型。如从空间的角度分析，有中心合同和单工厂合同。中心合同是指集团签订合同下面各个工厂都可以使用。这种合同集团集中采购的背景下利用的比较多。但是如果同一个集团下面的业务形态基本上不同，则意义不大。因为重合的原材料不会太多。具体的来说，可能主要要关注如下几个参数。

　　一是合同的类型。主要是指合同是数量合同还是价值合同。简单的说，就是跟供应商协商时，确认的是“某段时间内采购多少台设备或者多少吨的钢材”，还是“某段时间内采购多少金额的原材料”。在创建合同时，需要根据不同的业务形态来选择不同的单据类型。

　　二是合同的标的物类型。即在供应商协商时，是不是一个个物料对应清楚的（这种情况不会很多），还是指定的是某个物料类型。据笔者接触的项目来说，大部分情况下都是“某个类别的物料一年的采购量是多少”，也就是说，根据物料组来划分。

　　三是框架合同的时间。如是以一年为单位还是半年未单位。采购量大的企业或者市场价格波动比较大的原材料，其周期会比较短，会以季度或者半年未单位。月采购量不稳定的企业，则会以年为采购周期。这个框架合同的周期，一般情况下，企业都是跟供应商预先确认好的。作为顾问，只需要向用户要这个参数即可。

四是框架合同的审批流程。由于框架合同涉及到的材料，往往金额比较大。为此在框架合同的审批流程中，往往需要财务经理或者总监参与进来。作为顾问来说，需要向用户确认好相关流程，然后在系统中进行相关的配置，以实现这个审批流程。


    四，采购订单处理

　　当有需求时，用户需要生成采购申请和采购合同。在这个环节中，需要注意如下内容。

　　一是采购申请转采购合同时，需要选择对应的采购合同。以“数量合同+物料组”为例。只要采购申请中物料的物料组与框架合同匹配，则在通过ME57转采购订单时，就会自动去匹配这个框架合同。然后采购订单中得到的价格就是框架合同中确定的价格。

　　二是物料组的匹配关系。在建采购订单时，可以参考框架合同创建。此时用户需要手工输入物料编码。这里有个问题，如果用户输入的物料的物料组与框架合同的物料组不一致，如何处理。默认情况下，系统会给出警告信息。用户确认后仍然可以保存。不过一般情况下，顾问需要更改后台配置，将这个警告信息调整为错误信息。因为其他物料组的产品不能够计算到此框架合同中。

　　三是如果采购的数量超过此框架合同后该如何处理。系统默认情况下，如果超过了框架合同的数量，则会有错误信息。这主要是提醒用户，需要再次跟供应商协商创建框架合同。如果继续沿用原有的框架合同，对于企业来说是不利的。因为不能够保证企业在下个框架合同周期中仍然可以达到这个采购数量。如果用户确实有需要，也可以将此消息设置为警告信息。


　　五，后台配置与二次开发

　　框架合同的后台配置或者二次开发，往往包含如下几个内容。

　　一是框架合同的审批流程。系统可以根据企业的需求，灵活的设置审批的节点。如根据框架合同金额的大小，不同的工厂等等。

　　二是框架合同的打印格式。框架合同往往需要打印出来，让供应商签字盖章。系统标准的打印格式基本上不能用。这需要根据企业的需求，通过二次开发来实现表单的打印。

　　三是信息的调整。当出现意外情况时，系统会有警告信息，错误信息，无信息等情况。如遇到采购数量大于框架合同时，到底让系统显示的是无消息，警告信息（用户确认后仍然可以保存），错误消息（用户无法保存单据），这需要通过后台进行调整。