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:

  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 data usi=
ng the field based paradigm would have to be converted in sales orders, inv=
oices and sales history to complete this transition. In large databases thi=
s 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 ob=
stacles will make upgrading to this version a substantial task for some use=
rs. In order to defray that effort it will be necessary to support the lega=
cy structure for at least one version and provide a mechanism to convert da=
ta and report structures over extended period while still being able to use=
the system with the new method moving forward.
  =

  =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 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.
+ 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 combination of tax, and that reporting on any speci=
fic 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 map=
pings 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 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.
+ 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 assignments will allow the mapping of =
multiple tax codes to a tax authority and tax type pair. This will effectiv=
ely allow tax types and subsequent transactions to support as many tax code=
s and rates as are needed. It will also allow tax codes that are common thr=
oughout a given country or region, such a VAT, to be reusable on many tax t=
ypes 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 a=
mount.
+ The ability to define tax rate effective and expire dates will be added t=
o tax code maintenance so that users may define effective and expiration da=
tes in much the same way they are defined for currency exchange rates. User=
s will also be able to define tax rates that are either a percentage or a f=
ixed 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 b=
e referenced to determine G/L account to debit for the amount specified.
+ Voucher functionality will be extended include a designated 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 b=
e 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 amoun=
ts will be netted to provide easy calculation of net VAT tax due for tax co=
des that are VAT or work like VAT tax. The summary report will provide an o=
ption to drill down to a detail display of supporting detail for both sales=
and purchasing tax data.
+ The sales tax summary report will be modified so that it may consolidate =
both 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 sale=
s and purchasing tax data.
  =

  =3D=3D Window Changes =3D=3D
  =3D=3D=3D Tax Assignments =3D=3D=3D
@@ -101, +101 @@

  =3D=3D=3D Tax Code Rate =3D=3D=3D
  {{attachment:taxCodeRate.png}}
  =

+ =3D=3D=3D Sales Order Item, Select Billing Quantity, Invoice Item, Return=
Authorization Item and Credit Memo Item =3D=3D=3D
+ The tax code widget will be removed from these windows.  The tax type wid=
get will remain and the tax type id is the value that should be saved at th=
e line item level.
+ =3D=3D=3D Tax Detail =3D=3D=3D
+ The tax detail window appears when clicking on the tax hyperlink on the s=
ales order item, select billing quantity, invoice item, return authorizatio=
n item and credit memo item windows. It also can be navigated to from the t=
ax breakdown window.  The tax detail window should be converted to use an x=
treewidget list as picture to present all the tax codes that apply to a sel=
ected item, or to the entire order depending on the context.
+ The amount listed should be in the currency of the source document with t=
he corresponding currency symbol in the header.
+ {{attachment:taxDetail.png}}
  =3D=3D=3D Voucher and Miscellaneous Voucher =3D=3D=3D
  {{attachment:voucher.png}}
  =

@@ -160, +166 @@

  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 ||
@@ -169, +175 @@

  =

  =

  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: center=
">'''Description''' ||
+ ||<style=3D"text-align: center;">'''Name''' ||<style=3D"text-align: cente=
r;">'''Description''' ||
  ||!MaintainWhatever-you-call-it ||Can Add/Edit/Delete stuff ||
  ||!ViewWhatever-you-call-it ||Can View stuff ||
  =