PulseTec Solutions Support
version 4.61 (database version 1.158) - 08/11/2005
Official Release Notes for V4.6.1 of Aphelion
Please note: Before updating to V4.61 you will need to go to Reports - Employee - Phone List and print this report to get a copy of every employee's Barcode ID as they will need to enter this as their User Name for module logins in the new version along with their password.
o Billing: Added preliminary support for processing Scotia Bank billing returns files.
o Billing: Added date of birth to \'utilization\' export file for Medica insurance billing, per revised Medica specifications.
o Billing: Fixed bug - the billed amount exported in the CIBC credit card format was sometimes off by one (cent) in the generated entries.
o Configuration: Added a new Configuration setting related to defaulting the assigned instructor for a personal training check-in. Under the \'General\' and \'Corporate Information\' menu entry, and on the \'Check-in\' tab of the displayed dialog, there is now an option which allows specifying whether the instructor is defaulted from the instructor assigned to the training product or the trainer assigned to the member.
The previous program behavior always defaulted the instructor for a personal training check-in based on the instructor assigned to the product and the new setting defaults to providing this same behavior. Some clients have requested this new logic to avoid having to create a training product specific to individual trainers.
o Configuration: Added the ability to print the club list, from the club browse dialog.
o Data Entry: Added a utility function that allows deleting all current enrollments for a selected group of classes. This utility is found under the menu item of \'Data Entry\', \'Products\' and \'Delete Class Enrollments\'. Access to this utility is based on the employee access \'Classes\' setting on the \'Data Entry\' tab.
o Data Entry: Fixed bug - fixed regression from V4.60 release which broke document scanning.
o Data Entry: In the data entry functions which allow manually posting an invoice or credit memo, you can specify \'payment schedules\' which results in the program creating multiple charges at staggered due dates. Previously the program would always create a single invoice, regardless of the number of terms entries in the payment schedule. The program has a new checkbox, labeled as \'Post individual invoices for each charge\', which will instead create separate invoices for each of the resulting charges. When this new option is checked, each invoice is assigned the same post date as the associated charge\'s due date. Each invoice also receives its own receipt number.
The option to create invoices for each charge is disabled when the invoice product has attributes that make the quantity sold significant: it is for an inventory product or a product that will post \'visit\' units. The reason for this is that each invoice will have an associated product detail and since the program currently is limited to integer quantities, posting multiple invoices would distort the quantity of product sold in this case.
Whether this new option is checked has no effect on the resulting account balance and aging. It will affect the results of the accrual income by account report, when the report is run against invoice posts dates. This is because, with the new option checked, the associated invoice post dates will match the charge post dates. If a date range is specified for the report that encompasses a subset of the charge due dates, only those charges will be included in the report results.
o Data Entry: Fixed bug - when using the \'Add Invoice\' function to sell a personal training or visit unit and setting an expiration date, the expiration date value was not saved.
o Data Entry: When using the \'Add Invoice\' function to sell a personal training or visit unit, modified the logic to date the training/visit unit based on the post date rather then the system date.
o Data Exchange: Added support for exporting and importing customer \'Effective Date\' field.
o Front Counter: Modified the criteria to display the list recent check-ins. Previously, the program would display all check-ins from the start of the day through the current time, where the criteria was applied based on the database server\'s date and time settings. This criteria includes the cutoff through the current date and time to avoid always displaying records with odd check-in dates that occur in the future (this is not a normal condition, but it can occur). Since the date and time values written into the check-in record are from the check-in station, it is possible that this list would not immediately show new check-ins if the station clock is ahead of the database server\'s clock. To correct this, the cutoff criteria has been altered to include any check-in records written less then an hour after the database server\'s current date and time.
o General: Added the ability to define product pricing on a club and membership-type basis. Previously, product pricing could be defined at the product level with pricing over-rides optionally assigned at the club level. The new behavior provides a mechanism to further over-ride pricing at club and membership type levels.
When a product is sold, the program checks if pricing has been established for that club location and for the associated membership type. If this pricing is set, it is used. If not, the program then checks for club-specific pricing for that product. If neither is available, the regular pricing set at the product is used. If the pricing at the club and membership level is set, then no additional membership-type associated discount will be applied as it can be when pricing is set at the product or product and club level.
The user interface to set the pricing over-rides has been reworked to provide this new pricing facility in an intuitive manner. As part of this redesign, the club-specific settings related to product redemption and inventory reordering has been moved into separate dialogs.
o General: Logging into the programs now require both the employee \'User Name\' and the \'Password\'. The \'User Name\' is the same value that was previously labeled as the \'Employee ID\' or the \'Employee Barcode ID\'. In prior releases, only the \'Password\' field was required to log in. This change provides a more secure system and also removes the requirement for unique employee password values. The \'User Name\' field continues to require unique values and is used to identify the employee that is being logged in. The password is then used to authenticate the matched employee.
The employee passwords are no longer directly stored in the database. Instead a mathematically derived value is calculated from the password entries and stored with employee data. When a password is entered, the program calculates this value and compares it to the stored calculation. With this change, password values are no longer displayed when editing employee entries; instead the values can only be reset and requires the password to be entered twice to confirm the value.
In a related change, earlier releases had a configuration setting (found in the Configuration module, under the \'Corporate\' and \'General Information\' menu, and on the \'ProShop\' tab) which determined whether setting salespersons in the front counter was performed using the \'Employee ID\' or \'Password\' field. This setting is now implemented as a checkbox labeled as \'Require password confirmation when setting salesperson\'. The dialog to set up to 3 salespersons and their percentages of the sale now always takes \'User Name\' entries. If the configuration checkbox is checked, then as each user name is set, the corresponding employee password is prompted for.
o General: Fixed bug - fixed regression from V4.60 release which caused any Payfuse transmission initiated by the Aphelion desktop programs to record the results in the report log results for Payfuse. This regression did not affect the program\'s transmission of these transactions and results were still reported to the operator, but results were not logged on the client database side (results are still available from the Payfuse web site).
o General: The general member editing form in Data Entry as well as the \'Quick Add\' form present in several module allow using a bank check reader by pressing the \'Scan\' button adjacent to the \'Bank Account\' field. In prior release, only the values returned by scanning a US check could be parsed. This new release adds support for parsing bank route and account information from the MICR print on Canadian checks.
o General: Added the capability to delete a locker rental history entry. Also, the \'release\' function can now be applied to an expired locker rental. Without releasing or deleting an expired locker rental, it will continue to trigger a check-in alert for the associated member, unless a new locker rental has been created for that member.
o General: Fixed bug - corrected memory leak in United Kingdom Postcode Anywhere lookup address and bank lookups.
o General: Fixed bug - the \'Print Invoice\' function to print a summary of an individual invoice when viewing a member\'s \'Invoice History\' would incorrectly print some of the address information from the originating member under the billed-to member.
o Data Entry: Fixed bug - the member editing screens (both the regular editor from the customer browse and the quick-add version) no longer display products in the dues service list, where the products are set to an inactive status. Please note that the billing module does not bill for any dues associated with inactive products.
o General: Now display a \'Tracking ID\' value associated with member status entries. This is a unique integer value that is sequentially assigned by the database to each status entry and may be useful as a way to identify a member status change.
o General: Changed description for customer query wizard field from from \'Starting date of current contract\' to \'Effective Date\' to be consistent with the label used when editing this field.
o Reports: Added new options to the \'Income by Account\' reports. For the \'cash\' version, the date range filtering condition can now be optionally applied against either the dates payments are posted on or the dates payments are applied to charges. For the \'accrual\' version, the dates can now be against either the dates invoices are posted or the due dates on the charges. Earlier versions of these reports always filtered against payment or invoice post dates. In the \'cash\' case, where the dates filter is set to be against the dates payments are applied, the program still lists the sum of any unapplied payments posted over that date range.
o Reports: Fixed bug - the \'List Prospects that Converted\' report could incorrectly pick us members converted to collections.
o Reports: Fixed bug - \'Discounted Sales\' report would round discount amounts to the dollar in subtotals and grand totals.
o Reports: Fixed bug - \'Members with Expired Lockers\' report would not exclude lockers marked as open-ended.
o Reports: Added option to print \'Prospect Call List\' report for regular members only.
o Reports: Added new report to list payments applied over a specified date range, under the menu of \'Accounting\', \'Transactions\', and \'Payments applied by date\'.
o Reports: The \'Purge Paid Transactions\' utility performs an iterative process to generate lists of invoices and payments through the specified cutoff date that are completely paid/applied and only involve transactions within the two lists. The maximum number of passes to allow this comparison to converge has been increased from 30 to 50.
o Sales: The \'Contract Summary\' report has been reworked to clarify the reports results.
Previously, the report included columns headed by \'Initial Charge Due - Date/Amount\'. For this amount column, the program would report the sum of the initial terms charge due after the contract sale date for each invoice created with the contract. For the date it would report the earliest due date after the contract sales date. These values are not very useful and are highly dependent on how the charges for a contract have been grouped into invoices.
The program now shows the heading for these columns of \'Terms Due After Sales Date - Earliest Due Date / Total\'. The amount now shows the sum of all the charges due after the contract sale date that were created with the contract. The date is still the first due date that occurs after the contract sales date.
o Sales: Added an option to generate contract invoices where a single invoice is created for each charge. This logic is only applied to invoices that are for non-fee and non-\'visit\' add-ons. The option is set under the \'Setup\' and \'General\' menu, by checking the item labeled \'Post terms charges using individual invoices for each due date\'.
Sales: The program will now update the amounts in an existing due service entry where there is a corresponding service entry in the contract, regardless of whether there is a non-zero dues amount associated with that contract service. Previously, the pre-existing dues service amount would not be disturbed if the contract service had no dues amount associated with it.
Sales: A dialog is displayed at the time of approval showing any pre-existing dues services for the contract members that do not correspond with services defined in the contract. The operator is given a choice to remove all of these additional dues services, leave them as is (this corresponds to the prior program behavior), or cancel the approval process.
Category: Release Notes
Copyright 2017 PulseTec Solutions. All Rights Reserved.