Quadrant Systems RASWIN Release Notes 2012-2013

8/26/2013

New features and functions are added to the software usually in response to specific requests by our clients. The nature of these changes may include interfacing data to or from any new system, such as utilities or parking or business license or building permit type systems. We try to implement these in as generic away as possible so that in the event that other clients eventually use the systems, there is little as possible customer specific set of code wrapped around these interfaces, however, there are always certain things that are so tied to the specific customer site, that we do have logic in the program that operates only for a specific clients.

Also, since no software can ever be 100% error free we make corrections to logic errors as soon as discovered as well as changes designed to improved program performance. Not all of these changes affect all users, since not all functions are in use at all of our sites.

Programming new interfaces almost always requires the addition of new tables, modifications to existing tables or to stored procedures which process this data inside the database. In the past we have tried two approaches to implementing these types of changes.

Initially, we included the code to make the changes inside the main application; this had the advantage of simply installing the new primary program. At startup the changes needed were implemented automatically by the application and required fewer additional steps for the user. However, it could lead to situations where one user upgraded and another had not the changes that have been made, rendered the older systems in operative or functioning in a matter different than what they used to as additional changes and features were added.

Gradually, over time, this became unwieldy and we moved as much as possible of this code to an external program that would have to be run once during the upgrade process. We also found that changes we expected to be made by this external program were not getting processed because sometimes the update process was not being executed, and new features in the new program or corrections for errors, which relied upon the changes to have been applied, were not working properly.

As a result, we are moving back to the original scheme so that the installation of the new primary executable program will take care of everything needed.

Unfortunately, it still leaves the situation where in the name of progress we are adding new features or fixing errors but it forces all workstations to be updated with the new version.

Many of our sites do not have a full-time data processing support staff, and fewer still have database expertise in-house so it forces us to try to make the application do the work automatically. This usually works well, but it does require that all workstations be on the same version, so they are not fighting each other for a particular database format or content.

It would be great if everything could stay the same for everyone all the time but this is just wishful thinking.

Since early 2012, we have implemented many changes for custom interfaces for clients who requested new functionality and numerous program enhancements and bug fixes. Unfortunately our devotion to maintaining a detailed change summary was replaced with an effort to keep the user manual documentation up to date. This year we intend this year to do both. If you find we are not, please let us know.

2012-February 2013

A bidirectional parking interface using the Duncan parking system. Most of the payments are processed by Duncan at an internet site and mail processing facilities they maintain. A nightly export of processed transactions is sent to Quadrant and imported item by item, so the revenue gets to the proper accounts in the g/l system. At the local level, payments are processed over-the-counter and validated against a master list of unpaid citations, then uploaded to the web site for application to the proper accounts each day.
The interface to Advanced Utilities was implemented at client site in Idaho.
An on-line interface to the Cayenta utility billing system was implemented about a year ago. It includes the ability to query account balances post payments online and to post payments off-line with a later application of the off-line payments in a batch mode.
A interface to the Amanda building permit system in a Seattle area city was implemented. It includes the ability to query account balances post payments online and to post payments off-line with a later application of the off-line payments in a batch mode.
RASWIN credit card processing has been updated to comply with changes dictated by new credit card security requirements, including encrypted passwords, passwords that expire after a certain period, refinement of exactly what data we store in our database related to credit card transactions, and many other small details.
Many changes were required to support Windows 7.
Most newer computers do not come with parallel printer ports. RASWIN was modified to work with Epson USB printers using a special driver supplied by Epson. If you find you need a USB printer interface due to a new computer installation we can supply a replacement interface card for your older Epson printers for a small fee.
We are gradually moving away from the use of Crystal reports, which is a great reporting tool, but difficult to integrate into the underlying software we are using. The latest incarnation of reports within RASWIN utilize HTML and CSS (style sheets) technology and represent replacements for the older Crystal reports versions as well as some of the older non-Crystal reports that we generated (such as the Cash Recap Report and Quick Transaction Codes List).
After initial recommendations from the first few clients who started using these reports we’ve implemented a way to customize their appearance in terms of font sizes and to some degree, layout, although there is still a general format that is used to present the data for different topics, just as there was with the older Crystal Reports.
A quick reporting tool has also been added that allows you to get very fast answers to questions using extremely simple SQL queries which we can help you create.
RASWIN has long had the ability to reprint a customer receipt on demand. We recently added the ability to re-endorse a check in the event that the check was endorsed on the wrong side or the printer map malfunctioned. You can also now re-validate a document.
A new function has been added to the Main Menu under the Help option to allow you to easily size the RASWIN screen to 70, 80, or 90% of the screen size. In the past we made attempts to save the screen size and location in the Windows registry, but we have found with Windows 7 that security policies implemented in many customer sites do not allow access to the registry in an unrestricted fashion. Since we can’t control this across many sites we’ve simply given up trying to store the location of the screen, but may revisit this again in the future, perhaps with just a local text file containing the four values that we need to store.
Throughout the RASWIN, we have also implemented refined error tracking to assist us in analyzing log files when problems occur. The log files are of great assistance to us in tracing the data that was input how the program responded to it and the results.

