Code adaption for Pricing and Condition Technique

xiayutian_c

已于 2022-02-04 10:21:29 修改

阅读量1.8k

点赞数

分类专栏： S4HANA Conversion 文章标签： abap

于 2020-04-06 23:00:24 首次发布

本文链接：https://blog.csdn.net/xiayutian_c/article/details/105352144

版权

S4HANA Conversion 专栏收录该内容

11 篇文章

订阅专栏

参考note 2220005及其中cookbook

定价的变化

SAPERP的业务文档(如销售订单或购买订单)将定价结果存储在数据库表KONV中，VBAK与KONV通过KNUMV（条件记录号）进行关联（注，只有VBAK里才有KNUMV，VBAP里没有，因为一张单就只对应一个定价过程，所以整张单只需一个KNUMV，与Item无关）。
但到了S4HANA：

引入了一个名为PRCD_ELEMENTS的新数据库表来代替KONV表存储文档条件的功能
数据库层现在被分开了。对它的访问必须通过新提供的API和一个CDS View来实现。
数据库之上的所有层仍然使用经典的KONV字段属性来确保兼容性和稳定性。因此，KONV在所有这些层中作为数据字典中的结构定义继续存在。也就是KONV结构还保留。

可以看出字段是有所变化的，一些字段的长度也发生了变化：

图例：
ECC到S4后，KONV表已经废弃了（表还在，但是空的，是为了引用结构），使用了新表PRCD_ELEMENTS，KONH表中的VAKEY字段没有了

ECC中KONH表中存在VAKEY字段，对应了A表中的Key字段，如下图

那么ECC升级S4后原来根据VAKEY来找KNUMH的逻辑如何实现呢？

这里模拟一条ECC的数据

这里知道VAKEY是‘540000000100010’,
因为VAKEY有可能会对应多个条件表，所以只能先确定条件表，确定了条件表之后，可以根据下面这个函数，或者直接DD03K表里取条件表的主键字段，根据字段长度拆分VAKEY

也就是说前10位是VBELN,后5位是VBELP
这里再去A016表里去反向查询KNUMH

另外一些数据元素也发生了变化
在这里插入图片描述
PRCD_ELEMENTS中没有了字段WEGXX和STUFE。
如果之前是使用字段KOLN3来克服KOLNR的长度限制，KOLN3字段也不用了，因为KOLNR的长度增加了，改成了NUMC3。迁移过程中，KONV-KOLNR3的内容与PRCD_ELEMENTS中扩展的KOLNR字段的内容合并了。
现在的定价结果是包含货币单位的（字段 WAERK），这是因为在PRCD_ELEMENTS中，一些数量(例如条件速率或基值)不再存储为CURR，而是存储为DEC字段，因此以它们的自然形式存储。
例如:100日元(一种没有小数的货币)的条件汇率在KONV中存储为1.00 。100美元(一种有两个小数点的货币)的条件汇率在KONV中存储为100.00。但在PRCD_ELEMENTS中，它们都被存储为100.000000000，因此，PRCD_ELEMENTS与内部格式之间的转换需要了解所有有关货币的知识。

所以，必须替换数据库表KONV的所有直接读取、插入、更新、修改和删除语句。
在S4HANA中，严禁任何对KONV直接插入、更新或删除的操作。必须使用新的定价结果API来访问数据库层！！！尤其是涉及货币，一定要使用新的定价结果API往PRCD_ELEMENTS表写数据。
读操作可以通过API，也可以通过V_KONV去读（不是KONV），后者不推荐使用，因为PRCD_ELEMENTS被创建为透明表，集群表的自动缓冲不再可用。集群时容易出问题。

如上面所说，凭证需要有凭证货币，为了减少迁移期间的停机时间，迁移时没有读入相应的凭证，货币字段统一用 “2”(表示两个小数)填充。好处是一致的转换速度提高，并且能够立即开始处理数据。在**停机时间之后需要尽快执行PRC_MIG_POST_PROCESSIN。**报表日志记录在PRC_MIG_LOG表中。注意：如果有自开发的程序存储类似的凭证数据，也要开发一个类似的报表来填充凭证货币字段。

所以对现有自开发程序的影响：

需要检查数据元素的任何字段扩展是否会对自开发代码产生影响。目前，定价本身并没有利用字段扩展，但这在将来可能会改变。但是，SAP并没有承诺在将来的版本中会提供这样的扩展。
注意：公式和需求编号的长度现在是NUMC7。如果公式中的include name要从数字(例如，值公式999 -> FV64A999)改造，需要注意只取最后三位，否则公式调用将失败。
需要检查接口(如BAPI、IDOC或RFC)是否受到这些更改的影响。考虑为接口引入兼容的结构。
目前，定价将不允许计数器(字段ZAEHK，数据类型NUMC3)的值超过99，以保持接口稳定。在未来可能会改变。

用于外部通信的接口如bapi、IDOCs、RFC等函数保持稳定。接口中的字段保持原来的长度，延长的字段额外被添加到结构的末尾(兼容更改)。所以修改过的字段就会有一对字段，短的（原来的）和长的。
（下面的规则不止适用于定价，所有接口相关的扩展修改都适用）
以下是接口遵循的规则
Outbound Conversion:发

长的字段始终有正确的值
如果短的能放下，短的也有值
如果短的放不下，短的为空

Inbound Conversion:

如果发送方填了长的，就使用长的
如果长的没值短的有值，就用短的
如果两个都有值并且不一致，使用长的

示例：
在这里插入图片描述

需要检查自开发程序是否涉及下列过时字段之一:KOLNR3、WEGXX和STUFE。这些字段将不再存储在定价中，涉及的代码都要被调整。

