9.0.43 Release Notes

New Features

Delinquent Notice/Statements

In order to have a better idea how long the delinquent notice printing process will take, the current user notification will be modified to indicate what segment is being processed and how many segments are left.

• The message will state:
  • “Generating the report [Processing Segment X of Y]”
• X is the current segment being processed and Y is the total number of segments.

• Delinquent Notices Processing has been enhanced to allow property lists and generation by query.
  • Property selection:
    • All
    • Comma separated Prop IDs
    • Mortgage Codes
    • Property IDs SQL query
    • Comma separated Owner IDs
    • Comma separated GEO IDs

DOR Abstract of Assessed Value Report

During the 2014 Legislative Session two bills were passed that require we make changes to the Abstract of Assessed Values Report:

• SHB 1634 allows taxing districts to increase levying capacity through the construction of solar, biomass, and geothermal facilities. This change is effective for taxes due in 2015.
  • This is similar to the increase allowed for new construction of wind turbine facilities.
  • The value of each type of facility that is added to the assessment roll will need to be documented on page 1 of the Abstract.
• SB 6180 provides the option for counties to merge the timber land classification under chapter 84.34 RCW into designated forest land (DFL) under chapter 84.33 RCW. This change is effective June 12, 2014.
  • If your county chooses to merge these land classifications we will ask you to document that on page 2 of the Abstract.
  • If you answer “Yes” , that DFL includes merged Timber Land, we will expect to see no values listed under #4 (Timber Land) of page 2 of the Abstract.

• New Functionality added in PACS
  • Added new system Config for Combining DFL indicator
    • PACS. Admin > Tools >System Configuration > Reports > DOR Abstract of Assessed Value >Combine DFL and Timber
    • Values (true/False)
    • If set to True, DFL and Timer values shall be merged in DOR Assessed Value Report.

• Add new attribute ‘Facility Type’ to property sub type code file
  • PACS Admin>Tools>Code File Maintenance>Property>Property Sub Type
  • Facility Type combo box (default is NULL)
    • Wind Turbine
    • Solar
    • Biomass
    • Geothermal
    • None

• Modified DOR Assessed Value to report the new values of these Facility
• The Export has also been modified. PACS >Reports>DOR>Abstract of Assessed Value > Check ‘Export File’

Fees

The balance on the Fee Search Result grid was being calculated as the INITIAL_AMOUNT_DUE minus the AMOUNT_PAID which works provided the Fees never ever get adjusted. The calculation has been modified to CURRENT_AMOUNT_DUE minus AMOUNT_PAID.

This emulates the logic being used to display the balance on the FEE grid within the PROPERTY itself so the values between the SEARCH and the PROPERTY should now match.

NOTE: The PROPERTY appears to only display fees which are ACTIVE whereas the SEARCH does not seem to have any such filter so I believe there could be fees in the search results not listed on the property. If so, that could be correct due to the ACTIVE flag.

Improvements

Effective Age

Previously, PACS was using the most current PACS year when determining the Effective Age for improvements regardless of what year you open the property in. There was inconsistency for the effective age calculation between the Recalculation routine and the Improvement user interface. This has been resolved so that:

• Actual Age: [imprv_detail].actual_age
  • use[property_val].prop_val_yr to calculate Actual Age
  • [imprv_detail].actual_age = [property_val].prop_val_yr – [imprv_detail].yr_build
  •  
• Effective Age: [improv_detail].yr.new
  • use [pacs_system_year].depreciation_yr if available, otherwise use [property_val].prop_val_yr to calculate Effective Age.
  • If [pacs_system_year].depreciation_yr THEN
    • [imprv_detail].yr_new = [pacs_system_yr].depreciation_yrr – [imprv_detail].depreciation_yr
    • Else [imprv_detail].year_new = [property_val].prop_val_yr – [imprv_detail].depreciation_yr

Copy Improvement with Adjustments

Previously there were issues when a User attempted to copy an improvement that had more than 1 improvement adjustment. The initial design did not account for scenarios where more than one improvement adjustment could be applied to an improvement or an improvement detail.

As part of this project, the Copy function was redesigned to account for the allowance of multiple improvement adjustments. The following expectations now exist:

1. Copying the improvement and/or improvement detail will NOT retain any RMD (remodel) adjustments which existed at the source
2. Copying the improvement will set the initial base improve_adj_amt to zero and require a recalculation.
3. Copying the improvement detail will set the initial base imprv_det_adj_amt to zero and require a recalculation
4. When supplementing, the copied adjustment and/or improvement detail will retain any RMD (remodel) adjustments which existed at the source.
5.  

Litigation

The module has been modified in reference to the Bill/Fee Code wizard. The wizard now behaves consistently throughout PACS.

• In previous releases, the litigation module required a bill/fee code to be added to a property when added to the litigation.
• In R39, the bill/fee code wizard was modified so that the Bill Code field was not required, and added a NULL/empty item to the combo box
• This modification was not consistent wit the existing bill/fee code wizard used outside of the litigation module

• New Functionality added to Litigation

Add Property to Litigation

• The ‘No Bill Code’ checkbox has been added on this dialog to allow the option of no bill/fee code added.
• If the user checks ‘No Bill Code’, then the bill/fee codes on the property will not change.
• If the user does not check ‘No Bill Code’ the selection will be updated in the database (including BLANK).

Edit Property on a Litigation

• Added “instructional text”
• If the user clicks CANCEL, no change will be made
• If the user clicks OK, then the selection will be updated in the database

Remove Property from Litigation

• Warning message was modified to show modified text prior to “Set Bill Fee Code” dialog
• If the user clicks CANCEL, no change will be made
• If the user clicks OK, then the selection will be updated in the database.

1. Neighborhood Code

An issue was discovered where newly created Neighborhood Code File did not appear in PACS.ADMIN. THis was a result of the Appraiser field not being selected upon creation. The appraisal field was made required in a previous release but not all clients require an appraiser to be assigned to a neighborhood.

To reduce any additional data entry for clients not requiring an appraiser, the Neighborhood appraiser field will now default to the value of ‘Unknown’. The appraiser name of ‘unknown’ may not exist on every client so the following changes have been made:

• A SYSTEM FLAG has been added to the Appraiser table and dialog
• If the UNKNOWN appraiser exists, it will be set to a SYSTEM entry
• If the UNKNOWN appraiser does not exist it will be added as a SYSTEM entry
• A SYSTEM checkbox has been added to the Code File Maintenance Dialog
• Users may not delete SYSTEM appraisers.

Payment Receipt

A detailed receipt for taxable excise transactions displays the property ID. The non-taxable detailed receipt did not. This has been modified.

The REET Excise number is printed next to the FEE Type as:

• Fee – REETStTech: ####
• PACS only prints the first property in the Payment Receipt when multiple properties are associated with REET. This is existing behavior.

Payout Agreement Statement

The Statement has been formatted so that the County Logo displays at the top left and the County address has been added to the bottom of the receipt.

REET

Property Values vs. Sales Year

REET Year association issues have been reported, with several tickets going back and forth on this. The final determination after validating with clients and the DOR, we should use Sales Year.

• Some points in review
  • REET processing should pull the taxable value from the property year layer that corresponds with the sale year.
  • The location validation should be based on the sale year
  • Penalty and interest should be based on the collection year associated to the sale year.
• However, there will be occasion when the year does not exist in PACS.
  • Sale year entered as 1/2/1999, client database only has year 2000 and forward
  • Sale year entered as 2/3/2015, client database has highest appraisal year 2013-2014
• Based on the discussion with the DOR, the timing of the sale versus certification of the assessment year layer is important in reporting the taxable value.
  • Example1:
    • 2014-2015 is certified
    • 2015-2016 is not certified
    • Sale Date: 1/1/2015
    • Value should come from 2014-2015
  • Example 2:
    • 2014-2015 is certified
    • 2015-2016 is certified
    • Sale date: 10/1/2015
    • Value should come from 2015-2016

Due to all of the above, a NEW field ‘REET Year’ has been added to the REET dialog. Changing the REET Year should be a consideration of the user for the specific REET record.

• When the user enters a DATE of SALE, the new field ‘REET Year’ will display the assessment year associated to the sale year.
• If that year is not yet CERTIFIED, then the REET Year will display the most recent certified year.
• This REET YEAR can be changed by the user without impacting the DATE of SALE.
• However; the DATE of SALE cannot be changed without impacting the REET YEAR (assuming the certification years warrant a change).

The property search, addition and verification will then utilize the year visible in REET Year.

• The REET Year indicates the PACS year from which to pull property data. Once a valid PACS year is confirmed or selected by the user and the 1st property is added, the selected PACS year will be used to search for the remaining properties if there are multiple properties associated with the REET.
• If user changes the Sale date or REET Year after properties have been added, a warning will display to the User indicating the property Grid will be cleared. The user will have the options (Yes/No) to continue.

Technology Fee Distribution

Previously, we implemented a workaround for the Statement of Taxes report to accurately display the value of the added line ’12a’. The REETStTech and REETCoTEch are not system codes so if the user changes of deletes these, the report will not display the amount correctly. We’ve changed the following:

• FEE TYPE DIALOG
  • PACS.Admin>Tools>Code File Maintenance, Collections row, Fee Type Details
  • Added Technology Fee Checkbox as well as LOCAL/STATE Radial buttons to set the type
  • Only one Local and one STate Technology fee may exist (radial button and checkbox itself are disabled when not an available option.
• STATEMENT OF TAXES COLLECTED REPORT
  • Line 12 will now only contain STATE TECH FEE values (as configured in the Code File Maintenance)
  • Line 12a will now only contain LOCAL TECH FEE values (as configured in Code File Maintenance)
• DOR EXPORT
  • The <STATE_TECH_FEE> value in teh XML export will now include both the LOCAL and the STATE TECH FEE values as a single listing
• EXCISE DETAIL REPORT
  • The TECH column will include both the LOCAL and STATE TECH FEE values as a single listing.

Refund

Refund Date

The dates associated with processing refunds were inconsistent in PACS which resulted in miscommunication with taxpayers. The Refund Panel displayed date as ‘Posting Date’ (this date is the actual posting date in PACS). The refund disbursements paragraph called this same date the refund date.

The label in the Refund Details Dialog has been changed from ‘Refund Date’ to ‘Posting Date’ to be consistent with the Label on Refund Detail Grid.

Refund Count

When refunds in Mass were being created through the refunds wizard, at the point in the wizard after you select the statements or OPC items to be refunded, and you are presented with the screen for entering the check number and assigning the batch, and if the refund to selection of ‘Current Taxpayer on the Property’ is made, the number of refunds is not displayed. The only time the number of refunds is displayed is when the selections of ‘Taxpayer on Property at Time of Last Payment ‘ or Payer of Last Payment on Property’. The expectation is that the Number of Refunds will populate when any Refund to selection is made.

Split/Merge

Specific functionality in previous releases allows value from land property to be included in Income valuations. The split/merge process was modified to account for additional processing needed for these Income records. A NEW warning message added in R41, related to Income and associated land value properties, did not validate all years to warn user. The user would not want to process one year and not the other.

• Split Wizard
  • This dialog performs some real-time validations when the user changes from one control to another (one field to another). For example if a PROPERTY ID is entered and the user tabs to the next control, then the validation occurs. If the user does not change the control focus the validation is not automatic. The PROCESS button will always perform validations. Regardless of the sequence the user utilizes, the WIZARD will now preclude the user from completing the SPLIT whenever any property has income land for a year listed.
  • Example: Property 12345 has an income_land_detail_assoc record for only the default year 2014
    • Test#1: enter 12345 as the prop ID and hit PROCESS – receive warning “Property 12345 has income land associated value in 2014.”
    • Test#2: enter 12345 as the prop ID and hit TAB or click on any other field – receive warning “Property 12345 has income land associated value in 2014.”
    • Test#3: enter 12345 as the prop ID and hit TAB, changing the year to 2013 and hit PROCESS – should not receive warning message
    • Test#4: enter 12345 as the prop ID and hit TAB, changing the year to 2013 and hit TAB again or click on any other field – should not receive warning message
• Merge Wizard
  • This dialog performs very few real-time validations as the list of “Properties Involved in Merge” is not dynamically reviewed. Adding properties via the SEARCH WIZARD performs most of the validations and it would not be practical to place this code change on such a universally used piece of functionality. Therefore all of my validations occur when the PROCESS button is pressed.
  • Example: Property 12345 has an income_land_detail_assoc record for only the default year 2014
    • Test#1: enter 12345 as the prop ID and hit PROCESS – receive warning “Property 12345 has income land associated value in 2014.”
    • Test#2: enter 12345 as the prop ID, change the year to 2013 and hit PROCESS – should not receive warning message
    • Test#3: really load up the property and year lists with violating properties for the complete list of everything that precludes the MERGE from being PROCESSED.

Supplement Events

Supplemental Events added in R41 have been rolled back. The purpose was intended to allow Client Services access to information without affecting the client user interface.

• Remove changes made in R41 that log the new events to property level in table, displayed in PACS. These will no longer display in PACS.
• Retain changes that log the new events to table [system_event]

Top Taxpayer Report

The report was displaying a Taxpayer multiple times if one or more of the Taxpayer’s properties were supplemented. For example, Safeway (under the same owner id) reports as #3 and #72. The difference appeared to be per supplement number of the properties. These really should have been summed together regardless of the sup_num identifier.

Now, a cumulative total of the supplement number selected per Taxpayer will be listed.

Helpstar Defect Corrections