#adapt sale to b2c environment
Introduction
The current sale object in tryton is adapted to b2b business. B2c handling necessitates some modifications to that logic.
This document proposes to sum up the requirements, and discuss their possible solutions.
Note that while a probable requirement for a pos, this is tackling a different problem than a pos workflow or interface.
Price calculations
Issue
The price in a b2c environment is communicated «all taxes included» to clients.
The current sale object in tryton does all calculations on net price (without tax), and then computes the added taxes.
This poses problems for b2c because of the rounding.
Let's take the Belgian vat (which is 21%) as an example, with a product advertised at 1€ (vat included) to b2c clients (say on a web site).
current behaviour (b2b logic) in tryton for an order of 10 products:
1€ vat included is a 0,83€ net price.
10x 0,83 = 8,3 total, which makes 10,04 € vat included.
b2c clients expect 10x1€ to be 10€.
Proposed solution
In b2c, all amount computation and rounding must be done on the «tax-included» price.
Of course the usual rules apply to documents, invoicing,... so net prices and amounts still have to be computed from those tax-included amounts to appear at their usual locations on invoices and all.
Business clients in EU Intracom and all clients out of EU should still be invoiced without vat.
In tryton
A new sale logic has to be implemented for b2c. It can be added to sale, or a new object can be created for that purpose. Both methods have gotchas (see below).
A tax-included price has to be stored for products. In a separate "b2c_price" field, or in the usual list_price. If separate, those fields have to somehow be linked by a tax calculation (updating b2c_price should update list_price accordingly). If list_price is used, the sale object must be adapted to know that that price is tax included.
A b2c sale must use the tax included b2c_price for prices and amounts in lines.
The sum of all lines becomes the total of the sale (total_amount).
untaxed_amount has to be computed from total_amount and tax_amount.
The bunch of the calculations actually happens in account_invoice, where taxes are really calculated. So account_invoice has to be extended to support the b2c logic.
Gotchas
There has been a long multi discusion on irc about the way to implement that: inside sale, or as a new object.
Implementing it in sale could get messy and complicated. Messy and complicated means bugs. cedk has worked a long time on that problem in another project, and was never satisfied with the solution.
Implementing it as another object means that all extentions made to sale are not automatically availlable in that new object.
It is also less flexible because the user has the responsibility to manually decide of the context before creating the document, and it's not possible to switch once started. There is no way to make tryton decide of a default behaviour depending on the client or any other condition.