Products
The product catalogue defines which items can be ordered since all order lines have to have a product. The catalogue also structures products into service types, which can be further split into product groupings which in turn contain products. The products themselves have several defining features, such as the name, the type (One Time Charge or Recurring Charge), the accounting code, the validity period, the tax-rate and many other.
Main hierarchy
In its main hierarchy, Telefakt has three levels of product grouping: Service Type, Product Group, and Product. (e.g. Internett > Internett Fiber > Internett Fiber 10 Mbps (onnet). This is the normal grouping of conceptually related items that one would expect in a catalogue.
Additional levels were removed over the years as they were regarded as superfluous, clumsy for product management, and more effectively modelled using different approaches (such as bundles, paths, etc.).
The items in the hierarchy have a number of fixed fields associated with them that cover basic product information. However, the bulk of the information is stored in dynamic re-assignable attributes. That information can be infinitely and, crucially, instantly expanded through the use of the Attribute Store - see below. One common use is the separation of product-specific versus use-specific provisioning and configuration information for network components.
Bundles
Partly to avoid the need for additional hierarchy levels, but more so to reflect that real-life usage of products differs from the library hierarchy, there are Bundles. These collect products from arbitrary parts of the hierarchy together into groups that are commonly (or are desired to be) sold/implemented together in real-world situations. These can be applied to different purposes. For example, they can be used to force certain products into orders along with headline products.
Auto-add OSS product dependencies
Products can be defined to be automatically added and configured (from information in the Attribute Store) to orders for the purposes of OSS.
Attribute store
Telefakt has a comprehensive key-value store in the form of the attribute store, you can read more about attributes here. One use of this capability, that is relevant here, is Instance-specific versus Product-specific attributes for provisioning/configuration of network components. For example, some generic product provisioning information can be stored in attributes attached to the products themselves, whereas use-specific information can be stored in attributes attached to the Lines representing the customer’s particular use of a product. We call these two types of attributes product attributes and usage attributes respectively. Examples of these are connection speed and connection medium for product attributes, and ip-address and VPN-name for usage attributes.
The dynamism of the Attribute Store allows complete flexibility in supporting changing business requirements. Also, this allows other systems that use the Telefakt catalogue to have additional fields added for their own use, quickly – and this can be done by product managers, rather than programmers.
Product order-paths
These paths allow the product managers to define how orders can interact with products by;
- Define which items (by Service Type, Product Group, and/or individual Product) can or cannot be changed into which other items, by which types of order.
- Define which items (again, by Service Type, Product Group, and/or Product) are allowed or dis-allowed with each other within any particular type of order.
Charging types
The product catalogue has support for multiple charging types. Currently five are in use: One-time, Multiple-recurring, Traffic-based (e.g. telephony), Variable, and None charging types. It can also be expanded to support additional types. The type None is to support the required inclusion of a product that has no relevance to the customer commonly referred to as an RFS, resource facing service, in an order or a circuit. These types of products will be excluded from any customer-facing communications (emails, documentation, invoices, etc.), but still exist in the order and are thus available to anyone except the customer. Multiple recurring charges support any time period (e.g. month, quarter, year) for different products.