Release Notes #

New Features


Admin Refund Levy Legislative Change (courtesy of client Subject Matter Expert)

At levy certification, a receivables account is created where levy proceeds are deposited. However, during the year, taxpayers can qualify for exemptions which reduce the receivables account.

Under the old law, when a taxpayer qualified for an exemption after levy certification, the county was required to track the dollars refunded to the taxpayer and the district was allowed to re-levy for that same amount the next year in what’s called an “administrative refund” levy. This stays the same under the new law.

Under the new law, tax districts have more tools to allow them to recover reductions to their receivables account. Before, actual dollars had to be refunded to taxpayers before the county could track them for re-levying. In a situation where a taxpayer qualified for an exemption before they actually paid any taxes, the district’s receivable account would still drop, but there were no actual dollars refunded and therefore no chance to re-levy for the reduction.

Now, the law is to keep track of any additions or subtractions to a district’s receivables account but don’t actually result in a refund of taxes. These changes are netted together and if they result in a net reduction to the district’s receivables account, the net reduction can also be re-levied next year.

Modify the existing Refund Levy configuration with an option to adjust the administrative refund levy budget amount (levy.budget_amount) as described below.

Where tax due ‘cancellations’ represent a value greater than ‘supplements’

‘Cancellations’ represent a decrease in tax due

‘Supplements’ in this context represent an increase in tax due

Activities > Levy > Generate Refund Levy > Add


NOTE: Selecting the new option will increase the processing time required in the wizard for this step.

NEW columns in the wizard grid:

Sum of Adjustments – described below

Adjusted Refund Levy – comparison detailed below

Difference – difference between Total Refund Amount and Adjusted Refund Levy


Modify the Refund Levy Accept process:


If refund levy NEW option ‘Calculate Adjusted Refund Amount’ is selected

Select Budget Received check box

Populate Budget Received Date with current system date

Populate Budget Amount from NEW comparison calculation detailed below

If NEW option ‘Calculate Adjusted Refund Amount’ is unselected, the Accept process will behave as exists today updating the check box, budget data and budget amount with the total refund amount column

The Un-Accept process will behave as exists today:

Uncheck Budget Received check box

Clear Budget Received date

Clear Budget Amount

Modify report from ‘Print’


Include Columns:

Sum of Adjustments

Adjusted Refund Levy


Include total for columns:

Refund Amount

Adjusted Refund Levy


Comparison Calculation for determining refund levy budget in the Refund Levy configuration selection options as detailed above:

Using the existing process, Determine Refund Amount per taxing district levy (refund levy)

Sum of Adjustments

Sum total decrease in tax due (-) and total increase in tax due (+)

This should be similar to the calculation performed in PACS for:

  • Fiscal YTD Recap Report Adjustments column
  • Fiscal YTD Summary Report Adjustments row

Criteria for adjusting the Refund Levy/ Budget Amount:

Only negative sum of adjustment amounts per tax district are considered

Compare negative sum of adjustment to total refund amount per tax district (this should be the refund amount + additional amount as listed in the refund levy wizard dialog)

  • If absolute value of (–sum of adj) > total refund amount (refund amount + additional amount)
  • Indicate Adjusted Refund as absolute value of (–sum of adjustment)
  • Otherwise, use existing total refund amount

When the user selects the NEW option to Calculate the Adjusted Refund Levy, Populate Tax District Levy Data Budget fields for districts associated to the selected refund levy configuration: (follow existing procedure as when refund levy is accepted)

Budget Amount fields cannot be updated if associated levy certification run is Accepted

If the Budget Amount is updated by the process, the user should still be able to edit the Budget Amount field after the process is completed until the levy run is accepted.

The User is still responsible for setting the ‘Verified’ flag

  • If ‘Verified’ flag is set on the levy details (by a user) when this new process is completed, the ‘Verified’ flag will be un-checked.
  • The user will need to review the levy details following the completion of the new process and be able to re-check the verified flag.

Electronic REET Import Enhancements

Process Overview

Enhancements have been made to the electronic REET import webportal option. The modifications coincide with a project to allow integration with a specific vendor, SimpliFile. The vendor may be referenced in the description below but the webportal option is NOT intended to be vendor specific. Coordination between the vendor and Harris Govern/True Automation is required before the E-REET webportal option can be initiated.

The E-REET import in PACS is intended to reduce manual data entry of affidavits, while allowing a level of integration between PACS and a vendor. The Vendor provides affidavit data by updating the interface tables with a provided stored procedure, and then runs validation stored procedures on the affidavit data. This happens before the data is available to PACS and the user. Once the data is validated, the PACS processes can begin.

The following tables are used by PACS REET web Portal Import processing.

Temporary Tables: Temp tables store records before saving into the physical Interface tables.

  • ##reet_webportal_import
  • ##reet_webportal_import_property
  • ##reet_webportal_import_account

Physical Tables: Interface tables used by PACS for Web Portal Import.

  • reet_webportal_import
  • reet_webportal_import_property
  • reet_webportal_import_account