March 2013

At the request of the client who is relocating their entire data center from their local data center to a site 1,500 miles away we spent a good deal of time reviewing and optimizing the startup processing cycle, from the time the program icon is clicked until the screen is first available for processing.

In a local processing environment with the server of the same network, we were finding that program startup was in 1 to 2 second range and thus it was not overly important that this process be fully optimized. Once the data center was moved we found that amount of data that being sent back and forth between the server and the clients was causing a lengthy startup delay of up to 30 to 45 seconds. After working on the problem for several weeks, we concluded that it would be possible to place a lot of the functions happening in those first few startup seconds into a single stored procedure that would run on the server itself with a single call from the client. This work is on-going.

April 2013

The logfile name was established once at program startup only and thus was not being reset if the user left their computer running overnight without exiting RASWIN. Now it is reset each time anything is written to the file. As before, there is a logfile per calendar day written to the local hard drive of the computer.
Changes to the AIMS parking interface were made to insure that it is not possible for records from a multiple line receipt (containing more than one ticket) can’t be inserted via the interface more than one time. As payments are processed they are inserted into a ‘working table’. At the end of the processing the system loads the values from this table into an in memory array (which can contain up to 500 ticket items on a single receipt). These are then processed one at a time to insert them into the AIMS parking system and as each one is processed the temporary record is deleted from the Quadrant working table. Thus, once it is into AIMS it can’t be posted a second time. Also, in cases where the payment reference number (such as a check number, cc approval number, etc.) is found to be blank at posting to AIMS (because the payment records are typically processed AFTER the line items are processed and no payment reference number exists at that time) the system will check any payment records for a reference number and use that value.
On the table maintenance screen, the system now double checks the key values (first column) to see if the user has entered a % sign as part of the key value. Since the % sign is a SQL wild-card character it is inappropriate as a record key. In such cases, the program will automatically change the % sign entered to !. If this is not your desired value then you can change it after adding the record.
A client discovered that in cases where multiple departments are in use the system was not properly filtering codes that are permitted for use in one department but not in another. This has been corrected so that only codes explicitly listed in the DEPTTRANS table are allowed to be processed by users in the department to which they are assigned.
We found an error in the logic that checks for previously posted transactions when you try to delete a transaction code via table maintenance. Regardless of whether there was any history or not, the program thought there was. This was corrected so you can delete a transaction code that has no history, but not one that does, which was the way it was supposed to work to begin with.
A minor adjustment was made to for the values in the TranCodes table SHORT_DESCRIPTION field to valid values. These are used a ‘report grouping’ codes for the custom reports. In order for this process to function correctly, each code needs to be delimited with forward slash characters.e.g, you might have /PD/NSF/. This would permit special reporting for codes related to the PD and all NSF checks. (The specific meaning of these codes is totally up to you, but we always suggest trying to use codes that seem meaningful). If the / characters are not present, the reporting functions won’t properly recognize which trancodes belong on which report. The change we made checks the values and insures that a / is added at the start and end of each existing code, and also that any // (double slashes) are replaced with just a single /.
4/9/2013
The EDIT DATA FOR ALL RECEIPT option on the RECEIPT sub menu was not working correctly. If you adjusted the payment data it was adding a new payment instead of updating the existing one. Also, the CHANGE_DUE field at the header level was being calculated properly, but not displayed properly. Both of these errors have been corrected in version 3798.
4/18/2013
1. On startup the screen should initially size itself to 80% of your screens physical width and height.
2. Font sizes on the three primary receipting screens (receipt summary, line item entry, and payment entry) are better synchronized in this version. On the receipt summary screen there is a small Up/Down button in the lower left corner of the screen that you can use to adjust the base font size. The setting you select will be stored in the xxx-RCPT-FONT-SIZE setting in the MISCPARMS table. (the xxx is tied to your register number, so this setting is unique to each machine to account for differences in screen resolution and personal preference). There are two additional settings that are linked to specific areas of the screen: the function keys and the grid areas that show the line item details and the payment details. These settings are xxx-RCPT-FONT-SIZE-FKEY-MULTIPLIER and xxx-RCPT-FONT-SIZE-GRID-MULTIPLIER. These use the base font size and act as 'multipliers' to cause the font in the relevant areas of the screen to be slightly larger than the base font. Initially these are set to 1.2 for the KEY's and 1.3 for the GRID, which should give reasonably proportioned sizes. If you find that you want them larger or smaller you can adjust them manually in the FONT SETTINGS table via normal table maintenance after they have been set to their initial default values.
4/26/2013 version 1.0.3811
1. Last week we made some starting changes to handle font sizes on the receipting screens better than in the past. This release brings these changes to most of the other screens using the same settings noted in the 3810 release, item # 8.2 above. As of this release the only place you can change the 'global' font size (the one that applies to most screens) is on the main receipt screen (not the line item entry screen, but the one that it goes back to after adding a receipt item.), or manually via table maintenance.
  
  This setting is stored in one place and used by nearly 100% of the screens unless space is a major issue.
  
  Older versions included a font size adjustment 'up/down' button on many individual screens and stored these as separate values. These settings are no longer used and will be deleted from the database entirely in a future release .... they may still be there for a while (but they will be ignored).
