Click for Index

Quadrant Systems RASWIN Release Notes 2010

Contents


The changes are presented with the most current items at the top of the list.

November 2010 Ver:1.0.2716

  1. A minor but important change has been made to the way you control the format of dates in your export files (those that are intended for upload to host accounting and utility systems via the batch export mode available in RASWIN.)

    This change results in a simplified way to format instruct the RASWIN how to format the date values, and allows different date formats to be used for each of the two export (UB and GL) files. Previously only a single setting was available for both export files. A small number of the file formats have pre-defined hardcoded date formats and can't be changed via the options described here.

    For the standard versions of the export files there is usually one or two date fields. These include the ACCOUNTING_DATE (controlled by what date you assigned when doing the start of day function) and in some files but not all of them , the RECEIPT_DATE (the actual calendar date on which the receipt was entered.

    There are now just two settings needed to define the date formats for each of the UB and GL export files. These settings are:

    UB-DATE-SEQUENCE-ACCOUNTING-DATE
    UB-DATE-SEQUENCE-RECEIPT-DATE
    GL-DATE-SEQUENCE-RECEIPT-DATE
    GL-DATE-SEQUENCE-ACCOUNTING-DATE



    The system will create these new parameters automatically the first time you run your export process. However, you will probably have to adjust the default values it associates with them to match what is required for your location and host import process. To set the date_sequence values you simply enter into the Maintenance-->Table Maintenance-->Export Options menu and locate the settings noted above. The Text_Value column for each of these should be set to one of the following values:

    MMDDYY
    YYMMDD

    MM-DD-YY
    YY-MM-DD

    MM/DD/YY
    YY-MM-DD

    MMDDYYYY
    YY/MM/DD

    MM-DD-YYYY
    YYYYMMDD

    MM/DD/YYYY
    YYYY/MM/DD


    Some of the older export formats allow only a 6 or 8 digit date format. You can view the complete list of file formats at this link:

    Standard Export Formats.

    In addition to the standard formats RASWIN contains certain custom export formats to specialized subsystems such as parking violations, certain G/L systems and so on. The date sequence formats for these interfaces is hard-coded to avoid 'breaking' these interfaces.

    If you have any question about how to determine what your current settings are and what your new settings should be, please contact Quadrant Support for assistance.
  2. This information applies only to users that are linked to the Permit Plan/Accela

November 2010 Ver:1.0.2716

  1. This information applies only to users that are linked to the Permit Plan/Accela permitting system. In previous versions the RASWIN program checked to see what set of SQL statements to execute in two steps. First, there is a query to validate the permit # and payer name. Second, there is a query to retrieve the open permit items based on the Permit Plan receipt number and date (one or both), or based on a 'Case Number' (permit number) depending on the specifics of your implementation.

    The SQL statements for both steps is stored in the SQL STATEMENTS table. The first query was typically called ACCELA_PRODMODE_1, or TIMEMARK_CASE_NAME_QUERY. At some sites this sql looked something like this:

    SELECT NAME FROM APD_PEO WHERE NUMBER_KEY = '@A_RCPT_NUM@' or



    SELECT CSM_NAME_LAST AS PAYER_NAME FROM CASEMAIN WHERE CSM_CASENO = '@CASENO@'

    At some sites the payer name is stored in another field entirely.

    SELECT FEE_SUM.NOTATION AS NOTATION FROM FEE_SUM WHERE FEE_SUM.RECEIPT_NO = '@A_RCPT_NUM@'

    A run time the RASWIN program substitutes the user entered values (such as the receipt number or case number into the query and tries to find the matching entry, which it displays on the entry screen for the user to confirm.

    To lessen the chance for program updates changing the entries that have been customized specifically for your site, the SQL STATMENTS table key values for these queries have been made customer specific. Within the RASWIN MISCPARMS table there is a setting called SHORT_USER_NAME. This is a QSI controlled value with identifies your site to the program so that customer specific logic cab be processed in such a way that it applies only to your site and is ignored by other locations.

    The current version of RASWIN, and carrying forward from this release will therefore look for ACCELA_GET_NAME_[short-user-name] keys instead of the older ACCELA_PRODMODE_1 keys.

    So, for example, if your old settings were:

    Command Name           Sequence  Command Text
    -----------------      --------  ----------------------------------------------------
    ACCELA_PRODMODE_11SELECT FEE_SUM.NOTATION AS PAYER_NAME FROM FEE_SUM
    ACCELA_PRODMODE_12WHERE FEE_SUM.RECEIPT_NO = `@A_RCPT_NUM@`
    


    and your SHORT-USER-NAME setting is GOTHAM the new 'Command Name' the program will look for will be:
    Command Name           Sequence  Command Text
    ---------------------- --------  ----------------------------------------------------
    ACCELA_GET_NAME_GOTHAM1SELECT FEE_SUM.NOTATION AS PAYER_NAME FROM FEE_SUM
    ACCELA_GET_NAME_GOTHAM2WHERE FEE_SUM.RECEIPT_NO = `@A_RCPT_NUM@`
    


    Followed by a second query to get the permit data itself. Again, the specific SQL executed varied by client site depending on the details of your Permit Plan/Accela setup and version. The new name for the second query (to get the details) is now going to be

    ACCELA_GET_DETAILS_[short-user-name]
    


    e.g., as in our GOTHAM example

    ACCELA_GET_DETAILS_GOTHAM
    
    Command Name               Sequence  Command Text
    ------------------------   --------  ----------------------------
    ACCELA_GET_DETAILS_GOTHAM1        whatever sql is required
    ACCELA_GET_DETAILS_GOTHAM2        etc
    ACCELA_GET_DETAILS_GOTHAM3        etc
    

November 2010 Ver:1.0.2698

  1. In previous versions the RASWIN program checked for more current versions of the RASWIN only compared to the other versions installed and running at the local user site. This has been modified so that you have choices about how this is done (or not). Each time the program starts it now determines which version of the program is running on the local machine. It then checks a new misc_parm setting that tells the system how to check for program updates. This setting is done on a per machine basis, that is, EACH workstation can be set to show whether there are more current versions available or not.

    This way, you can have a few machines (say the supervisor or managers) check for more current versions and the basic users systems not bother to check or to check the locally installed versions only.

    This value will be automatically created by the system the first time the updated version of the program is run in the PROGRAM VERSIONS section of table maintenance.

    xxx-CHECK-VERSION-MODE
    


    By default, the setting of this value is WEB. This setting will tell the program to check the Quadrant web site to verify what the most current version of the RASWIN program is. In this setting, the 'xxx' value is actually the register #; so on register 1, the setting would be 001-CHECK-VERSION-MODE, on register #2, it will be 002-CHECK-VERSION-MODE, etc. If your workstation is unable to connect to the Quadrant web site for some reason (e.g., internet access is blocked) the message displayed will say "Unable To Retrieve Master Version".

    If the setting is manually changed to LOCAL, it will compare the version of the RASWIN running on the workstation to the version running on each machine, which is stored in RASWIN database each time the program starts. This is the same as the old behavior which did not check our web site or give you the option to suppress the version warning display.

    A setting of SKIP (or any other setting than those listed here) will tell the program not display the version warning message at startup.

September 2010 Ver:1.0.2677

  1. Some RASWIN users do not collect a payer name via the payment screen .. instead they place it in the receipt detail reference number field due to the way their interface data is transferred to their host accounting systems. When there is no need to collect a payer name via the payment screen you can turn this field off completely. This is controlled via the PAYMENT-OPTIONS setting called :

    PAYER-NAME-REQUIRED
    


    The valid settings are YES, NO, or OPTIONAL. If set to NO, the payer name entry field on the payment screen is not displayed, and the F11 (Reverse Name) function key reminder is suppressed as well. Also, when NO is used, the payer name data on the customer receipt is not printed.

    To reactivate the entry field, change he setting to YES or OPTIONAL.
  2. The "Edit data for a single receipt" function was not properly updating the payment record when the UPDATE button was pushed. This has been corrected. Also, the system now displays the fields which you are permitted to edit in a light green color, and those which you are not permitted to edit in a light red color, as shown below.



    to assign the security levels for each field adjust the TRAN_EDIT_RULES table using normal table maintenance functions.

    Also, the payment method text box entry field has been replaced with a drop down list of valid payment methods drawn directly from the payment types table. This insures that if the payment method needs to be changed, it is replaced with a valid method. In earlier versions it was possible to enter any text value which could result in some reports and displays not being able to find the related payment data because the underlying database view is 'broken' when the method is invalid.
  3. A change to the way data is saved after editing a line item during normal receipt entry process (e.g., editing after double-clicking or pressing F5 to edit) on the line item on the receipt summary screen) was made to insure that the record is properly updated following changes. Under some conditions some data values would be blank (e.g, if CANCEL was pressed instead of UPDATE). This has been corrected.

    In a future release we may eliminate the CANCEL button entirely and rely instead on the ESCAPE key to exit the detail entry screen if no changes need to be made.
  4. The CHANGE PASSWORD function was not working as intended. If the user's password has expired, it was forcing them to use PASSWORD as the OLD password when the CHANGE PASSWORD screen appeared, even if that was not their old password. It now accepts their old password and when they enter a new password it sets the password to the newly entered password, and updates the password expires date to the current date plus the number of days specified in the setting noted below.

    SECURITY-PASSWORD-RESET-PERIOD

    If a user is authorized to use the RESET PASSWORD function (for another user) the system will request the user id of the person who's password is to be reset, then insure that the specified user exists, and if so, it will reset that user's password to PASSWORD. Then when the specified user logs into the system, the program will force them to enter PASSWORD and their desired 'new' password. Once this is done, they will be able to log in normally.

    If you don't want to use the 'forced reset' feature, just change the expires period to a value such as 9999. This will place the reset date way out in the future and then when they log in and the system checks the current date against the expires date it will not force them to reset. The default period for this setting is 60 days.

    SECURITY-PASSWORD-RESET-PERIOD

    Changing this value via the SECURITY OPTIONS setting DOES NOT adjust any existing expire dates which were previously set via the PASSWORD RESET or CHANGE PASSWORD functions.

    If you want to completely disable the forced reset function (based on the expires date) , set the reset period to 0. It will still force the user to enter a new password if their password is set to PASSWORD (via the RESET PASSWORD function).

August 2010 Ver:1.0.2667

  1. A change to the cash recap report has been made to identify situations in where there is a gap in receipt numbers. An example of how this might happen would be if you processed a receipt on a different accounting date than 'surrounding' transactions, then ran your report for a the date you were primarily working on. Even though this receipt processed on the different date is successfully recorded in the database it might give cause for concern about an apparently missing record on the detail report. The report now displays a message about the sequence number that appears to be missing, as shown below so that you can research the item.

    Note that the large bordered RED highlights shown on the above sample are not are of what prints on the report ... they are there in this example just to highlight what is being compared to determine if the yellow "Receipt Number Sequence Issue" message is printed on the report.
  2. A new option has been created to allow you to specify that a cashier is permitted to access only certain register numbers. By default, any cashier with a valid login can access any register they have physical access to. However, under some situations, you may wish to restrict a user to only one or a few registers for accountability reasons.

    A new MISCPARM setting in the SECURITY SETTINGS table defines, for EACH cashier, which workstation[s] they can access. It will be created initially with a setting that permits access to all registers. If you want to restrict them you will need to go to the SECURITY_SETTINGS table and adjust the list. See this link for full details.
  3. It was discovered that the REFNUMREQUIRED field value in the PAYMENT TYPES table was not operating as defined. This has been fixed.
  4. Under rare conditions the program was not properly recording the payment reference # (such as a CHECK NUMBER). This has been corrected.
  5. The table data export function has been modified so that it creates a file suitable for import using SQL BULK INSERT functions at the same time that it generates the standard SQL script file as it previously did. These are simply tab delimited files with each record delimited by a CR/LF pair. Under some circumstances these can be orders of magnitude faster to load into a test database than the SQL Statements mode.

    Also, when the export function starts it uses a MISCPARM setting to determine where to place the output files. The default location is :

    c:\ProgramData\quadrant\export\
    


    If you change this setting, (e.g. to point it to a network drive or other more convenient location) the program will save the setting and use it the next time the export function is processed.

6/14/2010 ver:1.0.2640

  1. A minor change to the legacy export function has been made which allows you to specify the values for the DESCRIPTION, COMMENT, and REFERENCE NUMBER fields when these fields are blank. In the past, the program automatically supplied a value to indicate that there was no other value present in the table. For example, if the COMMENT field was left blank the program would insert NO COMMENT in the export file.

    There are new EXPORT OPTION parameters that will be created automatically the first time you run the export process. These will default to the same values that the program previously inserted in place of blank values, so if you don't want to override the values, you won't have to make any adjustments. Specifically, these new parameters are as follows:

    EXPORT-BLANK-COMMENT-VALUE = NO COMMENT

    EXPORT-BLANK-DESCRIPTION-VALUE = NO DESC

    EXPORT-BLANK-REFNUM-VALUE = NO REF#

    If you want to use a different value than the default values shown, you will need to edit these settings. If you want the program to leave the value blank, adjust the setting for the specific field to the word BLANK. When the program sees the word BLANK it will remove any text in the corresponding field in the export file, if it is blank. Any other value in the fields will be left alone. Each of the three settings is fully independent of each other.

5/24/2010 ver:1.0.2634

  1. A minor change to the Cash Recap Report has been made which causes the receipt details section of the report to highlight the change given if it is not zero and not part of a voided receipt. No modifications to any of the calculations related to the report have been made.



    Also, the totals displayed at the bottom of the report include a new value which is the total of all the change related to the data displayed on the report (the ones that are highlighted, as noted above.)



  2. A minor change to the custom export format for the LAWSON GL system has been made to enable inclusion of an additional output field.

5/20/2010 ver:1.0.2633

  1. If your security level permits editing the RCPTHEADERS, RCPTDETAILS, or RCPTPMTS tables you should be aware that a few minor changes have been made to the functionality of the display grid and search filter options. For most of our users this will have no impact. We strongly discourage using the edit functions of table maintenance on these three tables, and at most sites, access to these tables is not permitted. Editing this data via the maintenance functions can lead to serious out of balance and data integrity problems. The recommended option is to use theRECEIPT-->Edit Data for a single Receipt option from the main menu.

    In previous versions when you selected any of these three tables the program would have a long delay while the entire table was read into the display grid. This could be hundreds of thousands of records and would take quite a long time before it would return the complete list and return control to you. We have modified this so that only the first 50 records will be loaded which takes almost no time at all. This will then require that you enter a search criteria in the white box at the lower left corner of the screen. This will usually be a receipt number (or partial receipt #). We do not generally recommend searching for just a register number, since this can effectively put you right back where you were in terms of the long load time. Most often you are interested in finding a specific receipt # or relatively short range of numbers.... so we suggest using something like these:

    001-00012% will return 1000 register 001 records, from 001-00012000 to001-00012999

    whereas

    001-000121% will return only 100 register 001 records, from001-00012100 to001-00012199

    The receipt number must be formatted correctly (that is 3 digits for the register #, a dash, and as many of the sequence number digits as you want to use. The fewer digits to the right of the dash, the larger your returned data set will be.

    For the RCPTHEADERS table you can also search for records on a specific ACCOUNTING_DATE. To do this you just check the '3' box to the right of the white text box, and enter the accounting date you are search for, e.g.,

    5/20/2010

    After entering the date, press the ENTER key to start the search. You cannot search using the accounting_date for the Details or Payment records, as these tables do not contain this field.
  2. A significant change to the wayuser passwords are stored and processed has been made. Please see this link for complete details.
  3. In the RASWIN program, it is possible to restrict the acceptable payment methods (e.g., CASH only, or CASH and CHECK but not Wire Transfer) for individual trans_codes. This has always been possible.

    Now you can control the default payment method for particular trancodes. This used to be limited to a single default method controlled by a MISCPARM setting. Please see this link for details on how to control this new feature.
  4. A newExport Format has been finalized for use with Mitchell-Humphries G/L software. This format is called RASWIN_7. See this link for details.
  5. A interfaces has been finalized for use withNew World G/L andNew World U/B software.
  6. The several SQL update scripts have been combined into a single script that provides all needed updates to the database tables, views, and stored-procedures used by the RASWIN program.