Community mailing list archives


Re: Prices incl VAT in ecommerce and POS

- 12/14/2014 04:32:02
Basically you can only make assumptions on your web customer until he provided his actual shipping destination and/or VAT. Even the invoice address does not really matter when it comes to VAT no VAT!

So taking this as a fact you need to make an educated guess once the customer first comes to your website. We use GeoIP to determine if the user comes from an EU country or not in our current ecommerce solution. If ouside of the EU we show a pop-up asking if the user would like to ship outside of the EU or not. We also switch the currency to USD or GBP depending on the GeoIP. You can also make this configurable by the user by having a "net" price switch next to the language flags. It will be overwritten during checkout anyway once you have all the data on the shipping destination and VAT etc..

In general - business customers inside the EU have no problem with VAT incl. prices as long as you state the net price in the shopping basket and let him pay the correct price on checkout. Private customer often do not understand the concept of net prices and will not understand the procedure.

Regarding the rounding issue: Use more decimal number to get the desired rounding of prices.

Sportive Greetings,
Director & Founder

   aerobis Ltd.
   Hertzstr. 6
   50859 Cologne / Germany

   Skype: elmarschumacher

Registergericht Köln HR B 60978
Registered in England and Wales, Company Nr. 5967471
Geschäftsführer der Gesellschaft: Elmar Schumacher
UStIDNr: DE251851919

Im Geschäftsverkehr gelten unsere Allgemeinen Geschäftsbedingungen. Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof.

Jonathan Swift - "May you live every day of your life"

2014-12-13 18:16 GMT+01:00 Sylvain LE GAL <>:

Sylvain LE GAL
Service informatique
Groupement Régional Alimentaire de Proximité

3 Grande rue des feuillants 69001 Lyon
Bureau :
Astreinte :
Site Web :
Twitter :

2014-12-12 15:38 GMT+01:00 Ric <>:
You can handle channel with price list.

I think the real question is how prices are being formed. 

Either you want to focus on the psycological aspect of the price and you want to start by the Public price and you expect the VAT to be included
Or you want to focus on your margin so you start by the Cost Price and you add your margin and VAT on top but without actually caring about the 

Using Public Price or Cost Price seem to me quite OK.

Only trouble with v8

- it is not posible to declare a fiscal position AND pricelist by default for each POS.
Actually, There is a PR in OCA / POS project to manage Pricelist and fiscal position in POS V8 :
- it is not possible to set the pricelist on each invoices (it is only possible on sale orders)


2014-12-12 14:48 GMT+01:00 Jordi Ballester Alomar <>:

My 2 cents:

1. Introduce the concept of channel (B2B National / B2B Export / eCommerce,...) that you can enter in the sales orders.
2. Public prices are defined by product+channel
3. Taxes are defined by product+channel

Fiscal positions should be used for concepts such as Tax exemptions by the customer. Do not need to be changed at all. Just make sure that all possible source taxes for every channel the partner is involved in are mapped.


On Fri, Dec 12, 2014 at 2:08 PM, Fabien Pinckaers <> wrote:
Sebastien, That's exactly what the standard modules do. We do that for a lot of customers and it does not require a specific module. But the problem I'd like to fix is that it's complex for end users. Using fiscal positions, you can select taxes with price include/exclude so that you have a different way of working in both SO and eCommerce. That's what we do for our SaaS customers but it's not a good usability. On 12/12/2014 10:52 AM, Sebastien Beau wrote: > Hi all, > We already have a working solution for managing inc and exc tax in Sale > order (can be extended for the POS) > > We will document it really soon. But very quickly in 3 lines > - you can define if a price type is in taxe inc or not > - you can define on a fiscal position if the price should be in taxe inc > or not. > - than depending on the position fiscal selected on the sale order Odoo > will convert the unit price and use the right tax > > Exemple > > French Case : I manage my price in taxe include (price type tax include) > > Case 1 : french customer price tax include => position fiscal in tax include > - no conversion is done the unit price is the unit price of the product > (I do not map the tax) > > Case 2 : french profesionnal => position fiscal in tax exclude > - conversion of the unit price (tax inc => tax exc) > - mapping of the taxe in order to use the tax-exc > > Case 3 : belgium professional customer => position fiscal in tax exclude > - conversion of the unit price (tax inc => tax exc) > - mapping of the taxe in order to use the 0% tax (as it's an export) > > An OCA module (here is > waiting to be the merged but for now is blocked as we need to refactor a > little the Odoo core, a merge have been done and is in the pending state > : > > Sorry (I am very busy today). But I will be back when some documentation > will be done > > > Note : this module may not fit with every country (at least it should > work in all europe) contribution and review are welcome ;) > > > 2014-12-12 10:15 GMT+01:00 Wolfgang Taferner < > <
>>: > > Anyone has a better idea? > > Well, Fabien, not sure, but the problem is, as you said, the mix, so > remove the two way approach and always use one method (net approach > most obvious) and make it possible to choose how the price will be > displayed in any other context by using always the same way of > computation to achieve this. > > I guess this has already been talked of, but I do not know why this > can not be achieved and who will be cut off by doing this that it > was not done a long time ago?! > > My five cents. > > Wolfgang > > _______________________________________________ > Mailing-List: > Post to: <> > Unsubscribe: > > _______________________________________________ > Mailing-List: > Post to: > Unsubscribe: > -- Fabien Pinckaers Odoo Founder Phone: + Web: Twitter: @fpodoo Instant Demo:

Post to:


Jordi Ballester Alomar

Tel: (+34) 629530707 

E-mail:  |   Web:

Twitter: @jbeficent_erp                              |   Skype: jordi.ballester

Este email contiene información confidencial. El contenido de la misma se encuentra protegido por Ley. Cualquier persona distinta a su destinatario tiene prohibida su reproducción, uso, divulgación o impresión total o parcial. Si ha recibido este mensaje por error, notifíquelo de inmediato al remitente y borre el mensaje original junto con los ficheros anexos.

This message contains confidential information and it is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete it from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.



Post to:

Post to:

Post to: