Issue:
1. SRM contract with multiple conditions types are assigned to shopping cart
2. The SC is converted to PO using the program BBP_SC_TRANSFER_GROUPED
3. PO is created with duplicated condition types, meanwhile PO cannot be open.
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
- In call stack 27, 2 more conditions are added (Z056, PRXX)
- So in call stack 30, you can see 9 entries in lt_condition, in which has 4 valid entries: PBXX, O1CT, Z056, Z056
This is resulted by FM PRC_PD_ITEM_ADD_COND
Here, the IF is:
This is caused by the below setting in condition type:
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.
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