Section 11
Tran Codes Table

This table contains information about the types of fees you will be processing. Each different fee type, for example, tax payment, utility payment, business license, etc., will normally have its own entry.

During receipt entry the settings from this table control the entry of information such as account numbers, descriptions, reference numbers, document validation formats, etc. By setting different values for different TRAN_CODEs, you can tailor the transaction process so that your specific requirements for data capture are satisfied.

Each field in the table is listed, along with a short description, below:

TRAN_CODE

This is a 1 to 30 character field that is the "key" value for each different fee type. These settings must be unique. You can use any combination of letters or numbers to define your tran_codes. Some users prefer to use numbers (e.g., 1234, 5500, etc.) while others prefer to use more word-oriented codes such as UP or UTIL for Utility Payment, etc. The codes you use are up to you.
TRAN_DESCRIPTION

The description is a full text description of the tran_code. For example, you might use UP for the utility payment tran_code , and UTILITY PAYMENT as the description.

SPECIAL TRAN DESCRIPTION FOR CHECK CASHING:
1. At some of our customer sites checks are cashed for various purposes. These might include travel advance checks, petty cash expense reimbursements, and in some cases, as a convenience for employees. If you wish to process a check cashing transaction, the RASWIN program can easily handle this with a very simple setup. All you need to do is to set up a tran_code and set the tran_description to CHECK CASHING. If you need several tran_code's for check cashing items so you can track them separately (for example, CHECK CASHING-EXPENSES, CHECK CASHING-PERSONAL, CHECK CASHING-TRAVEL) simply setup up the number of needed codes, and the appropriate descriptions. RASWIN checks only the first 13 characters of the description for the text value CHECK CASHING. When it sees this value it will automatically add a line item to the receipt for zero dollars, automatically branch to the payment entry screen, set the method to CK (for CHECK) and position the cursor to the amount entry field. At this point, you need to enter the amount of the check that is being cashed.
2. If you have set the Payment Types reference number field to be required (via the payment types ) table, you will also have to enter this field, [typically a check number].
3. If you have indicated that the payer name field is required (via the PAYMENT OPTIONS table, PMT-PAYER-NAME-REQUIREDsetting) you will also have to enter this field.
4. From this point forward, the transaction will behave as any other transaction as far as endorsing the check, and completing the receipt is concerned.
SHORT_DESCRIPTION

This field is used primarily for reporting purposes. It permits you to have a short description value that fits better in a smaller space on reports. For example, you might use UP and the tran_code, UTILITY ACCOUNT PAYMENT as the full tran_description, and UTIL PMT as the short_description. This field is used to defined report grouping codes for the GENERIC_CUSTOM.RPT Crystal Reports template.
SYSTEM_CODE

The system_code tells the interface which host system or sub-system is affected by this transaction type. Some sample codes might be GL for general ledger, RV for revenue, UB for utility billing, BL for business license, etc. The specific codes you select are determined by the requirements of your host interface program. The RASWIN program does not use the system_code for any purpose except during export processing. The system_code can be up to 5 characters long.
EFFECTIVE_DATE

During processing RASWIN will check the effective_date to ensure that the transaction you are trying to process is valid. If the tran_code is not effect yet, it will not let you process a transaction of that type.
EXPIRES_DATE

During processing RASWIN will check the expires_date to ensure that the transaction you are trying to process is valid. If the tran_code has expired, it will not let you process a transaction of that type.
FEE_RULE_CODE

