APO 中的 ABAP
APO将在2025年停止支持。不过APO被拆成了两部分，DP和SNP组合成一个新产品IBP；GATP和PP/DS集成到了S4中。
1、APO的一些基本术语
CIF
Core
InterFace，本质是RFC，用来交互数据。APO和ERP无缝集成就是通过CIF实现的。ERP的主数据、业务数据有任何变动，会即时反映到APO。在S4中，部分APO的功能放弃了CIF，但部分功能依旧依靠CIF，自己和自己集成。你找一套S4系统，在SMOD里模糊查询一下APOCF*，会发现很多CIF的增强出口。一般情况下，APO的实施中，CIF需要大量的增强。这些增强的目的，简单来说，是把ERP的数据，处理成APO需要的数据。APO对数据的要求非常严格。
LiveCache
内存中的一块特定区域，用来存储APO中一些高频率使用的数据，比如物料主数据，(APO的)订单数据等等。可以粗暴理解为一团有序的memory
ID。S4中同样有LiveCache，SE37模糊搜一下/SAPAPO/OM*，找的的函数就是用来处理LiveCache的，包括读和写。LiveCache相关的事务码也是/SAPAPO/OM开头。
CTM
Capable-to-
Match。匹配能力。据说是C++写的，黑盒引擎。SNP和PPDS可以用CTM做供需匹配。举个极端简单的例子，有若干需求R1,R2,R3...Rx，有若干供给，S1,S2,S3...Sy，每个需求和供给都有各种属性，物料，数量，需求日期，到货日期，生产周期......CTM依据这些属性，对需求和供给进行匹配。据说CTM的逻辑并不复杂，完全可以用ABAP实现。不过这不是我们关注的话题。CTM涉及的开发一般是在CTM日志的基础上做一些报表，还有就是做增强，对传入CTM的数据进行一些清洗。
处理链
就是BW里的RSPC。由于BW顾问都消失了，可能这个事务码越发无人问津。用来处理大量的需要同时并行，以及有严格串行逻辑的程序。处理链是一种很不错的思路。即便在S4中也有用武之地。某些自开发的复杂功能，比如还原成本，利润预测之类，甚至常见的复杂公司内交易，都可以使用处理链。
计划版本
APO在运行标准功能时需要分配版本。比如常见的运行SNP优化器(事务码/sapapo/snpop)。除了默认的最完整的版本000，你也可以定义自己的版本。每个版本可以有不同的工厂、物料、供应商等。你可以让每个版本安排不同的分工，比如版本A1负责采购，版本A2负责库存，版本B1负责总装，版本B2负责半成品，版本Z1自己做研究等等。计划版本分内外码。
2、DP模块
Demand
Planning。需求计划。就是预测需求。基于BW的infocube。DP允许多种数据来源，然后执行预测、处理预测结果、发布预测结果到SNP。DP中有多种预测模型(好像是30种)，如一阶变量预测、加权移动平均、季节性模型、中位数算法......不用担心这些名词。如果我们做过预测类的项目，就会发现预测有个悖论：如果预测结果质量很高，则使用任何工具都能做出高质量的预测；如果预测结果时灵时不灵，则使用任何工具都是一样的结果。所以在实际的APO项目中，真正的预测可能是在APO之外完成的，APO只负责处理预测数据。举个简单的例子，销售部门根据CRM或者其他销售相关的系统中的合同、意向等，结合历史数据，给出一份产品的销售预测，生产部门把这份预测展成零部件，根据自己的生产能力、已有库存、供应商供货能力等等各种参数，对这份预测进行调整，产生更详细的预测数据，最后相关的人员审核一下，然后发布成SNP需要的需求。这个例子中，每一步都需要大量的开发工作。注意，DP的开发一般要用到动态内表，涉及大量的行转列、列转行。因为预测是动态的，可能每周甚至每天就要更新一次预测，每次预测的需求日期自然也是不一样的。
另外，通常使用APO的客户，一般是规模较大的集团公司，涉及多家工厂，无数的供应商。所以APO的程序，面对的数据是以百万为单位的，千万级是日常，上亿也是有的。所以APO的程序对优化的要求非常高，高到什么程度呢，简单说，Ctrl+F1检查代码，不能有黄色警告。
暂时讲这些。下次讲一下SNP。
