Retro Billing - Normal Sales Process

[Former Member]

Hi,

We intend to go for Retro Billing and we dont have Contract processing or Scheduling Agreements in our system. That is, we use the standard sales process of sales order - Delivery - Invoice.

Please let us know whether we can go for retro billing in a normal sales process.

We understand from the available information that Retro billing is used mainly in Scheduling Agreements.

If retro billing can be used in normal sales process, please let us know the procedure (Configuration, Process Flow, Master Data etc...) for perfroming the functionality in the system.

Please Help !

Regards

[Lakshmipathi · Accepted solution]

available information that Retro billing is used mainly in Scheduling Agreements.

Certainly not so !!!!!! You can also go with normal sale order process. For more information on this, check this link else google it; you will get lot of information.

[Processing for Self-Billing or Retro-Billing|http://help.sap.com/saphelp_crm60/helpdata/en/25/2b676303e311d4968000a0c943a141/content.htm]

Normally, we generate retro billing in case the customer give price increase or decrease. So it is not necessary the preceding document should be scheduling agreement.

thanks

G. Lakshmipathi

[Former Member · Accepted solution]

Dear Sir,

I tried all possible ways according to your thread, but the system gives the same response.

1. Copy control is maintained

2. VK12- changed price from 200 to 150/- and saved

3. Now i go to VFRB and put inputs as suggested.

4. i get result as

Billing document for reference

Please guide its a standard order where i am following the process.

[Former Member · Accepted solution]

Sear Sir,

Finally got the solution.It was restricting due to condition record maintained in customer/Material access sequence and company mainatins in acutomer /material /PO access sequence.

This can be a cause too for other users getting same issue

Regards

Abhishek Das

[Former Member]

Hello,

We use Retro Billing to Debit or Credit the customer based on price increase or descrease of your materials. System perform the Retro Billing VFRB based on the pricing date of the Billing document. If the Pricing date falls within the date in which the price of the materials was changed the system based on Retro Billing Order Reasons calculates the difference and poplates the difference in the amount accordingly. You can create a Credit Memo request or directly a Credit Memo but the document type you take should be different from the normal credit memo and do not forget to update the copy control for the same.

Let me know if this helps.

Regards,

Sumit

[Former Member]

Hi Sumit,

Thanks for the information.

Please let us know the configuration, process steps involved in performing this functionality of Retro Billing.

Also, the copy control has to be maintained between Credit memo request and credit memo ?

Please Help !

Regards

[Lakshmipathi]

There is no separate configuration involved to process retro but for copy control for billing to billing. Only thing is that you should take care of the following:-

a) Take the list of parent billing documents date for which, you would like to generate retro billing and ensure that they are not cancelled or reversed

b) Go to VK11, key in the pricing condition type and maintain the difference in price with the same validity period of the parent billing document

c) Execute VFRB by maintaining all the required fields like Payer, Material, Currency etc., It is always recommended to run this per material instead per customer

d) Once executed, system will show the retro debit / credit note in the same screen. Make a note of the document reference and check for value in condition tab

e) Finally maintain the original selling rate in VK11

thanks

G. Lakshmipathi

[Former Member]

Hi Laksmipathi,

Thanks for the update.

I have gone through the entire document available in help.sap.com website for retro billing.

We need to create 2 item ctaegories for retro billing (G2WT & L2WT) and if required - doc types - G2WT & L2WT. Is it ?

Also, please make me understand the Value only and the Value / Quantity Postings.

I have further clarification on the same as follows:

1. Is it necessary to have EDI in place for Retro billing.

2. Retro billing and Self billing - are they one and the same ?

As per your last update i have following clarifications:

1. Can you please explain the points - b & e in detail.

2. Can you explain the steps (a - e) with any example.

[Lakshmipathi]

1. Can you please explain the points - b & e in detail.

2. Can you explain the steps (a - e) with any example.

Below is a small example, as required by you.

You had despatched a material AB @ INR 500.00 per piece during May 2010. The total quantity despatched till May'10 end was 100 nos with various invoice references.

