Last updated

Entity Relationship Diagram (ERD)

erd_main

Product Catalog

CONTRACT

Contracts are used to add a level of pricing control after the provisioned products and provisioned package products. As indicated in the Pricing Overview section, BillingPlatform will consider the pricing information in contracts for provisioned products and package products when processing for periods outside of the effective dates of the provisioned items.

If you associate a contract with an existing rate class, that rate class will serve as the starting point for the contract rates. If no rate class is associated with the contract, contract rates will inherit the default product rates.
erd_contract

CONTRACT_RATE

The contract rate controls the rates of the products and package products provisioned to the customer if no provisioned rates are in effect. In each contract, you will define the effective dates and then add contract rates that will indicate the products that will be affected by the contract along with their corresponding rates. In case contracts or contract rates are removed/deleted from the account, the pricing engine will get the next available rate from the pricing hierarchy as outlined in the Pricing Overview.
erd_contract_rate

PACKAGE

Packages allow you to create collections of individual products. This is typically done to bundle products and then define customized pricing structures for the products included that behave differently compared to selling them individually.
erd_package

PACKAGE_PRODUCT

The instance of a product as it relates to a package. Here, special pricing as well as rating behavior can be defined specific to the context of the parent PACKAGE. erd_package_product

PARENT_PACKAGE_PRODUCT

This entity is used to maintain a hierarchy of products within a package. erd_parent_package_product

PRODUCT

The product is the foundation of BillingPlatform. It offers a way to structure your pricing information into an easy-to-use catalog that is recognizable by users. This is the first step in initially creating your product offering, and needs to be completed before you define the packages which these products will be part of.

As shown in the diagram below, to create a product you first need to create a rating method of the required type, then use its ID to create a product, and then use this product to create account products and packages.

erd_product

RATING_METHOD

The product catalog of BillingPlatform allows you to create products that are priced and rated in various ways. From the typical e-commerce store of selling single-charge products, to discount products as well as subscription products, the behavior of the products that you are selling will revolve around the rating methods that you use. This section explains the different rating methods that are available for use in the system.

erd_rating_method

Customer

ACCOUNT

An account in BillingPlatform is a customer account with the billing profile that consolidates all the information about a customer, statement delivery details and so on. The Account sits at the top level of the hierarchy. It contains the billable entities that you will create in your application and is multi-level in structural hierarchy. erd_account

ACCOUNT_PRODUCT

This section describes how to create an individual product that will be assigned to an account and then provisioned to the customer. Usage data for such products is then routed to the assigned account and processed at the end of the billing cycle configured for them. An individual account product is an instance of a generic product defined in the system. To create an account product from a product, you only need to specify its effective start and end dates for the customer. Products can be provisioned/assigned to accounts individually.

Refer to the diagram below to understand how the different elements related to Account Products are tied together. erd_account_product

ACCOUNT_PACKAGE

erd_account_package

CONTRACT

Contracts are used to add a level of pricing control after the provisioned products and provisioned package products. As indicated in the Pricing Overview section, BillingPlatform will consider the pricing information in contracts for provisioned products and package products when processing for periods outside of the effective dates of the provisioned items.

If you associate a contract with an existing rate class, that rate class will serve as the starting point for the contract rates. If no rate class is associated with the contract, contract rates will inherit the default product rates.
erd_contract

CONTRACT_RATE

The contract rate controls the rates of the products and package products provisioned to the customer if no provisioned rates are in effect. In each contract, you will define the effective dates and then add contract rates that will indicate the products that will be affected by the contract along with their corresponding rates. In case contracts or contract rates are removed/deleted from the account, the pricing engine will get the next available rate from the pricing hierarchy as outlined in the Pricing Overview.
erd_contract_rate

Billing, Invoicing, Accounts Receivable

ACTIVITY_COLLECTOR

Activity collectors in BillingPlatform allow you to collect data in different forms, from different sources, that you can run on a schedule or manually load. Activity collectors can be configured to process data from any delimited text file, which can be configured using the available fields. Collectors can also pull data from manual uploads, FTP locations, as well as utilize web services. erd_activity_collector

CREDIT

The BillingPlatform API allows you to create credits in your application. Credit entries contain the option to auto-allocate the credit. If this option is enabled then the credits funds will be distributed from the oldest to newest closed invoices (in the order) until funds run out. If all invoices are paid and funds still remain in the credit then they will sit in "unallocated" status. If amounts remain in unallocated status they will be applied to the next invoice that is closed.

If you choose not to auto-allocate funds then you may manually allocate amounts to closed invoices using the credit allocation entity. This option allows you to manually decide where the credit funds are applied. Follow the link for more information on manually allocating credits. erd_credit

DUNNING_INTERVAL

The dunning interval is used to define the aging level associated with a particular dunning action. For example, your would use this to configure the system to send a dunning letter of a configured type at 30 days past the due date. Dunning intervals are associated with specific dunning "Flows". A dunning flow can be assigned to an account's billing profile. erd_dunning_interval

INVOICE

This entity is used as the primary means of capturing positive financial transactions. Invoices can have various stages such as current and closed. The invoice will contain a summary of the rated ACTIVITY associated with an invoice as usage is collected and rated in real time such that a current invoice will show rated activity throughout the invoicing cycle.

Invoices can be created for accounts or user groups in BillingPlatform. It is not necessary to create an invoice if you plan on collecting data using the usage collector, as invoices will be created automatically once usage comes through the system. This section will describe the invoice object, and the different fields available. erd_invoice

Payments and Payment Gateways

PAYMENT_ALLOCATION

When a payment is created the user has two options for allocation. Auto-allocation and manual allocation. This section will cover the manual allocation creation for payments.

Manual allocation means you can divide the payment among multiple invoices. This is a handy feature over the auto allocation if you want to apply payments to invoices that aren't the oldest (as auto-allocation would).

Allocations will contain a payment ID (which must be created beforehand), which is where the allocation funds are sourced from.

  • All allocations using the same payment ID must not exceed the payment total.
  • Allocation amounts must not exceed invoice totals.
  • Payments can only be allocated to CLOSED invoices. erd_payment_allocation

PAYMENT_TYPE

The domain of payment types such as: CREDIT CARD, CHECK, BANK UPLOAD, ACH, WIRE.

erd_payment_type