on 12-13-2012 6:48 AM
Hi.
Does anyone know SAP's best practice for price correction of following sales document types?
RE: Returns
KE: Consignment Issue
Our client is using Sales Doc.Type RK for price correction.
But there is no standard copy control from those to credit/debit memo request(RK).
*No copy control from Billing Type RE to Sales Doc.Type: RK.
*No copy control from Billing Type F2/Item Category KEN to Sales Doc.Type:RK.
I think there are following ways to correct price.
1. Create RK with reference of original sales order OR.(Only for RE)
2. Cancel billing and correct sales order, and re-create billing document.
3. Add copy control from RE to RK.
4. Remove "Reference mandatory" from sales doc.type RK configuration and create without reference.
Regards,
Sayaka Yano
Hello Sayaka,
Generally Invoice correction (RK) is used when there is some pricing issue normal invoice (F2), which need to be corrected.
For Returns you have two options:
1. Create Returns order - Returns Delivery - Credit memo (with reference to Returns Order).
2. Create Returns Order & Returns Delivery. Create Credit / Debit Memo Request (Order) with reference to Original Invoice & create Credit / Debit Memo (Invoice).
Hope this helps,
Thanks,
Jignesh Mehta
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Mehta,
Thank you for your help!
I think that's a scenario of normal sales returns.
The scenario of my question is as below.
1. Goods sold with Sales Doc.Type OR and invoiced.
2. Return occurs with Sales Doc. Type RE and invoiced.
3. Price of step 2 was wrong and needs to be corrected.
What would you do for step 3?
Regards,
Sayaka
Sayaka,
Jignesh is somewhat right, if any invoice is involved, invoice correction request is the best option. But, standard RK too have some limitations, as it only creates Credit Memo.
Well, now your step 3 will depends, whether you are going pay back some money to your customer or you are entitle to receive amount.
If your are going to pay back, then create credit memo request and the invoice with credit memo.
Or else, if you have to receive some amount, then raise debit memo request and invoice with debit memo.
Regards, JP
JP,
Thanks for your help.
So, my understanding is,
you better not use RK for sales returns correction. RK is only for normal invoice (F2) as Jignesh mentioned.
When you want to correct price in return order,
create CR or DR without reference of any order. (Since there is no copy control from RE to CR/DR.)
Now, what about invoice correction for consignment issue?
There is no copy control from invoice(F2)/Item Category KEN(Consignment Issue) as standard configuration.
We could use CR or DR without reference of any billing document just like returns.
Also we could copy copy control of "TAN" and create new "KEN".
But before I decide I wanna know SAP best practice solution for the scenario.
Thanks,
Sayaka
G. Lakshmipathi,
Yes.
Actually our client said it rarely happens.
I think the situation is like this.
1. Original order with $100 dollars.
2. Return with $80 dollars, $20 less than the original since customer have been used for a while and the price was agreed and approved.
3. Somehow operator made mistake in typing price in sales order.
They realized it was wrong after sending invoice document to the customer.
Thanks,
Sayaka
Jyoti,
But, standard RK too have some limitations, as it only creates Credit Memo.
The above remark is correct!
But with sales document type RK (in other words: Invoice correction process) both - giving money to customer & getting money from customer - are possible!
So by "some limitation" what do you mean exactly?
Thanks in advance!
Message was edited by: T W
Sayaka,
You can make two documents by copying sales document type RK:
- one for giving or getting money from customer, for RE process: ZRRK
- one for giving or getting money from customer, for CI process: ZCRK
Or you can make one document by copying sales document type RK for both the processes.
(then keep field Reference Mandatory = Blank, in your sales document type, in VOV8)
T W wrote:
Jyoti,
But, standard RK too have some limitations, as it only creates Credit Memo.
The above remark is correct!
But with sales document type RK (in other words: Invoice correction process) both - giving money to customer & getting money from customer - are possible!
So by "some limitation" what do you mean exactly?
Thanks in advance!
Message was edited by: T W
Hi TW,
The billing document created with reference to RK can be for a debit value or a credit value. System creates a credit memo if the value is positive and a debit memo if the value is negative. But, the header always shows it as a credit memo and it is the limitation in this process.
Regards,
Ravi Sankar
Does anyone know SAP's best practice
Since you started your original post with the above text, for the issue what has happened, my suggestion would be
so that these sort of issues wont recur.
G. Lakshmipathi
G Lakshmipathi,
inactivate manual pricing in return order. Always, it should be automated
Sayak:
I think the situation is like this.
1. Original order with $100 dollars.
2. Return with $80 dollars, $20 less than the original since customer have been used for a while and the price was agreed and approved.
3. Somehow operator made mistake in typing price in sales order.
They realized it was wrong after sending invoice document to the customer.
If you look in to the business scenario description, if the "negotiated" amount in RE order is discussed and then fixed (during RE order creation), then inactivating manual pricing would not fulfill this scenario.
Furthermore, if the prices are discussed and fixed in RE order, then three things are important to site:
a. (if there is no logic) Manual pricing is needed in RE order
b. Users have to be careful while updating the Tab Conditions
c. Mistakes shall be made, and corrections would have to be done
Sayak,
Is there any logic followed to get the price (e.g. 80$) inputted in the RE order?
T W wrote:
Ravi,
Thanks for your post!
Could you please comment on - With an invoice correct request process (sales doc type RK > credit memo G2) can we/company get money (back) from customer?
Yes, we can. It all depends on the credit or debit that is happening. The header (credit memo) of the document has least improtance here. As per my understanding, you can as well configure to display it as Debit Memo...instead of credit memo...and still it can make debit or credit.
Regards,
Ravi Sankar
Ravi,
Thanks for your post!
The header (credit memo) of the document has least improtance here. As per my understanding, you can as well configure to display it as Debit Memo...instead of credit memo...and still it can make debit or credit.
A) Looking from one angle, the header (credit memo) is of least importance. The reason being in essence the billing document could be to pay money to customer or get back money from customer!
That flexibiltiy was in dispute between me and Jyoti. And it has been explained / discussed that the "two way" flexibility is there in the Invoice correction process.
B) Looking from another angle, the header (credit memo) is important. The reason for this because the document is a Credit memo (G2 billing type), therefore minus sign in it signifies the opposite of credit i.e. minus sign signifies that money should be got from the customer.
(for explanation sake) If the document type is changed to Debit memo (L2 billing document), then minus sign would mean give money back to the customer
Sayaka,
*No copy control from Billing Type F2/Item Category KEN to Sales Doc.Type:RK.
You have explained RE process with a business example.
Could you please give a business example for CI process?
Why is there a pricing error in Consignment Issue process, especially when in CF process, the item category KBN is not relevant for pricing?
SAP documentation is provided at http://help.sap.com/saphelp_46c/helpdata/en/dd/55fede545a11d1a7020000e829fd11/content.htm Based on this, the RK document type can be set as either only as credit based or only as debit based. So for second one, a z-type needs to be created to fulfill either debit or credit.
Regards,
User | Count |
---|---|
86 | |
7 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.