This setting can be set to one of several one character values to control edits on the transaction unit fee amount entered during the processing of normal receipts. These values are:
1. V - A variable amount
2. B - An amount between two amounts
3. E - Either of two amounts
4. G - Greater than or equal to an amount
5. L - Less than or equal to an amount
6. F - A fixed amount
7. Q - Quantity Based - The amount in DEFAULT_AMOUNT_1 is used as the unit_fee_amount, and multiplied by the entered Quantity to determine the extended fee amount.
8. FORM-xxxxx - This tells RASWIN that the price will be determined using a FORMULA. This is sometimes easier than setting up the PRICELOOKUP option described in the next pricing rule option. The value FORM- followed by 1 to 5 additional characters allows you to point to a specific entry in the MISCPARMS-RECEIPT OPTIONS table which actually contains the formula.
  
  For example, suppose you have a policy for photocopies that price is determined as follows:
  
  $2.00 for the first copy, and 25¢ for each additional copy.
  
  The formula to determine the total would would be : 2.00 + ( Q-1 ) X .25 )
  
  If you set the pricing rule in the trancodes table to FORM-COPY, then you would next need to create a miscparm in the RECEIPT OPTIONS table with a key value of FORM-COPY and the price formula as shown above in the second column.
  
  If the formula applies to more than one tran_code it can be shared by all of them so that you only need to enter the formula once. Note: You can use Q or QTY for the variable for the Quantity. You can use the asterisk ( *) or the letter x to represent the multiplication symbol. In some cases the table maintenance function may change the * enter in the RECEIPT OPTIONS table to a % sign.
  
  In this instance, RASWIN will convert the % sign to a * sign when the value of the formula is being calculated. After you enter the quantity for the specific tran_code and press enter or tab to leave the field, RASWIN will substitute the Quantity you entered for the letter Q in the formula and then compute the price.
  
  When this is done, the resulting total price is then set into the UNIT FEE AMOUNT, the Quantity value is changed to 1, and the comment field has the Quantity you entered inserted into the field. (e.g., QTY=50).
  
  The reason this must be done is that it is not always possible to have the system compute a unit fee price based on a formula, and then have that amount multiplied by the entered quantity without having the extended fee result in an incorrect amount.
  
  Any other letters or a word - tells RASWIN to look in the PRICE LOOKUPS table to determine the price, based on the quantity entered by the user at the time of the transaction.
DEFAULT_AMOUNT_1

