Tax improvement
Cédric Krier
situations.
I propose to make those changes:
- Change the Properties "Many2One" (like vat, supplier_vat) by one
Property "Many2One" to a new model (account.tax.rule) to be more
generic and no need to create new module to extend it.
- account.tax.rule will be composed with a One2Many of lines. Each lines
will define a replacement for a group of tax like this:
"Replace all taxes of group ... with this tax ..."
So for me, tax group will define kinds of tax like:
- VAT on product sale
- VAT on service buy
- ...
- Add a function on party.party which take a default tax and return the
right tax according to the rules define on the party.
If we write correctly this function, we will be able to extend the
rules in other modules to take care of the delevery address, ...
Finally after those changes, I find that it will be better to have tax
group on the product instead of tax. But this is a big change and need
to have default tax rule on every parties.
What do you think ?
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Cédric Krier
> The current implementation is not enough flexible to manage all the
> situations.
>
> I propose to make those changes:
>
> - Change the Properties "Many2One" (like vat, supplier_vat) by one
> Property "Many2One" to a new model (account.tax.rule) to be more
> generic and no need to create new module to extend it.
>
> - account.tax.rule will be composed with a One2Many of lines. Each lines
> will define a replacement for a group of tax like this:
> "Replace all taxes of group ... with this tax ..."
>
> So for me, tax group will define kinds of tax like:
>
> - VAT on product sale
> - VAT on service buy
> - ...
>
> - Add a function on party.party which take a default tax and return the
> right tax according to the rules define on the party.
> If we write correctly this function, we will be able to extend the
> rules in other modules to take care of the delevery address, ...
>
> Finally after those changes, I find that it will be better to have tax
> group on the product instead of tax. But this is a big change and need
> to have default tax rule on every parties.
>
> What do you think ?
>
So no comments?
I guess if there is any, it is because everybody agree :-)
Udono
the improvements looks good for me. But may we wait a week, when timitos
is back again?
Mathias Behrle
> The current implementation is not enough flexible to manage all the
> situations.
>
> I propose to make those changes:
>
> - Change the Properties "Many2One" (like vat, supplier_vat) by one
> Property "Many2One" to a new model (account.tax.rule) to be more
> generic and no need to create new module to extend it.
>
> - account.tax.rule will be composed with a One2Many of lines. Each lines
> will define a replacement for a group of tax like this:
> "Replace all taxes of group ... with this tax ..."
>
> So for me, tax group will define kinds of tax like:
>
> - VAT on product sale
> - VAT on service buy
> - ...
>
> - Add a function on party.party which take a default tax and return the
> right tax according to the rules define on the party.
> If we write correctly this function, we will be able to extend the
> rules in other modules to take care of the delevery address, ...
>
> Finally after those changes, I find that it will be better to have tax
> group on the product instead of tax. But this is a big change and need
> to have default tax rule on every parties.
>
> What do you think ?
>
It will be a great, great feature (I don't know any software so far that handles
this well and comfortable) to have a configurable tax system, that is able to
apply to the different cases of taxation occuring as well in the own country or
EU or export commerce.
It has to be very well analyzed, which model can serve best *all* purposes to
not have another inflexibilty afterwards. Currently I don't see, how it will
be able to differentiate in tax rules on products (or services) according to the
addresses of the supplier and the recipient, if they have VAT-Id or not, how
the transport is made, if there is any purchase/delivery threadshold exceeded,
how the payment is made etc.
So it is according to inland and EU taxation law a rather complex subject, we
should discuss and analyze very well. I agree with udono anyway to wait for the
input of Timitos, who has worked on that already and made a blueprint in
account_tax_system. If it should be not enough time to get it discussed,
implemented and tested for the upcoming release (which in my eyes is already the
case), then it will be better scheduled for release 1.4.
Cédric Krier
I think the key point is that we will have one unique function that will
do the job. So it will be easy to override it to extend it.
To differentiate the tax rules according to the addresses, we will give
to the function the addresses (from the purchase or the sale, it will
not be possible on invoice).
The VAT-id check will be done by the choose of the rule on the party.
For the transport, it will be like for addresses.
For the threshold exceeded, it can be done by the function according
to thresholds define on rule lines.
For the payment, I don't understand how can you know before being paid
how the payment will be made.
> So it is according to inland and EU taxation law a rather complex subject, we
> should discuss and analyze very well. I agree with udono anyway to wait for the
> input of Timitos, who has worked on that already and made a blueprint in
> account_tax_system. If it should be not enough time to get it discussed,
> implemented and tested for the upcoming release (which in my eyes is already the
> case), then it will be better scheduled for release 1.4.
The goal is not to have a complete system, but to have the base. And I
don't think it will be good to wait 1.4. If necessary we will
re-schedule the release date.
Mathias Behrle
> For the payment, I don't understand how can you know before being paid
> how the payment will be made.
Imagine the following case:
My store is in Germany, a customer from Switzerland is buying some goods. His
address is in Switzerland, but he pays at once in Germany. So it is not an
export, but an inland sale. You cannot know this from the address, so you must
have the possibilty to override.
> > So it is according to inland and EU taxation law a rather complex subject,
> > we should discuss and analyze very well. I agree with udono anyway to wait
> > for the input of Timitos, who has worked on that already and made a
> > blueprint in account_tax_system. If it should be not enough time to get it
> > discussed, implemented and tested for the upcoming release (which in my
> > eyes is already the case), then it will be better scheduled for release 1.4.
>
> The goal is not to have a complete system, but to have the base. And I
> don't think it will be good to wait 1.4. If necessary we will
> re-schedule the release date.
It is up to you to decide.
We will need in future a clear release schedule:
- to have something like a feature freeze
- to have enough time to test release candidates
- to have enough time for translators to fix translations
- to have a clear plan for all
Not everyone is available in the last few days/weeks before a planned release
(due to other work, vacations, diseases etc. etc.), so the schedule has to
allow for such incidences. And we are still few people to test the release
candidates.
Cédric Krier
> * Betr.: " [tryton] Re: Tax improvement" (Tue, 24 Mar 2009 11:59:48 +0100):
>
> > For the payment, I don't understand how can you know before being paid
> > how the payment will be made.
>
> Imagine the following case:
> My store is in Germany, a customer from Switzerland is buying some goods. His
> address is in Switzerland, but he pays at once in Germany. So it is not an
> export, but an inland sale. You cannot know this from the address, so you must
> have the possibilty to override.
It is not where you paid that is important but where the goods are
deliveried. So for a sale, it is the shipment addresse.
Udono
good news, Timitos told me, that in his opinion the tax improvements
from cédric are very good. So no need to hold the release waiting for
him.
Cédric Krier
Ok, I will start working on it.
I just have one issue about the migration. I think I will not be able to
migrate existing taxes defined on parties.
By the way, what does he think about using tax code on product instead
of taxes?
Udono
> On 24/03/09 14:29 +0100, Udono wrote:
> >
> > Hi all,
> > good news, Timitos told me, that in his opinion the tax improvements
> > from cédric are very good. So no need to hold the release waiting for
> > him.
> >
>
> Ok, I will start working on it.
> I just have one issue about the migration. I think I will not be able to
> migrate existing taxes defined on parties.
> By the way, what does he think about using tax code on product instead
> of taxes?
improvement?
Udono
> Imagine the following case:
> My store is in Germany, a customer from Switzerland is buying some goods. His
> address is in Switzerland, but he pays at once in Germany. So it is not an
> export, but an inland sale. You cannot know this from the address, so you must
> have the possibilty to override.
need to extend the tax system in any case...
Cédric Krier
So as others accounting parameter, they have their own template linked
to a chart of account template and we you create a account chart they
are created also.
They are updated with the update of chart of account.
So they replace the vat and supplier_vat property on party, but there is
no migration because it is not possible.
Please, test it before the release.
tim...@virtual-things.biz
Rgds
Timitos
On 24 Mrz., 14:43, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> On 24/03/09 14:29 +0100, Udono wrote:
>
>
>
> > Hi all,
> > good news, Timitos told me, that in his opinion the tax improvements
> > from cédric are very good. So no need to hold the release waiting for
> > him.
>
> Ok, I will start working on it.
> I just have one issue about the migration. I think I will not be able to
> migrate existing taxes defined on parties.
>
> By the way, what does he think about using tax code on product instead
> of taxes?
>
> --
> Cédric Krier
>
> B2CK SPRL
> Rue de Rotterdam, 4
> 4000 Liège
> Belgium
> Tel: +32 472 54 46 59
> Jabber: cedric.kr...@b2ck.com
> Website:http://www.b2ck.com/
>
> application_pgp-signature_part
> < 1 KBAnzeigenHerunterladen
tim...@virtual-things.biz
Cédric Krier
>
> Usage of tax group on products would be much better!
>
I'm not sure because it doesn't allow to use Tryton with simple taxes.
Because you will need to write tax rules for every party.
So the tax on the product is a default value.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
tim...@virtual-things.biz
complete with this change.
On 2 Apr., 18:10, Cédric Krier <cedric.kr...@b2ck.com> wrote:
>
>
>
> > Usage of tax group on products would be much better!
>
> I'm not sure because it doesn't allow to use Tryton with simple taxes.
> Because you will need to write tax rules for every party.
> So the tax on the product is a default value.
>
> --
> Cédric Krier
>
> B2CK SPRL
> Rue de Rotterdam, 4
> 4000 Liège
> Belgium
> Tel: +32 472 54 46 59
Cédric Krier
>
> i am sure that it is a good idea as for me the new system is only
> complete with this change.
>
Putting a tax on a product give more information than a tax group.
So you can do the same with tax on product than with tax group on
product.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Dr. Axel Braun
> On 02/04/09 10:01 -0700, tim...@virtual-things.biz wrote:
> > i am sure that it is a good idea as for me the new system is only
> > complete with this change.
>
> Putting a tax on a product give more information than a tax group.
> So you can do the same with tax on product than with tax group on
> product.
Nearly..if you assign multiple products to a tax group you just have to change
the tax group to make a tax change apply toall products.....instead of
changign every product.
Axel
Sasa Ostrouska
> On 02/04/09 20:31 +0200, Dr. Axel Braun wrote:
>>
>> Am Donnerstag 02 April 2009 schrieb Cédric Krier:
>> > On 02/04/09 10:01 -0700, tim...@virtual-things.biz wrote:
>> > > i am sure that it is a good idea as for me the new system is only
>> > > complete with this change.
>> >
>> > Putting a tax on a product give more information than a tax group.
>> > So you can do the same with tax on product than with tax group on
>> > product.
>>
>> Nearly..if you assign multiple products to a tax group you just have to change
>> the tax group to make a tax change apply toall products.....instead of
>> changign every product.
>>
>
> But it must not happen that you need to change all taxes on products.
> And any way, you can just modify the tax.
>
Its better to have the possibility of both, change the tax per
product, and change the tax for whole the group.
Rgds
Saxa
tim...@virtual-things.biz
better.
We have 19% standard vat here.
When i sell a product in inland i have to put 19% vat on it.
When i sell a service in inland i have to put 19% vat on it.
So far so good.
But when i sell a product to a country outside EU it is free of vat
for me.
But when i sell a service to a country outside EU i have to put 19%
vat on it (in most cases, there are also other special cases).
So for this case i need to create the tax double because i need to
different tax groups to make this working.
I need a tax with tax group 'product' which is changed to 'free'.
And i need a tax with tax group 'service' which is not changed.
But this is not what i want. Why should i create taxes of the same
value twice or more. I think I would need this tax nearly 5 times to
set up als tax cases here. Perhaps even more.
If i had only tax group on product it would be easy.
Rgds
Timitos
Cédric Krier
No, even with tax group, you must create the same number of taxes.
Because tax rule are can only replace a tax with an other one of the
same group.
And if we put tax group on product, which will be used when there is no
tax rules?
tim...@virtual-things.biz
taxes more than one time because such things would be confusing for
the user.
I am sure that there is a better solution.
Why did you put this constraint that tax rule can only replace a tax
with an other one of the same group? i can understand this in the view
of the old solution. But i think that tax groups now have a quite
different function compared with the old solution.
On 2 Apr., 22:31, Cédric Krier <cedric.kr...@b2ck.com> wrote:
Cédric Krier
>
> I think we should find a solution that do not need to create same
> taxes more than one time because such things would be confusing for
> the user.
For me it is not the same tax.
A VAT on product and a VAT on service even if they have the same
rate are different taxes.
In Belgium, for the VAT report you must have different code for VAT on
product and service.
> I am sure that there is a better solution.
> Why did you put this constraint that tax rule can only replace a tax
> with an other one of the same group? i can understand this in the view
Because for me it doesn't make sence to replace a VAT on product with a
VAT on service.
> of the old solution. But i think that tax groups now have a quite
> different function compared with the old solution.
In fact no, it is closely the same but more generic.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Carlos Perelló Marín
> On 02/04/09 23:24 -0700, tim...@virtual-things.biz wrote:
>
>> I think we should find a solution that do not need to create same
>> taxes more than one time because such things would be confusing for
>> the user.
>>
>
> For me it is not the same tax.
> A VAT on product and a VAT on service even if they have the same
> rate are different taxes.
> In Belgium, for the VAT report you must have different code for VAT on
> product and service.
>
>
Tryton, because Tryton used a lot 'name' to identify taxes, without
showing the description, and the only difference between our taxes is
for the tax code, but it's internal and the user is not interested on
that at all, so we had to 'misuse' name and description for taxes. Name
is really a description, and description is really the name, that way,
when we assign a tax to a product or service we get the description,
instead of a duplicate list of taxes (16% VAT, 16% VAT, etc... vs 16%
VAT on services, 16% VAT on goods, etc..), also, this produces a better
invoice with the default report in Tryton, however, we are going to
change it anyway, so this last part is not an issue.
>> I am sure that there is a better solution.
>> Why did you put this constraint that tax rule can only replace a tax
>> with an other one of the same group? i can understand this in the view
>>
>
> Because for me it doesn't make sence to replace a VAT on product with a
> VAT on service.
>
Wouldn't it make sense, for instance, when you have EU taxes group,
inland product group ?
So depending on the type of customer, you could use either an EU tax or
an inland one?
The best example is when you issue an invoice to a customer in another
EU country which doesn't validate in the VIES system, you should handle
that as an inland sell, but some days later, that same customer would be
in the special EU tax group. I know this would be 'fixed' using a
different grouping schema, but then, we are being too strict in the way
we allow users to define their tax groups...
>
>> of the old solution. But i think that tax groups now have a quite
>> different function compared with the old solution.
>>
>
> In fact no, it is closely the same but more generic.
>
>
>
Cheers.
--
Carlos Perelló Marín
[P+] SERVICIOS PROFESIONALES
http://www.pemas.es
mailto:car...@pemas.es || mailto:car...@gnome.org
Cédric Krier
>
> Cédric Krier escribió:
> > On 02/04/09 23:24 -0700, tim...@virtual-things.biz wrote:
> >
> >> I think we should find a solution that do not need to create same
> >> taxes more than one time because such things would be confusing for
> >> the user.
> >>
> >
> > For me it is not the same tax.
> > A VAT on product and a VAT on service even if they have the same
> > rate are different taxes.
> > In Belgium, for the VAT report you must have different code for VAT on
> > product and service.
> >
> >
> In Spain is the same, in fact I had problems defining the taxes in
> Tryton, because Tryton used a lot 'name' to identify taxes, without
> showing the description, and the only difference between our taxes is
> for the tax code, but it's internal and the user is not interested on
> that at all, so we had to 'misuse' name and description for taxes. Name
> is really a description, and description is really the name, that way,
> when we assign a tax to a product or service we get the description,
> instead of a duplicate list of taxes (16% VAT, 16% VAT, etc... vs 16%
> VAT on services, 16% VAT on goods, etc..), also, this produces a better
> invoice with the default report in Tryton, however, we are going to
> change it anyway, so this last part is not an issue.
To clarify the situation:
name = the internal name of the tax
description = the string that will be used in report like invoice (it is
in the help of the field).
> >> I am sure that there is a better solution.
> >> Why did you put this constraint that tax rule can only replace a tax
> >> with an other one of the same group? i can understand this in the view
> >>
> >
> > Because for me it doesn't make sence to replace a VAT on product with a
> > VAT on service.
> >
>
> Wouldn't it make sense, for instance, when you have EU taxes group,
> inland product group ?
>
> So depending on the type of customer, you could use either an EU tax or
> an inland one?
>
> The best example is when you issue an invoice to a customer in another
> EU country which doesn't validate in the VIES system, you should handle
> that as an inland sell, but some days later, that same customer would be
> in the special EU tax group. I know this would be 'fixed' using a
> different grouping schema, but then, we are being too strict in the way
> we allow users to define their tax groups...
I don't understand your example.
For me a party that was prevously without correct VAT number and now it
has a good one, you just need to change the tax rule on it.
Carlos Perelló Marín
name and description, I assumed the wrong thing.
>
>
>>>> I am sure that there is a better solution.
>>>> Why did you put this constraint that tax rule can only replace a tax
>>>> with an other one of the same group? i can understand this in the view
>>>>
>>>>
>>> Because for me it doesn't make sence to replace a VAT on product with a
>>> VAT on service.
>>>
>>>
>> Wouldn't it make sense, for instance, when you have EU taxes group,
>> inland product group ?
>>
>> So depending on the type of customer, you could use either an EU tax or
>> an inland one?
>>
>> The best example is when you issue an invoice to a customer in another
>> EU country which doesn't validate in the VIES system, you should handle
>> that as an inland sell, but some days later, that same customer would be
>> in the special EU tax group. I know this would be 'fixed' using a
>> different grouping schema, but then, we are being too strict in the way
>> we allow users to define their tax groups...
>>
>
> I don't understand your example.
> For me a party that was prevously without correct VAT number and now it
> has a good one, you just need to change the tax rule on it.
>
>
For my use case, I guess we should add the tax group change in the same
use case of, for instance, VIES checking, I'm not fully convinced that
such solution is the best one, but yes, that works.
Cédric Krier
> >>>> I am sure that there is a better solution.
> >>>> Why did you put this constraint that tax rule can only replace a tax
> >>>> with an other one of the same group? i can understand this in the view
> >>>>
> >>>>
> >>> Because for me it doesn't make sence to replace a VAT on product with a
> >>> VAT on service.
> >>>
> >>>
> >> Wouldn't it make sense, for instance, when you have EU taxes group,
> >> inland product group ?
> >>
> >> So depending on the type of customer, you could use either an EU tax or
> >> an inland one?
> >>
> >> The best example is when you issue an invoice to a customer in another
> >> EU country which doesn't validate in the VIES system, you should handle
> >> that as an inland sell, but some days later, that same customer would be
> >> in the special EU tax group. I know this would be 'fixed' using a
> >> different grouping schema, but then, we are being too strict in the way
> >> we allow users to define their tax groups...
> >>
> >
> > I don't understand your example.
> > For me a party that was prevously without correct VAT number and now it
> > has a good one, you just need to change the tax rule on it.
> >
> >
> For my use case, I guess we should add the tax group change in the same
> use case of, for instance, VIES checking, I'm not fully convinced that
> such solution is the best one, but yes, that works.
I don't think it is well to change automaticly the tax rule of a party
after running the VIES check wizard. As it is an important change, I
prefer to let the user decides if this check is enough.
tim...@virtual-things.biz
I first looked on my old prototype account_tax_system_de and i found
that i have a product tax category there.
For me tax groups are something like:
* vat
* petroleum tax
* tobacco tax
* taxes on alcohol
I use product tax category on product and first i thought it is like
the actual solution in tryton.
But for me product tax categories are more like different types of
products as they are handled different for taxes.
So for me product tax categories are:
* normal products
* new cars
* normal services
* transportation services
* services having to do with a piece of land
Why? Because all these categories are handled different for vat.
I also thought about if these categories could be used for other taxes
and yes i am sure that it is possible.
So i propose to put a field tax category on product and not to use tax
group as i thought first.
The rules should depend on this new field. The dependency on the tax
group is not necessary in my eyes.
I also found a solution for the question of cedric which tax should be
used when there is no tax rules found.
Now i think that it is correct that default taxes are on product but i
propose to use them as fallback but not as selection dependency.
We should first try to find a tax in tax rules and if there is no
match the default tax should be used.
What do you think about?
Rgds
Timitos
tim...@virtual-things.biz
For this solution perhaps taxes on rule must be a one2many relation
like it is on product.
Cédric Krier
>
> I thought about this topic again and i found some points to discuss.
>
> I first looked on my old prototype account_tax_system_de and i found
> that i have a product tax category there.
>
> For me tax groups are something like:
> * vat
> * petroleum tax
> * tobacco tax
> * taxes on alcohol
>
> I use product tax category on product and first i thought it is like
> the actual solution in tryton.
> But for me product tax categories are more like different types of
> products as they are handled different for taxes.
> So for me product tax categories are:
> * normal products
> * new cars
> * normal services
> * transportation services
> * services having to do with a piece of land
>
> Why? Because all these categories are handled different for vat.
So you think the system with only VAT in mind.
> I also thought about if these categories could be used for other taxes
> and yes i am sure that it is possible.
What about different kind of categorisation for an other tax?
> So i propose to put a field tax category on product and not to use tax
> group as i thought first.
> The rules should depend on this new field. The dependency on the tax
> group is not necessary in my eyes.
Don't forget that the account module doesn't depend on product module.
> I also found a solution for the question of cedric which tax should be
> used when there is no tax rules found.
> Now i think that it is correct that default taxes are on product but i
> propose to use them as fallback but not as selection dependency.
> We should first try to find a tax in tax rules and if there is no
> match the default tax should be used.
I find that it is never good to have fallback with different kind
fields.
> What do you think about?
I think that you try to have the tax system closer to the VAT.
So you try to have a system that select taxes to apply and what we have
now is a system that modify the default taxes.
Both are possible and it is just a matter of choice.
For me here is the pro/cons:
- Select system:
- pro:
- "could" perhaps express VAT rules like many people understand it
- cons:
- complex for simple use
- seem very close to VAT system
- "could" perhaps not be extendable to other uses than VAT
- add a double selection on product for tax groups and taxes
- Modify system:
- pro:
- can be used without any rules, groups
- extendable by module for any imaginable cases
- very generic
- define taxes on product like many people understand it
- cons:
- "difficult" to understand for complex use
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
tim...@virtual-things.biz
On 4 Apr., 19:09, Cédric Krier <cedric.kr...@b2ck.com> wrote:
>
> > I thought about this topic again and i found some points to discuss.
>
> > I first looked on my old prototype account_tax_system_de and i found
> > that i have a product tax category there.
>
> > For me tax groups are something like:
> > * vat
> > * petroleum tax
> > * tobacco tax
> > * taxes on alcohol
both systems.
> > I use product tax category on product and first i thought it is like
> > the actual solution in tryton.
> > But for me product tax categories are more like different types of
> > products as they are handled different for taxes.
> > So for me product tax categories are:
> > * normal products
> > * new cars
> > * normal services
> > * transportation services
> > * services having to do with a piece of land
>
> > Why? Because all these categories are handled different for vat.
>
> So you think the system with only VAT in mind.
> > I also thought about if these categories could be used for other taxes
> > and yes i am sure that it is possible.
>
> What about different kind of categorisation for an other tax?
> > So i propose to put a field tax category on product and not to use tax
> > group as i thought first.
> > The rules should depend on this new field. The dependency on the tax
> > group is not necessary in my eyes.
>
> Don't forget that the account module doesn't depend on product module.
extension of the rule system.
The field tax category should be added to the tax rules with the
module account_product.
With this change my idea also works with the modify system.
You add the default taxes to the products as it is now.
You can optional add a product tax category.
The rules will be extended.
So there is a rule like "If tax group is 'VAT' and product tax
category is 'new car' then ...
So this way you can create tax rules with product tax category or
without it.
> > I also found a solution for the question of cedric which tax should be
> > used when there is no tax rules found.
> > Now i think that it is correct that default taxes are on product but i
> > propose to use them as fallback but not as selection dependency.
> > We should first try to find a tax in tax rules and if there is no
> > match the default tax should be used.
>
> I find that it is never good to have fallback with different kind
> fields.
>
> > What do you think about?
>
> I think that you try to have the tax system closer to the VAT.
a necessary field in my eyes.
It makes the selection for the tax group 'VAT' more precise.
With my changes from above it is now an optional field. For other tax
groups it can be ignored.
> So you try to have a system that select taxes to apply and what we have
> now is a system that modify the default taxes.
>
> Both are possible and it is just a matter of choice.
>
> For me here is the pro/cons:
>
> - Select system:
> - pro:
> - "could" perhaps express VAT rules like many people understand it
> - cons:
> - complex for simple use
simple use you would only need one rule in most cases.
> - add a double selection on product for tax groups and taxes
not needed on product. Only tax groups.
The tax to select does not only depend on the product but on many
other attributes. The product is only one attribute for the tax case.
And this is why i do not think that it is correct to put taxes on
product.
This issue is also considerable for the modify system.
> - Modify system:
> - pro:
> - can be used without any rules, groups
> - extendable by module for any imaginable cases
> - very generic
> - define taxes on product like many people understand it
complain:
'Why do i need to create sames taxes twice or more times?'
This solution makes the manual selection of taxes more difficult.
> - cons:
> - "difficult" to understand for complex use
>
How can i add a tax which is not needed in default cases?
Perhaps a tax that i only have to pay when i send a product to a
special country for example.
Cédric Krier
> > So you try to have a system that select taxes to apply and what we have
> > now is a system that modify the default taxes.
> >
> > Both are possible and it is just a matter of choice.
> >
> > For me here is the pro/cons:
> >
> > - Select system:
> > - pro:
> > - "could" perhaps express VAT rules like many people understand it
> > - cons:
> > - complex for simple use
> I don´t think that this system would be complex for simple use. For
> simple use you would only need one rule in most cases.
So still more complex than no rule.
> > - seem very close to VAT system
> With my changes from above it will be more generic again.
No, because as you said, you create a field only for VAT.
> > - "could" perhaps not be extendable to other uses than VAT
> > - add a double selection on product for tax groups and taxes
> This is only because i tried to find a compromise. For me taxes are
> not needed on product. Only tax groups.
> The tax to select does not only depend on the product but on many
> other attributes. The product is only one attribute for the tax case.
This is the first attribute, you can add other on tax rule with modules.
> And this is why i do not think that it is correct to put taxes on
> product.
Most of the time people think about substitution of taxes and not
selection of taxes.
Like:
"The customer has a valid VAT number, so he doesn't pay VAT."
Instead of:
"The customer has a valid VAT number, so I must select a VAT of 0%."
> This issue is also considerable for the modify system.
> >
> > - Modify system:
> > - pro:
> > - can be used without any rules, groups
> > - extendable by module for any imaginable cases
> > - very generic
> > - define taxes on product like many people understand it
>
> But only for simple use. In other cases I already hear our customers
> complain:
> 'Why do i need to create sames taxes twice or more times?'
> This solution makes the manual selection of taxes more difficult.
I don't think you must create several times the same taxes.
Two taxes are not the same if they only have the same rate, it is the
all rate, accounts, codes, sign.
In Belgium, we have different tax code for product VAT and service VAT,
etc... which looks like we must create many times the same taxes but in
fact they are different. And I'm pretty sure this is the case in other
countries.
>
> > - cons:
> > - "difficult" to understand for complex use
> >
> There is one question to your modify system:
> How can i add a tax which is not needed in default cases?
Yes, you are right. I will add a call to tax.rule.apply with no group
and allow to function to return more than one taxes.
> Perhaps a tax that i only have to pay when i send a product to a
> special country for example.
--
tim...@virtual-things.biz
Cédric Krier
> Yes, you are right. I will add a call to tax.rule.apply with no group
> and allow to function to return more than one taxes.
>
I have pushed the changeset. So now group are no more required and there
is a call on invoice, sale, purchase for empty group.
And I have also improved the return value of apply function to return a
list of taxes instead of only one tax ids. This will allow to extend the
tax rule to replace one tax with many taxes.