877.245.5629
sales@billmax.com
|
BillMax Billing Solutions 877.245.5629 sales@billmax.com |
| Chapter 2. Reviewing the Nightly Log | ||
|---|---|---|
 |
Maintaining BillMax | 
|
A "standard" BillMax installation has a cron entry that runs /usr/local/billmax/bin/billmax-admin nightly (see Chapter 2, Preliminary BillMax Configuration. The following sets of variables in /usr/local/billmax/local/billmax.conf are set to "YES" in a typical BillMax installation:
Processes
CLOSEOFDAY
CCDAILY
MAKESTATEMENTS
SENDSTATEMENTS
Database Integrity Checks
BALCHECK
DBCK
Error messages from the "Processes" and the "Database Integrity Checks" are printed to the nightly log, /usr/local/billmax/logs/nightly.date.log where date is the date that /usr/local/billmax/bin/billmax-admin was executed.
Examination of error messages should be done on a daily basis and corrective action taken. Database integrity is verified using dbck. Note that dbck does not validate data against Constraints listed in the CGI Action Files. The following errors reported by dbck may be classified into three main categories:
Referential integrity errors. A value of a field of a record of a table should also be the value of a field in a different record in the same table or a different table. When this does not occur, it is an error. An example is the account.taxregion field having a value that does not exist in salestax.number field of the salestax table.
A incorrect value for a field. An example is have a positive value for payhist.ucash for a Payment.
Incorrect values within the context of the the data. An example is having Allocation records for a Payment that may have correct values by themselves, but the sum of the Allocation records exceeds the total amount of the Payment.
Each error reported by dbck has a five digit error code enclosed in parentheses and periods, .i.e. "..(XXXXX)..". In the following explanations of the error code, a category called "Repair Action" is included. This is the corrective action performed by dbck when executed with the -r option. Note that this option should be used with great care and may not be appropriate.
Checking Table 'account'
Account Admin" page. When viewing the Account through the Staff Interface, the Account will look as if it is in Open State.
Account Admin" page. When viewing the Account through the Staff Interface, the Account will look as if is non-taxable.
Account Admin" page. When viewing the Account through the Staff Interface, the Account will look as if the tax region has not been selected.
Account Admin" page. When viewing the Account through the Staff Interface, the Account will look as if the paytype has not been selected.
Account Admin" page.
Account Admin" page. When viewing the Account through the Staff Interface, the Account reason (field "Because;" on page) may show "Not Applicable". The "Not Applicable" reason will still need to be selected and the record saved.
Account Admin" page.
Checking Table 'auth'
Permissions" page.
Permissions" page.
Checking Table 'calltrack'
Calltrack" page. When viewing the Calltrack through the Staff Interface, the Calltrack will look as if it is in Open State.
Checking Table 'note'
Checking Table 'payhist'
A Sale represents a sale to a customer and a purchase by a customer. Sales may be classified as:
One time. One time sales may be further classified as:
Setup
Usage
Other - Sales entered through the Staff Interface (which may be classified as a Usage sale) and Sales with no startdate and enddate defined.
Recurring - Sales that are generated by BillMax using closeofday.
Sales may or may not have a time component as specified in payhist.startdate and payhist.enddate. Recurring Sales always have a time component.
Required fields for a well formed Sale consists of the following:
payhist.bankacct is 0.
payhist.ucash is 0.
payhist.ucredit is 0.
payhist.cdeposit is 0.
payhist.deposit is 0.
payhist.ntaxable is less than or equal to 0.
payhist.taxable is less than or equal to 0.
payhist.tax is less than or equal to 0.
payhist.ntaxable + payhist.taxable + payhist.tax must equal the negative of payhist.purchases.
payhist.startdate is less than or equal to payhist.enddate.
payhist.entdate should not be 0000-00-00.
payhist.taxregion is a valid value of salestax.number.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
A Deposit Charge is billed and collected for future consideration. It may be collected as a surety for equipment return or as a surety for payment against future services. It does not show up in the Apply. Please keep in mind the difference between a charge for a deposit, and a payment to satisfy that charge. In this discussion, a Deposit Charge refers to the charge for a deposit.
Example 2.1. Reasons to have a Deposit Charge
For use when distributing equipment (e.g. cable modem) for a service and expecting that cable modem to be returned at the end of the service.
For future service.
Some key features of Deposit Charges are:
Deposit Charges may not be paid for by Store Credit This is make sure cash is returned to the Account when necessary, not Store Credit
To make cash available for a Refund or for a Sale from a Deposit Charge, a Deposit Refund must be issued.
A Deposit Refund may not be created for a Deposit Charge unless the Deposit Charge has had Payments Allocated to it paying the Deposit Charge completely.
If a Account does not fulfill the terms to receive the Deposit Refund, the the Deposit Charge must be converted to a Sale. This may be accomplished by Voiding the original Deposit Charge and creating an appropriate Sale
Required fields for a well formed Refund consists of the following:
payhist.bankacct is 0.
payhist.ucash is 0.
payhist.ucredit is 0;
payhist.cdeposit is greater than 0.
payhist.deposit is equal to negative payhist.cdeposit.
payhist.ntaxable is 0.
payhist.taxable is 0.
payhist.entdate should not be 0000-00-00.
payhist.tax is 0.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
payhist.depno is a valid value of payhist.number for a Deposit Charge.
A Deposit Refund signifies that the conditions that required a Deposit Charge no longer exist.
![[Warning]](images/warning.png) |
Warning |
|---|---|
A Deposit Refund may not be Voided. If a Deposit Refund needs to be reversed, this may be done by creating by a new Deposit Charge. |
Required fields for a well formed Refund consists of the following:
payhist.bankacct is 0.
payhist.ucash is 0.
payhist.ucredit is 0;
payhist.cdeposit is less than 0.
payhist.deposit is equal to negative payhist.cdeposit.
payhist.ntaxable is 0.
payhist.taxable is 0.
payhist.tax is 0.
payhist.entdate should not be 0000-00-00.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
The receipt of legal tender from a Account in the form of cash, credit card charge, check …
Required fields for a well formed Payment consists of the following:
payhist.bankacct is greater than 0.
payhist.ucash is equal to negative payhist.bankacct.
payhist.ucredit is 0;
payhist.cdeposit is 0;
payhist.deposit is 0;
payhist.ntaxable is 0.
payhist.taxable is 0.
payhist.tax is 0.
payhist.entdate should not be 0000-00-00.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
Store Credit is credit that may be issued to a Account for use in paying the Account's outstanding balance.
Example 2.2. Reasons to issue Store Credits
A Referral Credit.
Credit for a service outage.
Credit for unused service.
Some key features of Store Credits are:
Store Credits may not be Allocated to Deposit Charges
Store Credits may not be Allocated to Refunds
Store Credits may be automatically generated through the Changetoprocess
Store Credits may be classified as:
One time. One time Store Credits may be further classified as:
Setup
Usage
Other - Store Credits entered through the Staff Interface (which may be classified as a Usage Store Credit) and Store Credits with no startdate and enddate defined.
Recurring - Store Credits that are generated by BillMax using closeofday.
Store Credits may or may not have a time component as specified in payhist.startdate and payhist.enddate. Recurring Store Credits always have a time component.
Required fields for a well formed Store Credit consists of the following:
payhist.bankacct is 0.
payhist.ucash is 0.
payhist.ucredit is 0.
payhist.cdeposit is 0.
payhist.deposit is 0.
payhist.ntaxable is greater than or equal to 0.
payhist.taxable is greater than or equal to 0.
payhist.tax is less greater or equal to 0.
payhist.ntaxable + payhist.taxable + payhist.tax must equal the negative of payhist.purchases.
payhist.startdate is less than or equal to payhist.enddate.
payhist.taxregion is a valid value of salestax.number.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
The return of legal tender to a Account in the form of cash, credit card charge, check …
Required fields for a well formed Refund consists of the following:
payhist.bankacct is less than 0.
payhist.ucash is equal to negative payhist.bankacct.
payhist.ucredit is 0;
payhist.cdeposit is 0;
payhist.deposit is 0;
payhist.ntaxable is 0.
payhist.taxable is 0.
payhist.tax is 0.
payhist.entdate should not be 0000-00-00.
payhist.customerof is a valid value of config.number.
payhist.account is a valid value of account.number.
If payhist.depno is non-zero, it must be a valid value of payhist.number for a Deposit Refund.
|
Warning |
|---|---|
A Refund is the recording of a physical refund given to a customer. The entry in BillMax of a Refund does not trigger any type of refunding process. |
Allocation records may be corrected by one of the following methods:
Using the Staff Interface. Using one of the Allocate pages (see "Using BillMax"), remove and then recreate the Allocation records. This technique may be used to fix individual Allocation records.
Using create_applies to remove and re-create all the Allocation records for a Account.
Using a SQL DELETE to delete incorrect Allocation records. This may cause additional errors to be reported requiring further repair actions.
Checking Table 'resources'
Resources" page.
Resources" page.
Checking Table 'salestax'
Sales Tax" page.
Sales Tax" page.
Checking Table 'servdef'
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if it is in Available State.
Service Definitions" page.
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if is non-taxable.
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if is non-renewable.
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if is the duration is the duration associated with the entry in durations list with the least value.
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if is the initial duration is the duration associated with the entry in durations list with the least value.
Service Definitions" page.
Service Definitions" page.
Service Definitions" page.
Service Definitions" page.
Service Definitions" page.
Service Definitions" page. When viewing the Service Definition through the Staff Interface, the Service Definition will look as if is the duration is the duration associated with the entry in durations list with the least value.
Checking Table 'service'
Service Admin" page.
Service Admin" page.
Service Admin" page.
Service Admin" page.
Service Admin" page.
Service Admin" page.
Service Admin" page using the "Move service to a different user" link.
Service Admin" page.
Service Admin" page.
Service Admin" page.
Service Admin" page. Either set the value for service.invdate or click the RENEW button.
This error is somewhat deprecated as of version 2.1. closeofday automatically invoices Services in the Open State.
Service Admin" page.
Service Admin" page.
Checking Table 'servicechange'
Change Service" page.
Checking Table 'termservers'
Terminal Servers" page.
Terminal Servers" page.
Terminal Servers" page.
Terminal Servers" page.
Checking Table 'tierplan'
Usage-Based Pricing Plan Setup" page.
Usage-Based Pricing Plan Setup" page.
Usage-Based Pricing Plan Setup" page.
Usage-Based Pricing Plan Setup" page.