omfgppc - 2009-03-04

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