• Main objects

Customers in Telefakt

Intro

The Party Information Model employed in Telefakt is compliant with a subset of GB922 (SID) while offering some improvements. Recognizing that many of the customers are small businesses (or individuals) it is possible in Telefakt to allow a party to also be used as an account (billing, service or other), thus removing the need to create both a party, a billing account, and a service account for these simple cases.

Overview of the Party Model Overview of the party model showing how it relates to other objects

The Party Information Model is designed to:

  1. Represent any entity (individuals or organizations) involved in interactions with one or more service providers.
  2. Model roles, relationships, and characteristics of these entities.
  3. Facilitate dynamic business requirements like customer management, partner relationships, and regulatory compliance.

All Parties (individuals/organizations) are stored in the DBO.BUSINESS table, where the many attributes (columns in the table) extend on the minimums of SID. The most important ones are;

  • Category - the customer type, allowed values are configured per instance and this controls several important aspects about the customer
  • Status - indicates whether the customer should be used for new operations

In Telefakt, there are two main Party types:

Individual, with extra attributes for

  • Full name
  • First name
  • Last name
  • Date of birth
  • Communication preferences and contact information.

Organization, with extra attributes for

  • Organization name
  • VAT and company registration number (if different)
  • Type.

Hierarchy

While a single business entity can exist as a single party/account, it is sometimes necessary and/or helpful to create in multiple accounts in Telefakt for the same customer (party). This is normally done when a customer has multiple departments and we want to model that or that a customer is customer of two supplier entities,

When modelling customer relationships and other attributes about the customer the hierarchies are especially important. There are three types of hierarchies in the customer object. These three types of hierarchies each control and effect different aspect of the customer and its relationships and interactions with other objects. The primary interactions are described in the following chapters. Below is also a screenshot of the customer hierachy being presented in WebTelefakt for our own customer card Hoberg & Vestrheim AS showing that:

  • Owner is the "Direkte" customer
  • Subsidiary of is itself
  • Bill recipient is itself screenshot of the customer hierachies configured for the Hoberg & Vestrheim customer at GlobalConnect AS

Party Role

Defines the specific roles a party can assume, such as:

  • Customer (and derivatives thereof, such as SMB, Carrier etc)
  • Sales partner
  • Reseller
  • Supplier
  • Etc. Which roles/types of customer a single party is allowed to own is defined by the customers role. For example a System Integrator might own a SMB's (Small to Medium Business) but it does not make sense for an SMB to own a SI. Which roles (types) exist and to which roles each can be related is configurable and is stored in the DBO.BUSINESS_CATEGORIES table.

Owner

The owner hierarchy is the primary hierarchy of customers, it determines where the customers are placed in the ownership tree and controls access to and control over the customers themselves. This is used primarily to model control and ownership within GlobalConnect, meaning which parts of GC are responsible for this customer, which of our partners own this customer etc. All customers must have an owner, this is stored in the BU_CUST_OWNER, a few customers own themselves - these would then be at the top of the hierarchy, while most customers are owned by someone else.

Subsidiary

In Telefakt the owner hierarchy is only an internal representation of how GlobalConnect wants to manage customer mappings whereas the subsidiary hierarchy allows us to model real-world relationships between companies. This means that we can model the owner structure at the customer in Telefakt, in this case the BU_SUBSIDIARY_OF column would point to the customer ID of the mother company. When we don't want to use the subsidiary hierarchy we simply set the customer as their own subsidiary as was the case for the Hoberg & Vestrheim example from above.

Billing accounts

It is the default behaviour for a customer to receive its own invoices. However, this might not always be desirable, the most common exception is when a parent company has multiple departments and all those departments should send their invoice to the parent company. In that case the BU_SEND_BILLS_TO column would point to the customer ID of the parent company. It is also possible to create several billing accounts under a customer (or any other party that can receive bills), for instance if the customer wants the services split on several invoices

Party Characteristic

The Telefakt attribute store allows customization by capturing additional details about a party. Examples of these are:

  • Customer preferences
  • Demographics
  • Industry classifications

Was this page helpful?