Some transaction types may have a standard price - for example, a business license may be $50.00 or a utility deposit might be $100.00, or may be subject to price rules (see previous field, fee_rule_code. Depending on the rule you select you need to put a dollar value in the default_amount_1, and possibly the default_amount_2 field. If you place a non-zero amount in the default_amount_1 field RASWIN will fill in this amount as the standard fee on the transaction entry screen. You can adjust it manually during entry if needed.
DEFAULT_AMOUNT_2

see above. This value is used only for amount_rule_code values E (either of two amounts) and B (between two amounts). For all other price rules, any value entered in this field will be ignored.
RCPT_FORMAT_CODE

This setting tells RASWIN what format to use when printing the detail lines on the customer receipt. It can be a number or combination of letters (up to 10 characters). For example, the value could be 1, 2, 3 (etc.) or it could be set to a word such as PERMIT, or TICKET. Each tran_code can share a common format, or each can have its own unique format depending on your needs. When it is time to print the line item detail portion of the customer receipt, RASWIN assembles record keys that includes the defined RCPT_FORMAT_CODE value (e.g., R-TICKET-01 through R-TICKET-20, or R-1-01 through R-1-20) and searches for these lines in the RECEIPT OPTIONS Table. It then uses the formats defined there to determine what to print on the receipt. Check the receipt options table description for more information about the formats.
VALIDATION_CODE

Some documents require validation (printing) to stamp them with reference information such as the date or receipt number. The validation_code links the transaction code to records in the MiscParm table which define the data values and other text to be printing on the source documents. Please refer to the Miscparms table for more information.
TRAN_TEXT_1

If you want to add additional description information and print this on the customer receipt, you can enter the text in this line. The ReCEIPT OPTIONS TABLE must be coded to include this line on the receipt, based on the specific RCPT_FORMAT_CODE. This applies to the next two fields as well.
TRAN_TEXT_2

If you want to add additional description information and print this on the customer receipt, you can enter the text in this line.
TRAN_TEXT_3

If you want to add additional description information and print this on the customer receipt, you can enter the text in this line.
DR_ACCT

This is the default debit account number. This will automatically fill in on the screen during entry of a receipt. If you want to enter an account number during entry, instead of having the system fill it in for you automatically, leave this field blank and enter an edit mask (next field.)

If you have a default account number entered here, the program will ignore any edit mask value and you will not be able to edit the number.
DR_ACCT_EDIT_MASK

If this field is set to a valid edit mask then you will be able to change the dr_acct field. If it is blank, then you can't change the value (previous field). If the dr_acct field is blank then you should enter an edit mask value to properly reflect your required account number format. If you have a general account number format such as %%%-%%%-%%%, just enter that value in this field.

The edit mask can contain characters that are "fixed values" -- for example, if your account number is always 123-%%%-0000, where the % signs represent the portion of the account number that the user is to enter, just type them in the edit mask field as shown here.

The user will not be able to change the first 3 digits ( 123) or the last 4 digits ( 0000). Alpha character positions are represented with the * mark place holder. The edit mask value * can be used to permit entry of a letter or number. A complete discussion of the edit mask rule characters can be found here.

Remember, if you have entered any value in the dr_acct field, the edit mask value will be ignored.

If you want RASWIN to verify that the account number entered by the operator is valid, you must activate the ACCOUNT VERIFY table. In order to do this, see the information in the RECEIPT OPTIONS section.
CR_ACCT

This is the default credit account number. This will automatically fill in on the screen during entry of a receipt. This works the same as the dr_acct field.
CR_ACCT_EDIT_MASK

If this field is set to a valid edit mask then the operator will be able to change the cr_acct field.

If it is blank, then they can't change the value (previous field). This works the same as the dr_acct_edit_mask field, described above.
ACCT_VERIFY_DATABASE

This field points to an ODBC data source name, which in turn can point to a database of customer account information which is accessible to the RASWIN program. This database can contain one (or more) tables defining the balance due figures for various accounts receivable systems such as utilities, taxes, licenses, etc. The ODBC name and the actual database name do not have to be the same, but the ODBC DSN name must be a valid ODBC name which you need to create via the Windows Control Panel. These tables can be updated periodically as required by exporting current values from your various host systems to the appropriate database.

If the field is blank, lookups will not be active.

If the field is set to one of the DSN names that the RASWIN understands RASWIN will present the operator with the option of checking the database table defined in the next field ( acct_verify_table) to see which table to access in association with the particular tran_code. These might include, for example, UTILITIES, PARKING, LICENSE, ANIMAL, etc. The specific names are up to you to define. The LOOKUP settings TABLE defines the import specifications for ASCII files which are exported from your various host systems. Quadrant Systems can assist you in setting up the import process steps.
ACCT_VERIFY_TABLE

This is the table name contained in the database defined in the appropriate DSN. IMPORTANT: The format of each table must be what the program expects. It must contain certain pre-defined columns.

For example, these 6 columns represent one of the possible options:

ACCOUNT (text)
ACCOUNTNAME (last/first - text)
ADDRESS (text)
TOTALDUE (currency)
PASTDUE (currency)
MESSAGES (text)

An import process is provided by Quadrant Systems as part of RASWIN, but you do not necessarily have to use this function if you have another method of updating/populating the tables. It is usually faster to clear the table first, then import all new values into the table, as opposed to performing a lengthy update process. The table can be "bulk-loaded" with SQL server T-Sql commands; BULK-LOADING can load hundreds of thousands of records in just seconds.

The ACCT_VERIFY_TABLE field is also used for some special processing related to custom interfaces to external databases (other than the main RASWIN database.) When RASWIN recognizes these special "keywords" it branches to the custom interface logic. Quadrant Systems will provide the needed setting information for these interfaces. Some specific lookup codes that are tied to real-time interface processes recognized by the RASIWN include these:
1. AIMS-PKG
  Note: additional special setup required. Table Contact Quadrant Support for details.
2. EDEN (or EDENUB)
  Note: additional special setup required. Table Contact Quadrant Support for details.
3. EDENBL
  Note: additional special setup required. Table Contact Quadrant Support for details.
When RASWIN sees these settings on a tran_code being processed it will branch to special logic that Quadrant has included in RASWIN in order to permit you to retrieve data from the applicable host system in a real-time mode. The following codes are linked to the off-line lookup tables stored within the RASWIN database.
- AL
- AR
- AR2
- AR3
- BL
- CT
- DT
- LT
- MEMBERS
- MR
- PK
- PM
- PR
- SA
- TX
- TX1
- TX2
- UB
ACCT_VERIFY_PASSWORD

If your database requires a user password, you can define it here. Normally this would be part of the ODBC setup, so it should not be required to be entered in the tran codes table.
ACCT_VERIFY_USER_ID

If your database requires a user id, you can define it here. Normally this would be part of the ODBC setup, so it should not be required to be entered in the tran codes table.
AUTO_TRAN_CODE

It is possible to create multiple receipt line items with a single transaction entry using this code. For example, you can set up entries in the autotrans table to cause sales tax, penalties, etc. to be automatically added to a specific transaction type. The auto_tran_code value in this table will link to the same value in the autotrans table.

To do a distribution (e.g., split a single fee 2 or more ways on a percentage basis), your auto_tran_code must start with the letters SPLIT. See the AUTO TRANSACTIONS table for more information.
DESCRIPTION_EDIT_FLAG

If this box is checked, the system will automatically jump the entry location to the Reference Number field following entry of a Tran_Code. If you have edit masks for the debit or credit account number fields defined, this setting will be ignored and you will be required to enter the appropriate values for those fields.
MAX_DISCOUNT_RATE

The value in this field determines the maximum discount percentage the user will be able to enter on the transaction entry screen. The default value is 0.00.
FIELD_TYPES

This field links to a record in the address field names table. If a matching entry is found in that table, then the cashier will have the option of entering additional (user defined) data values on a supplementary entry screen. These are not directly associated with the receipt entry process - but typically contain additional information such as addresses, descriptions, etc. These extra fields are then available for exporting to other systems or reporting purposes.
BANK_CODE

This field defines which bank endorsement will be applied to endorsed items. When RASWIN gets ready to endorse the check, it looks at the bank code (which defaults to a value of 001), and assembles a Misc Parameter key value such as E-001, followed by lines 01 to 20...e.g., E-001-01, E-001-02, etc. Up to 20 lines can be printed on the check endorsement.
SECURITY_LEVEL

This is the security level needed to process this transaction type. If the currently signed in cashier does not have a level equal to or greater than the security_level defined in this table, they won't be able to process the tran_code.
CONTROLKEY

This value links to a record in the CONTROL NUMBERS table. During transaction processing, if the controlkey value is not blank, and it the Control Numbers table has a valid edit mask defined, you will be able to have the RASWIN program assign a sequential number to the transaction. This is used for automatic numbering of transactions, such as business licenses, real-estate document filings, etc. Multiple transaction codes can link to the same controlkey value in the control numbers table, if required, or each can link to its own control key for independent number sequencing.
SKIP_QUANTITY

If checked, this value tells RASWIN to skip the quantity field on the line item entry screen. When this is happens the quantity defaults to a value of 1, and you can't change it.
SKIP_DESCRIPTION

If checked, this value tells RASWIN to skip the description field on the line item entry screen. When this is happens the quantity defaults to whatever the value of the description is from the trancodes table, and you can't change it. If it is unchecked, RASWIN will initially fill in the description based on the value of the description field in the transaction codes table, but you will be able to enter the description field and modify it if needed.
SKIP_REFNUM

If checked, this value tells RASWIN to skip the reference number field on the line item entry screen. When this is happens this field defaults to a blank value and you can't change it.
SKIP_COMMENT

If checked, this value tells RASWIN to skip the comment field on the line item entry screen. When this is happens this field defaults to a blank value and you can't change it.
SKIP_DISCOUNTRATE

If checked, this value tells RASWIN to skip the discount rate field on the line item entry screen. When this is happens this field defaults to a blank value and you can't change it. This is treated as a zero discount rate.
VALIDATION_SKIP_LINES

This is a numeric value that tells RASWIN how many lines to move down before printing a detail document validation. This permits you to tailor the location of the validation for each different document type. The minimum value is 0, and the maximum value is 99. When performing a document validation this value (if non zero) will be placed in the Extra Blank Lines field on the print preview screen for the validation. This applies ONLY to the Line Item Validations (F9), not to the Completion Action (F7) type validations.

Once the preview screen appears with the appropriate number in the extra blank lines field, you can manually adjust it using the up/down arrow control next to the field, or by simply typing in an alternate number in the entry field. Normally you will want to leave the value set to whatever value appears in the field.

Most printers print about 5 to 6 lines per inch, so if you want the validation to skip down about 3 inches before printing the defined document validation you would set this value in the range of 15 to 18 or so. Depending on the exact printer model you are using, this may require minor adjustment up or down to print exactly where you want to print. Also, some printers have a small margin of blank lines at the top of the validation before printing starts so you might have to compensate for this when setting the exact number of skip lines in this field.

PMT_TYPES_LIST

This setting permits you define a list of the payment methods that are valid for a particular tran_code. In the Payment Types Table, there is a column called PMT_TYPE_CODE. This is a one character field that is associated with a payment method. The values can be any number (0 to 9) or any letter (A to Z).

First, decide which combinations of METHOD's methods will be allowed for each Tran_code.

For example, for some Tran_code's you may wish to accept CASH, CHECKS, and CREDIT CARDS. For others you might want to accept only CHECKS, WIRE TRANSFERS and DIRECT DEPOSITS.

Each of these combinations is called a Payment Type Set. For the purposes of this discussion, assume the the PMT_TYPE_CODE values for each of the methods above are as shown below:

METHOD	PMT_TYPE_CODE
CASH	C
CC	2
CK	K
WT	W
DD	D

We'll call the first combination, [CASH, CHECKS, and CREDIT CARDS] SET#:001.

The second set, [CHECKS, WIRE TRANSFERS, and DIRECT DEPOSITS] will be SET#:002.

So, say for a utility payment, you wanted SET#:001 that would be what you put in the PMT_TYPES_LIST field.

For tax deposit from a county or state you would might want SET#:002.

The definition of what payment types are included in each set is contained in the payment_type_sets table.

Select Main Menu➔ Maintenance➔ Table Maintenance➔ Payment Type Sets .

Records for the above entries would look like this:

In these examples we have tried to use a PMT_TYPE_CODE that is similar to the METHOD the code, e.g.,

C= CASH, K= check, etc.

However, it is sometimes not possible to use the code for every method, e.g.,

C= CASH, C= CHECK, and C= CC.)