Now after the marketing follow up, the customer has given a price increase @ INR 60.00 per piece for those 100 nos. This means, the actual selling rate is INR 560.00 per peice. So here in order to generate a retro billing for the difference in rate of INR 60.00, you have to follow the step I have explained in (b), which means, in VK11, you will have to maintain only INR 60.00 with the same validity period of those parent billing documents.

Now as I explained in (e), execute VFRB by maintaining all the required fields like Payer code, Sales Organisation, Billing date from and to (should be of parent billing document date), Currency and without fail, also maintain the material code and execute.

Once you execute, you can see retro billing documents below to your parent billing document. Make a note of those retro billing document references and check in VF02 individually in condition tab whether the difference in rate alone is flowing with the required output tax for that equivalent quantity raised as I mentioned in (d)

Once you feel that everything is okay and retro debit note is generated for 100 nos, now you have to once again maintain the original selling price, ie.INR 500.00 as I mentioned above in (e). If the customer has given an open ended price increase, then the VK11 rate should be INR 560.00

Now this is clear to you.

thanks

G. Lakshmipathi

[Former Member]

Hi Lakshmipathi,

Thanks a lot for your quick responses.

On what Logic the prices are to be maintained two times. Is that the standard process flow for retro billing.

Do the document types / Item categories need to be maintained for retro billing exclusively.

Also, Is it necessary to have EDI in place for Retro billing.

What is Value only and the Value / Quantity Postings.

Thanks again for your time.

Regards

[Former Member]

On what Logic the prices are to be maintained two times. Is that the standard process flow for retro billing.

Do the document types / Item categories need to be maintained for retro billing exclusively.

Also, Is it necessary to have EDI in place for Retro billing.

What is Value only and the Value / Quantity Postings.

Hello,

If I understood your questions properly below is my reply:

As and when price increases the same is reflected in the Price Condition records for the condition type say PR00.

Here as explained by Laxmi you change the prices to 560 from 500 and the system picks the difference in the Debit/Credit Memo through a condition type PDIF. This has to be places at the appropriate place in the Pricing Procedure to get the difference ammount. Once value is passed in this condition type rest all other condition type gets deactivated except Taxes.

Yes you need to maintain the Document Type and Item categories to differential from the nor Credit / Debit Memo.

No EDI is required for Retro Billing.

Only Value difference related to price is captured. Please ensure to Retro Billing Order Reasons is maintained during VFRB transaction.

Regards,

Sumit

[Former Member]

1. Is it necessary to have EDI in place for Retro billing.

2. Retro billing and Self billing - are they one and the same ?

Please note that Retro billing and Selfbilling are entirely different processes and can be executed independently.

Let me explain using a very simple example:

You sell 10 units of a material A for $100 per unit - Amount $1000

Invoice is sent to customer for $1000 on say Sep 20, 2010

RETROBILLING

Now due to price negotiations price may change to $90 w.e.f Sep 01, 2010 , Thus you will update your price conditions in VK12 for this material/customer to $90 with validity from Sep 01, 2010. But as you have already invoiced the customer in past so to take care of the extra billing . You will execute retrobilling process.

You will go to VFRB and enter the selection criteria for the material and suitable dates, system will provide you the list of candidate invoices to which this price reduction is applicable and hence you can simulate or even execute retrobilling after providing Cr/Dr memo type and order reason. These documents will get attached to the original invoice

Imp to Note - you must maintain the 'use of order reason for retro-billing' in Order reasons config for this to work properly

SELFBILLING

Here customer raises invoices for itself. Supplier does not send the invoice to customer.

Customer may send a selfbill for the above case like $80 a piece. This will hit the supplier system in form of EDI/Fax/Paper etc and on verification in system will show in Selfbill Monitor VSB1n.

On processing, system will generate a credit memo of $200 for the customer and a debit memo for same amount with reference ?_?_?. Now the customer while paying will pay $800 as per its selfbill and the same would be settled against original invoice of $1000 and SB credit Memo of $200. Other debit memo of $200 (with ?_?_? reference) will remain open in system which may be cleared off by a retrobilling run where supplier may reduce the price by $20 or take further action as needed.

