VCS Tech Support : 
By: Nick Klein
The Parcel Revaluation batch process is an indispensable tool of CAMAvision. Anyone that manages pricing tables or performs program updates knows that to apply the pricing changes to parcels, all parcels need to be “reval’d.” Many users simply “click, click, click, confirm, click” through the screens, barely stopping along the way to read them. While there are a few extended settings depending on the state version, for this article I want to focus on settings for all state versions of CAMAvision.
Before You Perform a Revaluation. This screen poses a series of questions to you before starting the batch. Perhaps the most important being: Have you made a backup of your database? I have written articles before about the importance of backups. Even though we’ve made it immensely easy to cancel a reval or undo somea table change, it’s always a good idea to back up your data before performing a batch revaluation.
The Revaluation criteria, or “options” screen allows you to make select changes on how the revaluation executes. First select the pricing tables to be used: Main, Test or Report Only. The usual choice is Main, which means the parcels will be calculated using the Main tables, value changes will be logged, and the parcel will be saved. Test refers to parcels being calculated using the Test version of the tables: value changes will be logged, and parcels will not be saved.
“Report Only” is a holdover from a time when CAMAvision had fewer reports and the query wizard wasn’t as widely used. Basically this option generates a report of all parcels in the selected PDFs, showing the current total parcel value. Parcels are loaded for the sole purpose of reporting and are not calculated or saved. It’s useful in a pinch to get a simple list of parcel values and total value, but more and more people need values reported in ways never imagined a few years ago. Getting just a total is simply not enough so query wizard reports are used.
The Value Source selection is only applicable in Test mode or “Report Only” and dictates which parcel value is shown on the reports. “Current” (or final) parcel value is the most often choice. When running a Test reval, selecting Appraised might give you a better idea of how much the total value of each parcel could change as opposed to showing parcels that will change. Most jurisdictions have at least a small number of parcels where the current value is in a static override state. For these parcels, a batch revaluation does not technically change the final value and therefore would not be logged.
PDF selection is straightforward enough: you select which PDFs to run the process against. When Main tables are used you usually don’t have much of a choice – all PDFs must be processed. Test mode is more flexible, allowing you to see how a table change affects select classes of parcels or perhaps just a certain side of town. A common question we have following a program update is if it’s possible not to revalue certain PDFs lest historical parcels change value. Unless the parcel values have been rolled into override (or Board), the answer is usually no. Starting with CAMAvision v20 we’ve introduced a new Data Checker feature which going forward should give you a better heads up of parcels affected by a coming program update.
Assign revaluation date to all parcels (not just those that changed). This is actually a legacy setting that has been superseded by stronger reporting in the system log. It is tied to a date field stored with each parcel. If checked all selected parcels will be resaved whether or not its value changes. Uncheck this setting and the batch runs a little faster because it doesn’t need to spend extra seconds saving every parcel; only those that actually have a change will be resaved. Your mileage may vary, but you could see some reduction in processing time.
Load entire parcel during process. Under normal conditions, the revaluation only needs to load those parts of a parcel related to pricing: buildings, land, yard items, etc. Items not affected by a value change such as notes, permits, sketches, are not normally loaded. Selectively loading a parcel speeds up the regular batch process. However, sometimes a full parcel load may be requested, such as following a system update. Loading and saving the entire parcel can ensure that all parts of a parcel are initialized, even those not directly related to value. This is especially useful when non-value related sections get updated. There is no harm in always doing a full parcel load, but it is considerably slower.
Review your options. This screen summarizes all your selections and informs you of what is about to happen if you proceed. Early in the development we added the “I have reviewed the criteria” checkbox because too many people were simply not reading it. We wanted people to be absolutely sure of what they were about to do.
Processing. The processing screen shows you how many parcels have been processed, how many remain and total value change. In the example screenshot, the note in the upper right corner says “Parcels are not saved.” It looks like a link and actually is one. If you press it, it will pause the reval and show you the contents of the summary screen again.
Estimated time remaining. During the execution of the batch process there is one timer that counts down, estimating the amount of time remaining, and another that counts up the elapsed time of the process. I have been asked how the estimated time remaining is calculated. There’s no magic behind it, and is very similar to how file downloads are estimated. It looks at how much time has passed from the beginning of the batch to the current parcel, and estimates how many seconds per parcel it has taken to process. By knowing how many parcels still need to be processed, it extrapolates and estimated time remaining. The time estimate can vary greatly depending on what types of parcels it is calculating at any given point in time. This is because parcels with lots of pieces tend to take longer than parcels that do not. It has to load more out of the database, calculate it, and then turn around and save it back to the database. The calculation cannot take parcel “size” account which is why the time fluctuates. Other unknowns that can influence the estimate is network traffic and server load.
Revaluation log. This screen presents a grid showing all parcels that either changed, or could change (when Test mode is used). The grid shows a parcel’s old value, the new value and how much it changed in each of the main areas of land, dwelling and improvements. The log has buttons for four of the most popular report groupings: 1) by parcel, 2) changes by map, 3) changes by PDF, and 4) changes by class.
As mentioned, if you performed a Test reval, the grid is showing what the parcel could look like. This can be handy to compare against the parcel with the Quick Summary. If you right-click a parcel in the grid you will get a menu that allows you to invoke the Quick Summary. The Quick Summary loads the parcel from the database so it is showing you the parcel values as they are actually stored. Use the Quick Summary in conjunction with the log to compare how a parcel could change.
Now, have you ever been a little too quick to press the close button after finishing the reval and then instantly wished you would’ve paid closer attention to the logs? Our tech support has fielded many such calls to recover the logs. Previous versions of CAMAvision would store this information only in the system log.
This may be fine for individual parcels, but none of the other logs such as value changes by class or PDF would be stored. With v20, all revaluation logs are automatically saved into a zip file located in the CAMAvision Shared folder. Only the most recent revaluation logs are kept; hopefully long enough for you copy them someplace else if you really want to hold on to them.
Conclusion. I hope you enjoyed this dive into Batch Revaluation and the explanations of its screens. I also hope that my explanation and history of some of the features helps you better understand the careful thinking we try to put into this and all parts of the program.