The PMT_TYPE_CODE must be unique so the system can tell the difference between them when converting from the PMT_TYPE_CODE to its associated METHOD.

RASWIN determines which PMT_TYPE_CODEs to use as the valid PMT_TYPES_LIST. When a transaction is processed the payment_type_set is drawn from the tran_code's table for the most recently accessed Tran_Code.

If this field is blank it uses any letter or number as a valid type. If you process a transaction with multiple tran_codes on it, is possible that there could be DIFFERENT payment type set codes on each Tran_Code, and these might be incompatible e.g., one Tran_Code's payment type set may not include checks as a valid type, while another includes only Credit cards or Wire Transfers as valid codes.

In such a situation, RASWIN does NOT ADD the two lists together to arrive a list of what methods are valid. Rather, the payment type set that applies will be the most recently retrieved tran_code record (generally the last item on the receipt, but this may not be true 100% the time if you have gone back and edited a previous line item on the multiple receipt).

Another scenario where a different Tran_Code (or no Tran_Code) could have been accessed would be if you started to add a new line to a receipt, then cancelled that screen and then went into the payment screen.

In such a case, the list of valid codes is cleared, and subsequently, when RASWIN attempts to determine which codes are valid, it is not able to find ANY valid codes, so it uses ALL of them as possibilities. While this is not a frequent situation it can happen under the conditions noted, and can cause some confusion when RASWIN appears to not be enforcing the rules you have been set up.

