zoukankan      html  css  js  c++  java
  • Duplicated Conditions Types

    Issue:

    1. SRM contract with multiple conditions types are assigned to shopping cart

    image

    image

    image

    2. The SC is converted to PO using the program BBP_SC_TRANSFER_GROUPED

    image

    3. PO is created with duplicated condition types, meanwhile PO cannot be open.

    image

    image

    This is happening only when a contract assigned to a SC is converted to a PO. When a contract is directly assigned to a PO, the conditions are not duplicated and system is fine.

    Analysis:

    Call stack

    30 FORM           GET_ITEM_CONDITIONS                 SAPLPRC_INT                LPRC_INTF31
    29 FUNCTION     PRC_INT_ITEM_ADD_COND_MULTI    SAPLPRC_INT                LPRC_INTU50
    28 FUNCTION     PRC_PD_ITEM_ADD_COND               SAPLPRC_PRICING_API    LPRC_PRICING_APIU16
    27 FORM           PRC_MAINTAIN_SINGLE                   SAPLBBP_PDPRC            LBBP_PDPRCF02
    26 FUNCTION     BBP_PDPRC_UPDATE                       SAPLBBP_PDPRC            LBBP_PDPRCU01
    25 FORM           PRC_UPDATE_CALL                         SAPLBBP_PDIGP             LBBP_PDIGPF3K
    24 FORM           PRICE_AND_VALUE_DETERMINE         SAPLBBP_PDIGP             LBBP_PDIGPF3J

    - In call stack 24, the initial condition in IT_PRIDOC[] has 7 entries including two has valid values: O1CT and Z056

    image

    - In call stack 27, 2 more conditions are added (Z056, PRXX)

    image

    - So in call stack 30, you can see 9 entries in lt_condition, in which has 4 valid entries: PBXX, O1CT, Z056, Z056

    image

    This is resulted by FM PRC_PD_ITEM_ADD_COND

    image

    Here, the IF is:

    image

    This is caused by the below setting in condition type:

    image 

    image

    Here are the difference between “no restrictions” and “the manual condition has priority”

    Regarding the condition FRA1, we can see that the IPC Pricing Engine is returning two conditions, but only one is active. The other one is inactive 'M' (INACTIVE_DUE_TO_MANUAL_ENTRY). This is due to the customizing of the condition type. That means that the automatic found condition is deactivated by the manual one.

    image

    But the condition ZOA1 has no such restrictions as you can see below. The field "Manual entries" has the value "No restrictions". That means you can have in the Purchase Order an automatic found condition ZOA1 as well as manual condition ZOA1.

    718482 2013

    212345 2011

  • 相关阅读:
    面试题目——《CC150》链表
    TCP/IP——链路层
    TCP/IP——基本知识
    面试题目——《CC150》数组与字符串
    Java递归算法——三角数字(消除递归)
    Java排序算法——拓扑排序
    Java排序算法——希尔排序
    Python学习笔记——条件和循环
    Python学习笔记——集合类型
    英文写作——冠词的使用(Use 0f Articles)
  • 原文地址:https://www.cnblogs.com/lazymango/p/3263813.html
Copyright © 2011-2022 走看看