openerp-expert-accounting team mailing list archive

[David Mitchell <david@xxxxxxxxxxxxxxxxxx>]

Hi Stefan,

Just to throw an interesting twist into this . . .in some countries the
taxability of a product is not "absolute" and varies based on a number of
factors - which I believe supports your case. In no way, would we be able
to absolutely say a product is taxable/not taxable unless in a very small
selling tax jurisdiction. I can drive 1 mile today from where our offices
are today and experience where a product is taxable at completely different
rates and only one of the factors country, county, state, zip code, city
changes. (mostly city, or county)

In our case the "taxability" assignment of a product depends on the
following typically:

The type of product category a product falls under
AND
The geo-position based assignment of the seller (notice I didn't say
country, state, or in the US zip code). It is a geo-position taxability
matrix assigned independent of address.
AND
if the seller has what is called Nexus in the selling jurisdiction (a legal
taxable presence)
AND
the geo-position of the seller's ship to address
AND
the method of sale (internet, in-store, etc).
AND
the taxability laws active within the tax jurisdiction at that moment in
time
AND
Exemptions in place for the buyer for a unique jurisdiction, for unique
products.

So taxability may be driven by a multifactor formula at a higher level -
that may or may not be in effect at the product level. Category may be an
example of this at a single level above the product. (yes, secretly we wish
for VAT here - but then all the accountants would be out some serious
service dollars which they charge to businesses to manage this).

We would not define a product to be absolutely taxable or not - we would
rather create a function/calculation to determine taxability in a
particular situation based on a "matrix". <-- tracking the matrix is the
hard part - so we don't - we deferred to a callable web service Tax Engine.

For us, this creates a data-mart matrix of about 20,000 unique
(geo-positional) tax jurisdictions in which the product category in where a
product falls (which forces us to do address validation prior to
calculating tax) may or may not be taxable. These also change over time
(for example we get notices all the time (every couple of weeks for minor
changes to several of 100 counties here in North Carolina). In a simple
case of a single retail storefront selling similar goods (e.g. bicycles),
this is relatively manageable and openerp can be configured to support the
tax calculations. In the case of a seller with multiple selling points with
numerous tax jurisdictions - calculation and remittance to legal
authorities are difficult.

*Sorry if this is a long way of saying - taxability only at the product
level doesn't work for some countries, and there should be a configurable
hierarchy or conditional calculation to determine taxability.*

What did we do about this? For the US, if the tax environment/nexus is
complex for a customer we just have OpenERP call a web-service and pass in
the quote, sales order, invoice, refund, etc information  and have the
service calculate the tax situation.
We used AVALARA http://www.avalara.com/avaintegrations/openerp
Avalara then submits the reports to the legal authorities for the clients
as well <-- which is the bigger problem actually.

But, we believe your idea is sound - for what its worth.

David Mitchell
NovaPoint Group


On Mon, Mar 19, 2012 at 4:08 PM, Stefan Rijnhart <stefan@xxxxxxxx> wrote:

> On 19-03-12 20:30, Samer Nefawa wrote:
>
>> The tax is ignored on the sales order itself, on screen or on the PDF
>> version?
>>
>> I will check it tomorrow, didn't face such a problem..
>> Gr s
>>
>>
> Hi Samer,
>
> Yes, you could do that. See the bug report for the exact description. Note
> that the issue was already confirmed by the OpenERP devs and there was a
> patch (again, see the bug report). However, Fabien invalidated the issue
> saying that "if there is not tax on the product, it means that there should
> be no tax in sale or purchase" (in comment #5 [1]), introducing the
> interesting concept of an empty(!) value overriding a default value on a
> higher level.
>
> If you are as surprised as I am, then apparently we agree on the way that
> things are supposed to work and if no one else on the accounting mailing
> list objects then we can ask Fabien to reconsider.
>
> Regards,
> Stefan.
>
>
> [1] https://bugs.launchpad.net/**openobject-addons/+bug/796570/**
> comments/5<https://bugs.launchpad.net/openobject-addons/+bug/796570/comments/5>
>
>
> --
> Therp - Maatwerk in open ontwikkeling
>
> Stefan Rijnhart - Ontwerp en implementatie
>
> mail: stefan@xxxxxxxx
> tel: +31 (0) 614478606
> web: http://therp.nl
>
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> Post to     : openerp-expert-accounting@**lists.launchpad.net<openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~**openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>