Hi,
At the moment we have 10 different ordertypes which we use in CRM. For all these, we want the pricing to be redetermined when the order reaches ECC. To achieve this the current setting in SMOFPARSFA is:
Key: R3A_SALES
Paramname: PRICINGTYPE
Paramvalue: B
Now, a new requirement is that for 2 of these ordertypes we would like to copy the prices we have maintained in CRM (we are using a Request for Quotation scenario where we give discounts within the orders).
To achieve a copy of priceconditions from CRM to ECC we changed the SMOFPARSFA values to:
Key: R3A_SALES
Paramname: PRICINGTYPE
Paramvalue: G
However, this change of course is generic affecting all 10 ordertypes. So, we then tested to include the ordertype as paramname2 (similar to
how ordertype can be maintained as Paramnam2 for parameter INT_CHANGE_ORDER)
Eg
Key: R3A_SALES
Paramname: PRICINGTYPE
Paramnam2: ZTP
Paramvalue: G
Key:
R3A_SALES
Paramname: PRICINGTYPE
Paramnam2: ZOR
Paramvalue: B
With the purpose to copy pricing from CRM to ECC for ZTP order type, but allow re-pricing in ECC for ZOR order type.
When testing this, I first thought that the setup above worked, because I could see that when switching the value for ZTP from G to B the determination worked accordingly. Either copy or redetermination. However, after a few happy minutes I did a regressiontest on the ZOR ordertype, and I then realized that the ordertype paramname2 value is not taken into consideration. The only reason why my test on ZTP worked, was because it was "higher" up in the database table, and the system stopped "reading" the entries after the first hit.
So, my question is. How can we achieve to have different price re-determination/copy logic based upon order type between CRM and ECC. It feels extremely strange(!), if the SMOFPARSFA setting is generic for all ordertypes, and not possible to control on more detailed level...
Please advice!
BR / Alex