Pricing date in sales process
Pricing conditions are calculated based on a pricing date. In this document we are going to have a look at the different places where we can influence pricing date proposal and see how system gets and applies it according to certain priorities.
There are two places where we can customize pricing date proposal that will be used in sales documents.
When we define a sales order type, transaction code VOV8, we have field Proposal for pricing date, TVAK-PRDATV, with the following values available:
‘ ‘ Proposal based on today’s date
A Proposal based on requested delivery date (header)
B Proposal based on valid-from date (header)
C Proposal based on contract start (header/item)
When creating a sales document, proposed pricing date is shown in overview screen.
Another place where date proposal can be set is at price condition. When we define a price condition in customizing, we have field
Pricing date, T685A-KPRDT, with the following entries available:
‘ ‘ Standard (KOMK-PRSDT; tax and rebate KOMK-FBUDA)
A Date of services rendered (KOMK-FBUDA)
B Price date (KOMK-PRSDT)
C Billing date (KOMK-FKDAT)
D Creation date (KOMK-ERDAT)
E Order date (KOMK-AUDAT)
When using A. This is the Requested Delivery Date from overview sales document not from line item. If we change this date in the sales document overview, we have to run a new pricing for the document or a new pricing at item level to get the price condition defined with price date proposal A, updated as per new requested delivery date. Also, we have to consider that updating this date will update billing date.
When using C. Similarly to when using A, if we change billing date at header level, we need to run a new pricing for the document or a new pricing at item level to get the price condition defined with price date proposal C, updated as per new billing date.
Date pricing proposal at condition level is applied only to price conditions that have defined a date pricing proposal, rest of price conditions will use pricing date defined at sales document header level as we´ve seen previously.
That means that we can have different pricing dates in our document. Let see an example, in the sales order, where I´ve set pricing date
proposal for price condition PR00 to C (billing date) and left blank pricing proposal in document type (price date).
We´ve maintained prices
When creating sales order, on 24.10, I set manually billing date at header level to 5.11 (to ensure system will pick up 11 EUR price for the example)
We check price conditions after entering material and quantity, for PR00 and discount condition ZZK7 (for ZZK7 condition, no date pricing proposal is set, T685A-KPRDT is blank, that is, price date)
When the requirements can’t be achieved with standard solution explained above, we can use following user exits:
User exit MV45AFZZ, form USEREXIT_MOVE_FIELD_TO_VBKD to update field VBKD-PRSDT (pricing date).
User exit RV60AFZZ, form USEREXIT_PRICING_PREPARE_TKOMK to update field TKOMK-PRSDT (pricing date).
We can set manually pricing date at different documents and processes.
In sales documents we can set manually billing date at header level (applicable to the whole document) and at item level (applicable to a line item).
When working with deliveries, at the time of posting goods issue for a delivery (PGI), we can set a PGI date that will then be taken as billing date when billing. For example with transaction VL06G, when clicking on Post Goods Issue button, a pop up is displayed
This billing date will be used as pricing date.
For this, we need also to update pricing type (set to B or C), in copy control, at item level, in transaction VTFL. When billing, a new pricing will be run.
We can also set a pricing date when billing, in transaction VF01 or VF04 (tab Default data), field pricing date. As a result, system will run al new pricing for the documents that will be billed using this pricing date (in transaction VTFL, copy control, at item level, pricing type should be set to B or C).
Cooking it all together
Let’s see what happens when we put all together in different combinations and the results obtained.
This table shows from a sales document, what pricing dates are taken when billing. See below how to read it.
Let’s see how to read above table for example in row number 6:
We have condition pricing date proposal in PR00 condition set as A (date of service rendered or requested delivery date), sales order type used has been defined in customizing with today’s pricing date proposal (left blank). We create our sales order (VA01) on 25.10 and system calculates required delivery date on 5.11. As a result, PR00 pricing date is 5.11 and ZZF7 (without pricing date proposal) condition is 25.10.
While Posting goods issue with VL06G, we set manually actual PGI date to 27.10.
We run VF04 and set as default billing date 1.11 and when we billing, system runs a new pricing (defined in copy control, Delivery to
Invoice for line item TAN value B) getting the following results: PR00 billing date is 27.10 (system checks in custo actual value in field price date proposal for conditions, for PR00, value A, which is Actual PGI date) and ZZF7 billing date is 1.11 (ZZF7 condition price date proposal is blank).
In the example in row number 7, price date condition for PR00 is left blank. When running a new pricing in billing, system then picks as pricing date that set as default in VF04 (1.11).
Examples from row number 17 to 24 post goods issue is done by VL03N instead of VL06G (here documents created on 26.10 instead of 25.10).
In examples from row number 28 to 35, there are no deliveries involved, billing sales documents directly.
In short, when creating a sales document, system after getting pricing date proposal from sales order type, will proceed to get pricing dates for pricing conditions on the document by this priority:
1-Pricing date proposal for price condition defined in customizing
2-Pricing date for sales order line item
3-Pricing date for sales order header
When creating a billing document:
If price redetermination is set in copy control at item level (values B, C):
1-Pricing date proposal for price condition defined in customizing
2-Pricing date set in VF04-VF01
3-Pricing date from actual PGI
4-Pricing date from sales order
If no price redetermination is set in copy control at item level, Prices come from sales document.
it is very helpful to understand the pricing date usage.
you made the pricing date Control simple
Thanks for sharing.
Thanks for sharing helpful document.Keep sharing 🙂
Good document and nicely presetn. I would like to add one thing that from controlling point of view I think pricing date field must be in display mode in sale order so that no user can change it to any previous date and make the transaction on less low price. In most of the companies I have seen this field in display in sale order. It depends on client's requirement but it is good if you make this grey after discussing with clients.
Thanks for sharing your observation based on real-time experiences!
1. Is pricing date in uneditable mode in VF01 / VF04 also? So that user can not change it during the billing process.
2. How often do you see that the users have the authorization and need to change the prices, discounts etc. in an order or a billing, in Tab Conditions?
Please give some business examples.
We never use VF04. We create invoice with VF01 always and I didn't face any issue with pricing date in invoice or may be user's have never tried to play with that 😉
In my past experience user's were not allowed to change any price or discount etc except one manual discount and for that we also has restrictions within min max limit.
Pricing date should not be changed by end users. This can leave a blank area and users can change it to any older price date.
Users gave manual discounts, were these condition types marked as manual in the pricing procedure(s)?
When a condition type is marked as manual in the pricing procedure, then in sales order, Tab Conditions, the condition type does not show. The user has to give the manual condition type and its value.
Did it happen that the users forgot to give manual discounts?
How did users make sure to give manual discounts?
Yes it was a manual condition in V/08. User entered condition and its value manually and they never forgot it but if they did then they had to post credit note w.r.t that invoice to adjust discounts.
This is more an "operational" question - how did they "remind" themselves that for a particular order type (particular customer....particular material...) a manual condition type has to be inputted in the sales order?
(As you have been to different client sites)
We had sales policy for every month. On start of every month sales team prepared a sales policy in which they declare discounts on different products based on different techniques. For instance if they declare if a customer buys 10 materials of TV and fulfill all requirements (advance cash, within credit limit, any bundle or pairing goods etc) then he will get some discount on invoice. User will then check all the requirements and enter manual condition in discount.
They also had order to order deals with customers. If price of a material is 100 and minimum price is 90 then sales manager have margin of 10 rupees and he agreed to invoice this material to some customer on 90 to other on 95 and so on. So this discount was also entered in order manually.
They were following manual checks instead of automatic credit checks because of their requirements. For advance cash either cash posting has been already done or at least a bank draft is attached in order not. This is just one example of their requirement which we were not able to control through standard credit check.
Thanks for sharing useful document with good presentation.
I enjoyed reading this document. Like MozzaM commented the document is well structured and nicely presented, especially - "Cooking it all together" and "In short" 🙂
One question -
In the billing document, condition type ZZF7 would have what pricing date?
For ZZF7, the billing date is 1-Nov but why would this be the pricing date too?
thanks for your comments.
In the billing document, condition ZZF7 would have pricing date 1.11 as a result of running a new pricing according to copy control (B), having blank in pricing condition in custo (pricing date) and setting this pricing date in VF04 (1.11)
It is nice for me.
Good document Joan 🙂
Thanks Karuna for your comments.
Very nice article!! Was very helpful!!
Thanks Gabriel for your comments.
If interested, you can find more of my documents in SAP ERP Sales and Distribution and SAP GUI spaces.
Thanks for sharing!
Thanks for sharing. This is a very helpful document.
Thanks Jewel for your comments
Thanks Jaon , its really very helpful.