API

新的定价结果API在Package ‘VF_PRC_DB’中，通过Package interface ‘PRC_DB’来向外暴露API功能。

用于访问定价结果数据的工厂类：工厂类CL_PRC_RESULT_FACTORY用于返回实际API的一个实例。

通过GET_INSTANCE方法返回这个类的一个实例。
使用方法GET_PRC_RESULT来返回定价结果API接口IF_PRC_RESULT

定价结果数据接口： IF_PRC_RESUL
定价结果数据接口(IF_PRC_RESULT)提供了用于读取、写入和删除定价结果数据的API方法。它用于将当前数据持久性与应用程序代码解耦。
原来这些操作是基于KONV表，现在到了S4HANA变成了PRCD_ELEMENTS表

API中提供了以下方法来封装数据库访问:

GET_PRICE_ELEMENT_DB通过匹配给定的一组属性从定价结果中读取一组行。如果请求数据无效，则引发可捕获异常 CX_PRC_RESULT。
GET_PRICE_ELEMENT_DB_BY_KEY通过主键从定价结果中读取特定行。如果请求数据无效，则引发可捕获异常CX_PRC_RESULT。
SAVE_PRICE_ELEMENT_DB将定价结果数据写入数据库表。由于新的数据库表PRCD_ELEMENTS保存document currency，因此需要为每个定价文档提供document currency(技术关键字:KNUMV)。如果没有提供document currency，或者在插入过程中检测到重复的键，则会引发可捕捉的异常CX_PRC_RESULT。注意SAVE方法只是插入操作，如果主键数据已经存在，就需要先删除原来的数据再插入。并没有update功能，并且save方法不会触发数据库提交，因为我们希望定价结果嵌入在业务文档中，业务文档集中控制提交或回滚。
DELETE_PRICE_ELEMENT_DB_BY_KEY:删除一个专用的定价文档或定价文档项item。
DELETE_PRICE_ELEMENT_DB:支持删除多个定价文档(KNUMVs列表)。
DELETE_PRICE_ELEMENTS_DB:删除专用定价结果行列表。执行删除时要一定小心，因为该API不会触发或强制执行任何定价文档的重新计算。它实际上是在数据库记录级操作的。

代码示例

更新KONV表的数据，
下面的示例演示了如何利用新API替换数据库表KONV上的典型更新。例如，包含LV45UF0K的代码从数据库表KONV中删除现有记录，并将新记录或更新后的记录插入数据库表中。
SAP ERP语句：

S4HANA后的语句：
从KONV表取数据
要通过API读取定价结果数据，程序中的现有代码可能需要根据以下示例进行调整(包括LV61AA11)。
SAP ERP语句：

S4HANA后的语句：

或者是：
删除KONV表的数据
除了KONV表的更新(在这种情况下，首先需要删除记录，然后再插入它们)之外，还有一些用例，只需要从数据库表KONV中删除数据。要准备切换到新的数据库表PRCD_ELEMENTS，可以使用API方法触发这些删除操作。下面的报表SDVFKKDL(存档的删除)片段演示了调整后的代码的样子。调整前，将KONV中删除的数据记录如图所示
SAP ERP语句：

S4HANA后的语句：

条件技术的变化

Data Model的变化：
条件表的拼接关键字段VAKEY已经从所有条件的头表中删除了，包括KONH(定价),NACH(output determination),KOND3(Campaign determination),KONDN(Free Goods determination),KONHM(Portfolio determination),J_3GPRLHD (CEM price list determination)和WIND(Document index)。拼接的数据字段VADAT也被删除了。这样做是为了避免由于字段长度扩展而导致这些表的数据迁移，例如，物料编号字段长度从CHAR18扩展到CHAR40。
内部处理中，引入了长度为CHAR255的长数据元素VAKEY_LONG和VADAT_KO_LONG。
新的long VAKEY和VADAT的内容可以在运行时通过服务类CL_COND_VAKEY_SRV的方法来确定。
出于兼容性的原因，将字段VAKEY_LONG (CHAR255)添加到批输入结构中(程序RV14BTCI)。如果外部程序填充或使用该字段，则使用该字段的内容，而不是仍然存在的字段VAKEY的内容。
由于兼容性的原因，字段MATNR_LONG (CHAR40)、UPMAT_LONG (CHAR40)、BOMAT_LONG (CHAR40)和VAKEY_255以及VADAT_255都被添加到COND_A IDOC段中。如果在仍然存在的短字段之外，还填充了长材料编号或长VAKEY/VADAT的这些字段，则长字段的内容具有优先权。
一个access sequence(DTEL KOLNR)中可能的最大访问数已从99增加到999。因此，Pilot SAP Note 1812828中所描述的解决方案(对于发布了此Note的客户)不再是必需的，也不再有效。在迁移过程中，此解决方案中的任何内容都将自动转移到标准表。
附加更改:数据元素QUDIW(访问序列中的特殊值源)已从CHAR20扩展到CHAR50。数据元素SKONDTAB(用于存档SD条件的CHAR128)已被SDKONTAB_LONG (CHAR512)取代。数据元素KOND_DATA(用于一般条件确定)已从CHAR255扩展到CHAR512。

示例代码：
VAKEY和VADAT字段(例如KONH表中的字段)不再可以直接访问。相反，可以根据条件记录号和分配的a表内容重构它们。如果需要在编码中访问这些字段，可以使用服务类CL_COND_VAKEY_SRV的方法。例如，函数模块RV_CONDITION_RECORD:
在这里插入图片描述

S4HANA后：