Openerp Refund Must Be Splitted/Differentiated into Two Different Documents

Registered by hbto [Vauxoo] http://www.vauxoo.com

Right now, Openerp has only one document, from my accounting PoV, that deals with Sale Returns and Allowances
Thus, some workarounds have to be done to accomplish the task of creating and Allowance to a Customer,

Right now, be it, that you go to:
Procedure A)
 (1) a outgoing picking, (2) making a return picking, and then (3) invoicing the returned picking, yielding a (4) customer refund,

Procedure B)
or that you go to (5) a Customer Invoice, making and (6) Customer Refund,

always book the COGS for the product you are returning,

Though both could seem to be ok, one of them is prone to human error,

The First Procedure is what some would describe as a Sale Return, something the openerp rightfully does, because a product is been returned to the warehouse, and thus the COGS has to be write down into an accounting move, but

The Second Procedure is ambiguous, some would think this procedure is the one that should lead to a Sale Allowance, i.e, reduce the initial price of sale, but that is not true if some workarounds are not made to accomplish it, because if you say that
the product A, you sold in your customer invoice, is going to undergo a undervaluation, because of some defective properties or some kind of arrangement between the buyer and the seller, then resulting document coming from this procedure should not book the COGS of product A,

Though, let the doubt be alive, and think this, from me PoV, it is right, and we say, yeah, it is right to do that. Then this Thinking comes to my mind, you could allow someone, to __unbook__ COGS to your products in an undesirable way, because, you could not be aware that the old product are not being returned to the warehouse, and the warehouse valuation and the accounting valuation could not match, there are and there will be mismatches between the warehouse valuation and the accounting valuation. Conclusion there is no way that the people in the stock logistic be aware that new products are been returning if that was the intend.

Another concern comes out, whenever there are sale returns or sale allowances, those records should not be booked into the same account regarding to the product revenue of the products returned or allowed, they should be booked into their own accounting account, thus letting accounting people scrutinize how much allowance has been done during certain period.

------------------------------------------------------------------------------------------------------------------------------------------
Sale Returns and Allowances. Merchandise sold may be returned to the seller (sales return). In other cases, the seller may reduce the initial selling price (sales allowance). This might occur if the merchandise is defective, damaged during shipment, or does not meet the buyer's expectations.
If the return or allowance is for a sale on account, the seller usually issues the buyer a credit memorandum, often called a credit memo. A credit memo authorizes a credit to (decrease) the buyer's account receivable. A credit memo indicates the amount and the reason for the credit.
Like sales discounts, sales returns and allowances reduce sales revenue. Also, returns often result in additional shipping and handling expenses. Thus, managers usually want to know the amount of returns and allowance for a period. For this reason, sales returns and allowances are recorded in a separate sales returns and allowances accounts, which is a contra (or offsetting) account to Sales.

Financial and Managerial Accounting
 By Carl S. Warren, James M. Reeve, Jonathan Duchac
Page 221
http://books.google.com/books?id=1pLR1T2N_r4C&lpg=PA353&dq=allowance%20accounting&pg=PA221#v=onepage&q=sales%20returns%20and%20allowances&f=false

------------------------------------------------------------------------------------------------------------------------------------------

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.