[Web-erp-developers] Re: Latest

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

A few more thoughts about tax calcs. Sherif may like to cut in here too -
although I think we have decided to go only half way on the OA solution ie
not Tax groups with mutiple tax rates per line as this is not applicable in
many enviroments. We are really only looking at as many different rates as
the user wishes for a tax authority depending on the item being sold.

With the additional table I described for TaxAuthLevels - recapping with
another field I thought of !

TaxAuthLevelID - unique id for the record - primary key - to be held against
each stock movement - the tax authority to be stored in the DebtorTrans /
SuppTrans
TaxAuthority - related to the tax authority recorded in the customer
branch - GL codes extracted from the Tax Authority record
TaxAuthLevelDescription VarChar(20)  (zero rated, taxable supplies, exempt
or some such)
LevelCode TinyInt  - the tax level to be held against the stock item (stock
item gives us finer control over tax than stock categories)

The rate is then determined from this table using the StockMaster -
TaxLevelCode - a new field in stock master and the TaxAuthority from the
CustBranch table - already there. There is a unique entry in the above table
for the Level. We will need a new script perhaps linked from the Tax
Authorities page that enables the input of the levels of tax applicable to
the Tax Authority at the levels existing in the StockMaster TaxLevelCode for
all parts. Perhaps these could be created automatically when a new
TaxAuthority is created with 0% for all levels and be available for editing
the rates only. The stock.php script will also need to allow entry of the
tax level - if the level does not exist in the table above for all
TaxAuthorities it will need to be created. If the item is changed to a
different level then if no other stock items need this level then the
TaxAuthLevel that was defined for this part should then be deleted. -
referntial integrity rules to ensure when looking up a tax rate one can
always be returned. perhaps the TaxAuthLevel in the stock master can only
contain 1 to 4 to limit the ability to stuff up!!

We need 2 additional fields in StockMoves - the TaxAuthorityLevel and  the
TaxRate - or maybe just one the rate - we dont need to store the amount
since the price x quantity x rate will do the trick.

All scripts that create invoices or credit notes need to be updated to
obtain the correct tax rate. 2 credit note scripts and one invoice script.
Perhaps a function in SQL_CommonFunctions.inc that takes the StockID and the
TaxAuthority the DebtorNo and the BranchCode (probably a db pointer too) -
returning an array of the Level Description and the rate. I normally like to
minimise the round trips to the sql server by getting all the information
required in one bite - even though the SQL can get a little tricky.
Unfortunately, this process we are considering will mean several extra trips
to the database for information - one for each line item - but its all for a
good cause. The existing SQL that gets the rate will need to be modified in
each of these scripts. The field for TaxRate in TaxAuthorities can now be
dropped too. Each script will need the creation of stock movements to be
amended with the rate and the TaxAuthLevel code. Invoice/credit note pages
for pdf and html versions will need mods too, to show tax on each line and
accumulate the total. The ConfirmDispatchInvoice.php script will need to
allow manual over-ride of tax calculations at the line level. The manual
entry in total would no longer be appropriate.

GL integration may be interesting it would be nice to consolidate the tax as
one entry per invoice ... I think ? rather than a gl entry for every line on
every invoice may be going overboard?? This would probably mean that the GL
integration could be left alone once the total tax is accumulated into one
total.

This whole tax thing, is a serious blue in the fundamental design really.
Sorry chaps!!

Phil

----- Original Message -----
From: "Stins, D.R." <d.r...@wo...>
To: <ph...@du...>
Sent: Wednesday, February 04, 2004 12:35 PM
Subject: Re: Latest


> Phil,
>
> Thanks.  I develop still at window2 2000, because I do not yet have a
> machine for linux.
> I use ultimate zip (freeware/adware). I handles bz2 fine.
>
> For the VAT/TAX development, when we agree the design/functionality to
> implement + the datamodel, I would be pleased to implement this or develop
a
> prototype. It would be a good excercise to get familiar with lots of
web-erp
> scripts.
>
> Did you receive my first proposal/brainwave for VAT implementation?
>
> When you want a complicated version, we can consider a datamodel with vat
> per regions, vat per subregions, rate per region, vat codes, cross
reference
> region vat code + product. And ofcourse several complicated not very easy
to
> understand relations between those entities. Ofcourse is this much harder
to
> implement.
>
> I also read the information of Sherif. For The Netherlands, we probably do
> not need taxgroups. We only have two tax groups. VAT and other tax. May be
> is the current tax type good enough, because like you said, you can join a
> gl account automatically.
>
> With best regards,
>
> Dick Stins
>
> ----- Original Message -----
> From: "Phil Daintree" <ph...@du...>
> To: <DR...@Zi...>
> Sent: Tuesday, February 03, 2004 9:59 AM
> Subject: Latest
>
>
> > Hi Dick,
> >
> > Here is the latest... there is some work on the EDI - and the bug
fixes -
> > excluding the contract link - this script is yet to be written. No tax
> > developments yet  - this will be after EDI.
> >
> > Not sure if you develop in windows or linux - assumed linux bz2 its the
> best
> > compression.
> >
> > Phil
>
>