Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Wiki Change:

omfgppc
2009-02-27
2013-03-08
  • omfgppc
    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 ||
      =