On 29/12/11 07:32 -0800, Giedrius Slavinskas wrote: > > On 29 Gruo, 15:34, Cédric Krier <[email protected]> wrote: > > On 29/12/11 15:12 +0200, Giedrius Slavinskas wrote: > > > > > In many business taxes (VAT) are already rounded per unit and not per > > > unit_price*quantity (or the tax sum). If you go to the shopping center, > > > you will see that the taxes there, are already included in the listing > > > price, so that means they are rounded per unit. > > > > This is a special cases of sales with taxes included. > > Yes, it is different from sales point of view. But from accounting - > is not. Taxes > are always included. In this case, its just shown on the label.
I can not agree on this statement.
> >
> > > If it would be rounded
> > > per unit_price*quantity or the tax sum, you can get a strange situations
> > > when buying for example 2 pens which list price is 1 EURO you must pay
> > > 2.01 EURO..
> >
> > I don't understand your example
>
> Let's say we have 21% VAT, so Pen price in shop = 0,83 unit_price +
> 0,17 vat = 1€
> actually VAT = 0,83*0,21= 0,1743
> So when rounding is done on tax line (or tax sum), buying 3 pens would
> cost 3,01 because:
> 0,83 * 3 = 2,49€ and VAT = 2,49 * 0,21 = 0,5229 ~ 0,52.
> So 2,49 + 0,52 = 3,01€
This is because you are not using a correct unit price.
If you use a correct one:
unit_price = 1 / D('1.21') = D('0.8264462809917355371900826446')
tax = unit_price * 3 * D('0.21') = Decimal('0.5206611570247933884297520661')
unit_price * 3 + tax = Decimal('3.000000000000000000000000000')
QED :-)
All this misunderstanding comes from the point that you are looking at
tax included price which can not work and will not work in the ERP.
If you have such needs, you must define a way to retro-compute the taxes
for each line you are saling.
> > > Btw, if you read the law of VAT, you will see that this tax adds value
> > > for single product, material or service and not for invoice.. So
> > > logically, if you have rounding on the sum of taxes, that means you
> > > adding value for the invoice.
> >
> > > Normally, VAT is counted like this:
> > > VAT = round(unit_1_price * VAT_% / 100) * quantity_1 +
> > > round(unit_2_price * VAT_% / 100) * quantity_2 +
> > > ..
> > > VAT = round(VAT)
> >
> > This is very strange because you can have a unit_price with a precision
> > lower than the currency one. So if you round such unit_price tax
> > computation, you will have 0.
>
> Basically, when unit price is lower when precision of the currency,
> you will never buy
> or sell such a single unit. That means, you have choosen too small
> unit of measure.
No. I got a request when working at Tiny for a customer who was salling
battery to have a unit price with 3 digits.
And yes of course you don't sale unit of such product but you want to be
able to sale any kind of multiple of it not only by 10 pieces.
> If there is a case to have the product in such a small unit of measure
> (or price), then
> you need to setup the accounting transactions to have more precision
> than
> the currency one.
No, you can not do write accounting transaction with a lower precision
than the currency.
> > > So speaking in words, we need to know what is the added value (in same
> > > precision as the list price) for a single product. After that, we need
> > > to sum up all VAT for a single product by its quantity. In case, when
> > > all quantities are integer we always get an accurate VAT without need of
> > > rounding tax lines or the tax sum. But if we have decimal quantity, we
> > > need to round one more time. And think this the situation what the
> > > Germany laws are speaking about. If we round each tax line, we will get
> > > an incorrectness:
> > > round( round(unit_1_price * VAT_% / 100) * quantity_1 ) +
> > > round( round(unit_1_price * VAT_% / 100) * quantity_2 )
> > > is not equal to
> > > round( round(unit_1_price * VAT_% / 100) * quantity_3 )
> > > where quantity_3 = quantity_1 + quantity_2
> > > so we must round the sum and not the lines.
> >
> > Yes but:
> >
> > round( unit_1_price * VAT_% / 100 * quantity_1 +
> > unit_1_price * VAT_% / 100 * quantity_2 )
> >
> > is equal to
> >
> > round( unit_1_price * VAT_% / 100 * quantity_3 )
> >
> > And this is what we do in Tryton. The only issue is about the display of
> > base amount in the tax lines of invoice which should be rounded by lines
> > to have the same value as the untaxed amount.
> >
>
> This is true as long as you are not selling things in the shop or
> internet.
Tax included must be managed in a separate workflow.
> What if i want to sell a pen for 1€? I make the most accurate list
> price
> i can get 1 / 1,21 = 0,826446281 ~ 0,8264.
> But its wrong even for single unit 0,8264 * 1,21 = 0,999944 ~ 0,99
> And if i sell 10000 of them 10000 * 0,8264 * 1,21 = 9999,44
Increase the precision of the unit price but the best solution is a
separate workflow.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgp8ApxTWexgW.pgp
Description: PGP signature