The following PACS stored procedures are required to validate and insert records into the REET WEB Portal Interface tables. See APPENDIX

  • [1] REETWebPortalPropertyValidate.sql
  • [2] REETWebPortalInsert.sql
  • [3] REETWebPortalImportPropertyInsert.sql
  • [4] REETWebPortalImportAccountInsert.sql
  • [5] REETWebPortalSave.sql
  • [6] REETWebPortalPurge.sql
  • [7] REETWebPortalDeleteRejectImportRecords.sql

The following PACS stored procedure is needed to retrieve the excise data of completed REET Records.

  • [8] REETWebPortalImportQuery.sql

The client user will process the REET records through the PACS software application.

The vendor will access the interface tables for rejected status or final excise information.

PACS User Pre-requisites

Request functionality be activated by Client Services

Set user right for REET Import Reject code file maintenance


Create REET Import Reject Code(s)


Create REET Status Code with NEW ‘disabled’ attribute


Vendor Pre-requisites:

Agency_id is established with the PACS client, will be recognized from the webportal import data on the Affidavit date (agency ID/code = agency ID/unique ID or webportal ID)


Mechanism exists to access and populate interface tables using required stored procedures below

Reject reasons/codes and actions required are coordinated with client (client user will select from these codes as necessary on records needing additional information or processing)

Login for client users match username in PACS software application (client will determine whether to use this to process packets imported from vendor application)

Processing Records


1) Collect REET data

2) Validate Data

a. Validate Property IDs are valid PACS property IDs.

i. Error – Property doesn’t exist for the given id in Year XXXX

1. Resolve error, Purge and re-insert

2. Or create new webportal ID with corrected data

ii. No error – continue to PACS UI Import

b. Validate there are valid PACS properties for the input GEO IDs.

i. Error – Property doesn’t exist for the given id in Year XXXX

ii. No error

c. Validate all properties have the same location code.

i. Error – Location Code: XXXX Do not Match. Multiple properties are only allowed where the resulting distribution of funds is consistent; i.e. City or County.

ii. No error

d. Validate all properties have the same Urban Growth code.

i. Error – Urban Growth Codes do not match.

ii. No error

1) Insert Data

  1. Web Portal
  2. Account – new validation added to check phone number format, numeric only to remove dashes
  3. Property
  4. Save

4) Retrieve Excise Data – The presence of an excise number along with a ‘Completed’ status in the interface table will serve as a trigger for the vendor to retrieve the completed Excise data.

Processing Records


1) Open PACS > Activities > Electronic REET Processing


  1. > Select Web Portal – this option is only available when records exist in the interface tables (inserted by the vendor)
  2. > Enter Criteria

i. Date Range

ii. User, if system setting is set to allow limiting by username


c. > Ensure Mapping Key is selected; e.g. Property or Geo ID (default setting is available in PACS.Admin)

2) Review Search results

a. A ‘Print Rejected Records’ button will be added to the Import Records List Grid. Click this button to print the report before leaving this dialog. The report will print a list of Import records having the ‘Reject’ checkbox selected.

b. The existing column name ‘Taxable Selling Price’ on REET Import Grid is misleading, value displayed is ‘Gross Selling Price/Sale Price’, not ‘Taxable Selling Price’.

i. Gross Selling Price is from Import Data ‘Sale Price’.

ii. Taxable Selling Price is a calculated value on REET Sale Information Paragraph, not stored in the Database table [reet]. Taxable Selling Price = Gross Selling Price – Personal Amt – Exemp Amt

iii. The column name ‘Taxable Selling Price’ is changed by this project to ‘Sale Price’, and the value of ‘sale price’ is printed to the Import Reject report.

c. When values of ‘Instrument Type’, ‘Sale Date’ or ‘Sale Price’ are changed by user from the REET Detail Dialog, the changed values do not show on the Import Grid. This project will modify the Import Grid to display the changed value, and the changed value will be printed to the report instead of the original values from import data.

d. The first column of the Import Grid has been modified to display the ‘Web Portal ID’ from the Web Portal Import Data. The replaces the current display of a sequence number starting from 1 for the Web Portal Import. A flat file import displays a unique identifier in this column.


3) Verify EREET records – all records must be verified or rejected. The user will receive a warning.


a. Not verified-user MUST verify or reject

b. Verify & Reject

i. Use Reject Code


i. Print Report – each rejected record will display with the following columns. This report will only be available while the dialog is open for this import. Once the user advances to the next action, the report will not be available to reprint.

  2. Agency ID
  3. Instrument Type
  4. Sale Date
  5. Sale Price
  6. Reason rejected/ action required


i. Vendor will need to

  1. Purge, Delete and re-insert using stored procedures before re-import
  2. Or create new webportal ID with corrected data to re-import
  3. c. Verify and Pass


4) Select Action

a. Create REET only

