Code adaption for Pricing and Condition Technique

参考note 2220005及其中cookbook

定价的变化

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

  • 引入了一个名为PRCD_ELEMENTS的新数据库表来代替KONV表存储文档条件的功能
  • 数据库层现在被分开了。对它的访问必须通过新提供的API和一个CDS View来实现
  • 数据库之上的所有层仍然使用经典的KONV字段属性来确保兼容性和稳定性。因此,KONV在所有这些层中作为数据字典中的结构定义继续存在。也就是KONV结构还保留。
    Code adaption for Pricing and Condition Technique
    可以看出字段是有所变化的,一些字段的长度也发生了变化:
    Code adaption for Pricing and Condition Technique
    另外一些数据元素也发生了变化
    Code adaption for Pricing and Condition Technique
    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去读,后者不推荐使用,因为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:发

  1. 长的字段始终有正确的值
  2. 如果短的能放下,短的也有值
  3. 如果短的放不下,短的为空

Inbound Conversion:

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

示例:
Code adaption for Pricing and Condition Technique

  • 需要检查自开发程序是否涉及下列过时字段之一: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不会触发或强制执行任何定价文档的重新计算。它实际上是在数据库记录级操作的

代码示例

  1. 更新KONV表的数据,
    下面的示例演示了如何利用新API替换数据库表KONV上的典型更新。例如,包含LV45UF0K的代码从数据库表KONV中删除现有记录,并将新记录或更新后的记录插入数据库表中。
    SAP ERP语句:
    Code adaption for Pricing and Condition Technique
    S4HANA后的语句:
    Code adaption for Pricing and Condition Technique
    Code adaption for Pricing and Condition Technique

  2. 从KONV表取数据
    要通过API读取定价结果数据,程序中的现有代码可能需要根据以下示例进行调整(包括LV61AA11)。
    SAP ERP语句:
    Code adaption for Pricing and Condition Technique
    S4HANA后的语句:
    Code adaption for Pricing and Condition Technique
    或者是:
    Code adaption for Pricing and Condition Technique

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

条件技术的变化

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_LONGVADAT_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:
Code adaption for Pricing and Condition Technique
Code adaption for Pricing and Condition Technique
S4HANA后:
Code adaption for Pricing and Condition Technique
Code adaption for Pricing and Condition Technique