SD（销售与分销），积极支援销售和分销活动，具有出色的定价、订单快速处理、按时交货，交互式多层次可变配置功能，并直接与盈利分析和生产计划模组连接。
创新互联建站主营永吉网站建设的网络公司,主营网站建设方案,成都app软件开发公司,永吉h5成都小程序开发搭建,永吉网站营销推广欢迎永吉等地区企业咨询
MM（物料管理），以工作流程为导向的处理功能对所有采购处理最佳化，可自动评估供应商，透过精确的库存和仓储管理降低采购和仓储成本，并与发票核查相整合。
PP（生产计划），提供各种制造类型的全面处理：从重覆性生产、订制生产、订装生产，加工制造、批量及订存生产直至过程生产，具有扩展MPRⅡ的功能。
FI（财务会计），集中公司有关会计的所有资料，提供完整的文献和全面的资讯，同时作为企业实行控制和规划的最新基础。
CO（管理会计），是公司管理系统中规划与控制工具的完整体系，具有统一的报表系统，协调公司内部处理业务的内容和过程。
扩展资料
SAP系统的优点
1、SAP是全球所有ERP产品中对企业构架和财务控制考虑得最细致的系统，也是整体控制逻辑和整体系统结构是最严谨的系统，可以让企业引进先进的管理理念；
2、对产品在各种行业的适用性考虑得最多的系统，既应用的行业最广；
3、SAP系统是整体稳定性最好的系统；
4、 应用最广的产品。它集成性好，财务、物资、项目、设备、人力资源等等功能都具备；
5、可以进行事前很好的控制，国内软件一般都是事后控制。
6、SAP有针对不同行业的解决方案，也有适合中小型企业的产品，如SAP Business One，SAP All-in-One，和云产品SAP Business ByDesign。
sap各模块的英文缩写及相应的中文说明：
SAP ERP核心模块包括：
FI：财务会计
CO：管理会计
MM：物料管理（含采购、库存和物料主数据功能）
SD：销售管理
PP：生产管理
PM：设备管理
QM：质量管理
HR：人力资源管理
SAP
是上层访问下层所提供服务的点。在计算机体系结构中，下层是为相邻上层提供服务的，而下层对它的所有上层都是透明的。
SAP是临层实体（“实体”也就是对应层的逻辑功能）间实现相互通讯的逻辑接口，位于两层边界处。从物理层开始，每一层都向上层提供服务访问点（应用层除外），每一层都有SAP，但不同层的SAP内容和表示形式是不一样的。
以上内容参考：百度百科-SAP
笔者在 SAP 成都研究院工作多年，从事过多款 SAP 产品的标准开发工作。这些产品里无一例外地都存在着订单(Order) 这种数据模型。
订单模型从数据结构上来说是一棵树，根节点就是我们通常俗称的订单抬头(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 这两款具有代表性的客户关系管理解决方案，着重介绍了其订单编排逻辑的设计原理与实现细节。
