HIGHLIGHTS

Highlights of Odin Automation Premium 7.3 include:

You may want to know what business value this Odin Automation release will bring to you and your customers.

Billing

1.      Integration with the Vertex O Series Taxation Engine

Starting with version 7.3, Odin Automation supports one more external taxation engine Vertex O Series. For each taxation rule, providers or resellers can define one of the supported taxation methods: (1) built-in taxation, (2) AvaTax for Communications, formerly called BillSoft EZtax (if installed), or (3) Vertex (if installed). Resellers can use their provider's account in Vertex (if allowed by their provider) or their own accounts. The integration with Vertex is not enabled by default after an Odin Automation deployment or upgrade. A provider can install an additional Billing component (the bm-tax-plugin-vertex package) to enable Vertex functionality. Watch the demo video here.

For additional information, refer to the OA Billing Provider's Guide >> System Configuration (System Administration) > OA Billing Configuration > Configuring Financial Settings > Configuring Taxation Settings > Tax Calculation via Vertex O Series.

 

2.      Capability to Select a Payment Method for Automatic Top-Up of Balance

 

Resellers need sufficient balance to provision resold services to customers. Some resellers have a credit limit allowed by their provider to continue their activity when their balance becomes negative. Odin Automation provides a mechanism of automatic balance replenishing (balance top-up) when it is insufficient. This enables resellers to continuously provide services to customers.

Previously, resellers were able to use only the default payment method for balance top-up. Now, they can select which payment method to use for automatic top-up of their balance (it can be the same payment method as the default one for an account). Watch the demo video here.

For additional information, refer to the Getting Started with Billing – Reseller's Guide >> System Initial Configuration > Replenishing Balance > Configuring Balance Auto-Replenishment.

3.      More Flexible Issuing of Invoices to Suspended Customer or Reseller Accounts

 

This new feature will allow providers to collect due payments on time and manage their billing and accounting processes more efficiently. Starting with version 7.3, providers can:

  • Bill their customers for all of their subscriptions on each billing date, including suspended subscriptions.
  • Bill their resellers on each billing date for all of the services they or their customers use, whether or not the corresponding reseller subscriptions are suspended.

Previously, invoices generated on billing dates included only the charges for the currently active subscriptions.

Scenario 1. A customer's subscription is suspended

How it worked previously

  1. A customer fails to pay for a new billing period (period A). The respective service subscription is suspended. The customer's account is put on credit hold.
  2. The customer does not pay for the service for three more billing periods, B, C, D. The service remains suspended. The customer's account remains on credit hold.
  3. The customer eventually pays for billing period A. The service is activated.
  4. (unconditional behavior) The system issues an invoice, charging the customer for billing periods B, C, and D. The customer has to pay a comparatively large bill at once. The provider has to process a payment covering several billing periods.

How it works now

  1. A customer fails to pay for a new billing period (period A). The respective service subscription is suspended. The customer's account is put on credit hold.
  2. The customer does not pay for the service for three more billing periods, B, C, D. The service remains suspended. The customer's account remains on credit hold.
  3. (configurable option) Unless configured to behave as before, for each billing period, the system issues its own invoice charging the customer separately for billing periods B, C, and D on each respective billing date. The customer can continue making regular payments in manageable amounts. The provider can close each period on time.

Scenario 2. A reseller's subscription is suspended

How it worked previously

  1. A reseller fails to pay for a new billing period (period A). The reseller's subscription is suspended (the reseller's account is put on credit hold). The reseller's customers continue using their services.
  2. The reseller does not pay for the service for three more billing periods, B, C, D. The service remains suspended. The reseller's customers continue using their services. The system does not issue invoices for these periods to the reseller.
  3. The reseller eventually pays for billing period A. The service is activated.
  4. (unconditional behavior) The system issues a consolidated invoice to the reseller, charging the reseller for the reseller's subscription and for the services the reseller's customers consumed during periods B, C, and D. The reseller has to pay a comparatively large bill at once. The provider has to process a payment covering several billing periods.

How it works now

  1. A reseller fails to pay for a new billing period (period A). The reseller's subscription is suspended (the reseller's account is put on credit hold). The reseller's customers continue using their services.
  2. The reseller does not pay for the service for three more billing periods, B, C, D. The service remains suspended. The reseller's customers continue using their services.
  3. (configurable option) Unless configured to behave as before, for each of the billing periods B, C, and D, the system issues its own invoice to the reseller on each respective billing date. Each such invoice includes the charges for the reseller's subscription and for the services the reseller's customers consumed during the respective billing period. The reseller can continue making regular payments in manageable amounts. The provider can close each period on time.

Configuration

The capability is regulated by a new setting, Bill for Subscriptions on Hold. When enabled for a customer class, the invoice for any billing period for each customer (or reseller) of this class will include the charges for all the services the customer (or reseller and reseller's customers) consumed in that period, including those services which were suspended. The new setting does not affect the charge calculation logic. The applicable charges are calculated in the same way as before, whether the setting is enabled or disabled. Watch a demo video here.

Upgrade/installation

For new ("clean") Odin Automation installations, the setting is enabled in the default customer class. After an upgrade from a previous version, the setting is disabled by default in the existing customer classes, to ensure consistency with the provider's existing billing policies.

For additional information, refer to the OA Billing Provider's Guide >> Configuring Credit Terms.

4.      Correcting Orders and Reseller Transactions

                                                                                                 

In version 7.2, the only way to fix an incorrect-but-already-provisioned order was to issue a credit or a debit memo. Similarly, there was no way to fix a not-yet-invoiced reseller transaction. In some cases, this can be inappropriate from the accounting point of view.

Starting with version 7.3, Odin Automation features the abilities to create correcting orders and to correct existing reseller transactions.

  1. If an order was created with incorrect details or prices, it is now possible to correct the order, even if the order has the "Completed" status and the respective service has already been provided.
  2. Reseller transactions store the charges to be paid by a reseller to a provider until the reseller receives a billing order for his or her subscription from the provider.

A Provider can correct any of the reseller's transactions within any billing period by using the Provider Control Panel. For example, a provider can cancel the reseller's transactions that reflect the refund adjustment in a customer's order.

The functionality that allows correcting orders and reseller transactions is useful in the following business cases:

  1. Exceptional cases for no-refund policy.

A company may have a no-refund policy for its resellers: the company will not refund a reseller if their end-customer cancelled their subscription before the end of the subscription period. In exceptional cases (e.g., an end-customer purchased a three-year subscription by mistake and canceled it on the second day of the subscription period) a reseller can ask the company for a refund.

  1. Billing errors.

Some APS applications have their own billing logic implemented, and report the usage to Billing not as a resource amount, but directly as its money equivalent. So, if a miscalculation happens on the side of such an application, there is a need to correct the respective billing order in OA Billing.

Example:

An application reported a $30 USD usage, while the actual usage was $25 USD. The respective billing order should be corrected ($25 instead of $30).

Processing Correcting Orders and Corrected Reseller Transactions

In terms of Odin Automation, correcting orders are orders of the CO order type (i.e., change orders). The system keeps the relations between order details in a correcting order and the details in the order it corrects (note that these relations are internal and are not displayed in the Control Panel).

Corrected reseller transactions are processed in accordance with the standard order flow – they get to a reseller's billing order. Also, there is an option (configured when the correction is made) to refund directly to the reseller's payment method, without the need to wait for the billing order. Watch the demo video here.

In case of correcting orders, it is possible either to create a credit memo (increase the account's balance) or to refund directly to the account's payment method (configured when the correction is made). Watch the demo video here.