Abstract Data Model and Encoding

4.2.2.1 Transformation Business Pricing Models into mathematical Formulae

Pricing models are designed to provide a customer with a transparent way of determining costs. Today, most price models are published digitally, but with an uncertain semantic (see use cases chapter 3). Conditions are often defined in language.

The semantics of this kind of information representation has to be interpreted by humans and relies on a subjective point of view.

There are several real-world examples, showing misinterpretation of a public pricing formula. The scaled price in 3.1.1 is an example. Because of the wide range of price models with completely different approaches (see use-cases in chapter Figure 3), only a generic presentation can be used.

The smallest common denominator to cover these requirements in a case of a pricing method is the mathematical formula. The following steps are necessary:

• Principle: First core pricing elements, then secondary elements like “update”

elements

• Declaration of variables and their units

• Successive transformation of free-text business price model into a mathematical formula

As analyses in chapter 4 and experience with the Geobroker project (see chapter 7) (LGB, 2002a) shows, the textual business price models can be transformed into mathematical formulae, likely to be hand written.

This first step cannot be supported by computer procedures.

4.2.2.2 “Filling the receipt”-Concept and Price Model Methods

Data models may have several views depending on use. Views enable the selection of relevant data. However, a plurality of views means a plurality of tools. This design is a trade-off of both.

The general idea of this design is to use a template of a complete receipt as a price model, which can be filled partly by each workflow step.

• The getPriceModel method creates an instance of the pricing & configuration catalog and selects the requested product price models up to the root in a hierarchical catalogue.

• The getPrice method sets the user given parameter values, calculates the formulae and stores the interim results in each hierarchical level up to the root in a hierarchical catalogue.

• The orderProduct method stores the customer relevant data, e.g. address, status and transaction number into the selected catalogue instance.

• The getOrderList method returns a valid catalogue structure, but with a list of defined former customer orders.

Roland M. Wagner After a valid and complete workflow the instance can be stored with all contract and

interim results for documentation at the customer client site as a result of the response

“OrderProduct” and at the supplier site.

There are more methods for calculation, mapping and administration, which are implementation dependent and will be discussed in the applied approach section.

4.2.2.3 Organization of Products in Groups and Catalogues with Data Types Some suppliers provide a large number of possible products. Therefore it is suitable to organize products in hierarchical product families or product-groups. There are any number of ways to arrange products in groups and catalogues. Product groups can contain other product groups.

Several data objects are necessary to describe a business model completely.

The highest element acts as an envelope and collects one or more catalogues. Suppliers may have their own catalogue. In the cascading case, the catalogues are collected on this level. The catalogue contains one or more product groups. A product group may consist of another level of product groups or consist of product elements. The product element is always a leaf in the hierarchical tree. Therefore, the “product” object and the “product group” objects are the main structure elements. Source 19 shows this hierarchy in a principle representation.

+envelope +catalogue +productGroup

…

+productGroup +product

Source 19 Principle Pricing Catalogue Structures

A “higher” level in this hierarchy means that the level is closer to the root element

“envelope”. A “lower” level means, that the level is closer to the leaf element

“product”.

4.2.2.4 Product Elements and the “Basic Process”

The main price-able unit in an order process is a single “product” object. It can offer a complete price calculation result. This mechanism is called the “Basic Process”. The object and its process is independent and can only be triggered from outside by configuration parameter settings and external data exchange (see 4.2.2.7). The output result is most often a price, which corresponds to a Meta data entry and therefore to a business product.

Different measurement units may cause incorrect calculation and with it incorrect cost publication. Therefore each parameter must have a unit entry. Especially so in the cascading use where different instances from independent suppliers, and different currencies, can occur.

03.06.2003 Product-Group Elements and the “Hierarchical Process”

The “product” object calculation capability is sufficient to provide a price for a single product. Price may vary depending on special constellations between instances of

“product” objects. More typically, there may be minimum fees, applicable only to special product groups.

The data encoding offers a mechanism, the “Hierarchical Process”, which enables enhanced pricing on “productGroup” object level depending on multiple results from

“product “ object level. The results may be prices, but also area extents or other measurement units. The solution is an algorithm, which first sequentially calculates the leaf “product” elements. The results are stored in the parameter objects of each product. After a calculation at “product” object level, the results may be referenced by a “productGroup” calculation formula. There are two reference methods:

• Single-referenced parameter, referring by product ID to a determined value of a determined parameter name

• Multiple-referenced parameter, referring to a list of all parameters on

“product” object level with the same name

A default example is the summation of prices in each “productGroup” level for an interim price of all selected product items. Group calculations may summarize interim prices from lower groups. The final result of all calculations is stored in the root calculation object on Envelope level.

4.2.2.5 Inheritance Methods and the Inheritance Process

In the case of a large supplier, many thousands of products have a price model. In fact, in most price models are often series or recurrent entries like contract information. To avoid data redundancy and offer more efficient administration capabilities, the inheritance mechanism has been developed.

Frequently occurring objects may be declared as “inherited” from a certain hierarchical product group level. These objects will be inherited at runtime to all lower

“productGroup” levels and finally to the “product” level.

There are two possible methods to interrupt the inheritance process. This occurs, if an inheritance object appears on a lower hierarchical level. The inheritance process will also be stopped if the same object type is found on a lower level.

The Inheritance Process runs prior to other processes, to set-up an initial valid catalogue environment. The inheritance will be invoked at the pricing catalogue level and completed through all lower levels.

An example is contract information. The address of a supplier company is required for every potential contract of a product. Therefore, the contract information object is filled with information and declared in the highest possible pricing catalogue level. If there is another contract information object in the catalogue, this object will be inherited to

Roland M. Wagner each product. The advantage of this mechanism is apparent, if the telephone number is

changed for any reason - only one adjustment is needed to the pricing catalogue.

4.2.2.6 Order of Processes

Calculation processes at “product” object level, calculation on “productGroup” level and optimization by inheritance need a certain order, which depends on the request:

1. Inheritance Process 2. Basic Calculation Process 3. Hierarchical Calculation Process

From a more general point of view, the manipulation starts at the XML Document root (with the highest inheritance level) down to the leaves. Then, via setting of configuration parameter-values, this goes back to the root with the calculation hierarchy.

4.2.2.7 External Data Exchange

There are some reasons that price formulae may depend on external data (see 3.1.2, 3.1.5 and 3.2.2). For example, a price can only be calculated, if some parameters:

• are dependant on mass storage filtering, e.g. pricing by number of objects.

• need sophisticated sub procedures, e.g. calculation of extent, which may depend on different co-ordinate systems

• Actual values, e.g. stocks or interests

• other…

Solutions for these external requests are embedded Web Service calls, with a set of output parameters and a set of input parameters. They will be called in the encoding

“Web Service Calls (WSC)”. Due to time-outs, it is required, that an external process should be done “on-the-fly”.

03.06.2003