2. The option to select the method with a single click has been removed because it created issues that most users would not see in normal operations but some would depending on the way they select the payment method. We found two issues related to this: 1) if you used the arrow keys to select the method it was assuming the first method you ended up on was the one you wanted and jumped immediately to the payment amount field even if you had not yet selected the desired method 2) The reference number field was not being turned on or off as it should have been (depending on your setting for each payment method in the PAYMENT TYPES table), if you used the F2 or F3 buttons on the payment screen.
  
  To select the method you can use your up/down arrow keys, type the first letter or two of the method you want, or use the mouse. You can then either click on the next field (usually payment amount) or hit TAB or ENTER to advance.
  
  In effect, it is just a single click to select the method anyway, as once you chose one you simply click on the payment amount field instead of on the method you have selected. Same result with one click.
3. The void screen was letting you process the void without selecting a void reason if you entered a receipt number and clicked directly on the PROCESS button instead of hitting enter or tab to advance to the REASON drop down list.
  
  Now if you click on PROCESS VOID without a method having been selected it will position you back in VOID REASON selection drop down list to pick a valid reason.
4. On the receipt entry screen the Quantity you entered was initially being stored correctly but changed to 1 when you ADD (F4) the line item. This has been corrected.
5. For users who are processing receipts using our 'limited' volume licensing setup, the processing related to determining how many receipts you have processed now has two options for figuring this out. In SQL Server there are two ways to find records that match a criteria. In the case of the logic related to figuring out how many receipts have been processed we perform a query to check the DETAIL_VIEW to count the number of receipt line items that have been completed for a given register in a given period of time (either the current calendar year or the current month). This query takes the general form:
  
  select count(rcpt_number) as trancount
  from detail_view
  where receipt_number like '001%'
  and year(accounting_Date) = 2013
  
  or
  
  select count(rcpt_number) as trancount
  from detail_view
  where substring (rcpt_number,1,3) ='001'
  and year(accounting_Date) = 2013
  
  The difference is in 2nd line and is the method of determining which register is to be checked, using either the "=" or 'like' operator. It is not always possible to determine which of these two methods will perform best in any given environment as different users have different SQL setups, different versions, and other factors which can affect the speed with which the needed value is determined. In our own testing with very limited amounts of data the difference is so small we can't determine any advantage to one method over the other, but we have only a few thousand transactions to test with; in a production environment you might hundreds of thousands to check.
  
  We therefore added an option to allow you to choose between either of the two options using a new parameter in the LICENSE table called
  
  LICENSE-CHECK-MODE
  
  The setting will default to LIKE (VALUE CAN BE LIKE OR SUBSTRING) Internally, the program only looks at the first character ( L forLIKE or S forSUBSTRING) but to make it easier to know what your options are we have put the extra text following this first character to remind you what your options are.
  
  If you are experiencing delays when the program does the test to determine how many receipts have been processed give the SUBSTRING option a try by changing the value to :
  
  SUBSTRING (VALUE CAN BE LIKE OR SUBSTRING)
  
  And see if that gives better results in your database environment.

