PulseTec Solutions Support
Version 4.65 (database version 1.182) - 13/12/2006
Official Release Notes for V4.6.5 for CheckFree(Aphelion)
o Billing: Applied employee club access restrictions to Billing module displays and reports.
Any member-oriented reports will limit the results to those members where the home club is assigned to a location that the employee is allowed access for.
The event-oriented reports and displays is limited to showing events where there is one or more members associated with that event that the employee has access to the associated club. An example of this type of display is the history of billing events and associated billed members. An employee with access to only \'Club A\' will see any events that include \'Club A\' members and will see all details of those events in that display, including any \'Club B\' members billed in those events.
o Billing: For billing events, added details of billed charges to what is stored in the billing history data. This will allow for more detailed reporting of prior billings.
Similar history has also been added to the processing of billing returns (declines). In this case, the program now stores off the list of charges the declines are applied against. In the case where the declines logic is not able to identify a corresponding billing event, the program posts a new invoice and the added history then is linked to these added charges.
The display of member billing history includes new drill-down dialogs that show the details of related charges for specific billing and decline events. This drill down will only be available for new events processed after the feature of storing additional history has been implemented in the program. These new dialogs can be displayed by pressing the \'Details\' buttons within the \'Billing\' and \'Decines\' tabs.
o Added new \'Collected Billing Summary\' report. This is found under the \'Reports\' menu within the Billing module.
The report displays sums of billed and \'collected\' amounts using the following groupings:
Billing Type - Draft or Statement, based on how a member was billed
Aging - Current of Past Due (see detailed explanation below)
Invoice Category or Income Account - based on an input selected; values are derived from the billed invoices. Please note that the amount values are displayed in the report using 2 decimal places. When the amounts are calculated based on an income account categorization there is some division involved (charge contributions have to be divided based on line item contributions). In this case there is some roundoff involved and the totals may vary slightly from the totals calculated based on invoice category.
The report can list amounts for all selected clubs or by individual clubs.
This report examines the billed charges within all of the specified billing events for the range of dates selected. A charge may have been billed multiple times within the range of dates selected for the listed billing events, but the charge amount (and the paid amount of that charge) is only reflected once within the report. The categorization of that charge (current or past due, draft or statement) is derived from the most recent of the selected events from which that charge was billed.
\'Past Due\' versus \'Current\':
A charge is included in the \'Current\' category if the most recent billing event performed including that charge occurred in the same month or before of the charge due date.
A charge is included in the \'Past Due\' category if the most recent billing event performed including the charge occurred in a month after the month of the charge due date.
This is the sum of the charge amounts for all charges billed in the specified billing events during the selected date range. In some cases, this might not exactly match the billed amount as it is possible that a charge was already partially paid and the billing was for the unpaid amount of the charge.
This reflects the total paid amounts for all charges billed in the specified billing events during the selected date range. These paid amounts reflect all applied payments against these charges, whether from billing, front desk payments taken at the club, etc.
This report uses new history data that documents specific charges billed with each billing event. This feature was added to Fitness Manager November 2006. For billing events created prior to November 2006, the report logic looks at payments created through electronic billing and the charges to which they are applied to derive the results for the draft events.
Statement events performed prior to November 2006 (or whenever the corresponding update was applied at your installation) will not be reflected in the report.
o Billing: Added a new utility to apply negative payments. Please note that this function is independant of and in addition to the existing function to apply (positive) payments. This new function is accessed via the pulldown menu from \'Run\' and \'Apply Negative Payments\'.
The program looks for a number of different types of conditions to match payments against invoices and charges. There are five \'stages\' used to find these matches:
Stage 1: Match against negative invoices (\'credit memos\') where the billed member matches the payment member and the unpaid charge amount matches the unapplied payment amount. This is typical of a return and refund with a single charge, where the refund has been unapplied.
Stage 2: Match against negative invoices (\'credit memos\') where the invoice originating member matches the payment member and the unpaid invoice amount matches the unapplied payment amount. This is quite similar to stage 1 and handles the case of a multi-charge credit memo.
Stage 3: Match against charges linked to positive payments where there is a positive payment for the same amount and for the same member as the negative charge. Further, the logic in this stage requires that the positive charge us totally applied and the negative payment was posted on or after positive payment post date. This is a case of a decline-posted negative payment that has been unapplied.
Stage 4: Match against negative invoices (\'credit memos\') where the billed member matches the payment member and the charge has some unpaid amount. This is similar to stage 1, but where the unpaid amount of the charge does match the unapplied amount of the payment. In this case, the preference is to match the payment against the earliest due unpaid and negative charges.
Stage 5: Match against postive invoices where the billed member matches the payment member and the charge is partially or fully paid. The preference is to match the payment against the latest (most recent) due paid and positive charges. In this case, applying the negative payments will make a paid charge unpaid.
The inputs for the apply negative payments function allows individually setting whether the payemnts will be applied against positive and negative invoices. The options also include limiting an examination of payments based on selected member home clubs.
When the inputs are completed, the program creates a preview display of the payments and details of how they will be applied. The user has an option to deselect any payments in the list they do not want applied. The payments are not actually applied until the \'Process\' button is pressed.
The preview display allows accessing 2 related reports from the \'Reports\' pull down menu:
The \'List details\' report provides a printed listing similar to the display.
The \'Billing Impact\' report demonstrates the impact of applying the negative payments on potential billing totals. While applying negative payments does not impact member balances, it does increase the net charge total which the billing process examines. Typically unapplied negative payments are accompanied by unpaid credit memos or unapplied positive payments. This report examines the combined impact of these transactions and shows members where your billing totals may change.
o Billing: Fixed bug - When processing declines for the ACH billing format, the case of a returned credit transaction was instead treated as a returned debit transaction. The updated logic now properly distingushes these cases and only accepts entries where the transaction code indicates the expected transaction types.
o Billing: Fixed bug - The declines process now properly posts transactions for the case of a returned credit transaction. Earlier versions would create a history entry, but not create any new accounting transactions from processing the declines. The corrected logic will not create NSF fees for declined credit transactions, even if the return code settings would normally indicate to do so.
o Billing: Added subtotals by billing form of payment (Statement, Bank draft, Credit Card draft) to the totals printed for the \'Billing History over Range of Dates\' report.
o Billing: Added a new employee access switch to control ability to back out billling-related events for posting dues, billing and processing billing returns. The new option is on the \'Accounting\' tab of the access settings dialog and is labeled as \'Back out billing-related events\'. The value for the new setting will be defaulted based on an employee\'s current access to the billing module.
o Billing: Billing statement emails now generate a multi-part email that includes both a plain text and an HTML version of the billing statement.
o Billing: Made a number of enhancements to the Declines Notifications process:
- Inputs allows specifying a minimum balance to generate notifications for; the program generates a warning for any members who would otherwise be notified.
- The notifications preview screen (and associated report) now includes the last decline date in the member list.
- The notifications preview screen allows selecting which customers in the list are to be processed.
o Collections: Added the ability to filter against member home club in a number of the Collections reports. To specify selected club, select the menu entry of \'Club settings\' under the \'Reports\' menu. Regardless of the club filter selections, report results will be limited based on the allowed clubs that the logged-in employee is configured for access to.
o Configuration: Removed configuration of \'Contract sales account\' setting under \'Account Defaults\'. This setting is no longer referenced in the program.
o Configuration: When adding a new club, the program now checks if any membership plans are excluded from being offered at some locations. If so, the program prompts the operator whether membership plans should be configured as offered at the new club or excluded at the new club.
o Data Entry: When adding a family member, the program now verifies that the attendant has access to the primary member club\'s data. If access to that club is not configured for the attendant, an override dialog is presented requiring an employee log-in which allows adding a new member and access to the primary member\'s home club.
o Data Entry: Fixed bug - when converting a member to a prospect, sometimes the program would report an \'invalid date format\' error.
o Data Exchange: Added a detail preview of the transactions that will be imported in the Booking Plus transaction import.
o Front Counter: Fixed bug - the notes did not display when pressing that button on the \'Prospect Info\' screen. This bug was a regression introduced in V4.64.
o Front Counter: Fixed bug - selecting \'Referrals\' as an optional check-in display field would result in an error message and prevent completing the check-in.
o General: Added new capability related to fingerprint verification. Previously, the software supported the following optional fingerprint verification events: employee log-in, employee timeclock, employee prior to the open cash drawer, and member verification upon check-in. The program now adds an additional option to verify the trainer prior to a personal training check-in. If the option is checked and the check-in station is configured within Fitness Manager to have the fingerprint hardware installed, the program will prompt for the trainer employee\'s fingerprint prior to completing the training check-in entry.
Furthermore, the program allows optionally specifying that trainers must register all 10 fingerprints. This prevents the scenario where a trainer could have a single finger registered in their employee record and a different finger registered in a member record and use this combination to falsely record training check-ins. When the 10-finger registration option is configured and when registering employee fingerprints, the program will prompt as to whether the employee in question acts as a trainer; in that case 10 fingerprints must be registered. In a training check-in, the program will first prompt to validate the trainer\'s fingerprint. If the trainer has no fingerprints registered or only a single fingerprint registered, the program will require all 10 to be registered. If the trainer already has all 10 fingers registered, any of the trainer\'s fingers can be used to perform the validation. The program then prompts to validate the member\'s fingerprint. Since members can only register a single fingerprint, they will need to use the same finger to perform their validation. The program will also check that the member fingerprint does not match any of the 10 employee fingerprints and reject the check-in if they do.
To accommodate the new fingerprint logic related to personal training check-ins, the member verification now occurs after the type of check-in has been determined. Previously, this occurred immediately after the check-in member was selected.
The fingerprint verification options are set within the Configuration module under the \'Security\' and then \'Fingerprint verification\' menus.
A new access setting switch has been added to allow completing the check-in in the case of a failed member fingerprint verification for a training check-in . This access setting is set on the access settings \'Fingerprint\' tab and is labeled \'Personal Training override authority\'. This switch only applies if the trainer fingerprint verification is enabled. With a failed verification, the program will prompt for an employee log-in and password where the associated employee has the new access switch checked.
o General: Fixed bug - the \'Query Wizard\' function would sometimes fail when evaluating comparisons against string values with embedded quotes.
o General: the display of a member\'s check-in history now includes the check-in club number inline within the list. Also, several of the list column headers can now be clicked on to control the list\'s sort.
o General: When entering a member credit card number, the program now performs an additional validation test to check that the value of the credit card type that the card number evaluates to matches a \'configured\' credit card type (as set in the Configuration module, under the menu of \'Accounting\' and \'Credit Card\'). If this test fails, the program warns the user with a message of \'The credit card number evaluates as a \'[matching card type]\' card type, which is not an entry in your configured credit card types\'.
o General: Added support for new Discover card IIN ranges.
o General: Re-implemented graphs in Front Counter (check-in screen) and Expert module. The new implementation no longer requires the \'Graphics Server\' ActiveX control.
o Reports: In the \'Invoices by Date\' report, added remaining due amount at invoice level to report output.
o Reports: Added a new option to the \'Invoices by Date\' report to allow limiting the results to paid or unpaid invoices.
o Reports: Added an option to the \'Charges by Date\' and \'Charge Sums by Club\' reports which will allow including invoices assigned to \'cash customer\'. Perviously, these invoices were always excluded from the report results.
o Reports: Add a report to document the member query wizard expressions under menu item of \'Memorized\', \'Members\' and \'Query Listing\'.
o Reports: Added several new fields as choices for the \'custom sort order\' function in the member report and spreadsheet wizards.
o Reports: Added an option in the utility to \'Add charges to members\' which allows basing the members and amounts on a selected billing event.
One intended use of this new option is to provide a mechanism to reverse members\' accounts for a draft billing that has already been submitted for processing. To accomplish this, the \'Based on Billing Event\' option would be selected for this utility with the charge based on a fixed percent of -100%. The billing event would be selected and the invoice settings applied for a product which would not incur any taxes. This would post credit memos for the negative amount of the billed amount for each member in the selected billing. Then, using the Billing module, a billing run could be executed and submitted which allows refunds and would pick up these negative charges.
o Reports: Added a new report to list member dues grouped by service types. This report appears under the menu of \'Accounting\', \'Billing\' and \'Member Dues by Service\'.
o Reports: - In the \'Sales Summary\' report, added an option to apply the date filtering against the transaction post date or creation date values. Previously, the report would always apply the date filters against the post dates.
Post dates are user editable date values, which default to the current date and time.
Creation dates (sometimes referred to as \'system dates\') are internally assigned values and are always set based on the current date and time.
o Reports: In the \'Check-ins by Date\' report, added an option to determine if club filtering is applied against the home club of the check-in members or the check-in location. In earlier versions, this report would always filter against the check-in location.
o Reports: Added new option to \'Check Required Member Information\' utility to locate members with blank email address values.
o Reports: The \'Members with Remaining Visit Units\' and \'Members with Remaining Personal Training Units\' reports have been modified to reflect units associated with products marked as inactive. Previous versions of this report would exclude inactive products from the results.
o Reports: Reworked utility to purge prospect records based on expiration date. The updated and wizard-based utility now provides a preview of the prospects that will be purged.
o Reports: Fixed bug - when editing a Z-out entry, the display title would always reflect the local station ID number rather then the value associated with the edited Z-out entry.
o Reports: Fixed bug - the utilities to post loyalty points did not handle members with negative points balances. These members would be excluded from the preview of loyalty points to post and a \'range\' error would be displayed for each of these cases.
o Sales: In calculations of dues and terms proration values, the logic now considers the respective discount amounts. Previously, the proration amounts were calculated from the base amounts without including the discount.
Category: Release Notes
Copyright 2017 PulseTec Solutions. All Rights Reserved.