If only ONE method is valid, that will become the default method for payments and will be assigned to the {F2} key on the payment screen. If the is PMT_TYPES_LIST is blank or set to * then the default payment method defined in the MISCPARMS Table PMT-F2-METHOD setting will be assigned to the {F2} key.

DEFAULT_PAYER_CODE

Each TRAN_CODE can be associated with a pre-defined default_payer_code. This is a shortcut entry that permits you to have the system automatically fill in the payer name on the payment entry screen in situations where it is expected that the payer for a particular transaction type will always be the same entity.

For example, if you have a Tran_code set up to receipt money for revenue from the state for a tax they collect on your behalf (such as a gas tax or a property tax, you can set the default_payer_code to AZ. Then in PAYER NAMES table you would set up an entry with a key value of PAYER=AZ, and a text value of State of Arizona. Whenever you process any tran_code with the AZ default_payer_code set the AZ RASWIN will automatically fill in STATE OF ARIZONA for you in the payer name field on the payment screen.

During maintenance of the tran_codes table, the program will default the Default_Payer_code to NONE. If RASWIN finds this value or a value for which there is no PAYER=xxx value set up in the PAYER NAMES table, it will not try to pre-fill the payer name field.
SUMMARY_FLAG

Each TRAN_CODE can be flagged to summarize transactions posted to a higher level when the data is exported from the RASWIN database for uploading to your host accounting system[s]. There are a couple of things you need to do in order to cause this summarization to take place correctly.

First, on each transaction code record that you want to summarize, place an "S" in the summary_flag field. Any tran_codes that are not flagged with an S will be treated as detail records.

Second, in the MISCPARMS table you need to be sure the EXPORT SETTING which controls whether or not ANY records are summarized (EXPORT-SUMMARIZE-BY-CR-ACCOUNT) is set to YES. The default value is NO, so if you want to adjust this setting you will need to change it. It can be done via the MISCPARMS-EXPORT SETTINGS option.

The summarized records are rolled-up to provide few records in your upload file as follows:

Records are grouped by Accounting Date, Account Number, System Code, Tran_Code, and BankCode. Any records which have the same values in these fields will be grouped into a single summary record, as long as the tran_code is flagged with the "S" value in the Summary_flag field. If any of these fields contains a different value it will be in its own group (with any other records that have the same values). In most cases, you will be exporting your records for a single day and most users have only one bank, and most users have only one system code assigned to each account; therefore, you will normally get a single rolled-up total by account.

Certain data can't be carried forward to a summarized record, so some fields are replaced with the value "** SUMMARIZED BY CR ACCOUNT **". For example, when rolling up more than one record into a single total, you will lose the ability to pass the payer_name, the reference_number field, the description, etc. Also, some values such as receipt number can't be carried forward in a summary record, as well as the actual date/time of the receipt (as opposed to the accounting date).
EXPORT_SHIFT_RULES

The EXPORT_SHIFT_RULES define what happens to the individual fields when the transaction records are exported in the various export formats available in the RASWIN program. The codes permit you to move, on a tran_code by tran_code basis, data from one entry field to another by setting the rules appropriately.

The fields that can be shifted from the standard positions in the export file to another position in the export file include:
1. A = Account #
2. C = Comment
3. D = Description
4. P = Payer Name
5. R = Reference Number
Any of the above fields can be moved to any other of the listed fields. For example, for Utility Billing transaction types, you will probably capture (on the RASWIN entry screen) the customer account number in the reference_number field. But when this data is exported to the host system via the "Create Upload Data File" function on the FILE menu, you might wish to have this value moved to the ACCOUNT # field. The EXPORT_SHIFT_RULES permit you to tell the export program to do this.

Each of five fields is assigned a one letter code, as shown above. To move a value from one field to another at export time you need to set the export_shift_rules to tell the system the source field (the one that contains the value you wish to move) and a destination field (the field where you want to put the source field value). This is done using the one letter codes listed above. The first letter is the source field and the second letter is the destination field. For example, if you want the Reference Number to be moved to the Account Number field, the correct value would be would be /RA/. If you wanted to move the Account Number field to the Reference Number field the rule would /AR/. As an added bonus, (if you are not already confused by this concept), if you wanted to swap the fields, you would list both rules, e.g., /AR/RA/, (or /RA/AR/).

The / character acts as a delimiter value between multiple shift rules. It must be present on both sides of your shift rule, even if there is only one in use. For example you may want to move the reference number as described above, AND move the payer name to the Description field. he rule for this would be /RA/PD/. If we just listed the letters without the delimiters, RASWIN would see RAPD. Note that RA is a valid combination, AP is a valid combination, and PD is a third valid combination. This would result in an extra shift taking place, which you probably don't want to happen. The delimiters prevent this.

As noted earlier, any of the fields listed above can be shifted to any other field. RASWIN remembers the initial values of each of the source fields when it reads a record. While it would not make sense to do so, you could direct the program to shift different source fields into the same destination field. If this is done, RASWIN always processes the shift rules in alphabetical order. So if you specify both /RP/ and /AP/, for example (move the Reference Number to the Payer Name field, AND move the Account Number to the Payer Name field, Both would take place, but the LAST one (alphabetically..in this case, RP) would override the previous shift ( /AP/), even if these were put in a reverse order in the shift rule itself. In other words, /RP/AP/ and /AP/RP/ will give the same results, that being, that the Reference number would be in the Payer Name field in the output file.

Usually there is only on such shift that need to take place. These typically include Utility billing and AR interfaces. Quadrant Systems will work with you to determine the correct settings for your host interface file.
EDIT_MASK_KEY

Each TRAN_CODE can be associated with a predefined reference number edit mask. This allows you to define specific edit rules to be used for the reference number field during data entry on the line item screen. The edit_mask_key points to a record in the EDIT_MASKS table, which in turn, contains the edit mask that is to be used during data entry. Multiple TRAN_CODEs can share a single edit mask so that you only need to create one entry for each unique edit mask that is needed.

It properly defined, an edit mask entry will display in the REFERENCE # field on the transaction entry screen as a combination of any literal text you have defined (e.g, PERMIT #) and a series of one or more underscore characters that define the location where you are required to enter text or a numbers. If, for example, you needed to collect information related to a permit and you wanted to display the words PERMIT #: and then 7 spaces for the operator to enter the permit # (numbers) you would first define the edit mask as

PERMIT \#: %%%%%%%

Note that there is a backslash character in front of the # sign, since the # sign can be used to represent a numeric position where the operator can enter the numbers 0 to 9, the period, and the minus sign (-). We want the cashier to enter only numbers, we are using the % sign as the place-holder for the numeric positions in the edit mask, as described in the EDIT_MASKS table.

The prompt, as seen on the screen when entering the value will be:

PERMIT #: _______

The underscore characters will be where the cashier can enter the numbers for the permit #. If you wish to force the cashier to enter a full seven digits, you need to adjust the value of the RECEIPT-OPTION called REFNUM-EDIT-MASK-FORCE-ENTRY from NO to YES. This will tell the program to return to the entry field if there are any underscore characters remaining in the field when the user tries to exit the field (e.g., by pressing ENTER or TAB). If the underscore characters are blanked out with the space bar (by the user) so that they are not present when the field is exited, this system edit will not take place.
AUTH_LEVEL

This value is used to force authorization of a receipt line item by another cashier with a higher level than the cashier doing the receipt. The default value for the AUTH_LEVEL setting is 9999 unless modified via table maintenance (for each individual TRAN_CODE)

In these cases, the SUPERVISOR-SECURITY-LEVEL setting controls what level the system considers a supervisor to be. This is setting via the SECURITY_SETTINGS table. When the cashier processing a receipt is below the level set as the AUTH_LEVEL on a specific TRAN_CODE, then a supervisor level cashier must enter their password when the cashier processing the receipt tries to process that particular tran_code.
CIP_GROUP_CODE

This field is not used at the current time.
USER_DATA_1 to USER_DATA_9

These 9 fields contain custom settings that RASWIN will recognize to cause the special processing logic (usually custom on-line interfaces) to be triggered when needed. If you put non-recognized data values in these fields it will simply be ignored.

Here's an example of what such an entry might look like:

In this example, the tran_code RT value causes the value ROC-TICKET contained in the USER_DATA_3 field to be associated with tran_code RT whenever that tran_code is processed during receipt entry. If additional tran_codes also need to be linked to the same user data, you would simply place the same value on each such tran_code.

If special values need to be placed in these fields to trigger custom interface code related to a specific host system, Quadrant will provide that information or you.

Section 11 Tran Codes Table

Section 11
Tran Codes Table