May 2013

5/1/2013
1. A few screens needed minor adjustment to font sizes due to recent changes we've made to the way they are set and re-sized. This work is on-going.
5/6/2013
1. A new option called QUADRANT DOWNLOAD MANAGER is available on the FILE menu. This allows you to download predefined files from our web site with very little effort. The initial setup of this will be done when you install the RASWIN program using the SETUP_RASWIN_EXE.EXE program. From that point forward you will be able to perform downloads from within the RASWIN program itself. These downloads will be placed in the
  
  C:\PROGRAMDATA\QUADRANT\DOWNLOADS
  
  directory. A running program can't replace itself so it will still be necessary to exit from the RASWIN application once the download is complete so you can copy the updated version to it's proper location. We are working on a method which will do this automatically but at the current time this is not implemented. Access to the FILE→QUADRANT DOWNLOAD MANAGER is controlled by security level and by default requires a 99999 security level. This can be adjusted to a lower level via table maintenance.
2. A new menu option is available on the Main Menu → HELP sub menu that permits you to view the current release notes on our web site (internet connectivity required).
5/16/2013
1. Two new standard exports have been created, one in CSV format and the other in XML. These new formats allow you to define a list of fields and the order in which they will appear in the export file. If you need a CSV or XML export file for import into a spread-sheet or another financial application this will be of use to you. Setup is quite easy.
  
  These new export options can take the place of one or both of the existing file formats used during your standard 'Create Upload File' process. Contact Quadrant support for details on the setup of this option if you want to use this.
  
  For both formats, the fields that can be included in the export file are listed below:
  - ACCOUNTING_DATE
  - BANK_CODE
  - COMMENT
  - CR_ACCOUNT
  - DESCRIPTION
  - DR_ACCOUNT
  - EXTENDED_FEE_AMOUNT
  - PAYER_NAME
  - RCPT_DATE
  - RCPT_NUM
  - RCPT_SEQUENCE_NUM
  - RCPT_TIME
  - REF_NUMBER
  - REG_NUM
  - SYSTEM_CODE
  - TRAN_CODE
  - USER_ID
  A sample of the XML format records looks similar to this
  
  <?xml version="1.0" ?>
  <RASWIN_EXPORT>
    <TRAN_RECORD>
      <RCPT_NUMBER>001-00127720</RCPT_NUMBER>
      <SEQUENCE_NUMBER>0001</SEQUENCE_NUMBER>
      <USER_ID>JD</USER_ID>
      <SYSTEM_CODE>RV</SYSTEM_CODE>
      <FEE_AMOUNT>150.00</FEE_AMOUNT>
      <CR_ACCOUNT>99-99999098-99999</CR_ACCOUNT>
      <DR_ACCOUNT>10-45352323-55313</DR_ACCOUNT>
      <REFERENCE_NUMBER>2013000565</REFERENCE_NUMBER>
      <COMMENT>NO COMMENT</COMMENT>
    </TRAN_RECORD>
  </RASWIN_EXPORT>
  
  In an upcoming release we plan to create a similar XML format that will contain ALL information about each receipt in a single XML export file. This will have the following general structure.
  
  <?xml version="1.0" ?>
  <RASWIN_EXPORT>
    <RECEIPT>
  
     <HEADER_RECORD>
      <RCPT_NUMBER>001-00127720</RCPT_NUMBER>
      <USER_ID>JD</USER_ID>
      <RECEIPT_TOTAL>150.00</FEE_AMOUNT>
      <TOTAL_TENDERED>150.00</TOTAL_TENDERED>
      <CHANGE_DUE>0.00</CHANGE_DUE>
      <ACCOUNTING_DATE>4/15/2013</ACCOUNTING_DATE>
      <CALENDAR_DATE>4/14/2013</CALENDAR_DATE>
      <RECEIPT_TIME>09:37AM</RECEIPT_TIME>
     </HEADER_RECORD>
  
     <DETAIL_RECORD>
      <RCPT_NUMBER>001-00127720</RCPT_NUMBER>
      <SEQUENCE_NUMBER>0001</SEQUENCE_NUMBER>
      <SYSTEM_CODE>RV</SYSTEM_CODE>
      <FEE_AMOUNT>150.00</FEE_AMOUNT>
      <CR_ACCOUNT>99-99999098-99999</CR_ACCOUNT>
      <DR_ACCOUNT>10-45352323-55313</DR_ACCOUNT>
      <REFERENCE_NUMBER>2013000565</REFERENCE_NUMBER>
      <COMMENT>NO COMMENT</COMMENT>
     </DETAIL_RECORD>
  
     <PAYMENT_RECORD>
      <RCPT_NUMBER>001-00127720</RCPT_NUMBER>
      <SEQUENCE_NUMBER>0001</SEQUENCE_NUMBER>
      <PMT_METHOD>CASH</PMT_METHOD>
      <AMOUNT_TENDERED>150.00</AMOUNT_TENDERED>
      <REFERENCE_NUMBER>NONE</REFERENCE_NUMBER>
      <PAYER_NAME>BILLY BOB</PAYER_NAME>
     </PAYMENT_RECORD>
  
    </RECEIPT>
  
  </RASWIN_EXPORT>
