Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Wiki Change:

omfgppc
2009-03-10
2013-03-08
  • omfgppc
    omfgppc
    2009-03-10

    tax.
      =

    + =

    + =

       . {{attachment:voucherItem.png}}
      =

    + =

    + =

      =3D=3D=3D Voucher Miscellaneous Distribution =3D=3D=3D
    + =

      In addition to G/L account and expense category, users will now have a th=
    ird option to select a tax code on miscellaneous distributions. The G/L acc=
    ount associated with the tax code will be used to capture the debit amount =
    associated with the tax on the general ledger. Tax code will only be enable=
    d if a tax area has been selected on the voucher.
      =

    + =

    + =

       . {{attachment:voucherMiscDistrib.png}}
      =

    + =

    + =

      =3D=3D Report Changes =3D=3D
    + =

      =3D=3D=3D Summarized Tax History =3D=3D=3D
    + =

      The Summarized Taxable Sales report will be renamed Summarized Tax Histor=
    y. The report should be moved from the Sales > Reports menu to an Accountin=
    g > Tax > Reports menu.
      =

    + =

    + =

       . {{attachment:dspSummarizedTaxHistory.png}}
      =

    + =

    + =

      The report will be expanded to summarize by either tax code or tax type. =
    If tax type or another option is selected as the summary option, the option=
    s to show "All Tax Codes" or "Selected Tax Codes" should be changed to disp=
    lay options relating to the summary.
      =

    + =

    + =

      It is likely that users will want to use this report to reconcile general=
    ledger activity, so an option will be for date basis to be based on the in=
    voice date, which is used currently, or the (G/L) distribution date. If the=
    distribution date is selected, the report will perform an outer join on th=
    e aropen table to determine the distribution date. If no corresponding invo=
    ice record exists (such as the case might be from imported sales history) t=
    he report will use the invoice date of the record even if distribution date=
    is selected.
      =

    + =

    + =

      Users will be able to choose whether to display sales and purchase histor=
    y. If both options are chosen, the report will show totals for sales histor=
    y as it has historically done, and summarized purchase history based on vou=
    cher tax distributions. These two tax figures will be netted to display the=
    net tax due on a given tax code. This functionality is specifically target=
    ed toward users who both collect and pay VAT taxes and must report on and p=
    ay net VAT taxes collected. Columns that display sales data will only be vi=
    sible when the sales option is selected, and columns that display purchase =
    data will only be visible when the purchase option is selected. The netting=
    column will only be visible when both sale and purchase options are select=
    ed.
      =

    + =

    + =

      If sales tax history is being displayed, users will be able to right clic=
    k on a row and drill down to the supporting detail on the Detailed Sales Ta=
    x History window described below. This window will open in a modal state wi=
    th the tax code or type and date options pre-selected and disabled. This be=
    havior will mirror functionality in other places such as the ability to dri=
    ll down to supporting detail in the Recievables Aging window.
      =

    + =

    + =

      Similarly, if purchase tax history is being displayed, users will be able=
    to right click on a row and drill down to the supporting detail on the Det=
    ailed Purchase Tax History window described below. This window will also op=
    en in a modal state with options pre-selected and widgets disabled.
      =

    + =

    + =

      The corresponding printed report for this window should likewise be renam=
    ed and modified to include the additional data points described for the win=
    dow.
      =

    + =

    + =

      =3D=3D=3D Detailed Sales Tax History =3D=3D=3D
    + =

      The Detailed Sales Tax History window will be included to provide support=
    ing detail for the Summarized Tax History report. While it will be able to =
    be accessed by right click drill down from that window, it will also be ava=
    ilable in the menu system under Accounting > Tax > Reports.
      =

    + =

    + =

       . {{attachment:dspDetailedSalesTaxHistory.png}}
      =

    + =

    + =

      The screen shot above shows the report content requirements. The sales hi=
    story (cohist) table and a corresponding tax table will be used to accumula=
    te most of information shown. The rules concerning the date basis will be t=
    he same as the Summarized Tax History described above.  The currency design=
    ated on the right most calculations will be drawn from the tax authoritity =
    designated on the sales history record.
      =

    + =

    + =

      There should be a right click option to drill to the Sales History Inform=
    ation window that is accessible in the same manner from all of the windows =
    found in Sales > Sales Analysis > Sales History.
      =

    + =

    + =

      A printed version of this report should be created to match data elements=
    as shown in the window.
      =

    + =

    + =

      =3D=3D=3D Detailed Purchase Tax History =3D=3D=3D
    + =

      The Detailed Purchase Tax History window will be included to provide supp=
    orting detail for the Summarized Tax History report. While it will be able =
    to be accessed by right click drill down from that window, it will also be =
    available in the menu system under Accounting > Tax > Reports.
      =

    + =

    + =

       . {{attachment:dspDetailedPurchaseTaxHistory.png}}
      =

    + =

    + =

      The screen shot above shows the report content requirements. The vohead a=
    nd vodist tables will be used to accumulate most of information shown. The =
    rules concerning the date basis will be the same as the Summarized Tax Hist=
    ory described above, except that in this case the distribution date is avai=
    lable on the vohead table. The currency listed in the rightmost colum will =
    be that of the tax authority specified on the source voucher.
      =

    + =

    + =

      There should be a right click option to drill down to view the voucher wi=
    ndow from the selected row.
      =

    + =

    + =

      =3D=3D Batch Manager Changes =3D=3D
    + =

      TBA
      =

    + =

    + =

      =3D=3D Usability Considerations =3D=3D
    + =

      Certainly the change of assigning multiple tax codes to a tax type will m=
    ake the application more flexible, and will likely reduce the amount of red=
    undant tax code data. Establishing tax codes associated with tax types shou=
    ld be more intuitive and reporting capabilities by tax code will be much mo=
    re granualr as a result of this change.
      =

    + =

    + =

      Also, the ability to specify tax rate effictivity will make it much easie=
    r to prepare for and administrate tax holidays or tax rate changes.
      =

    + =

    + =

      On the down side, tax set up and control will remain a complex topic, and=
    with some of the new features such a tax rate control and type, will becom=
    e increasingly so.
      =

    + =

    + =

      =3D=3D Problems and Alternatives =3D=3D
    + =

      TBA
      =

    + =

    + =

      =3D Internal Design =3D
    + =

      Now that we have defined ''what'' we have to do and how we think it shoul=
    d look to the user, we can describe the ''internal'' structure of the appli=
    cation. If possible, outline the architecture of the feature implementation=
    here. Then in the sections below describe the changes and additions to the=
    application to create this architecture.
      =

    + =

    + =

      =3D=3D Basic Algorithms =3D=3D
    + =

      Are there particular algorithms required to implement this feature? If so=
    , describe them here.
      =

    + =

    + =

      {{{
    + =

      If you are going to outline a particular algorithm in pseudo-code
    + =

          put it in a programlisting
    + =

          try to limit lines to approximately 80 characters
    + =

          try to limit programming constructs while still being clear about int=
    ent
    + =

      end if // a programming construct that may be unavoidable to maintain cla=
    rity
    + =

      }}}
    + =

      =3D=3D Custom Widget Changes =3D=3D
    + =

      Do we expect to modify existing custom widgets to support the windows des=
    cribed above?
      =

    + =

    + =

      What new custom widgets will we need? Will they be derived from existing =
    widgets? What behavior do we expect from them?
      =

    + =

    + =

      =3D=3D Schema Changes =3D=3D
    + =

      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;">'''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 ||
      =

      =

      =

      =

    + =

    + =

    + =

    + =

    + =

      What privileges do we need?
    + =

      ||||<style=3D"text-align: center;">'''Privileges for feature''' ||
    + =

      ||<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 ||
      =

      =

      =

      =

    + =

    + =

    + =

    + =

    + =

      =3D=3D Stored Procedure Changes =3D=3D
    + =

      What stored procedures do we expect to create, eliminate, or change?
      =

    + =

    + =

      =3D=3D Performance Considerations =3D=3D
    + =

      How will this feature impact the performance of the application overall?
      =

    + =

    + =

      =3D=3D Error Handling =3D=3D
    + =

      What internal errors do we anticipate might occur?
      =

    + =

    + =

      How can we best hide them from the user, prevent them, or fix them automa=
    tically?
      =

    + =

    + =

      =3D QA Considerations =3D
    + =

      Does this feature require any special tools or data to test? Is it testab=
    le (some features may be hard to reach from the user level)?
      =

    + =

    + =

      What are some anticipated areas of concern that require special attention?
      =

    + =

    + =

      =3D Documentation Considerations =3D
    + =

      Is there a significant documentation impact?
      =

    + =

    + =

      Does the feature require a standalone essay or only field-level descripti=
    ons?
      =

    + =

    + =

      =3D Release Considerations =3D
    + =

      What release would we like to target?
      =

    + =

    + =

      What is the potential impact on a release if we don't finish in time?
      =

    + =

    + =

      What happens if we only get some of the functionality done?
      =

    + =

    + =

      Are there any pieces that would be useful on their own?
      =

    + =

    + =

      Are there any dependencies on other features or applications (such as Qt =
    4 or a particular release of OpenRPT)?
      =

    + =

    + =

      What is the anticipated impact on users, particularly those who have cust=
    omized the sources, reports, and database schema?
      =