Hope this clears your doubt on these two procesess.

Do let us know if you have any further questions

[Former Member]

Hi Harpreet,

Thanks for the detailed explanation.

Is it mandatory to create an exclusive credit and debit note type for retro billing. As currently, am able to create debit & credit notes with the help of the normal credit and debit note document types.

Currently i have a price of 1.5 Rs. from 01st Sep to 30th Sep. But till August it was 1.00 Re only. This 1.5 Rs is wrong and customer should be credited for the difference (0.5 Re) for the invoices created between 1 u2013 10 Sep. With the current setup in the system, when we run VFRB for the first time, system is creating a credit note for 1.5 Rs. initially, then again when we run the VFRB tcode, system will be creating a debit note for the correct amount (1.00 Re).

We need to have a credit note created for 0.5 Re directly. I have tried including PDIF condition type but the system is picking only the difference value but the taxes are showing as Zero. Please help.

[Former Member]

Hi

Is it mandatory to create an exclusive credit and debit note type for retro billing. As currently, am able to create debit & credit notes with the help of the normal credit and debit note document types.

No, there is no such requirement at all for Retrobilling as long as you do not wish to separate the Retrobilling cr/dr memos with regular Cr/Dr memos using different number range.

Currently i have a price of 1.5 Rs. from 01st Sep to 30th Sep. But till August it was 1.00 Re only. This 1.5 Rs is wrong and customer should be credited for the difference (0.5 Re) for the invoices created between 1 u2013 10 Sep. With the current setup in the system, when we run VFRB for the first time, system is creating a credit note for 1.5 Rs. initially, then again when we run the VFRB tcode, system will be creating a debit note for the correct amount (1.00 Re). 

This certainly would have happened, if you failed to include PDIF doc type.

 I have tried including PDIF condition type but the system is picking only the difference value but the taxes are showing as Zero.

Try using PDIF condition type in your pricing procedure right after the pricing condition types and before Discounts/Taxes . After that you will have to have a net- value calculated. If you proceed like this you would get desired results.

For PDIF condition type - keep print ID as 'a', Condition subtotal as'F',

I am sure you will be bang on taget with this.

If you still face any issue, do let me know.

Also Check my post in this thread on Retrobilling [url]

Regards

Harpreet

[Former Member]

Hi Harpreet,

Great Job !

In my case, currently the pricing procedure is not having the PDIF condition type and even i incorporate it now, the system is just copying as it is from the invoice. I think for this the copy control settings has to be changes as mentioend in your other forum post. That is, the VTFF tcode @ item level the Pricing type should be "C" (Currently it is "D"). My concern if i change the Pricing Type then will it affect the normal process of F2 (Invoice ) to G2 (Credit Memo). Please clarify.

Regards

[Former Member]

Well Changing it C, the only effect in your normal process would be that pricing would not be copied as it is from F2 to Cr/Dr memo and would be recalculated.

If your requirement is not to redetermine prices in normal process then you may as well go for a new Cr/Dr memo doc type just for retrobilling. But otherwise there should not be an issue.

Also Please maintain PDIF carefully with the settings which I provided and you should be perfectly fine !

Regards

Harpreet

[Former Member]

Hi Harpreet,

Thanks again for your confident and quick response.

Analysed the system for various options and my findings are follows:

1. To have the new pricing carried out we can use the Option u201CCu201D in the Pricing Type in VFRB t code and hence there is no need to go for any new document types. This is for your information.

2. We tried using the PDIF condition type in the pricing procedure and we found that values are getting calculated incorrectly.

That is, we have PR01 as the first condition type and which is nothing but u201CPrice inclusive of sales taxu201D. Followed by Gross price value (without Condition types u2013 that is for sub totalling) , MWI1 & MWIG condition types. Atlast we have NTPS condition types.

Whereas I checked for a normal pricing procedure and it works fine.

Now, I need to know for the pricing procedure which has PR01 (Price inclusive of sales Tax), we canu2019t have the retro billing run correctly. Please confirm.

If still you believe that it is possible then please let me the procedure to be followed.

Please help.

Thanks for your time.

Regards