5/22/2013
1. The font size in the section of the screen that displays the output text on the receipt printing/check endorsement/document validation screen has been adjusted to be 2 times the 'global font' size instead of the same size. This makes it a bit easier to read and there was plenty of space available on the screen to do this.
2. On the main menu screen the message about 'check accounting date' was displaying regardless of whether the calendar date and accounting date were the same or different. This has been corrected.
3. We think we have finally solved the issue of the Unit Fee / Quantity / Discount Rate fields on the line item entry screen not highlighting correctly when you enter those fields to edit the data. As of now, when you enter the fields (whether under program control, by tabbing into them, or clicking on them) the entire current text will be highlighted. If you want to type in a new value this should result in automatic deletion of the existing value and it will be replaced by your new entry. If you want to adjust an the values, simply use the cursor keys to move to the right and edit your entries. If done this way it will be necessary to manually delete anything that you need to. This is pretty much standard windows behavior.
  
  One new thing that is available (only for the Unit Fee field) but which probably won't be needed given the corrected behavior described above is that you can press C to clear the field, and H to highlight it completely. At present this will only work in the Unit Fee field.
5/31/2013
1. In some circumstances the pricing rules associated with each trancode in the trancodes table (such as F = Fixed, G = Greater Than, L = Less Than, etc) were not working correctly. Even if your entered price properly complied the defined rules, a warning message saying that it did not would appear. This has been corrected.
  
  Also, in the case of rule F the program will set the price to whatever value you have preset and regardless of whether you change it or leave it alone during entry, and will reset it to that value when you leave the unit fee field. In earlier versions it would permit you to change it and then display the warning message that it must be that preset amount. Now it just makes it that value. F really does mean FIXED!
  
  If you want to have a preset price but to be able to adjust it you must use rule v [= Variable] and set the default price in the trancodes table in field default_amount_1
