Introduction

Findings of the SAP Mobiliser 5.1 data model: This is the second part of my Data Model blog series. I’m still in the learning phase of the product SAP Mobiliser 5.1 – see the introducory words in Part 1: Multi-tenancy.

The concept of Customer Groups

In my understanding a grouping concept could facilitate the handling of large numbers of similar entities (here: customers). Often a group could contain another group, which will allow a hierachical organisation. Most often an entity could be a member of multiple groups. The grouping concept is quite common – no rocket-science.

Typically operations can be performed on all group members jointly instead of performing the operations for each and every individual member.

Neither in the documentation nor in the database schema I found this concept of a Customer Group.

Let’s see what similar concepts are available:

Org-Unit

Customers are bundled into org-units, see chapter 2.1.9:

to a customer. Usually, a customer is created in an org-unit and this org-unit is never changed. The org-unit

also contains some basic information for a tenant like default country, language, currency, VAT. In case multiple

groups of customers must be separated e.g. from call-center access (CST) multiple org-unit in a single project

can be set up. Customer identifications must still be unique across all org-unit, meaning that a customer with a

But the org-unit cannot contain other org-units and a customer is assigned to exactly one single org-unit (1:1 relationship).

Customer Type

The customer type is more a classification than a grouping in my understanding. In the first sentence of the documentation below I’d change “groups of customers” into “categories of customers”.

2.1.2 Table MOB_CUSTOMER_TYPES

The customer type is used to differentiate groups of customers. Customer types represent business roles in

Money Mobiliser. Common customer types are “consumer”, “merchant”, CSR, agent. There is no hard-coded

logic on customer types. Customer types can be defined for each installation separately. The customer type is

mandatory for a customer and is set at registration time and usually not changed over the lifetime of a customer.

Yes, this classification will represent a group – but in a 1:1 relationship. One customer has exactly one single customer type – multiple memberships are not possible. For me a scenario where a customer is both a “merchant” and a “consumer” doesn’t seem invalid in the real-world: I could sell goods and at the same time buy goods from another merchant. How to model this in SAP Mobiliser – with a new customer type “consuming_merchant”?

Column ID_PARENT (Customer Hierarchy)

In the table MOB_CUSTOMERS, the column ID_PARENT IS defined with this description:

A reference to the customer’s parent. Mainly used for agents that work on behalf of their parent or for Distribution Partner hierarchies.

Customers with the same parent would represent a simple grouping, like in a family. But the major aspect in this approach is the hierarchical structure.

Relationships (network)

It’s possible to more or less freely define relationships between customers.

2.1.7 Table MOB_CUSTOMERS_NETWORKS

Lists all customer (network) relations that exist. A customer network is a link between two customers (father

and child). The link is owned by the father. There is no core business logic in Money Mobiliser that makes use

of this information. It is rather the front-ends that use this to model relationships between customers / agents.

This is a powerful concept and could be used -besides others- to define a grouping concept yourself. I appreciate that relationships are already designed into the data model. I’m using relationships quite a lot in CRM BOL/GenIL developments, but only for defining groups this seems to be too complicated,

And as the excerpt states, there is no business logic behind.

Example scenarios for user groups

Given is a sales organisation with two units North and South and the executive board. Typically we would define three customer groups: North, South, Board.

We need to define different limits for North and South and a very different limit for the board members. But the Sales Director would be both member of the South unit and of the board. How to model this? The only way I see would be to assign an individual limit set to the Sales Director.

Given is a family with father, mother and three children, so that we need five customers. The children shall use the payment instrument Credit Card of the father in their respective wallet with a limit set which applies to the children as a group. The sum of all children spendings should not exceed 100EUR per day.

Summary

The common concept of group processing doesn’t seem to be available in the data model or the business logic of SAP Mobiliser. Related concepts exist though, but without providing the intuitive grouping logic.  I’m assuming that the main reason is to keep the scenarios simple and basic. Performance could also be a good reason!

What do you think – are customer groups necessary?