¶ Testing the instance
Once an instance is configured, basic tests and activities can be completed to verify invoices will be generated as expected. In general, the smartbilling implementation approach will be to create a sandbox instance, have SB users upload or create content, and verify features and functionality. Once this sandbox is approved, the sandbox configurations and data is copied into either a QA instance for further tests, or the live, SB customer-specific production instance. The following diagram illustrates a summary of these activities:
¶ Catalog complete
Ensure that catalog items are as expected. For the basic start, the focus should be on the following components:
- Ensure features related to integrations or configurations are mapped as expected. For example, ensure taxes and tax codes are defined correctly for all catalog items. Ensure other configurations, such as G/L accounts (if using) are properly assigned to catalog items. Ensure custom fields are properly assigned, and values are formatted as required.
- Charges and products: ensure pricing, currency, invoice billing descriptions, and other data are verified
- Usage rates and rate plans are defined. Ensure any usage that is to be billed has a corresponding usage rate. Verify the usage rate field values. Verify that the usage rates and usage rate supplier field values to be used and defined are the same ones expected from CDR imports. Verify any "quantity included" usage are defined as such
- Ensure any usage pools are defined where required
- Verify services have the correct bundle of charges, products, and usage rates. Verify the usage identifier type matches the expected inputs from CDR imports. Verify the supplier of usage in a service matches the supplier defined for any CDR imports
- Unit test key catalog items via test subscriptions, draft invoices, and test small CDR imports. Contact your smartbilling liaison regarding specific guidelines for catalog testing of a sandbox instance.
¶ Customers complete
Ensure all customers and customer locations, and customer subscriptions have been defined.
- Ensure any customer configurations made in Administration > Configurations are defined for the required customers. For example, invoice groups, payment profiles, portal users, tax exemptions and custom fields
- Ensure the number of customer accounts in SB are as expected. If using customer locations, ensure the correct locations and subscriptions are mapped. If using parent-child relationships between accounts, ensure these are set up
- Ensure customer account field values are as expected. Example: email address, invoice send method, invoice terms, etc.
- If relevant, ensure tax locations are as required. For example, USA customer locations require a zip code; otherwise tax calculations will error on invoice generation when a tax integration is present
¶ Subscriptions complete
- Ensure that all subscriptions for customers have been accounted for, mapping the correct service or plan to the correct customer, with the desired charges and rates fees.
- Ensure usage identifiers are correct and map correctly to usage and CDRs via a defined CDR import template.
- Test subscriptions, draft invoices, and test small CDR imports to verify usage rates and charges are calculating as expected. For this exercise, suggest to create test CDR csv files where the usage to be billed and rated is known.
¶ Bill runs drafted and unit tested
Generating a valid bill run is a critical goal of the system.
- Ensure that a default invoice template has been selected either in the Administration > Configuration settings; or by requesting a custom invoice template
- Optional: create default messages template and content for invoice message and invoice advertisement sections
- Ensure that the SB user understands what the various bill run settings should be, based on their specific service plans, customer subscriptions, and use cases. Consult with SB support if necessary.
- Create a bill run with no usage loaded for any subscriptions. Check the invoice results match expected outcomes for non-usage charges, particularly for recurring charges.
- Once rated recurring charges results are acceptable, add usage (if any) to the test setup. Test the outcomes for rated usage.
Once an invoice run is drafted, note that any usage that was loaded for that period is marked as "billed". To review the rated, unbilled usage, use the "unbilled usage" section of the Accounts module for a specific account prior to creating a bill run.
During testing, it is common for tests to require either a usage reprocess, or to delete the usage import file and reload it all together. Reprocess can be used if only rates (for example, cost per minute or cost per GB) are changed. For all other changes, it is recommended to delete the test usage file and reload it. For this reason, it is recommended to use a smaller sample set when testing.
For the first invoice test run, DO NOT POST any invoices until all checks are complete and verified. Any posted invoices will require back-end work to reverse. It should only be done in consensus with the smartbilling team and SB user.
It is recommended that the first test bill run is completed as a joint activity with smartbilling support.
¶ Reports tested
- Review the default reports. Verify they provide the required information. Note that some reports may required invoices to be posted. Posting invoices is discouraged during testing because it required backend work to reverse.
- Create any reports to support verifying test results. For example, use a version of the invoice details and invoice summary reports to more easily verify monthly charges per account / invoice / subscription
For new reports, be careful about adding columns that summarize data. Due to how reports are designed, this can have unintended consequences and the report can misrepresent the underlying data. Consult with your smartbilling contact prior to using a custom report for test verification purposes.
¶ Optional: Portal test
- By setting up portal users for a customer account, SB users can test the portal function by using the "Impersonate" feature found in the specific customer account in the Accounts module.
Because this is a test environment, some portal functions will be limited. For example, no payment features will be available; balances will be incorrect; and no invoice copies will appear unless invoices are posted against the account.