2. For some time RASWIN has contained a setting to restrict what keys are allowed to be used in the trancode field on the line item entry screen. This setting is called FILTER-TRANCODE-KEYS. By default, the following keys CAN'T be entered as part of a the trancode field:
  
  / ; : [ { ] } \ | ! @ # $ ^ & ( ) + = < . > / ? ~ ` _ " (and a space)
  
  In earlier versions we also allowed you to include the - (hypen) as a restricted character. This has been removed. If you have a compelling reason to include any of the above characters (such as a $ or +) in your trancodes you can allow this by edited the FILTER-TRANCODE-KEYS setting in the MISCPARMS table.
  
  Generally, we recommend against any characters but letters, numbers, and perhaps the hypen as part of the trancode. Making the user enter punctuation can be troublesome (e.g, the difference between [, { and (, or ; and : can cause confusion, and lead to entry errors.
  
  Also, having to press shift the get any of the 'top row' punctuation characters can slow the user down at bit, so we discourage their use.
June 2013
1. The CASH RECAP REPORT was printing too wide for one of our clients on their particular printer. We modified the settings to make the print width slightly narrower than before, and adjustable.
  
  First, you can control the overall width of the detail sections of the report as a percentage of the page width.
  
  The setting that controls this is called
  
  CASH-RECAP-PAGE-WIDTH
  
  the default value is 95 (which means 95%)
  
  Second, the detail section of the report contains 4 basic columns. These display the information about each receipt. These settings can be adjusted from their default values to cause the width of the individual columns to be narrower or wider as best fits your data. Note that the total values should not exceed 100 which represents the total width as a percentage of the defined report width. The system does no checking to validate that your entries exceed a total of 100. The settings are:
  
  CASH-RECAP-DETAIL-COL1-WIDTH     15
  CASH-RECAP-DETAIL-COL2-WIDTH     30
  CASH-RECAP-DETAIL-COL3-WIDTH     30
  CASH-RECAP-DETAIL-COL4-WIDTH     15
  
  If you find that your columns are narrower that you would like and you have no issues with data being truncated, you can try increasing the default settings a little bit at a time to increase the sizes of one or more columns.
2. The font size on the PROFILE screen is based on a fixed 'global' font size which you set on the main receipt screen. For some screens resolutions the resulting font size is too small. We therefore added a new setting to allow you to adjust the profile screen font size as a multiple of the base font size.
  
  xxx-PROFILE-SCREE-FONT-SIZE-MULTIPLIER 1.5
  
  Note that the xxx in the above sample is really the 3 digit register number, which allows you to have a different multiplier value for each workstation. The default value is shown above but may require minor adjustment up or down to best fit your display resolution.
July 2013
1. The export table data and send logfiles function has been improved. In older versions you could export and send only one file at a time. You can now do multiple table exports and then upload them all at once.
  
  This works as follows:
  
  To tell the system which tables to export and send you just need to check the items by clicking on the check-box next to the table name in the scrolling list at the top left side of the screen. There is also and option to clear all checked files and another to check "Key Tables". The 'Key Tables' are the most important tables used by the system and will often be those that Quadrant support requests you to send. Exporting all of the key tables does not take much longer than exporting just one or two of them.
  
  After selecting the tables you want to send click on EXPORT and then SEND. Note that the SEND button will not be available until you have completed the EXPORT function.
  
  When the system sees the checked box it will export the last table and then branch to the SEND FILE screen. A new way to select which files you want to send is now to to simply check the names of the files you want to send and the clicking on SEND.
  
  It will then send all of those files with a single click of the SEND button.
August 2013
1. An error was found in the logic related to AUTOMATIC TRANSACTIONS that caused them not to function correctly when they were part of PROFILE TRANSACTIONS. This has been corrected.
2. The logic related to loading and displaying the function keys on the transaction entry screen has been reviewed and adjusted to cause the keys to load only once when the screen is initially displayed instead of each time the keys need to be displayed. The time it took to do this was very small to begin with and on most computers you never would have noticed the difference in the speed of display. However, it did place an additional burden on the database in terms of repeated access.
  
  Also, the priority for loading the keys was slightly adjusted so that it is now USER, REG, DEPT, then the global defaults. The user manual documentation was updated to reflect this adjustment. See this link for full details.

Quadrant Systems RASWIN Release Notes 2012-2013

8/26/2013

2012-February 2013

March 2013

April 2013

May 2013

June 2013

July 2013

August 2013