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:

  =3D Feature Specification =3D
  =3D=3D Feature Name: Enhanced Tax Internationalization =3D=3D
  =3D Overview =3D
- The existing Tax management system in xTuple 3.0 is designed to be flexib=
le to the extent that it can handle a variety of tax schemes where tax rate=
s and authorities vary from one product and ship to location to another. Ho=
wever, there are limitations in both the tax structure methodology and repo=
rting that make reporting difficult outside the United States without custo=
mization.  The goal of this specification is to add in enough flexibility i=
n tax functionality so that most international tax scenarios can be handled=
without major customization to the software.
+ The existing Tax management system in xTuple 3.0 is designed to be flexib=
le to the extent that it can handle a variety of tax schemes where tax rate=
s and authorities vary from one product and ship to location to another. Ho=
wever, there are limitations in both the tax structure methodology and repo=
rting that make reporting difficult outside the United States without custo=
mization. The goal of this specification is to add in enough flexibility in=
tax functionality so that most international tax scenarios can be handled =
without major customization to the software.
  =

  Functional Requirements
  =

@@ -44, +44 @@

  This is the place to define new words and phrases to be used in the appli=
cation and the documentation. If this feature introduces a new concept or c=
hanges the semantics of an existing concept in the application then define =
it here. Define it even if you think the definition should be obvious, sinc=
e your definition might not match the definition used by the reader, like s=
o:
  =

   . '''Tax Assignments'''
-   * Tax assignments map tax authority and tax type combinations to multip=
le tax codes.  Formerly known as tax selections.
+   * Tax assignments map tax authority and tax type combinations to multip=
le tax codes. Formerly known as tax selections.
   . '''Tax Code'''
-   * A single tax item that includes a G/L account mapping.  Formerly tax =
code contained 3 fixed tax items A, B and C with a single percentage rate.
+   * A single tax item that includes a G/L account mapping. Formerly tax c=
ode contained 3 fixed tax items A, B and C with a single percentage rate.
   . '''Tax Rate'''
-   * A tax rate determines the amount of tax that a tax item collects.  Th=
e amount may be a percentage or a fixed amount.  Tax rates have effective d=
ates and many can be associated to one tax item.  However, only one rate ma=
y be effective in any given date range.
+   * 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
- What other requests have we gotten that might tie in nicely with this fea=
ture?
+ [[http://www.xtuple.org/mantis/view.php?id=3D3075|3075]]  Tax calculation=
needed on PO.
  =

- What open issues might be addressed by this feature?
+ [[http://www.xtuple.org/mantis/view.php?id=3D3148|3148]] Voucher ignors P=
O Freight/Tax.
  =

- Try to create hyperlinks to web-accessible data, such as this link to [[h=
ttp://www.xtuple.org/mantis/view.php?id=3D2949|Mantis issue 2949]].
+ [[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
  =

  =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=
the field based paradigm would have to be converted in sales orders, invoi=
ces and sales history to complete this transition.  In large databases this=
will likely require substantial upgrade time.  In addition, a complete swi=
tchover to this methodology will likely "break" existing reports and forms =
that users have customized that rely on existing tax calculations.  These o=
bstacles will make upgrading to this version a substantial task for some us=
ers.  In order to defray that effort it will be necessary to support the le=
gacy structure for at least one version and provide a mechanism to convert =
data and report structures over extended period while still being able to u=
se the system.
+ 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
- Describe how the new functionality will appear to and behave for the appl=
ication user. To write this properly you will need to jump back and forth b=
etween this section and the Internal Design section.
+ 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.
  =

- Describe the menu changes and overall application structure changes here =
then get detailed in the subsections.
+ 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.
  =

  =3D=3D Window Changes =3D=3D
  =3D=3D=3D Tax Assignments =3D=3D=3D
@@ -148, +156 @@

  What changes do we anticipate making to the database schema? New tables? =
Views? Indexes?
  =

  '''The new whatever-you-call-it table'''
- ||<style=3D"text-align: center;">'''Column Name''' ||<style=3D"text-align=
: center;">'''Description''' ||<style=3D"text-align: center;">'''Data Type'=
'' ||<style=3D"text-align: center;">'''Comments''' ||
+ ||<style=3D"TEXT-ALIGN: center">'''Column Name''' ||<style=3D"TEXT-ALIGN:=
center">'''Description''' ||<style=3D"TEXT-ALIGN: center">'''Data Type''' =
||<style=3D"TEXT-ALIGN: center">'''Comments''' ||
  ||{{{}}}field1 ||Describe me ||data_type ||how it's used ||
  ||foreign_key ||Describe me ||integer ||foreign key to other_id ||
  ||enum_field ||Status or similar field ||character(1) ||Can take one of t=
he following: <<BR>>* A value <<BR>>* Different Value <<BR>>* Final Value ||
@@ -157, +165 @@

  =

  =

  What privileges do we need?
- ||||<style=3D"text-align: center;">'''Privileges for feature''' ||
+ ||||<style=3D"TEXT-ALIGN: center">'''Privileges for feature''' ||
- ||<style=3D"text-align: center;">'''Name''' ||<style=3D"text-align: cente=
r;">'''Description''' ||
+ ||<style=3D"TEXT-ALIGN: center">'''Name''' ||<style=3D"TEXT-ALIGN: center=
">'''Description''' ||
  ||!MaintainWhatever-you-call-it ||Can Add/Edit/Delete stuff ||
  ||!ViewWhatever-you-call-it ||Can View stuff ||
  =