Introduction

The billing statements produced by the Advantos Enterprise application can be created with a scan line on the statement. This scan line allows banks to scan the document with machine readers that pick up important information from the scan line. This information is then forwarded to the management company, where our software takes this information and imports it into the application, allowing the user to actually post the payment information to a resident account without manually entering the information. (see additional information)

Statements can be configured with a variety of attributes associated for them. You can even create a custom statement configuration for an individual property. There are quite a few OCR configurations that need to be addressed. If no configuration is made, all of the OCR data fields are left blank, then no OCR line will be printed on a statement.

Configuring a Client

If the 'Client No.' field is left blank then the 'default' configuration will be used; it is actually loaded when the form initially loads.

If, on the other hand, you click on the 'List Custom Configurations' link then you can see what clients have custom configurations already defined. If you want to access one of these custom configurations, just click on the client no. in the search listing.

Override Information

This allows the user to override the normal return address and URL, as defined in the client. This is often used by management companies that want to define a lockbox for all statements, or want a single address used for all statements prepared. It is also handy for when the management company wants to use a single URL on both printed and electronic statements. e.g. when you want to use the management company's web site.

OCR Information

The OCR line is a line of information contained in a special font printed on statements. This line contains particular information in particular output format and in a particular order so that a third party can scan this information and return it to the management company via a 'remittance' file.

The information defined here is provided by the third party who scans the statement stubs. This information includes the bank-assigned bank#, whether there are spaces between the fields in the OCR line (often called the scan line), and the check-digit calculation method of different than the default '2121 reverse sum of weight (Mod 10)'. The following are the available checksum codes:

• 0 - 2121 reverse sum of weight (Mod 10)
• 1 - 2121 reverse sum of digits (Mod 10) - Luhn
• 2 - 1212 reverse sum of weight (Mod 10)
• 3 - 1212 reverse sum of digits (Mod 10) - Luhn
• 8 - Sum of 4 variables (4client + 16cust + 3bank + 10balance)
• 9 - No check digit calculated and null used

The third party processor also defines the format of the data in the line, although there is a default. Since the usual scenario is the Unit#s can have non-numeric characters in it but nothing else does, there is a methodology to address this. On the OCR line, the standard methodology is to convert the unit# into a 16 digit numeric representation of the 8 digit unit#. Each digit of the unit# is converted into a 2 digit numeric value that represents the ASCII digit (this implies the unit# is limited to 8 digits). This is then inserted into the usual data in the OCR Line. It looks like:

Bank#   Client#   Unit#..   AmtDue$...   CheckSum
510     605       L6602     225.00       -

Number of digits for each field:

Bank#   Client#   Unit#..   AmtDue$...   CheckSum
  3        4        16         10            1

The converted value (ASCII to Decimal - see chart) looks like (no checksum digit added):

 510060576545448503232320000022500

Now a checksum can be calculated, since the data has been converted to numeric data. The assumption, of course, is the Client# is numeric. This may not be true, which would have an effect on the checksum calculation.

If the client# is defined with alpha characters, the check-sum calculation is made on numeric data only (all non-numeric data is eliminated). Thus if the OCR line looks like:

510MAST76545448503232320000022500

...then the checksum is calculated on

51076545448503232320000022500

Therefore, if a management company chooses to use alpha characters in the client# they will not get a correct check-sum calculation on their OCR lines and, thus, the bank may have a problem with their OCR lines.

Other Information

There are a number of additional configuration parameters available to the management company.

You can see in the 'Newsletter' section above that it begins with two carriage returns. This will print this default newsletter on the statements two lines down from their potential start.