SAP-MM知识精解-计划协议

导读

 SAP计划协议是非常常用的一种采购凭证。本篇我们简单介绍一下计划协议相关内容。

 正文

 业务背景

 在实际业务中，企业经常和供应商会保持一种长期供应关系。

 企业不断给供应商下达具体的采购需求，供应商会按照企业提供的需求计划不断供货，企业定期给供应商结算付款。

在这种业务条件下，企业一般不会采取不断下采购订单的方式进行采购，而是会和供应商签订一种长期的供货协议，在SAP中，计划协议就是对这种供货模式的管理。

 计划协议概览

 一般来说，目前较为常用的计划协议分：LP和LPA两种类型。
相较于LP来说，LPA能够产生release document，本篇我们主要介绍LPA的模式。

如上图，以LPA的计划协议为例，计划协议包含了：计划协议（Scheduling Agreement），交货计划（Delivery schedule）及下达需求（Release document）。

 计划协议（Scheduling Agreement）：本质上就是一个长期的采购订单，包含所采购的具体物料，计划数量，有效期，采购对象即供应商，采购组织，采购组等基本信息，并可以参考计划协议进行收货

 交货计划（Delivery schedule）：实际上就是企业自己未来的需求计划，我们会给计划协议维护交货计划，即我们可以为计划协议维护具体未来每天、每周、每月的需求量，这就是交货计划，对于供应商来说就是一个具体的供货计划，也就是交货计划，对于企业自己来说这就是一个需求计划。

 下达需求（Release document）：企业会以交货计划为基础，以某种方式下达采购需求，并将此采购需求传输给供应商。在供应商接到此采购需求后，会以此需求为基础，进行销售计划协议（订单）的创建，生成需求进行排产生产等。

 注意：SAP针对release document的翻译是批准凭证，实际上这个翻译不太准确，容易误解为对凭证的审批等，release在这里的意思是释放下达，，并不是批准，也就是把交货计划正式以需求的方式发送给供应商，而不是批准了某凭证，所以，这里我翻译为下达需求，仅供参考。

 预测交货计划和JIT交货计划

 根据SAP标准功能的设计，在交货计划的基础上，需要生成给供应商一个具体的需求清单，在生成需求清单时，我们有两种方式，如前图，预测交货计划和JIT交货计划。

 JIT交货计划，也就是Just In Time的交货模式，可以针对未来某个期间内，以日为单位，生成需求清单，即确定从某日到某日每天的需求量，发给供应商；

 预测交货计划，也是Forecast delivery schedule，可以针对未来某个期间内，由近到远，以日、周、月汇总需求，并将此需求发给供应商。供应商可以参考日需求进行实际排产，周和月需求进行预估计划等。

批准参数文件的配置

 后台路径

IMG → 物料管理 → 采购 → 计划协议 → 维护无审批凭证的计划协议的审批参数文件

 批准参数文件的设置就包含了对“预测交货计划和JIT交货计划”的不同设置，如下图所示，我们能看出针对JIT和预测交货的不同设置，那这样的设置的实际效果是什么呢？

 假定：某企业的交货计划如上图中交货计划一栏所示：

1号分别有100（蓝色）和50（黄色）两笔需求，
2号与1号的情况一样，
3-7号每天均是100的需求量，
8-10号分别每天50的需求量，
11-14号没有需求，
15号50的需求量，
16-27号总共50的需求量，
28号为50的需求量。

 根据之前后台配置截图的设置：

 “没有合计”

JIT：“没有合计”设置了0-1天，那么如上图所示，1号的两笔需求“100（蓝色）和50（黄色）”，将已两笔需求的形式，产生在下达给供应商的需求清单中；
预测需求：“没有合计”什么也没有设置，那么，1号的两笔需求“100（蓝色）和50（黄色）”，将会合并为作为一天的需求，产生下达给供应商。

 系统测试结果如下：我们能看到JIT所产生的需求中，是两笔100 和 50；而预测所产生的需求是合并的一笔150。

 “每日合计”

 在JIT中，每日合计，设置了2-7天，那么再如前图表格中所示，JIT下2号-7号，交货计划将以每天为单位汇总需求，发给供应商。因此，2号这天，即使再交互计划中，为两笔100和50，也会被合并处理；

在预测中，每日合计，设置了0-7天，那么如前图表格，0-7号的需求将会以每天为单位，将需求发给供应商。

 “每周合计和每月合计”

JIT与预测在配置上的区别就是JIT无法设置，周合计和月合计。因此，这里我们只看预测的设置。

 基于预测的后台配置设置：未来8-14天为周合计，15天往后就是月合计；

 也就是说，如果交货计划包含了数月之后的计划，从产生下达需求之时，系统将未来8-14天的需求，合并为周需求，将15天以后的需求，以月为单位进行需求汇总，以此发送给供应商。

 如下图所示，即是以预测的方式产生的供应商需求了。

 本篇我们介绍了计划协议的概念和核心业务逻辑，除上述内容以外，以下几个点也需要注意：

 1. 计划协议类型：LPA和LP的区别是，LP根据交货计划生成下达需求，传输给供应商。

 2. 计划协议与合同：本质上计划协议是一种长期的采购订单，可以参考计划协议进行收货，而合同不是，合同从系统层面来说无法参考合同进行收货，可以参考合同创建采购订单，合同可以理解为一种系统货源。

 3. 在实际业务应用中，一般企业和自己的核心供应商都有接口，基于交货计划的采购需求生成后，会以接口的形式直接发给供应商，供应商接到需求后，会自动参考此需求，生成销售订单或销售计划协议，最终，供应商以此为基础运行MRP，跑出生产计划和自己的采购需求，再发给自己的供应商等。

 4. 目前，针对2中所描述的接口业务，标准接口解决方案，一般都是采用EDI为接口方式。

 5. 本篇，我们主要介绍了核心业务和逻辑，下一篇，我们再介绍计划协议的创建维护，以及主要的主数据配置和后台配置。