Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Direct Bills 'paying' a Folio and Companies 'paying' their Accounts Receivables accounts.

Because the Direct Bill event  'payment' is entered by a User and adds to the Company's 'account receivable' this payment to a Folio, creating the liability, is shown on the Transaction Summary report, but is not included in the JSON array. It is not included because the Total Accounts Receivables is included in the GL JSON data and thus is captured in your GL  as soon as the JOSN is built.

When a Company 'pays' their Accounts Receivable account, that payment (by check, Visa, wire, etc) is included in the JSON array since it affects a payment Category (CREDIT CARDS or NON CARDS, for example) and the amount paid to the Accounts Receivable account is reduced by that payment. If a property was to run a past date for a JSON array, the Accounts Receivable will take 'today' and not attempt to assess what theAccounts Receivable liability amount was at that past date.   It is always 'now'.

Advanced Deposits

The Advanced Deposit number that is included in the JSON array is also, as in Accounts Receivables, always 'today'. The amount reported here will be whatever the Advanced Deposit  report was reporting as of the Night Audit event that triggered the JSON to be delivered.  Thus if a property was to run a past date for a JSON array, the Advanced Deposit will take 'today' and not attempt to assess what the Advanced Deposit amount was at that past date.   It is always 'now'.

Automating the JSON to a General Ledger GL System

Because BookingCenter is designed for properties to manage simply, taking advantage of the checks built-into MyPMS, we reduce the complexity for Users and avoid complexity of managing the Accounts Receivable and Advanced Deposit liabilities accounts. When issuing Payments and Charges to Folios, as well as Cancelling and Editing Bookings, the traditional Guest Ledger and City Ledger required Users to allocate these events to specific GL code(s) to decide what account to credit/debit.  Instead, because of the checks built-into MyPMS, GL automation keep the daily activity 100% accurate, while avoiding duplication of managing the Accounts Receivable and Advanced Deposit liabilities accounts. We do this by 're-setting' the daily Accounts Receivable and Advanced Deposit liabilities account totals, and then posting the new number each day.  For example, if the GL account for Accounts Receivable was $1,250 'yesterday', we read that total, offset it with a -1250 entry, then post the current (ie 'today') Accounts Receivable amount that was accurate as of Night Audit and detailed in the Accounts Receivable Aging report. We do the exact same thing with the Advanced Deposit liabilities account.  This saves a property a lot of accountant time and frees up staff to focus on guest and hospitality and not allocating Payments & Charges to Folios and Cancellations & Edits to specific accounts to track these events in a GL system,  The AD is NOT run for any specific date, the 'date' for AD is like the date for AR - always 'now' - ie current system date.