Section 11
Ticket Fines Rules Table
This table contains information needed to cause the automatic
adjustment of fees for parking tickets to be done during receipt entry.
The adjustment is based on the number of days since issue of the ticket
and the initial fee amount, as well as an additional set of logic that
determines which penalty rules apply based on the ticket number itself.
Normally, the ticket data will be scanned via a bar-code entry contained
on the parking ticket or other citation document. The program assumes that
the bar-code consists of the
ticket number, the
ticket
amount, and the
issue date. NOTE: You
can optionally enter a fourth field (the
POSTMARK
DATE) which can be used to override the normal penalty
assessment by using the
POSTMARK DATE as the paid
date instead of the current accounting date. Each field is separated by a
space. A sample scan line might look like this:
12345678
25.00 9/1/2012 12345678 25.00 9/1/2012
10/15/2010 (Includes postmark date in last position). If this
information is not scannable, the user can enter the three (or four)
fields manually, each separated by a space. The exact format of the date
is not critical .. e.g.,
9/1/12,
09/01/2012,
9/1/2012 or
09/01/12 will all be read correctly.
The amount can be entered with our without the decimal point, e.g.,
25,
25.0,
25.00 will all be treated as
25.00 dollars.
If there are fractional dollars (e.g.,
10.50), the the decimal point must be entered, but
the trailing zeros do not need to be entered.
When the program receives this scan line in the
COMMENT field on the transaction entry screen and
determines based on the
tran_code that this is a
ticket by checking the
USER_DATA table, it will
break the scan line down into the separate fields. It will store the
ticket number in the
reference
number field, and place the
amount value
in the
UNIT_FEE field on the receipt entry screen.
It will then compare the
issue date to the current
date (based on the computer's date setting.) To direct the program to
perform these steps, the
USER_DATA_3 in the
USER_DATA table field associated with the
tran_CODE must be set to
ROC-TICKET. For example, the four tran_codes shown
below will be subject to all the processing described in this section, but
no other tran_codes will.
| TRAN_CODE
|
USER_DATA_3 |
| pv1 |
roc-ticket |
pv2 |
roc-ticket |
pv3 |
roc-ticket |
pv4 |
roc-ticket |
The number of days since the
issue date will
then be compared to the
STEP_DAYS value in the
TICKET-FINES table. Depending on how many days
have elapsed the matching adjusted fee amount will replace the amount from
the original ticket entry or scan. If it is beyond the number of days
specified in the last entry for the records, the amount shown in the last
record
DUE_AFTER_STEP_DAYS field will be used.
- price_rule
This is the NAME of the rule. It can be any value.
When the ticket is scanned from the bar-coded bill (or manually
entered via the keyboard) the program knows that the TICKET rules
apply because the specific trancodes are set to cause the extra
logic to be run. See below for details on how to ensure this
happens. Once it knows it's a ticket item subject to the extra
processing it determines which set of records to retrieve from the
Ticket Fines table.
If no matching entries are found, it will not be able to
perform the price adjustments described in this section of the user
manual.
- INITIAL_FINE_AMOUNT
This is the initial ticket amount. The program uses the amount
scanned from the bar-coded bill (including the ticket_number, issue_date, and ticket_amount to retrieve the records from the
Ticket Fines table. If no matching entries
are found, it will not perform the price adjustments described in
this section of the user manual. The first step is to break the
scanned or entered data into the three separate fields noted above.
Once this is one, the program examines the ticket_number to determine which Ticket RULES Table rule applies. This consists
of reading the records from the rules table and figuring out which
one matches the first digit (or digits) of the ticket_number. Sample entries in the ticket rules table are as shown below:
| MISC_PARM
|
TEXT_VALUE |
| ticket-pattern:0 |
ROC-TICKET |
| ticket-pattern:1 |
ROC-TICKET |
| ticket-pattern:2 |
ROC-TICKET |
| ticket-pattern:3 |
ROC-TICKET |
| ticket-pattern:4 |
ROC-TICKET |
| ticket-pattern:5 |
ROC-TICKET |
| ticket-pattern:6 |
ROC-TICKET-NEW |
| ticket-pattern:7 |
ROC-TICKET |
| ticket-pattern:8 |
ROC-TICKET |
| ticket-pattern:9 |
ROC-TICKET |
By comparing the ticket_number to the
ticket-pattern value (which is the portion of the ticket pattern
following the literal text ticket-pattern:),
it is possible to determine which set of price rules to use. In the
sample above, if the ticket number starts with 0, 1, 2, 3, 4, 5, 7, 8, or 9, then the ROC-TICKET
rules apply. If it starts with 6, then ROC-TICKET-NEW rules apply. Note that it is
possible to refine the patterns to look at MORE than just the
first digit. For example, if the series of tickets in the 6xxxxxx
range were such that those beginning with 60 TO
64 were subject to one set of penalty rules, and 65 to 69 to another you will simply need to
create additional patterns as shown here:
| misc_parm
|
Text_value |
| TICKET-PATTERN:60 |
ROC-TICKET |
| ticket-pattern:61 |
ROC-TICKET |
| ticket-pattern:62 |
ROC-TICKET |
| ticket-pattern:63 |
ROC-TICKET |
| ticket-pattern:64 |
ROC-TICKET |
| ticket-pattern:65 |
ROC-TICKET-NEW |
| ticket-pattern:66 |
ROC-TICKET-NEW |
| ticket-pattern:67 |
ROC-TICKET-NEW |
| ticket-pattern:68 |
ROC-TICKET-NEW |
| ticket-pattern:69 |
ROC-TICKET-NEW |
- STEP_DAYS
This value is compared to the issue date scanned (or manually
entered). If the number of days since ticket issue date and the
current date is greater than the number of days specified in STEP_DAYS the fee amount will automatically be
adjusted to match the amount specified in DUE_AFTER_STEP_DAYS column.
- DUE_AFTER_STEP_DAYS
This is the amount of money the customer owes if the payment
date is after the issue date plus the number of days specified in
STEP_DAYS. In our example below it shows
just three steps ( 31, 76 and 90) per initial_fine_amount. The # of steps per INITIAL_FINE_AMOUNT does not have to be the
same ... so you could have 10, 20, 30, 60, and
90 for one initial fine amount,
and 30, 45, and 60 for another. As far as
the program is concerned these are two completely separate sets of
prices.
As in the samples above, there will usually be 3 or 4 records
defined for a specific
PRICE_RULE and initial
ticket amount, corresponding to the individual periods of time at which a
price increase in the
amount due is made. These
must be whole numbers. The system will not calculate fractional days or
use the hour the ticket was issued to determine when a 24 hour periods has
passed. For example, if you are processing a ticket issued yesterday the
system will calculate the time period as 1 full day even if the ticket was
issued at 11:59pm and paid at 12:01am the next day. It is the combination
of the
PRICE_RULE and
INITIAL_FINE_AMOUNT that cause the records to be
considered part of a set of rules when determining the adjusted price, if
any. Here's an example showing how this table might look:
| Price_Rule |
Step_days |
Initial_Fine_Amount |
Due_After_step_days |
| roc-TICKET |
31 |
100 |
165 |
| roc-TICKET |
76 |
100 |
185 |
| roc-TICKET |
90 |
100 |
185 |
| roc-TICKET-new |
31 |
100 |
195 |
| roc-TICKET-new |
76 |
100 |
205 |
| roc-TICKET-new |
90 |
100 |
205 |
In this example, looking at the first three entries, which are all
for the
INITIAL_FINE_AMOUNT of
100.00, you can see that :
the
DUE_AFTER_STEP_DAYS value is
165.00 if the
STEP_DAYS value
is
31
the
DUE_AFTER_STEP_DAYS value is
185.00 if the
STEP_DAYS value
is
76
the
DUE_AFTER_STEP_DAYS value is
185.00 if the
STEP_DAYS value
is
90
The program will determine the # of days since the ticket was issued,
and compare it to the entries in this table. It just steps right down the
list until it reaches the right range and adjusts the amount as needed. If
the number of days is greater than the number of days in the LAST entry in
the list, the last amount is the value that is used; so if the # of days
is
REALLY BIG (e.g., 200 or 300 days after the issue date) it
will still use only the value associated with the last entry for that
group, in this
ROC-TICKET example, 90 days is the
highest entry, so the adjusted price will be
$185.00, no matter how many days beyond 90 it
actually is. Likewise, for the
ROC-TICKET-NEW
example, 90 days is the highest entry, so the adjusted price will be
$205.00. The above price rules will apply for the
rule
ROC-TICKET. If
ROC-TICKET-NEW applied, the penalty amounts will be
the values shown in the table, using the same logic described in the
previous paragraphs. Remember, it is the
TICKET-PATTERN:x rule that determines which set of
rules apply. After the program makes these adjustments the user has the
option to manually adjust the fee to any other value before adding the
item to the receipt. Normally you will not have to adjust the calculated
fee but in special cases it may be necessary to manually adjust the amount
collected.
As noted above, if the scanned ticket amount does not match one
of the
INITIAL_FEE_AMOUNT values contained in the
table, the program will not be able to adjust the ticket amount, since no
rules will be able to be located. In such cases, the amount entered for
the ticket will be what is shown on the screen as the amount paid.
Also note that there is absolutely no consideration
whatsoever of weekend days, holidays, etc. If a ticket is issued on the
Wednesday before Thanksgiving and the city offices are closed until the
following Monday and the rule is you have 3 days to pay the ticket the
program will see the time between
issuance and payment as more than 3 days and step to the next price
level. Manually overriding the fee amount (or entering a earlier
postmark date, as noted above) is the way around this.
