This article details out some common and known issues that are currently present when printing Statements in 7.0 and some early builds of 7.3. These issues are corrected in a future build of MacPractice that is currently undergoing testing. If you are currently on a 7.0 build of MacPractice, we strongly recommend updating to a 7.3 build as many of these issues will be corrected soon in 7.3. For questions and concerns about updating, please contact MacPractice Support.

Note: This is not a comprehensive list. If you encounter any additional issues, please contact MacPractice Support for assistance.

Credit On Previous Balance Causes Statement Balance To Be Off

When a user prints a statement with a start date, a Previous Balance item is printed as the first line item on the statement to summarize any transactions outside of the statement date range. This Previous Balance calculates any debit and credit that occurred on transactions prior to the statement date range.
However, a miscalculation occurs when the payment date falls within the statement date range, but is applied to a transaction outside of the statement date range. 

Workarounds:

1. Expand the statement date range to include the charges the payments are crediting. This can still cause the same issue if there are additional payments in the expanded date range applied to charges still outside of the date range.
   In Statement Manager, simply adjust the 'Print Transactions' start and end date in the Dates tab.
   In the ledger, you will need to go to Preferences > Statements > Statement Printing and change the date range set for your account statements.

2. Use no date range. This issue won’t occur if no date range is used at all, however that can produce an incredibly long statement, especially for large family accounts and patients with a lengthy clinical history at the office.

3. Use the Statement 4 Column form. The running balance column that causes some confusion is omitted with this form. Unfortunately, the previous balance still displays the bottom line. Additionally it displays the credit line items so it’s confusing for a patient to see that they owe the “previous balance” but there are credits showing on the statement.
   You can select a different form in Statement Manager with the drop down option in the bottom-center of the Statement Manager window.
   If printing from the ledger, you will need to adjust Preferences > Forms > Account Statement and change the default form there.

Past payments applied to current charges display issue

A patient has an unapplied payment from a past visit that was left as a credit, and then future charges are added and the payment is applied. If the statement print date range excludes that payment, the credit is not accounted for in the running balance and appears confusing. The more items on a ledger, the more confusing it becomes.

Workarounds:

1. Expand the date range to include the charges the payments are crediting. This can still cause the same issue if there are additional payments in the expanded date range applied to charges still outside of the date range.
   In Statement Manager, simply adjust the 'Print Transactions' start and end date in the Dates tab. 
   In the ledger, you will need to go to Preferences > Statements > Statement Printing and change the date range set for your account statements.

2. Use no date range. This issue won’t occur if no date range is used at all, however that can produce an incredibly long statement, especially for large family accounts and patients with a lengthy clinical history at the office.

3. Use the Statement 4 Column form. The running balance column that causes the confusion is omitted with this form.
   You can select a different form in Statement Manager with the drop down option in the bottom-center of the Statement Manager window.
   If printing from the ledger, you will need to adjust Preferences > Forms > Account Statement and change the default form there.

Print After date does not display items on that day

If you have transactions on the same date as the Print After date, the transactions on that date will not display on either the statement or the previous balance. If an office runs statements in the Statement Manager it is likely that they will have incorrect balances in the balance column if they have a print after date selected.

Workaround:

1. Select your print after date to a date that has nothing posted, so there is no fear of anything being omitted (most commonly the day prior).

Account Statement not printing without previous account or incident statements

In 7.0 and 7.3.6, if the patient has never had a statement printed before, you will be unable to print an account statement.

Workarounds:

1. Print an incident statement first, then the account statement will print.

2. Enable the preference to select a date range before printing. The account statement will then print, even if there is no date range entered. 
   This preference can be found in Preferences > Statements > Statement Printing tab.

Open

Printing Finance charges crashes MP

Present in only 7.0, but fixed in 7.3. When printing statements with finance charges, MacPractice crashes.

Workaround:

1. Sort Statement Manager by the finance charge column to bring all the assessed $0.00 finance charges in a group together. Then manually uncheck each of these $0.00 finance charges (the finance charge checkbox) so you are only assessing a finance charge for the patients who need one. Then print and it will not crash.

Open

Cannot Print Selected Transactions from Account ledger with archived incidents displayed

With the preference 'Print Transactions in Archived Incidents on Account Statements Printed from the Ledger' enabled:
Select the information you want to include in a statement from the account ledger, ensuring that archived incident information is available.
Navigate to the Print Drop Down Menu > Print Selected Transactions.
A statement line item will appear on the ledger, however it will not print. Attempting to open it produces an error. Attempting to print patient payments for a fiscal year when several payments are contained in archived incidents produces a similar error.

Workaround:

1. Unarchiving the incidents in question will allow you to print selected transactions.