Pricing date issue

[Former Member]

Hello All,

We have an issue with the Line item pricing date.

In our project we are using the supersession functionality; we have one sales order with header pricing date ex: 25.12.2008 with some line items, for line item 10 we have created superesession material on 01.01.2009 with other material and maintained the pricing condition records validity date same as 01.01.2009.

We maintained in a way that if the material is not available and superseded material is available one job will run and creates the new line item with superseded material and copies the all information from the old line item. Here the problem is it copied the old material pricing date as 25.12.2008 due to this the new line item price is not calculated because the condition record is available from 01.01.2009 and it is disable mode.

Can any one give an idea how to solve the above issue.

Thanks and Regards

Srinivas Kapuganti

[Former Member]

Pricing Date field is VBKD - PRSDT both @ Header and @ Line Item. That is the reason the line item pricing date is copied as 25.12....in your scenario. You need to update the program to read the pricing date from line and pass the same to the new line rather copying VBKD-PRSDT.

Thanks

Sai

[Former Member]

Hi Srinivas,

just a question: the pricelist of the new and the old material are the same? If yes, maybe you can use the "Pricing reference material" field (VBAP-PMATN).. This could be one of the possibile solution.

For instance, in the standard access sequence PR00 (trx V/07), the field used to determine prices in the pricing communication structure is KOMP-PMATN (filled from VBAP data...); so when you create the new item you can fill the filed "Pricing ref material" with the superseeded material (i.e. the old one).

This solution let you not to change the pricing date in order to avoid possible "side effects"... For instance other pricing conditions (i.e. discounts and so on) that are valid on 25.12.2008 and not on 01.01.2009...

Hope this help.

Kind regards - Massimo

[Former Member]

Hi Srinivas

the answer lies in your question iteslf. The job in which you are creating the line item you can modify the code to get the new pricing date.

Regards

Yatin Thakkar

[Former Member]

Hi All,

The job which is running not in R/3 whereas in APO. The job Name is /SAPAPO/BOP which is creating new line item and copying the old line item information.

Please let me know if you need any further clarifications.

Thanks and Regards

Srinivas Kapuganti

[Former Member]

Hi Srinivas,

reading the answer above, there are 2 ways to solve your problem:

1) Modify the logic that determines the pricing date

2) Use the pricing reference material field (i.e. workaround)

Unfortunately in the landscape currenly i'm working, I haven't installed APO... So I cannot make any tests in a similar landscape.. however I can try to suggest to you something...

Concerning the "idea" N. 2 you have:

A) To check (from a "business point of view") if superseeded material and the new material have the same price.. I think so.. In the past I've worked as consultant in an A&D company and we have implemented supersession.. Usually, from a "commercial point of view" no impact on pricing must be "charged" to the customer because "supersession". So, usually, the superseeded material and the new one has the same pricelist...

B) From a "technical" point of view, try change manually the sales order updated by APO BOP and fill (manually) the field VBAP-PAMTN (item detail, tabstrip "Sales B") and, please, check if SAP determines the correct price condition record.

C) If test in point B is "ok".. I think that when BOP try to change the sales order, the userexit move_field_to_vbap will be called (include MV45AFZZ).. If you are able to understand to which "old" SO item is referred the new one, you can use this exit to fill VBAP-PMATN field of the new item with the superseeded material code (the old one)....

Advantage:

1) You don't have to change the program called by RFC from APO (maybe it requires an out of standard solution? I don't know..). You have "only" to implement an userexit..

2) SD pricing date will be, also for the new item, the 25.12.2008; but, in this case, SD will be able to find (via PMATN field) the pricing condition record linked to the superseeded material. This solution is Ok if hypotesis in point A) is correct. Otherwise it make no sense.

Sorry for quite long answer. Hope this help.

Have a nice day - Massimo