笔者在 SAP 成都研究院工作多年，从事过多款 SAP 产品的标准开发工作。这些产品里无一例外地都存在着订单(Order) 这种数据模型。
我们提供的服务有：成都网站设计、网站建设、外贸网站建设、微信公众号开发、网站优化、网站认证、龙泉驿ssl等。为数千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的龙泉驿网站制作公司
订单模型从数据结构上来说是一棵树，根节点就是我们通常俗称的订单抬头(Header Level) 结构，主要包含订单 ID，创建时间，创建者，订单描述信息，订单涉及到的业务合作伙伴(Business Partner)等字段。
根节点通过所谓的 Association 和 Composition，关联到其他叶节点，最典型的叶节点就是订单行项目(Line Item) 结构。行项目包含订单设计到的产品明细，比如产品 ID，产品数量，产品单价，计税方式，定价信息等等。订单根节点和订单行项目的对应关系为 1:N .
SAP 产品里的订单处理，无论是 On-Premises 解决方案还是云产品，笔者认为归根到底可以概括成四个字：订单编排。这个概念包含两个层次的内容：
比如 SAP CRM 里经典的 User Status(用户自定义状态)和 System Status(SAP 标准状态)的设计，通过引入 Business Transaction 将两者关联起来，完美地实现了用户自定义订单状态被 SAP 标准程序的感知。
下图左边的 Open, In process， Released 和 Completed 就是用户自定义订单状态，SAP 允许客户给每个状态分配一个 Low 和 High 的值，通过这种方式巧妙地提供了一种用非图形化方式进行状态跳转的定义。
比如 In process 状态的 Low 为 20，意味着 In process 状态不可能重新回到 Open 状态，因为 Open 状态的 ID 10 小于 In process 状态的 Low 字段定义的 20——一个状态能跳转到的目标状态的 ID，必须在由该字段的 Low 和 High 定义的区间内。
用户状态通过 Business Transaction 映射到的 SAP 标准状态，在我截图的系统上一共有 906 个，这既体现了 SAP 软件的高度复杂性，也不得不让人佩服 SAP CRM 当初的设计者考虑问题的周全。
除了复杂的状态处理和跳转外，SAP 订单编排的复杂度主要体现在以下方面：
因此 SAP 系统对订单编排增强的支持就非常必要。
当然，不同的 SAP 产品，对订单增强的实现方式也各不相同。
在 SAP CRM 里，虽然 SAP 没有明确提出 Business Object 这个名词，但订单应用基于的模型实际上仍然是由不同的节点组成：
每个节点对应一些更底层的模型节点，上面可以注册各种事件处理函数。下图是 Service Request 这个 Business Object 的抬头节点的事件处理函数：
每个节点可以分配一个分配一个执行函数，当然，严谨的德国人在最简单的观察-发布者模式上又添加了几个维度的设置。
下图第一列红色的 Execution Time，表示这些分配的函数到底是事件触发后立即执行，还是延迟到订单抬头或者行项目的通用例程执行完后再执行(往往用于实现批量操作，或者待执行函数同通用例程存在依赖关系，或者出于性能考虑）。
第二列的 Priority，即函数执行优先级，如果若干函数除了优先级外其他维度维护的属性完全一致，则按优先级从高到低依次执行。
第三列 Event，就是观察者-发布者模式里的事件了，下面是 SAP CRM 订单框架一些标准的事件：
最后一列就是事件监听函数。
笔者倾向于把 CRM 订单处理系统的运作方式理解成类似下图这种复杂的水管传输系统，订单业务流程依次被注册在不同事件上的监听函数执行，就像这一根根大小粗细长短各异的水管一样。
如果客户对其中某个业务步骤需要做增强(需要替换某根水管), 只需要用一个自己实现的函数去替换 SAP 标准函数(自己另外找一根水管替换掉现在正在工作的水管），能替换的前提是自己实现的函数的接口同被替换函数完全一致(自己另外找的水管和以前的水管两端接口的规格完全一致）。
而 SAP Cloud for Customer 里的订单模型，其 Business Object 在目前最新的 1811 版本里仍然是由 ESF2 框架实现，只是后台对 Partners 不可见，但大家可以类比 SAP On-Premises 世界里的 BOPF 框架，两个框架的实现原理类似。
在 Cloud 的世界里，想对订单处理流程做增强，同之前介绍的 SAP CRM 相比，相对来说受的限制要多一些。
在 Partner 做增强的 Cloud Application Studio 里，所有能做增强的点以 Hook 的方式显示如下:
Partners 可以在这些 Hook 里进行业务功能增强。有些 Hook 可能存在某些读写限制，比如 AfterLoading 这个 Hook，会在 SAP BO 的标准加载逻辑执行完毕后被调用，在这个 Hook 的实现里，SAP 不允许任何对 BO 节点标准字段的写操作，以避免 Partners 的增强对 SAP 标准流程可能带来的影响。
有的顾问朋友可能会说，这些 Hook 不就是 SAP Netweaver 里传统的 Business AddIn(BAdI) 么？没错，概念上可以这么理解，需要提醒的就是，这些 Hook 创建之后，在 ABA P后台并不是以 BAdI Implementation 的方式存储，而是以 ESF2 Determination 的方式存储，类似下图这种 BOPF 里的Determination：
本文首先给出了 SAP 产品里订单模型的统一实现思路，接着选择 SAP CRM 和 SAP Cloud for Customer 这两款具有代表性的客户关系管理解决方案，着重介绍了其订单编排逻辑的设计原理与实现细节。
方法/步骤
1/8 分步阅读
在主界面抬头指令框内输入事务代码CO08，输完回车，进入面向销售订单创建生产订单的界面，依次输入销售订单号、物料号、生产计划工厂和订单类型等字段内容；
2/8
进入如下抬头界面，依次输入生产订单开始、结束日期并确认数量；
3/8
输完点击保存，左下角出现提示信息框，生成生产订单号20240000098；
4/8
事务代码CO02，进入生产订单修改界面，输入生产订单号，回车；
5/8
进入汇总订单结构界面，准备下达订单；
6/8
此时订单状态为“CRTD，创建状态”，点击“读汇总订单”按钮图标，检查无误如下图；
7/8
点击执行，则下达订单，结果如下所示，订单状态为“REL，下达状态”，随后点击保存；
8/8
读取汇总订单，点击菜单栏“功能-删除标记-设置”，结果如下图所示，订单状态变为“DLFL”，确认后点击保存，完成删除标记操作；
sap计划订单生成方法是：
1、MRP自动产生。
2、手工创建MD11—计划订单。
3、修改计划订单-MD12。
4、显示计划订单—MD13(个别)，MD16（集中）按照条件显示。SAP是全球企业管理软件与解决方案的技术领袖，同时也是市场领导者。30余年，通过其应用软件、服务与支持，SAP持续不断向全球各行业企业提供全面的企业级管理软件解决方案。
