The title of this document is “The VybeBooks Management System”, but this system is actually a collection of several systems designed to work together. These systems manage the physical system accounts and files on the system, perform billing functions and keep accounting records.

The VybeBooks Management system is a robust and flexible system which can manage all facets of billing and bookkeeping. Most of the system’s interfaces are browser based, and so can be accessed remotely from virtually any platform and are encrypted through transport layer security (TLS/SSL).

VybeBooks is modular. The G/L, A/R, A/P, billing and other add-on modules are completely separate and information is moved from one part to another through import tables. This allows an enterprise to decide to feed their own systems at any part of the process. They may decide to use the billing part but feed their own A/R. They can use the VybeBooks A/R and/or A/P but feed their own G/L system. All it needs is a simple import process that understands both systems. It can also work the other way with VybeBooks importing from other billing systems, A/R, A/P or payroll systems.

Because VybeBooks is designed to work with many types of charges generated by any number of systems, local and remote, it is not invoice based but rather transaction based. Transactions are created and at some point the transactions are gathered together and an invoice is created by the system. Transactions can be created in three different ways:

  1. System generated transactions

  2. Recurring billing

  3. User created transactions

Number 1 is where the real power of VybeBooks shines. Many different systems count and measure client products. For example, the ISP billing module counts the amount of disk space used, domains registration renewals, mailboxes, phones, PBXs and many more. These different quantities are applied to the client’s service group and a daily script reads these when needed and generates transactions based on the service types for the individual clients.

Sometimes the system is not able to determine exact pricing on some products so we create recurring billing objects. This object is attached to the client like service groups are but are completely free-form. The user enters the details of the item, what appears on the invoice, the period in months which is usually 1 or 12 and the G/L revenue account to apply the income to. When the item becomes due the system will issue a transaction using the data in the recurring billing object and set the due date to the appropriate date based on the period.

Finally we have number 3 for ad-hoc billings that don’t fit anywhere else. This will usually be one time charges for hardware sales, programming, consulting, etc. There is also a price list to make adding common items easier.

The rest of this manual will go into details of how all of this is managed.