Restrictions of the Beginning Balance Method

1. Deposit Charges may not be included in a Beginning Balance record. This is due to the fact Deposit Charges is are mapped one-to-one to Deposit Refunds.

2. Deposit Refunds or Refunds may not be included in a Beginning Balance record.

3. More than one type of Financial Transaction may not be represented in a Beginning Balance record. In other words, a Beginning Balance record may look like a Payment record or an Sale record, but not both.

4. An Account may not have more than one Beginning Balance record. If an Account requires more than one of the following:

   1. Unallocated Payments.

   2. Unallocated Sales.

   3. Unallocated Store Credits.

   historical data will need to be imported.

5. Beginning Balances do not show up on Sales, Payments, Credits, or Deferred Revenue reports. They also do not show up as "Tax Billed" on the Sales Tax report. However, subsequent payments will show up as "Tax Paid" on the Sales Tax report.

6. The payhist.startdate and payhist.enddate for Beginning Balances are for all intents and purposes are ignored. No monthlysale table records are created and they are not considered with computing tax exemption amounts.

7. Manual Allocations may be made to Beginning Balance records. However, Manual Allocations "from" Beginning Balance records are not allowed. In other words, when receiving a Payment, the Payment may be made to a Beginning Balance record that represents money owed. However, the Beginning Balance record is not available in the Charges/Deposits list to Allocate it to the Payment.

8. The Beginning Balance record must be the earliest in Account history. In other words, when doing a MySQL select from the payhist table and ordering by payhist.entdate, payhist.enttime and payhist.number, the Beginning Balance record must be first.

9. The payhist.entdate of the Beginning Balance record must be greater than or equal to the account.startdate.