[Web-erp-developers] Fw: Confirm Dispatch Invoice.php

[Phil D. <ph...@du...>]

Hi Dick,

I dont think it is not a major to change the rates on the day of the change.
The rate at which tax is paid on every invoices is recorded firstly in the
GL and secondly against the stock movement - so I think we have ample
logging of rates used.

Tax Authorities are the authority that collects the taxes. Different
authorities in different countries mainly or different states in the USA. I
don't know how it works in the US but lets say the sales tax in New York is
10% and sales to customers in Michigan attract sales tax at a different rate
payable to a different state tax authority.

In the UK Australia and NZ, the Inland Revenue, Australian Tax Office and
the IRD are the relevant tax authorities. Sales to customers that fall under
the ATO from a company in NZ do not attract any tax - ie exempt export.
However, the same customer who has a branch in Auckland NZ will fall under a
different tax authority the IRD - attracting GST @ 12.5% for the same item
delivered there.

So the tax authority is the factor relevant based on where the branch of the
customer is who is receiving the supply. This is probably stuff that should
go in the manual.

Hope this description of what a tax authority is helps.

Phil

----- Original Message -----
From: "Stins, Dick" <DR...@Zi...>
To: <ph...@du...>
Sent: Monday, February 09, 2004 11:29 AM
Subject: Re: Confirm Dispatch Invoice.php


> Phil,
>
> I think we miss a very important feature. All serious system do have it.
>
> The goverment change rules from time to time.
>
> What happens when a stock item is move from a high to low rate?
>
> What happens when the government decides to change rates?
>
> So what do we need to registrate these changes:
> - historical data! (sometimes called journalling or logging data)
>
> But we do not like slow systems. So we need a small denormalised system.
>
> (I do not yes really understand what a taxauthority is?)
>
> For example:
> Taxauthlevels needs a extra column with a startdate.
>
> Taxauthlevelshist is a new table wich contains all data of taxauthlevels
> (also the current active row, because we
> lose a join condition when we are querying current + historical data).
> The taxauthlevelhist table needs a end date too, because this speeds up
> queries. Also in oracle databases of versions lower than 10g.
>
> For a start, we try never to use historical data, but we need it to be
able
> to audit calculations and ... for ... (you as an accountant should be able
> to tell me why).
>
> When we create a invoice (I guess this is table debtortrans), it will be
> harder, because the VAT tax level is dependent of the date. The VAT level
is
> also dependend of the date.
>
> So to simplify this issue, we should denormalise the VAT calculation. When
> the invoice is created (the date when the order is delivered?), we create
> for every VAT level of the appropriate Taxauthority an extra invoice line
> with the total VAT level amount.
> This prevents us to query in the historical tables to calculate the
invoice
> after a change in the VAT level of the ordered product and/or rate.
> We definitely need to put the VAT amounts per level at the invoice.
>
> I hope you understand my example?
>
> I apologise to be late with this proposal, but unfortunately is my time
> limited.
>
> Where stands GST for?
>
> With best regards,
>
> Dick Stins
>
>
> ----- Original Message -----
> From: "Phil Daintree" <ph...@du...>
> To: <DR...@Zi...>
> Sent: Sunday, February 08, 2004 11:04 AM
> Subject: Confirm Dispatch Invoice.php
>
>
> > Dick,
> >
> > Pls find updated ConfirmDispatchInvoice.php
> > I think this works ok for the line item tax rates.
> >
> > Perhaps invoices/credits should show the line item GST rates and amounts
> too??
> >
> > I have dropped the field in TaxAuthorities that holds the taxrate. As
all
> tax
> > rates should now come from TaxAuthLevels taxble.
> >
> > Still have to work through the two credit note scripts - and then
> > suppliersinvoices....
> >
> > Phil
>
>