Skip to Content

Pricing Date

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.

 

In customizing

 

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)

1.JPG

When creating a sales document, proposed pricing date is shown in overview screen.

2.JPG

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)

Considerations:

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.

3.JPG

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

4.JPG

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)

5.JPG

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)

6.JPG

User exit

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).

Manually

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).

7.JPG

 

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

8.JPG

9.JPG

 

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).

10.JPG

 

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.

11.JPG

12.JPG

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.

Regards,

JM

To report this post you need to login first.

29 Comments

You must be Logged on to comment or reply to a post.

  1. ' MoazzaM '

    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.

    Thank$

    (0) 
    1. Typewriter TW

      MoazzaM,

      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.

      (0) 
      1. ' MoazzaM '

        Hi TW

        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.

        Thank$

        (0) 
        1. Typewriter TW

          MoazzaM,

          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?

          Thank you!

          (0) 
          1. ' MoazzaM '

            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.

            Thank$

            (0) 
            1. Typewriter TW

              MoazzaM,

              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)

              (0) 
              1. ' MoazzaM '

                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.

                Thank$

                (0) 
  2. Typewriter TW

    JM,

    Very nice!

    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 –

    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 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?

    Thank you!

    (0) 
    1. joan mas Post author

      Hi TM,

      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)

       

      Regards,

      JM

      (0) 
    1. joan mas Post author

      Thanks Gabriel for your comments.

      If interested, you can find more of my documents in SAP ERP Sales and Distribution and SAP GUI spaces.

      Regards,

      JM

      (0) 

Leave a Reply