omfgppc - 2009-02-27

You have subscribed to a wiki page or wiki category on "xTuple" for change =
notification.

The "EnhancedTaxInternationalization" page has been changed by jrogelstad:

  Functional Requirements
  =

   * The term "tax selection" should be changed to "tax assignment."
-  * The relationship tax assignments to tax codes should be one to many.
+  * The relationship of tax assignment to tax codes should be one to many.
   * Tax rates should have effective and expiration dates.
   * Tax rates should able to be defined as percentages or fixed currency a=
mounts.
   * Add the ability to identify miscellaneous distributions on vouchers as=
tax distributions.
@@ -50, +50 @@

   . '''Tax Rate'''
    * A tax rate determines the amount of tax that a tax item collects. The=
amount may be a percentage or a fixed amount. Tax rates have effective dat=
es and many can be associated to one tax item. However, only one rate may b=
e effective in any given date range.
  =

- =

- =

  =3D=3D Related Existing Functionality =3D=3D
  The new functionality described in this document builds on existing funct=
ionality described in TaxBasics.
  =

  =3D=3D Similar and Related Requests =3D=3D
- [[http://www.xtuple.org/mantis/view.php?id=3D3075|3075]]  Tax calculation=
needed on PO.
+ [[http://www.xtuple.org/mantis/view.php?id=3D3075|3075]] Tax calculation =
needed on PO.
  =

  [[http://www.xtuple.org/mantis/view.php?id=3D3148|3148]] Voucher ignors P=
O Freight/Tax.
  =

- [[http://www.xtuple.org/mantis/view.php?id=3D5158|5158]]  No tax on Misc.=
Charge.
+ [[http://www.xtuple.org/mantis/view.php?id=3D5158|5158]] No tax on Misc. =
Charge.
  =

  [[http://www.xtuple.org/mantis/view.php?id=3D8244|8224]] Purchase VAT rep=
ort
  =

  [[http://www.xtuple.org/mantis/view.php?id=3D8274|8274]] Add tax calculat=
ions to purchase orders.
  =

- [[http://www.xtuple.org/mantis/view.php?id=3D8411|8411]], [[http://www.xt=
uple.org/mantis/view.php?id=3D8496|8496]], [[http://www.xtuple.org/mantis/v=
iew.php?id=3D8221|8221]]  Rounding problems on tax calculations
+ [[http://www.xtuple.org/mantis/view.php?id=3D8411|8411]], [[http://www.xt=
uple.org/mantis/view.php?id=3D8496|8496]], [[http://www.xtuple.org/mantis/v=
iew.php?id=3D8221|8221]] Rounding problems on tax calculations
  =

  =3D=3D Conflicting Features =3D=3D
  This specification will call for creating a one to many relationship betw=
een tax types and tax codes which is a major paradigm shift from the curren=
t 3 element A, B, C field code method. Tax codes will be specified to only =
include only one G/L Account mapping. A large amount of historical using th=
e field based paradigm would have to be converted in sales orders, invoices=
and sales history to complete this transition. In large databases this wil=
l likely require substantial upgrade time. In addition, a complete switchov=
er to this methodology will likely "break" existing reports and forms that =
users have customized that rely on existing tax calculations. These obstacl=
es will make upgrading to this version a substantial task for some users. I=
n order to defray that effort it will be necessary to support the legacy st=
ructure for at least one version and provide a mechanism to convert data an=
d report structures over extended period while still being able to use the =
system.
  =

  =3D User-Level Functionality =3D
- The most glaring problem with the existing tax structure is that 3 tax el=
ements are had coded into every tax code, and only one tax code may be refe=
renced in a transaction.  This creates two problems: 1) It limits the numbe=
r tax items to 3 per transaction and 2) tax rates within codes are generall=
y not resuable.  If there are two tax authorities that collects the same VA=
T and separate local taxes, and the VAT component is recorded as the "A" ra=
te, the VAT component is not shared between codes. So while the tax selecti=
ons mapping system should ideally allow the flexibility to reduce the numbe=
r of tax types and tax codes, the hard coding of the A, B, C fields all but=
ensures that tax codes will proliferate for every possible comination of t=
ax, and that reporting on any specific element A, B, or C is both limited a=
nd fallible.  The only way to ensure an accurate total for a give tax eleme=
nt is to rely on the G/L account mappings to record all transactions for a =
given tax.  Consequently, there is no way to confidently report on supporti=
ng detail.
+ The most glaring problem with the existing tax structure is that 3 tax el=
ements are had coded into every tax code, and only one tax code may be refe=
renced in a tax authority/type mapping and subsequent transaction. This cre=
ates two problems: 1) It limits the number tax items to 3 per transaction a=
nd 2) tax rates within codes are generally not resuable. If there are two t=
ax authorities that collect the same VAT but separate local taxes, and the =
VAT component is recorded as the "A" rate, the VAT component is not shared =
between codes. So while the tax selections mapping system should ideally al=
low the flexibility to reduce the number of tax types and tax codes, the ha=
rd coding of the A, B, C fields all but ensures that tax codes will prolife=
rate for every possible comination of tax, and that reporting on any specif=
ic element A, B, or C is both limited and fallible. The only way to ensure =
an accurate total for a give tax element is to rely on the G/L account mapp=
ings to record all transactions for a given tax. Consequently, there is no =
way to confidently report on supporting detail.
  =

- Tax codes will be altered so that each code has one and only one G/L mapp=
ing.  The existing A, B, C structure will be broken up so that it is record=
based instead of field based, so an existing tax code that had A, B, and C=
percentages will be converted to three distinct tax code records.  Tax Sel=
ection mappings will be renamed Tax  Assignments.  Tax assignements will al=
low the mapping of many tax codes to a tax authority and tax type pair.   T=
his will effectively allow tax types and subsequent transactions to support=
as many tax codes and rates as are needed.  It will also allow tax codes t=
hat are common throughout a given country or region, such a VAT, to be reus=
able on many tax types.
+ Tax codes will be altered so that each code has one and only one G/L mapp=
ing. The existing A, B, C structure will be broken up so that it is record =
based instead of field based, so an existing tax code that had A, B, and C =
percentages will be converted to three distinct tax code records. Tax selec=
tion mappings will be renamed "tax assignments" to more closely follow exis=
ting and similar naming conventions such sales assignments, A/R assignments=
and price schedule assignments. Tax assignements will allow the mapping of=
multiple tax codes to a tax authority and tax type pair. This will effecti=
vely allow tax types and subsequent transactions to support as many tax cod=
es and rates as are needed. It will also allow tax codes that are common th=
roughout a given country or region, such a VAT, to be reusable on many tax =
types thereby limiting the number of total tax codes required.
+ =

+ The ability to define tax rate effectivity will be added to tax code main=
tenance so that users may define effective and expiration dates in much the=
same way they are defined for currency exchange rates.  Users will also be=
able to define tax rates that are either a percentage or a fixed currency =
amount.
+ =

+ Voucher functionality will be extended include a desginated tax authority=
at the header level and a new miscellaneous distribution of type "tax" whi=
ch may be selected along with a corresponding tax code.  The tax code will =
be referenced to determine G/L account to debit for the amount specified.
+ =

+ The sales tax summary report will be modifed so that it may consolidate b=
oth taxes collected on sales and vouchering for a given code.  The two amou=
nts will be netted to provide easy calculation of net VAT tax due for tax c=
odes that are VAT or work like VAT tax.  The summary report will provide an=
option to drill down to a detail display of supporting detail for both sal=
es and purchasing tax data.
  =

  =3D=3D Window Changes =3D=3D
  =3D=3D=3D Tax Assignments =3D=3D=3D