I need to know the changes made to the PARMSDS data structure from v5 to v5.6 in SalesTaxII.
There have been several new fields added to the PARMSDS data structure. In addition several of the
field sizes may be different than the version you currently are running. Any programs on your system that
call the program TCALC will at a minimum need to be recompiled. In addition you may want to load some
or all of the additional parameters.
PARMSDS Field size changes
PCMPY - (From 2A to 5A) This change affects all customers. Field should be left justified. If your
company code is numeric we recommend including any leading zeros.
PCUST – (From 8A to 20A) This field change will affect many of our longtime customers. We recommend
loading this parameter left justified. (The data conversion program will copy the current customer number
in TAXEXEMT and place it left justified and include any leading blanks from the original data. If you have
the current version of this field it will be copied as is.)
PEXMP – (From 12A to 50A) This field change will affect many longtime customers. (The data conversion
program will move all data left justified and include any leading blanks from the original data.)
PARMSDS New Fields
PDIV – Division (5 Alpha). This is an optional parameter for those customers that have reporting
requirements at the division level. No taxing decisions are made based upon this field: it is simply passed
along to the SalesTaxII tax accumulator file (TAXACCUM).
PUNINC – Unincorporated Flag (1 Alpha) This is an optional parameter that identifies to SalesTaxII that it
should process the incoming transaction as an unincorporated transaction. In the past a transaction was
identified as an unincorporated transaction when ‘UN’ was passed in the commodity code parameter
(PCOMC). This worked well unless a customer had a need to calculate a specialty rate in an
unincorporated area as they shared the same parameter. While the ‘UN’ functionality remains, we are
recommending our customers now use the unincorporated flag to avoid any future conflicts.
PSPL – Special Charge Code (3 Alpha) This is an optional parameter that can be used to separate
transactions into separate groups of records in the tax accumulator file. Generally there is one set of
transaction records for each invoice processed regardless of the number of invoice lines (one for each
taxing jurisdiction). Some of our customers have the need to create a separate set of transaction records
for the same invoice to separate tax amounts for detail line items from other special charges like freight. If
a customer wanted to store transactions at the invoice line level it could now be done by using the PSPL
field to hold invoice line number. Keep in mind however this would result in large number of records
written to the accumulator file. If you don’t have that specific need we recommend leaving it blank.
NOTE: If you are currently separating out records and creating a separate group of records you must make a
change for SalesTaxII to continue to split them out. Currently this process is performed by changing an
area in the PACDC field as this field is a key field in the tax accumulator file in version 5 and a change
in its value will result in a new set of records being created for a particular invoice. Starting in V5.5 this
field will no longer be part of the key. The conversion program has the ability to recognize these records
and load the PSPL field accordingly
PCUSNM – Customer Name (25 Alpha) This is an optional parameter to hold the customer name. We
have had several customers inform us it would be nice to see the customer name on SalesTaxII reports in
addition to the customer number. It would be impractical to tie our reports to every client’s customer
master so we have made it a new field that can be passed along when calling TCALC. No tax processing
is based on this field; it is just simply passed along to the tax accumulator file.
NOTE: None of our existing reports use this new field but it will be included as we redesign our current reports
and add new reports in upcoming future releases.
PFEATR – Future Use (256 Alpha) – Not Used, reserved for future development.