i. Disable-select status where new attribute is selected.

  1. Must SAVE in order for disable to take effect
  2. Cannot undo ‘Disable” on a reet record
  3. Disabled records will not be included in the REET DOR Export


4. Once disabled, the following would not be allowed:

  1. Save/Cancel
  2. Calc Escrow
  3. Calc Excise
  4. Pay Excise
  5. Pay H1/Next
  6. Pay Full
  7. Validate Slip
  8. Generate Excise Number
  9. Changing any drop down selection on Excise Information panel
  10. Selecting options on Sale Information & Excise Due

i.Personal Property Included

ii.Exemption Claimed

iii. Gross Selling Prince

k. Modifying Property Information

i. Add/remove properties

ii. Acreage sold/transferred

iii. Land Use

iv. Metes and Bounds

l. Modifying Grantor/Grantee Information

i. Add/remove Buyer/Grantee

ii. Percentage sold/transferred

iii. Add/remove Seller/Grantor

m. Modifying Land Use – Rollback indicator

n. Modifying Exemption Information – remove exemption indicator

o. Modifying Mobile Home Information – transfer indicator

p. Modifying Recording Information

q. Modifying Events – add/remove/update

r. Modifying Affidavit Data panel

i. REET Data

ii. Property Data

iii. Buyer Data

iv. Seller Data

v. Comment

ii. Continue processing

b. Calculate and Pay Excise Only

c. Calculate Excise and Pay Half Taxes

d. Calculate Excise and Pay Full Taxes

5) Store Images – using PACS image tree

Income Matrix Schedules

In order to utilize the Schedule (Improvement Level) method, Clark will need an additional ‘Data Type’ added to Axis 1 and Axis 2 in the Matrix Maintenance Detail Dialog for Unit Size.


The Data Type button should behave similarly to other units of measure, allowing the user to enter in axis values which will be used to create the matrix. The Matrix will use the values entered for the appropriate axis in the matrix, allowing the user to enter the cell values consistent with current functionality.

Unit Size currently displays in the Income Schedule (Improvement Level) details, once the matrix is built and assigned PACS will reference the Unit Size and compare to the matrix assigned to determine the end result of the matrix calculation.


Helpstar Defect Corrections


The billing information export did not identify payout agreements. This has been corrected.


New agent authorities and mailing type defaults did not have all boxes checked. This has been corrected.


The tax statement message did not appear on statements for accounts that had the SNR exemption added and zero taxes due. This has been corrected.


The Aggregate Levy Limit Calculation was including the refund levy incorrectly. This issue has been resolved.


0 rollback bills were created during the Activate Levy Bills step for rollbacks that were completed in an old prior year. This issue has been resolved.


REET events were not copying properly. This issue has been resolved.


Changes were applied to the Admin Refund Levy per new WA law 5705.


When appraisal\field review cards were generated from the activities menu, deleted properties were not being excluded. This issue has been resolved.


The excise detail report was not including all transactions. This is no longer an issue.


The OCR line on the statement was printing at the top of the 2nd page. They now print on the payment coupon itself.


The system setting for Ignore October 31st Rule when set to True did not calculate taxes correctly based upon this rule. This is no longer an issue.


Printing delinquent notices resulted in an error. This issue has been resolved.


When printing the Field Review Card for properties that are using Marshall & Swift and have multiple improvements, PACS printed all M&S Commercial Calculation Estimate Reports for each improvement. This issue has been resolved.


The Refund levy configuration, specifically the begin date for the refund levy, was allowed to be updated after the refund levy had been accepted. This has been corrected.


The Official Payments URL has been corrected.


Delinquent notices were failing with the error “failed to open a rowset”. This issue has been resolved.


Excise amounts were doubling on the slip receipts. This is no longer an issue.


REET Interest calculations for prior years were incorrect. This is no longer an issue.


When applying escrow to property taxes, the previous payment payee was used to populate the payment record as the payee for the escrow record. The correct payee now populates the field.


The Levy Calculation Summary Reports did not match Final Levy Rate on the Tax District Summary panel. This issue has been resolved.


A data truncation error resulted when running Payment Detail Listing Totals for cash drawers. This issue has been resolved.


REET processing was not taking the taxable value from the correct place. This issue has been resolved.


Outstanding balance reports completed as blank documents. This issue has been resolved.


Computers running Office 2010 were unable to run Letter Processing. This issue has been resolved.


The Amount and Trace fields in the Auto Pay export were not padded with zeros. This has been corrected.


Overpayment credit posting was not defaulting to the correct place. This issue has been resolved.


Tax statements were not calculating the correct amounts. This is no longer an issue.


Payment due dates were updating incorrectly. This is no longer an issue.


When the Generate Refund Levy totals was initiated and generated, the sum of adjustments only captured the general levy current tax year amount. This has been corrected.


The tax statement export for multi coupon, single coupon, and taxpayer did not calculate the correct half total due amount. The Half total due did not include penalty and interest. This has been corrected.

Suggest edit
Last updated on December 7, 2018
Suggest Edit
%d bloggers like this: