9.0.44 Release Notes

New Features

DOR Reports – Stratification and Sales

• Recent changes initiated the addition of prior year Assessed values to the DOR Stratification Real and Personal reports and the Valid/Invalid Sales reports.
  • If the property did not exist in the prior year and has no entry for “prior year assessed” then it should be BLANK, not 0
  • When supplements exist in the prior year the reports will utilize the value from the latest supplement (prop_supp_assoc)
• Real Stratification

• Personal Stratification

• Valid sales

• Invalid Sales

Levy Calculation – Annexation & New Construction

In the Highest Lawful Levy & Actual Levy Calculation Elements, annexed new construction value is being included in the ‘New Const. Value’ calculation for Additional Levy. This is incorrect and it should not be included. The ‘Annexed Value’ for Additional Levy includes all value elements (e.g. Real, Personal, State Assessed, New Construction), therefore this issue is inflating the ‘New Const. Value’ calculation causing the calculated levy and levy rate to be incorrect.

• This was due to a previous client request, though incorrect to implement.
• Ensure the Highest Lawful Levy Limit is calculated as below:
  1. Limit carried forward from prior year
  2. Plus: [New Construction] x [last year’s levy rate]
  3. Plus: [Net increase in State Assessed Utility Value] x [last year’s levy rate]
  4. Plus [Value added through annexations] x [complicated derived rate]

• Adjust Annexation Area value
  • For a simulation tax district:

• Calculation as outlined:
  1. Prior Year Limit
  2. 3,000 * Last Year Rate
  3. 2,000 * Last Year Rate
  4. 17,000 + 12,000 * New Rate
  • Modify HLL calculation (described as ‘B’ above) to not include annexation new construction in the section for new construction
  • Ensure Annexation non-new construction value and annexation new construction value are accounted for

Mass Maintenance

Add Condition Code

• A request was made to add Condition Code to Mass Maintenance options for Improvement Detail.

Mass Maintenance

Restrict UNDO Action

• When the Undo action is initiated on a run in a certified year, the User is prompted to supplement the properties before continuing:

Miscellaneous Receipts Distribution – Description Field

• We changed Miscellaneous Receipting in release 39 as part of a client project. That process now automatically populates the account descriptions into the fee_misc_rcpt_detail table. That description is then included on the export to the external accounting software. Some clients do not that information included in their export.
• PACS.Admin> System Configuration > Financial Management System has a new configuration

‘Exclude Misc. Account Receipting Description’

• If it is set to ‘True’ (meaning exclude the description) the description will be REPLACED with the Comment for populating the export “description” field.
• The default value is “True”.
• Currently, only accounting types of “JD EDWARDS” and “NEW WORLD SOFTWARE” have description fields with “Misc. Account Receipting Description” in export file, and rest of the types do not have any description in their export files.

Personal Property Rendition Penalty – Daily Amount Limit

• Personal Property training from the Department of Revenue reviewed the maximum per day penalty not to exceed $50 per calendar day if less than one month per RCW 84.40.130, WAC 458-12-110. Listings received after the due date of April 30th are subject to a penalty of an additional 5% per month – not to exceed $50 per calendar day if less than one month – to a maximum of 25%, of the tax due.
• There was no configuration in PACS to set this minimum, so the following is added.
• Modified Penalty configuration with a NEW column Penalty Maximum:

• PACS.Admin > Tools > Personal Property Rendition Maintenance > Configure Penalties
• Values default to 999,999,999 for any new row added.
• The values in the cell are formatted as currency.

REET Status Codes – Required

• The following REET status codes are also used by PACS in REET processes and should not be removed. These will be created at each client site where not existing and will be identified as ‘System’ codes.
  • Cancelled
  • Correction
  • Created
  • ExciseGen
  • Exported
  • Imported
  • Recorded
• The User cannot edit or delete the codes.

Special Assessment Import – User Values

• Several user value fields exist, in separate locations, which can be used for special assessment calculations. An import process exists to update user_property_special_assessment and clients have requested an additional process that will update the user_property_val table.
• There are two ways to get to the Special Assessment Imports:
  • PACS -> Import -> Special Assessment (Import Dialog only)
  • PACS -> Activities -> Special Assessment Import Run List, and click the [+]
    • This path displays history and status of all imports, very useful

• The labels for the import type have been modified for clarity:
  • Property Attributes is an existing option and updates the Special Assessment Attributes on the Property Codes panel. The file layout is fixed length based on the database tables.

• Special Assessment User Values is an existing option and updates the User Values associated to the Assessment on the property from Tax Area, Exemptions & Special Assessments panel

• Property User Values is NEW to update the user values on the property Values panel

• The two User Value imports (bottom radio buttons) rely on the fields existing through PACS.Admin configuration for the associated table. Treasurer Role, Tools -> User Table Management

NOTE: It is critical that the user fields for both these tables stay in sync in order for imports to be successful. For user_property_val the prop_id, prop_val_yr and sup_num fields cannot be deleted.

• The Import processes the files as indicated by the dialog selections made. The import file is a comma delimited text file with data present for each of the fields needed.
  • This will always include the prop_id, the geo_id and then each of the fields from the User Table Management definition.
  • The user will have to know what these fields are for the file layout to be understood.
  • If the provided number of fields does not match the expected number of fields this message will be received:

• For a property in the import file, the following scenarios are possible:
  • The Property ID exists in the system and already has data:
    • In this case, upon PROCESSING, the existing data should be overwritten with the new data
  • The Property ID exists in the system but currently has no data:
    • In this case, upon PROCESSING the new data should be recorded on the property
  • The Property ID does not exist in the system:
    • In this case the ‘Special Assessment Import Run List’ will allow the user to select the MATCH command which brings up another dialog to map that bad Property ID to the account with which it needs to be associated.
    • The user also has the option to select ‘NO MATCH’ and skip that entry if it truly does not apply to any records in this environment. The import must then be PROCESSED.

NOTE: If all properties on the import file MATCH to begin with this task is performed automatically, this only applies when accounts do not all line up through the initial import action.

Statement of Taxes Collected Report – MH Excise

• For reporting of MH excise, we needed to be able to address several scenarios. Previously, the report was only capturing MH property type REET taxes.
  • Real Property with MH improvement type listed:
    • MH title not eliminated, where 2 REET affidavits are expected (one for the mobile & one for the land)
    • MH title eliminated, where only a REET affidavit for the land is expected
    • MH title eliminated, “married” to the land parcel as a single parcel where only one REET affidavit is expected
  • MH Property
• To accomplish this, we added an indicator to REET Type Code to allow each office to indicate the affidavit should be used to report Mobile Home taxes.
  • The new check box is not required.
  • More than one REET Type can have the check box selected, i.e.
    • MH taxable
    • MH exempt

• Modify the Statement of Taxes Collected report:
  • Use the REET Type Code where Mobile Home Affidavit is selected to populate Line 2.
    • The existing rules should be retained, meaning non-taxable records should not be included even if indicated as MH.
    • Line 1 should reflect all other taxable non-MH REET records as indicated by REET Type
  • Use the REET Type Code Mobile Home Affidavit to populate the ‘Total No. of Mobile Homes’ at top right of report

Tax Statement

Export – Acreage

Legal Acreage and Fire Patrol Acreage needs to be added to both tax statement exports that go to Master’s Touch. This was requested by several users at the Focus Group.

• We attempted to export the fields requested, as requested. The User values depend on client configuration.
• The field benefit_acre_sum in user_property_val can be named anything, or even not exist at all. As such PACS will attempt to dynamically identify the field.
  1. LOOK FOR “user_property_val.benefit_acre_sum”
     • If it exists, we will select from that field. This appears to be the standard naming convention shared by most clients.
     • Select field_name from meta_user_field where table_name = “user_property_val” and field_name = “benefit_acre_sum”
  2. LOOK FOR THE FIRST FIELD IN “user_property_val” WHICH CONTAINS “sum”
     • If the client uses a different name, it should at least say “sum”. For example at Whatcom, this is called “sum_acres” which would be used to select the data.
     • Select top 1 field_name from meta_user_field where table_name = “user_property_val” and field_name like “%sum%”
  3. IF NO APPLICABLE FIELD CAN BE FOUND, EXPORT A VALUE OF 0
     • This is the catch-all default case, in case the fields are unidentifiable as an acre benefit sum.

Update tax statement export to add fields at the end of the layout:

• Legal Acreage – property_val.legal_acreage (14,4)

• Fire Patrol acreage stored as Benefit Acre Sum – upv.benefit_acre_sum (18,4)

• Special Assessment Benefit Acres – property_assessment_attribute_val.benefit_acres (18,4)

NOTE: Request the new Tax Statement Export Layout from Support, if needed for the print vendor.

Tax Statement

Payment Dates

• When printing a property tax statement–multi coupon, and the ‘Use Effective Date’ is selected -the Pay or Postmark date is not populating correctly.
  • When creating a property tax statement at the property level, the effective date is used to populate the Pay or Postmark date.
  • At this time, it is only populating with April 30 when the current tax year 2015 is used to create a statement.
• There was a gap in the real property coupon date logic when prior year funds were owed. In this scenario, the User is expecting to use the effective date selected rather than waiting until the statutory due dates in April or October. The business logic here is to bill and receive the payment before any P&I changes.
  • To that end, a new hierarchy is implemented for due date logic as it pertains to the multi-coupon statement.

NOTE:    All of these assume that the Effective Date System Setting is turned ON. If this is not the case then the statutory due dates will always apply.

• First Half Coupon:
  • If there are any delinquent amounts due use the effective date
  • else take the later of the effective date and the April statutory due date
• Second Half Coupon:
  • If there are any delinquent amounts due use the effective date
  • else take the later of the effective date and the October statutory due date

Helpstar Defect Corrections

Helpstar ID Description of update