A Domain Model for Customer Commitments

(1)

Modelling Sales Data

A Domain Model for Customer Commitments

Master Thesis of Hannes Hilgenkamp Rijksuniversiteit Groningen

Faculty of Economics Groningen, 2006-03-10

(2)

2

Modelling Sales Data: A Domain Model for Customer Commitments

Master Thesis: Master of Science in Business Administration – Specialization Business&ICT

Author:

Hannes Hilgenkamp +31618889117 hanneshilgenkamp@hotmail.com

Student number:

1257161

Supervisors:

University of Groningen:

1^st supervisor:

Dr. P.E.A. Vandenbossche piet.vandenbossche@ssaglobal.com 2^nd supervisor:

Dr. Ir. T.D. Meijler t.d.meijler@rug.nl

Company:

Facilitair Bedrijf

Afdeling Schoonmaakmanagement & Verhuisdiensten Blauwborgje 8

9747 AC Groningen

The author is responsible for the content of the thesis; all rights regarding this thesis are reserved for the author.

(3)

3

Modelling Sales Data

A Domain Model for Customer Commitments

Master Thesis of Hannes Hilgenkamp Rijksuniversiteit Groningen

Faculty of Economics Groningen, 2006-03-10

(4)

4

Index

1 Problem Statement... 9

1.1 Introduction ... 9

1.2 Domain engineering ... 10

1.2.1 Background ... 10

1.2.2 The fundamentals of domain engineering ... 11

1.3 Scope of the research ... 12

1.4 Research objective and questions ... 15

1.5 The domain model for customer commitments as an extension of the Contract Data Model of Vandenbossche (2004)... 17

1.6 Research design ... 18

1.7 Research methodology ... 20

1.8 Conclusion ... 21

2 Positioning in current literature ... 24

2.2 The double-entry bookkeeping system... 25

2.2.1 The double-entry bookkeeping system and its adoption in software systems ... 26

2.2.2 Implications of the double-entry bookkeeping system for handling customer commitments in software systems ... 27

2.3 The REA Model... 28

2.3.1 The basic REA model ... 29

2.3.2 The extended REA model ... 31

2.3.3 Implications of the (extended) REA Model for developing the domain model for customer commitments ... 34

2.4 The principles of Grundrechnung... 36

2.4.1 The four basic principles of Grundrechnung... 36

2.4.2 Implications of the principles of Grundrechnung for developing the customer commitments pattern... 37

2.5 The Contract Data Model ... 38

2.5.1 Fundamentals of the Contract Data Model ... 39

2.5.1.1 The individual contract clause... 39

(5)

5

2.5.1.2 Relationships between contract clauses: The contract portfolio ... 41

2.5.2 Implications of the Contract Data Model for developing the domain model for customer commitments ... 42

2.6 The choice of an approach... 43

2.7 Relationship between the Contract Data Model of Vandenbossche (2004) and this research ... 45

3 The domain model for customer commitments... 49

3.2 The design features of the domain model for customer commitments... 50

3.2.1 The exchange... 52

3.2.1.1 Functional implications ... 52

3.2.1.2 Implications for the UML class diagram... 55

3.2.2 The parties involved ... 56

3.2.3 The rights and obligations involved ... 60

3.2.3.1.1 The right to receive ‘compensations’ ... 63

3.2.3.1.2 The obligation to deliver ’products’ or ‘activities’... 65

3.2.4 Customer commitment life-cycle and execution... 70

3.2.4.1.1 The transition from ‘planned’ to ‘committed’ ... 72

3.2.4.1.2 The execution phase ... 72

3.2.5 Relationships between customer commitments ... 78

3.3 Simplifying the UML class diagram of the domain model ... 83

3.4 Tailoring the domain model for customer commitments to real-life situations ... 88

(6)

6

3.4.1 Tailoring by discarding parts of the domain model ... 89

3.4.2 Tailoring by extending parts of the domain model ... 89

4 Validation... 94

4.2 Using a multiple case-study for validating the design features ... 94

4.2.1 The approach to validation ... 95

4.2.2 The organization where the case data were collected ... 96

4.2.3 Case descriptions... 96

4.3 Validating the design features ... 100

4.3.1 Introduction ... 100

4.3.2 The exchange... 101

4.3.2.1 Capturing the case data using the design features... 101

4.3.2.2 Implications for the completeness and correctness of the design features. 103 4.3.3 The parties involved ... 107

4.3.3.2 Implications for the correctness and completeness of the design features. 109 4.3.4 The rights and obligations ... 112

4.3.4.2 Implications for the completeness and correctness of the design features. 113 4.3.5 Customer commitment life-cycle and execution... 119

4.3.5.2 Implications for the completeness and correctness of the design features. 122 4.3.6 Relationships between customer commitments ... 124

4.3.6.2 Implications for the completeness and correctness of the design features. 125 4.4 Case-study conclusion ... 127

4.5 Generalization of the case study results ... 129

4.6 Validation conclusion ... 129

5 Conclusion ... 132

(7)

7 5.2 Research results ... 132 5.3 Suggestions for further research ... 134 5.4 Final conclusion... 137

(8)

8

Modelling Sales Data: A Domain Model for Customer Commitments

Chapter 1: Problem statement

(9)

9

1 Problem Statement 1.1 Introduction

In trying to improve the performance of organizations, the focus has shifted from the organizational to the inter-organizational level over the past years (Den Hengst & Sol, 2001).

The traditional view of a company, as taking products and services from a supply market and combining these inputs to deliver them to customers, is not sufficient in today’s dynamic business environment (Ford et al, 2003). Companies are operating in a network of business relationships, and to face increased competition, shifting markets and increased customer expectations in terms of price and quality, they are becoming more and more dependent on these relationships, especially those with customers (Ford et al, 2003).

This importance of customer relationships in today’s dynamic business environment results in the need to handle the various aspects of customer relationships in software systems in a flexible way, making the systems capable of responding quickly to changes in markets, business processes, or the introduction of new technologies. This research will be concerned with the first step towards achieving this flexibility for handling customer relationships in software systems, by performing a domain analysis resulting in a domain model for customer commitments¹.

A domain analysis resulting in a domain model is the first phase in domain engineering, an approach to achieving flexibility in software systems. The background and fundamentals of domain engineering will be explained in the next section.

1 Customer commitments are considered the aspects of customer relationships to be captured by software systems, and will be further specified in section 1.3.

(10)

10

1.2 Domain engineering

1.2.1 Background

Achieving flexibility in software systems has received much attention from researchers and practitioners recently. The business environment as well as the available technologies are changing rapidly, but most software systems are still not capable of dealing with these changes (Zeng & Zhao, 2002). Furthermore, flexible production as it exists in manufacturing, by configuring standard components to specific situations and implementations, is still lacking in the software industry (Greenfield & Short, 2003).

Two types of variability² encountered in software engineering drive the need for flexibility in software systems:

• Technological variability in software systems: Today’s state-of-the-art systems are tomorrow’s legacy systems, and with the continuous evolution and proliferation of new technologies it is difficult to choose the right and more capable of evolving ones (Lahire et al, 2004). Many recent efforts have therefore been aimed at making software systems technology-independent, or as software engineers would call it, portable.

The Model-Driven Architetecture (MDA) approach to software engineering can be considered the most influential effort towards achieving this portability (Poole, 2001).

It was proposed in November 2000 by the Object Management Group (OMG) as

”...an approach to using models in software development.” (OMG, 2005). In MDA, the software system to be developed/maintained is specified in models that separate different aspects of the system. MDA is mainly concerned with separating platform independent aspects from platform specific aspects (Cook, 2004). Platform independents models (PIMs) and platform descriptions (platform models) are used in MDA to get a platform specific description of a system (specified in platform specific models or PSMs) (Poole, 2001). The aim is to make software systems easily

2 Variability is defined as: “The quality, state, or degree of being variable or changeable” (Houghton Mifflin, 2000).

(11)

11 adjustable and portable by keeping functional aspects separated from technological aspects.

• Functional variability in software systems: Functional variability in software systems arises from the fact that requirements, important elements and changes in these elements of a software system are different for different functional domains and organizations within these domains. Various authors have indicated that the modelling language used in MDA, the Unified Modelling Language (UML)³, is too general to fully describe aspects of a system that are specific for a certain functional domain (Thomas, 2004; Cook, 2004). To handle functional variability, reusable and extendible software components are needed that can be tailored for use in specific situations (Harsu, 2004). With reusable and extendible components, the steps of analysis, design, and implementation do not have to be repeated once changes in the environment force the system to change, and software engineering can become a continuous process.

Thomas (2004) and Cook (2004) argue that the reusability and extendibility needed to handle functional variability in software systems is poorly supported in UML, the modelling language of the MDA approach. Other approaches have therefore been proposed. Domain engineering, an approach to handle both technological and functional variability in software systems, will be discussed in the next section.

1.2.2 The fundamentals of domain engineering

Domain engineering is an attempt to achieve flexibility in software systems by providing reusable core assets for assembling or customizing software systems in specific situations (Harsu, 2004). Domain engineering can be divided into three faces:

- Domain analysis: Domain analysis is associated with reuse, its purpose is to capture information involved in the domain to be reused in developing further applications of the same domain (Prieto-Díaz, 1990). In domain analysis, the difference and

3 UML is defined as “a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system” in the OMG UML specification (OMG, 2001). It is a standardization on the notation of a number of diagrams designed to capture different views of a system. The models used in MDA are to be specified in UML diagrams.

(12)

12 familiarity between individual systems is captured and structured (Clements, 1994).

The output of domain analysis is a domain model. Iscoe et al. (1991) define a domain model as: “Domain models are representations of an application domain that can be used for a variety of operational goals in support of specific software engineering”

(Iscoe et al., 1991).

- Domain design: In domain design, the core architecture for a family of applications is designed (Harsu, 2004). In this phase, it is also decided how to enable the variability between individual software systems.

- Domain implementation: The last phase covers the implementation of the architecture, components, and tools designed in the previous phase. This comprises, for example, writing documentation and implementing Domain Specific Languages (DSLs) and generators. The purpose of a DSL is “…to create an infrastructure of reusable and configurable components to develop and maintain a family of systems, instead of developing one individual system.” (Van Deursen & Klint, 2003). DSLs are defined to model systems in certain functional domains, and offer an approach to map the elements of the DSL to the technologies available to realize software systems.

By capturing and structuring the commonalities and differences between individual software systems in a certain functional domain, and offering an infrastructure of reusable and configurable components for a family of systems, domain engineering attempts to support both technological and functional variability in software systems. Therefore, performing a domain analysis resulting in a domain model for customer commitments is an important first step towards achieving flexibility for handling customer commitments in software systems. In the next section, the scope of this domain analysis and the resulting domain model will be further specified.

1.3 Scope of the research

After having positioned this research as the first phase of domain engineering for the domain of customer commitments, the scope of this research can be further specified by offering

(13)

13 some definitions that will be used to describe the domain model for customer commitments resulting from this research:

• Customer: The functional domain of customer commitments is chosen for this research, because companies depend heavily on their relationships with customers to compete effectively in today’s dynamic business environment (Ford et al, 2003). The other categories of relationships, like relationships with suppliers, the research community and capital markets all depend on the relationships with customers and on solving their problems in those relationships (Ford et al, 2003). The importance of customer relationships is highlighted by Levitt (1983) as: “The purpose of a business is to create and keep a customer.”

A customer is defined in the dictionary as: “One that purchases a commodity or service” (Merriam-Webster, 2005). Using this definition, the customer in the domain model for customer commitments is considered the party that receives the commodity or service and provides the payment (or other compensation).

There are some examples where the customer provides the commodity or receives the compensation, like the customers of a stock-broker or a pawnbroker (Partridge, 2002). However, the domain model is aimed at describing the general commonalities of customer commitments, and because this exceptional situation will only occur in a small fraction of customer commitments with very different characteristics, it is left outside the scope of this research.

• Commitments: Since domain engineering is aimed at providing reusable core assets for developing software systems, the domain model for customer commitments should include only the aspects of customer relationships that are to be captured by software systems. The data to be captured on customer relationships is specified as ‘accounting data on (potential) sales’ in the broadest sense of the word, for supporting changing information requests in applications involving customer relationships defined by different users (modified after Vandenbossche, 2004). The aspects of customer relationships that are considered relevant for capturing this information are the formal, mutual

(14)

14 commitments between an organization and its (potential) customers. These commitments can be defined as:

- Formal commitments: Explicit agreements between separate legal entities resulting in rights and obligations that are legally enforceable.

- Mutual/bilateral commitments: Commitments having: “…reciprocally balanced implications for the two participants.” (Vandenbossche, 2004).

• (Inside) Perspective of the selling organization: Different perspectives can be taken for describing commitments between two parties, and the main question is whether to take on an inside or an outside perspective:

- From the outside perspective, no assumptions are made with respect to the party for which the relevant information is to be captured. From this perspective, a commitment involving the exchange of resources for money between two parties will always involve one supplier (the party providing the resources) and one customer (the party providing the money), and the commitment cannot be labelled a ‘customer commitment’ or a ‘supplier commitment’. This outside perspective on commitments implies symmetrical information needs, i.e. no difference between the relevant information for the supplier and the customer. A domain model with this outside perspective could be used by a government institution that tracks transactions in a certain industry to ensure fair competition.

- The inside perspective involves taking the viewpoint of one of the two parties involved in the customer commitment. This means that from an inside perspective, the agreement to exchange products for money can be labelled a sale or a purchase, depending on whether the viewpoint of the selling or the buying organization is taken. The inside perspective is useful when the relevant information is expected to be different for the two parties involved in a commitment, i.e. in situations with non-symmetrical information needs.

Since the functional domain of customer commitments was chosen for the domain model to be developed in this research, this research argues that there is a difference between information needs on customer commitments (viewed from the selling

(15)

15 organization) and supplier commitments (viewed from the buying organization). The use of different systems, applications, and even departments for handling both viewpoints on commitments found in practice provides support for this difference.

Thus, this research takes on the inside perspective of the selling organization for developing the domain model for customer commitments, aimed at capturing the information that is relevant for the selling organization.

• The organization: Having described the perspective of this research as the inside perspective of the selling organization involved in customer commitments, this organization can now be defined as: An organization selling commodities and/or services to customers, that can use the domain model for handling customer commitments in its software systems.

Using these definitions and the definition of a domain model given in section 1.2.2, the domain model for customer commitments to be developed in this research can now be specified as: A domain model describing the functional domain of commitments between an organization and its customers, from the perspective of the selling organization.”

1.4 Research objective and questions

Since a domain analysis resulting in a domain model comprises the first step in domain engineering, a version of the domain model in a common modelling language should be given to make it useful as input for the next steps towards realizing flexibility in software systems for handling customer commitments. The UML class diagram is widely accepted as a diagram for describing and communicating the (static) structure of a system or domain (Dennis et al, 2002). Therefore, a UML class diagram of the domain model for customer commitments will also be provided in this research. This UML class diagram can be used in the further steps of domain engineering, e.g. for implementing a domain specific language⁴ or framework⁵ for handling customer commitments in software systems.

4 The purpose of a DSL is “…to create an infrastructure of reusable and configurable components to develop and maintain a family of systems, instead of developing one individual system.” (Van Deursen & Klint, 2003)

(16)

16 The research objective can now be specified as follows:

To provide a solution to this research objective, existing approaches to handle commitments in software systems and their implications for this research should be discussed first. An existing approach to handling commitments in general will then be used as a starting point for the development of the domain model for customer commitments, and the design features of the domain model for customer commitments will be formulated by extending the design features of the chosen approach. Finally, it will be examined if the formulated design features of the domain model are capable of capturing all relevant data⁶ or need further specialization or modification, using customer commitments from business practice.

The following research questions should be answered to provide a solution to the research objective:

5 A framework is “A reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact.” (Johnson & Russo, 1992).

6 The relevant data to be captured by the domain model for customer commitments was defined in section 1.3 as:

‘accounting data on (potential) sales’ in the broadest sense of the word, for supporting changing information requests in applications involving customer relationships defined by different users (modified after Vandenbossche, 2004).

Research objective:

To perform a functional domain analysis for formal, mutual commitments between an organization and its (potential) customers from the perspective of the selling organization, resulting in a domain model and a UML class diagram of this domain model.

(17)

17 As indicated in research question 2, the design features of the domain model for customer commitments will be formulated by extending the design features of an existing approach to handling commitments in software systems. The next section will offer a brief indication of the differences between the existing approach and the domain model for customer commitments that result in the need for extension of the existing approach.

1.5 The domain model for customer commitments as an extension of the Contract Data Model of Vandenbossche (2004)

In chapter 2, various existing approaches to handling commitments in software systems will be discussed, and it will be explained why the Contract Data Model of Vandenbossche (2004) is chosen as a starting point for developing the domain model for customer commitments. The Contract Data Model of Vandenbossche (2004) offers a general approach to capturing data on commitments and their fulfilments, and its design features should be further specialized to formulate the design features of the domain model for customer commitments. Two main differences between the Contract Data Model of Vandenbossche (2004) and the domain model for customer commitments developed in this research drive this need for further specialization of the design features of the Contract Data Model:

Research Questions:

Research Question 1: What are the implications of existing approaches to handling commitments in software systems for this research?

Research Question 2: How can the design features of the domain model for customer commitments be formulated as extensions of the design features of one of the existing approaches to handling commitments in software systems?

Research Question 3: How can the design features of the domain model for customer commitments be represented in a UML class diagram?

Research Question 4: Do the formulated design features of the domain model for customer commitments need further modification to capture the relevant accounting data on real-life customer commitments?

(18)

18

• Difference in scope: First of all, the domain model for customer commitments is aimed at capturing data on commitments with (potential) customers, while the Contract Data Model offers a general framework for storing accounting data on business processes (Vandenbossche, 2004). This narrower scope of the domain model developed in this research requires the design features of the Contract Data Model to be extended to include aspects of commitments that are specific for the domain of commitments with (potential) customers.

• Difference in perspective: Secondly, the choice of the domain of customer commitments enables this research to view commitments involving a buyer and a seller from the perspective of the selling organization. In the Contract Data Model of Vandenbossche (2004), no assumptions are made with respect to the party for which the relevant data should be captured, resulting in a framework for storing accounting data on commitments (and their fulfilments) involving symmetrical information needs for the two parties involved. Because information needs on buyer-seller commitments will be different for the two parties involved, the design features of the Contract Data Model of Vandenbossche (2004) should be extended to capture the relevant information from the viewpoint of the selling organization.

After having provided a brief indication and motivation of the chosen approach, the following section will describe the structure of this research for developing the domain model for customer commitments.

1.6 Research design

To answer the research questions and provide a solution to the research objective, this thesis is subdivided into five parts:

- Part 1: Problem statement

- Part 2: Positioning in current literature

- Part 3: The domain model for customer commitments - Part 4: Validation

- Part 5: Conclusion

(19)

19 Part 1: Problem statement

The choice of performing a domain analysis resulting in a domain model for customer commitments was motivated in the preceding sections. This domain analysis is an important first step towards achieving flexibility for handling customer commitments in software systems, and the resulting (UML class diagram of the) domain model can be used as input for the further steps in domain engineering, domain design and implementation.

Part 2: Positioning in current literature

As indicated in research question 2, the design features of the domain model for customer commitments will be formulated as extensions of the design features of an existing approach to handling commitments in software systems. Four prominent existing approaches to handling (customer) commitments will be discussed in this part of the research, and the choice of the Contract Data Model of Vandenbossche (2004) as the starting point for developing the domain model for customer commitments will be motivated.

Part 3: The domain model for customer commitments

In this part of the research, the design features of the domain model will be formulated, by extending the design features of the Contract Data Model. Furthermore, the UML class diagram for representing these design features will be gradually developed. This part of the research will provide the answers to research questions 2 and 3.

Part 4: Validation

After having formulated the design features of the domain model for customer commitments, this part of the research will investigate the need for further specialization or modification of the design features to handle real-life customer commitments. Three example customer commitments from business practice will be used for this validation, providing the answer to research question 4.

(20)

20 Part 5: Conclusions

In this part of the research, the results of the development and validation of the domain model for customer commitments will be presented. The use of the domain model for the development of real-life software systems will be discussed, and suggestions for further research will be given to conclude the research.

1.7 Research methodology

Two methodologies will be used in this research: Design-oriented research and case-study research. Part 2 and 3 of this research, concerned with the development of (the background for) the domain model, will be design-oriented research. In design-oriented research, the ultimate goal is the description and design of a model, which might take different forms, such as a framework, a design, a software model, etc. (De Leeuw, 1993). In this research, the model to be designed will be the domain model for customer commitments. Generally speaking, design-oriented research is focused on providing practical solutions (Florusse&Wouters, 1991). The knowledge that comes from studying the designed artefact in use or from the process of bringing the product into being can be considered the main contribution of design-oriented research, while the artefact that has been developed is more of a means than an end (Fallman, 2005). This implies that the artefact developed, the domain model for customer commitments, does not need to encompass all services, functions, and level of completeness that a final ‘product’ would need to encompass (Falmann, 2005).

For this research, this means that the development of the domain model should result in a functional description of commonalities and differences encountered in customer commitments, without offering a full (real-life) implementation of the domain model in practice. An explicit UML class diagram of the domain model will be given, but the next two phases in domain engineering, domain design and implementation, are left for further research.

After formulating the design features of the domain model for customer commitments as extensions of the design features of an existing approach, the completeness of these design features will be validated in part 4 of this research by performing a case-study. In case-study

(21)

21 research, a thorough investigation of one or more cases in practice is done with the objective of drawing more general conclusions from these cases (De Leeuw, 2001). A critique to case- study research as a methodology is that it is dependant on a single or a few cases, and therefore not capable of providing a generalizing conclusion (Tellis, 1997). Yin (1993) argued that case study research is ‘microscopic’ because it lacks a sufficient number of cases. The relative size of the sample, whether 2, 10, or 100 cases are used, does not transform a multiple case study into a macroscopic study (Hamel et al, 1993; Yin, 1994). However, Yin (1994) also pointed out that generalization of results, from either a single or multiple cases, is made to theory and not to populations. The parameters should be established by the goal of the study, and in this way, even a single case could be considered acceptable, provided it met the established objective. Multiple cases strengthen the results by replicating the pattern- matching, increasing confidence in the robustness of the theory (Tellis, 1997).

Using a case-study, it will be examined if the design features are capable of capturing all the relevant accounting data on real-life customer commitments, or if they need further specialization or modification. This will be done in part 4 by applying the design features to three sales contracts found at the Cleaning Management department of the University of Groningen. To make the results of the validation more generally applicable, three sales contracts with different characteristics will be chosen for this validation.

1.8 Conclusion

In this chapter, a domain analysis resulting in a domain model for customer commitments was chosen as the subject of this thesis. This research was positioned as the first step in domain engineering towards achieving flexibility for handling commitments with customers in software systems. The domain model will be developed by specializing (extending) the design features of the Contract Data Model of Vandenbossche (2004) for the functional domain of formal, mutual commitments between an organization and its (potential) customers, to capture the data on these commitments that is relevant from the viewpoint of the selling organization.

(22)

22 The following chapter will be concerned with a discussion of existing approaches to handling commitments in software systems, and a motivation of the choice of the Contract Data Model of Vandenbossche (2004) to base the development of the domain model for customer commitments on.

(23)

23

Modelling Sales Data: A Domain Model for Customer Commitments

Chapter 2: Positioning in current literature

(24)

24

2 Positioning in current literature 2.1 Introduction

In this chapter, various existing approaches to handling commitments in software systems will be discussed, resulting in the choice of an approach that will be used as a starting point for the development of the domain model for customer commitments. This will provide an answer to research question 1.

The following prominent approaches to handling commitments in software systems will be discussed in this chapter:

• Double-entry bookkeeping: In the development of software systems that handle commitments between an organization and other parties, the requirements from financial accounting have always been leading (Verdaasdonk, 1998). Double-entry bookkeeping is the fundamental methodology of financial reporting, and is still adopted in many software systems for recording data on business processes involving commitments, and the assets and liabilities resulting from commitments (Beek et al,1997). Therefore, the fundamentals and implications of the double-entry bookkeeping system for handling (customer) commitments in software systems will be discussed in section 2.2.

• The REA Model of McCarthy (1982): The REA model and its extensions are able to fulfil a wide variety of information requests (Verdaasdonk, 1998) and have had a major impact on accounting information systems research and the structuring of accounting data (including accounting data on customer commitments) in software systems (McCarthy, 2003). Therefore, the REA model and its extensions will be discussed in section 2.3.

• The principles of Grundrechnung: The principles of Grundrechnung offer a set of general guidelines for capturing accounting information in software systems. The Research Question 1: What are the implications of existing approaches to handle commitments in software systems for this research?

(25)

25 central idea of the principles of Grundrechnung, the strict separation of the application domain and the registration domain, has had a large influence on research into accounting information systems (Verdaasdonk, 1998), and a discussion of the four principles of Grundrechnung and their implications for this research will therefore be given in section 2.4.

• The Contract Data Model of Vandenbossche (2004): The Contract Data Model was recently proposed by Vandenbossche (2004) to resolve a number of shortcomings of existing approaches to capturing accounting data in software systems. Mutual commitments between two parties play a central role in the Contract Data Model, and this framework for capturing accounting data will be discussed in section 2.5.

While discussing these four existing approaches in the next four sections, a simple example commitment between a car manufacturer and an audio equipment producer will be used to demonstrate some of their implications for describing customer commitments. This example is outlined in Text box 1 below.

The next section will continue by discussing the fundamentals of double-entry bookkeeping and its implications for this research.

2.2 The double-entry bookkeeping system

Double-entry bookkeeping is a widespread approach to “…providing users, inside and outside the organisation, with financial information by recording and processing financial data about the business processes, assets and liabilities of an organisation.” (Beek et al.,

Text box 1: Example customer commitment

Consider a commitment between Fragilectronics, an audio equipment producer, and one of its customers, Zenith, a multinational car manufacturer. Fragilectronics has agreed with Zenith on a two- year sales contract describing the purchase of car radios by Zenith for prices indicated in the contract.

The actual quantities to be ordered are not mentioned in the contract, since Zenith is unable to predict its production for the next few years with reasonable precision. Actual sales orders (i.e. periodical orders for the delivery of a certain quantity of car radios) are placed by Zenith’s purchase department.

Fragilectronics’ sales department receives the actual orders. The actual, periodical orders are subject to the prices and terms indicated in the two-year sales contract.

(26)

26 1997). Its roots are found in Pacioli’s 1494 work “Summa de Arithmetica, Geometria, Proportioni et Proportionalita”, and double-entry bookkeeping is still used as the standard source of financial information (including financial information on commitments with customers) in many organizations. The use of the double-entry bookkeeping system to store data on commitments and its implications for developing the domain model for customer commitments will be discussed in the next two sections.

2.2.1 The double-entry bookkeeping system and its adoption in software systems

The double-entry system was originally intended to support manual bookkeeping. The essential idea of the double-entry system is that equity is recorded in both its extent and its composition (Van Liempt, 1990). Using the double-entry bookkeeping system, day to day transactions are first recorded using debit and credit entries in the journal. The data from the business processes can also be non-financial, but in that case this data is no direct input (Vousten-Sweere & Van Groenendaal, 1999). Periodically, the transaction information is summarized and transferred to the accounts of the general ledger.

As technological developments offered ways to automate many calculation and information processing tasks, the double-entry bookkeeping system was used in information systems too (Wilson & Sangster, 1992). Organizations were already familiar with double-entry bookkeeping (Vandenbossche, 2004), and databases were used to store the data of the special journals, the entries in the general journal, the general ledger, etc.

However, various shortcomings of the double-entry bookkeeping system arose when it was adopted as a data model in accounting information systems. McCarthy (1980) lists the following weaknesses of the double-entry bookkeeping system as a data source for software systems:

- Its dimensions are limited: Most accounting measurements are expressed in monetary terms, a practice that precludes maintenance and the use of productivity, performance, reliability and other multidimensional data.

- Its classification schemas are not always appropriate: Chart of accounts for a particular enterprise represents all the categories into which information concerning

(27)

27 economic affairs may be placed. This will often lead to data being left out or classified in a manner that conceals its nature from non-accountants.

- Its aggregation level for information is too high: Accounting data is used by a broad variety of decision-makers, each needing different degrees of quality, aggregation and focus depending on personalities, decision styles and conceptual structures. Therefore, information concerning economic events and objects should be kept at the most elementary form possible to be aggregated by specific users.

The implications of these drawbacks to the use of the double-entry bookkeeping system as a source of data for software systems, and more specifically, as a source of data on customer commitments, will be discussed in the next section.

2.2.2 Implications of the double-entry bookkeeping system for handling customer commitments in software systems

The example commitment introduced in Text box 1 will be used in this section to illustrate the implications of the use of the double-entry bookkeeping system for capturing data on customer commitments. When Zenith places an order for a certain quantity of car radios at Fragilectronics’ sales department, a software system using the double-entry bookkeeping system for handling customer commitments at Fragilectronics would only record the financial consequences of the sales order. At Fragilectronics, the transaction would be recorded by a journal entry that debits the ‘accounts receivable’ for the account of Zenith, and credits the

‘sales’ account, for the amount of the sale to Zenith. An additional journal entry may record the costs of the sold car radios by debiting the account ‘cost of goods sold’ and crediting the

‘inventory’ account. Some additional comments on the exchange might be added, e.g. the documents describing the delivery (delivery note) and the details of the payment (invoice), but the double-entry bookkeeping system would not be able to provide Fragilectronics with information on the various terms of the sales contract, productivity measures, the relationship between the two year sales contract and the actual sales orders, or the employee(s) responsible for the sales. Because it only includes financial data, the double-entry bookkeeping system is clearly not capable of providing all the accounting data that is considered relevant for this

(28)

28 research⁷. Attempts have been made to include additional data by partitioning the accounting classification schemes (e.g. using spreadsheets), but these attempts generally resulted in increased complexity and clumsiness (McCarthy et al, 1996).

McCarthy et al. (1996) compare the position of accounting information systems based on the double-entry system in the evolution of enterprise information systems to the position of the fish in the evolution of animals. These systems exist in an environment where “accounting needs and conventions pre-empt all others”, and are not capable of “surviving outside the water (where most of the worldwide economic action is taking place)” (McCarthy et al, 1996).

Because of the drawbacks of the double-entry bookkeeping system, extension of the traditional accounting model to support for a broader spectrum of management information needs has become a topic of research interest (Verdaasdonk, 1998). Research into this area has been led by two ‘schools’, an American school and a German School (Verdaasdonk, 2003). The main result of the American school, the REA model that was proposed by McCarthy (1982) to resolve the shortcomings of the use of double-entry bookkeeping in software systems, will be discussed in the next section. The main result of the German school, the principles of Grundrechnung, will be discussed in section 2.4.

2.3 The REA Model

In 1982, the REA Accounting Model was presented by McCarthy as: “…a framework for building accounting systems in a shared data environment, both within enterprises and between enterprises” (McCarthy, 2003). The REA model is vastly extended and provides a universal framework for capturing data in accounting systems by means of generalization (Verdaasdonk, 1998).

7 In chapter 1, the data to be considered relevant for this research was defined as: ‘accounting data on (potential) sales’ in the broadest sense of the word, for supporting changing information requests in applications involving customer relationships defined by different users (modified after Vandenbossche, 2004).

(29)

29 In this section, the fundamental elements and ideas of REA modelling will be explained, starting with the basic REA model in section 2.3.1, followed by some extensions to the REA model in section 2.3.2. Then, a discussion of the implications of REA modelling for the development the domain model for customer commitments will be given in section 2.3.3.

2.3.1 The basic REA model

The REA model is a modelling technique that is intended to be a foundation for the storage of accounting data in information systems (Nakamura & Johnson, 1998). Its aim is to capture only the essential aspects of economic phenomena, without including the artefacts associated with journals or ledgers, such as debit, credit, or accounts (McCarthy, 2003).

The basic components of the REA model are economic Resources, economic Events and economic Agents, and their relationships (McCarthy, 1982). McCarthy (1982) uses the following definitions of these components:

- Economic Resources are defined to be objects that (1) are scarce and have utility and (2) are under the control of an enterprise (Ijiri, 1975).

- Economic Events are defined as a class of phenomena which reflect changes in scarce means (economic resources) resulting from production, exchange, consumption, and distribution (Yu, 1976).

- Economic Agents include persons and agencies who participate in the economic events of the enterprise or who are responsible for subordinates’ participation (McCarthy, 1982).

Economic events are considered the trigger for changes in the state of scarce resources, and this is represented by the ‘stock-flow’ relationship between resources and events (McCarthy, 1982). Economic agents and events are related because agents participate in economic events, as represented by the ‘control’ relationship between events and agents (McCarthy, 1982).

Using these components and relationships, economic phenomena can be modelled as a dual picture of economic resources, events and agents, from both a ‘give’ and a ‘take’ perspective (Geerts & McCarthy, 1997). The two different perspectives (‘give’ and ‘take’) result in the participating agents being either an ‘Inside agent’ or an ‘Outside agent’. A ‘give’ event from the perspective of the ‘Inside agent’ ultimately always results in at least one ‘take’ event from

(30)

30 the perspective of the ‘Outside agent’ (McCarthy, 1982). The duality that results from these two perspectives is modelled using the ‘duality’ relationship (McCarthy, 1982). The basic REA pattern is illustrated in Figure 1.

Figure 1 Overview of the basic REA pattern (McCarthy, 2003)

The example customer commitment introduced in section 2.1 will be used here to demonstrate how REA Model can be used to capture. Figure 2 illustrates what a typical periodical sales order of the example would look like in the REA Model, from the perspective of Fragilectronics. From a ‘give’ perspective, Fragilectronics has the obligation to supply the quantity of car radios specified in the sales order. From a ‘take’ perspective, Fragilectronics has the right to receive cash. The ‘delivery’ is the event that results in an outflow of the resources ‘car radios’, and the ‘payment’ is the event that results in an inflow of the resource

‘cash’. The ‘customer’ (outside agent) receives the ‘delivery’, and an ‘inside agent’ (e.g. the sales department) of Fragilectronics is responsible for supplying the ‘delivery’. An ‘inside agent’ (e.g. the administration department) of Fragilectronics is responsible for making sure the ‘payment’ is received, while the ‘customer’ is to supply this ‘payment’. The duality relationship links the ‘delivery’ event to the ‘payment’ event.

(31)

31

Figure 2: REA sales contract example

The basic REA model was meant to replace the general ledger of double-entry bookkeeping (McCarthy, 1982). It supports a wide range of accounting information requests, while avoiding the artefacts resulting from double entry-bookkeeping. However, a number of drawbacks to the use of the (basic) REA model have been indicated as well. These drawbacks and the solutions to these drawbacks will be used to describe the extended REA model in the next section.

2.3.2 The extended REA model

After its introduction in 1982, a number of drawbacks to the use of the basic REA model have been indicated. They include:

• The number of REA components can grow exponentially because it is an entity- relationship model, limiting its possibilities for real-life customer applications (Sakagami, 1995).

• Future-oriented data was not captured by the basic REA model (Verdaasdonk, 1998).

• Two big advances in information technology in the 1990s, business process reengineering (BPR) and the advent of Enterprise Resource Planning (ERP) systems required extensions of the basic REA model (McCarthy, 2003).

(32)

32

• Reusability⁸ and extendibility⁹ are poorly supported in the basic REA model (Geerts, 1997).

Various extensions to the basic REA model have been introduced to resolve these drawbacks.

An object-oriented version of the REA model was introduced to avoid the disadvantages of the original entity-relationship model. The object-oriented version of the REA model is expressed in a UML class diagram in Figure 3 below.

Figure 3: The object-oriented version of the basic REA model expressed in a UML class diagram (Source:

Hruby, 2004)

To include future-oriented data, the basic REA model was extended by Geerts & McCarthy (2000) to include the concepts ‘commitment’, ‘contract’ and ‘claim’. Using these concepts, data on the ‘sales order’ of the example commitment introduced in Text box 1, that probably existed before both the ‘delivery’ and the ‘payment’ events took place, can also be captured by the REA model. This extension to the REA model is illustrated in Figure 4, with the basic REA model shown in bold.

8 Geerts (1997) defines ‘reusability’ as:

‘Reusability is the ability of software elements to serve for the construction of many different applications.’

9 Geerts (1997) defines ‘extendibility’ as:

‘Extendibility is the ease of adapting the accounting information system to changes in the economic activities of a company.’

(33)

33

Figure 4: Updated UML class diagram of the REA model after extension by Geerts&McCarthy (2000) (Source: Hruby, 2004)

Furthermore, to include the implications of business process reengineering (BPR) and the advent of Enterprise Resource Planning (ERP) systems, the ‘business process’ and ‘enterprise value chain’ concepts were introduced to group individual REA instances like the one shown in Figure 2 (McCarthy, 2003). For practical reasons, a lower level was also introduced to decompose business processes into tasks (Geerts & McCarthy, 2001). This resulted in a

‘stack’ with three layers of abstraction: Value chain specifications, business process specifications and task specifications.

Finally, the REA model was extended to support reusability and extendibility by dividing the model into two ‘views’: an accountability infrastructure and a policy infrastructure (Geerts &

McCarthy, 2002). The accountability infrastructure is a conceptualization of actual business events, capturing the data on “what has occurred or has been committed to” (Geerts &

McCarthy 2002). The policy infrastructure governs the accountability structure by conceptualizing what ‘could be’ or ‘should be’. It encompasses ‘type’ images of the actual

(34)

34 entities (e.g. resources, events, etc.) that are in place in the accountability infrastructure, and offers possibilities for reuse and extension to modify the accountability infrastructure.

After describing their fundamental ideas and components, the next section will discuss the implications of the REA model and its extensions for handling customer commitments in software systems.

2.3.3 Implications of the (extended) REA Model for developing the domain model for customer commitments

Just as for the double-entry bookkeeping system, the example commitment between Fragilectronics and Zenith introduced in Text box 1 will be used in this section to discuss the implications of the REA model and its extensions for the development of the domain model for customer commitments. When Zenith places an order for a certain quantity of car radios at Fragilectronics’ sales department, a software system using the basic REA model for handling customer commitments at Fragilectronics would record that a certain quantity of car radios is

‘given’, and that a certain amount is ‘taken’. Furthermore, the events of delivery and payment associated with giving and taking these resources would be recorded, along with the agents controlling these events. Data on the actual commitments (the two-year sales contract and the sales orders that are subject to this sales contract) that result in the exchange of resources would not be recorded in the basic REA model before the events of delivery and payment take place, but this issue is resolved by the extension of the basic REA model with the concepts of

‘contract’, ‘commitment’ and ‘claim’, that enable the storage of future-oriented data.

By describing customer commitments in terms of resources, events, agents and the relationships between them, information requests concerning the field of financial accounting as well as the field of managerial accounting are supported by the (extended) REA model (Verdaasdonk, 1998). The REA model and its extensions are thus capable of capturing more

(35)

35 relevant accounting data¹⁰ on customer commitments than the double-entry bookkeeping system, which only recorded the financial consequences of customer commitments.

There are however some aspects of the example commitment that are not captured by the (extended) REA model. Examples are the terms describing the various rights and obligations in case of default, a possible sales quotation that existed before the final sales contract or a periodical sales order was agreed, and the relationship between the two year sales contract and an actual sales order.

An additional drawback to the (extended) REA model is noted by Vandenbossche (2004): “It has yet to be designed further into object-oriented analysis models that can be implemented and deployed as the data models of real-life ERP systems implementations”. While part of this drawback is resolved by Hruby (2004) by offering the object models of the (extended) REA model illustrated in Figure 3 and Figure 4, real-life implementations of the (extended) REA model are not yet available.

In short, the (extended) REA model includes a much wider range of aspects of customer commitments than the double-entry bookkeeping system, while avoiding artefacts like accounts, debit and credit. However, there are also relevant aspects of customer commitments that are not included in the (extended) REA model, and no examples of real-life implementations can yet be found.

Another important perspective on capturing accounting data in software systems is offered by the principles of Grundrechnung, the main result of research initiatives into accounting information systems of the German School. The principles of Grundrechnung will be discussed in the next section.

10 The data to be considered relevant for this research was defined in chapter 1 as: ‘accounting data on (potential) sales’ in the broadest sense of the word, for supporting changing information requests in applications involving customer relationships defined by different users (modified after Vandenbossche, 2004).

(36)

36

2.4 The principles of Grundrechnung

The Grundrechnung¹¹ is developed independently by Schmalenbach (1956) in Germany and Goetz (1949) in the United States. The Grundrechnung is the term Schmalenbach (1956) used for the collection of data that is necessary in an accounting information system to supply data undistorted so as to satisfy a great variety of potential information requirements (Dunn &

McCarthy, 1997).

In the next two sections, the principles of Grundrechnung will be described, followed by a discussion of their implications for developing the domain model for customer commitments.

2.4.1 The four basic principles of Grundrechnung

Goetz (1939; 1949) argued in American literature that accountants are not qualified to select, classify or measure business phenomena unless they fully understand the nature of the issues to be decided, and that users cannot evaluate information unless they fully understand the methods used to produce it. He proposed the creation of a ‘Basic Historic Record’ or ‘Basic Pecuniary Record’ to preserve the original data in its most primitive form so that it could be organized in the most appropriate form for each decision maker.

At the same time, Schmalenbach (1956) was making similar arguments in Germany, and he used the term ‘Grundrechnung’ to refer to this objective record of occurrences (transactions) (Dunn & McCarthy, 1997). Based on the work of Schmalenbach (1956), Riebel (1994) developed four basic principles of Grundrechnung for recording accounting data in software systems:

1. No heterogeneous classification or summarizing of elements that are needed separately for applications.

2. No arbitrary division and allocation of accounting data.

3. Recording an entry at the lowest level possible in the hierarchy without introducing arbitrary allocations

11 “Grundrechnung” can be translated to English as “Basic Recordings” (Verdaasdonk 2003)

(37)

37 4. Characterization with all attributes of interest and importance.

These four basic principles are implemented using the so-called identity-principle (‘Identitätsprinzipz’), which defines revenues and costs as cash income and expenditures resulting from a particular decision (Verdaasdonk, 1998). Therefore, costs and revenues can be referred to as negative and positive decision consequences, measured by cash values that are objective parts of contracts with other parties.

The principles of Grundrechnung are aimed at maintaining an objective record of transactions to serve a broad range of changing information requests (Dunn & McCarthy, 1997). The design of this objective record must be flexible enough to introduce new attributes when requirements change or grow.

Grundrechnung does not provide an entity-relationship diagram based convention for expressing the relevant elements to include in the objective record. However, an indication of the basic elements of this objective record is offered by Back-Hock (1995). He identified the basic types of data units in the Grundrechnung as:

1. Objects of decisions

2. Factors that influence these objects

3. Domain values of objects and influence factors.

The principles of Grundrechnung thus offer general guidelines for recording accounting data in software systems, with the strict separation of application and data as the main objective (Verdaasdonk, 2003). They do not address issues from the financial accounting domain and are thus not intended to replace the general ledger (Verdaasdonk, 2003).

2.4.2 Implications of the principles of Grundrechnung for developing the customer commitments pattern

Because the Grundrechnung does not provide an entity-relationship diagram describing the basic elements used to capture accounting data, the principles of Grundrechnung should be made operational for every company (Verdaasdonk, 2003). Sinzig (1994) uses the Grundrechnung as a central concept for data recording to develop a relational database model that is able to provide relevant data for the “Einzelkosten- und Deckungsbeitragsrechnung”.

(38)

38 His relational database was designed for one specific organization, possibly bringing the generality of the model into question. Later, Riebel et al. (1992) and Sinzig (1994) reported that a generic form of the model had been implemented in the first version of SAP’s ERP system (R2), but research by Weber and Weissenberger (1997) indicated that Riebel’s approach has not resulted in applications in practice (Verdaasdonk, 2003).

Returning to the example commitment introduced in Text box 1, if Fragilectronics’ would develop a software system for handling customer commitments, the principles of Grundrechnung would offer no suggestions for the relevant elements and relationships to include in the system. The three basic types of data units identified by Back-Hock (1995) and the example implementations provided by Sinzig (1994) and Riebel et al. (1992) would probably offer some insights, but Fragilectronics would still have to spend much time an efforts to find out which elements to include and how to make the principles of Grundrechnung operational.

In short, the principles of Grundrechnug are useful as a set of guidelines for recording data on customer commitments objectively, but they do not offer a generally applicable model of the elements and relationships used to capture accounting data.

Another approach to handling commitments in software systems, the Contract Data Model, has been proposed recently by Vandenbossche (2004) to resolve various shortcomings of the approaches discussed earlier. The Contract Data Model is the subject of the next section.

2.5 The Contract Data Model

The Contract Data Model is proposed by Vandenbossche (2004) as “a data organization framework allowing the storage of ex post and ex ante accounting data on business process instances¹² suitable for supporting changing accounting information requests defined by different users.” In this section, the fundamental ideas and principles of the Contract Data

12 Vandenbossche (2004) defines a business process instance (BPI) as: “an actual process in a specific situation, which includes data, real actions and specific decisions.”

(39)

39 Model will be described (in section 2.5.1), followed by a discussion of the implications for this research (section 2.5.2).

2.5.1 Fundamentals of the Contract Data Model

Vandenbossche (2004) identifies the ‘exchange of resources or value-adding activities’ as the recurring aspect of reality for storing accounting data on business process instances. He introduces the central element ‘contract’ as the trigger of these exchanges. The ‘contract’ is used in the Contract Data Model as a general concept for representing agreements, not limited by its definition in, for example, legal science or agency theory. With the ‘contract’ as the central element for storing accounting data, various shortcomings of existing approaches, like the limited scope of data or the lack of support for future-oriented data and relationships, can be overcome. The ‘contract’ is defined by Vandenbossche (2004) as: “a collection of contract clauses, where a contract clause is the expression of an exchange of resources or value- adding activities executed by one or more observances of the contract clause terms”.

In the next two sections, the fundamental ideas and elements of the Contract Data Model will be explained. First, the use of individual contract clauses will be described in section 2.5.1.1.

Then, in section 2.5.1.2, the elements facilitating the relationships between contract clauses will be described. In both sections, the example customer commitment introduced in Text box 1 will be used to illustrate some of the fundamental ideas of the Contract Data Model.

2.5.1.1 The individual contract clause

To see what an actual contract clause looks like in the Contract Data Model, Figure 5 illustrates a contract clause representing a sales order of 350 car radios for € 15,750, from the perspective of Fragilectronics.

In the Contract Data Model, the participants of a ‘contract clause’ are divided into two roles,

‘party’ and ‘opposing party’ (Vandenbossche, 2004). From the perspective of Fragilectronics,

‘party’ Fragilectronics should supply 350 car radios and should receive € 15,750. The

‘opposing party’, Zenith, should supply € 15,750 and should receive 350 car radios. This

(40)

40

‘party’ and ‘opposing party’ perspective on what to supply and what to demand is very much like the ‘duality’ relationship between the ‘give’ and ‘take’ perspectives of the REA model described in section 2.3.1.

Figure 5: Example contract clause with terms (modified after Vandenbossche, 2004)

The Contract Data Model also records the ‘terms’ of an exchange as balancing the various

‘rights’ and ‘obligations’ resulting for the two parties involved in the exchange (Vandenbossche, 2004). The ‘abrogation terms’ are considered a special class of terms, involving the rights and obligations in case of default.

The life-cycle of contract clauses is dealt with in the Contract Data Model by introducing two states for contract clauses: planned and committed. A contract clause is in a ‘planned’ state during the phase in which “…the contract clause has already been proposed but not yet agreed upon.” (Vandenbossche 2004). A sales quotation of Fragilectronics for the supply of car radios is an example of a ‘planned’ state contract clause. When the two participants have agreed on a certain clause, the clause enters the ‘committed’ state, indicating that the various

‘rights’ and ‘obligations’ resulting from the ‘terms’ in a ‘contract clause’ have become legally

(41)

41 enforceable. An actual sales order for car radios placed by the purchase department of Zenith is an example of a ‘committed’ state contract clause. ‘Fulfilment documents’, such as delivery notes or bank statements are the central concept for capturing data on the execution of these

‘committed’ contract clauses in the Contract Data Model. These ‘fulfilment documents’ are groupings of ‘fulfilment lines’, that contain data on the fulfilment of a specific ‘contract clause’ (Vandenbossche, 2004).

In addition to capturing data on individual contract clauses, the Contract Data Model also facilitates relationships between contract clauses. Vandenbossche (2004) uses the concept of a

‘contract portfolio’ to indicate that an organization can be considered a nexus of interrelated contracts. This ‘contract portfolio’ will be discussed in the next section.

2.5.1.2 Relationships between contract clauses: The contract portfolio

An organization can be considered a nexus of contracts, or, in other words, a portfolio of legally enforceable contracts that manifest its legal ownership rights (Vandenbossche 2004).

Within this ‘contract portfolio’, contracts can be related in various ways. Vandenbossche (2004) divides these relationships into two categories:

- Hierarchical relationships: This relationship exists when one contract subsumes the other, i.e. contains more specific rights and obligations while being subject to the more general, higher-level (overall) contract. The relationship between the two-year sales contract and an actual sales order of the example customer commitment introduced in Text box 1 is an example of a hierarchical relationship.

- Horizontal relationships: This relationship is defined between contract clauses to:

“…represent a mutual dependency between related contracts” (Vandenbossche, 2004). The relationship between an actual sales order that is subject to the example two-year sales contract of Text box 1 and a sale of 100 speaker sets belonging to these car radios is an example of a horizontal relationship.

To record these two types of relationships, Vandenbossche (2004) divides contract clauses into two types: overall contract clauses and contract clauses at the lowest level. Overall contract clauses are contract clauses where the agreed conditions of possible future resource exchange are recorded. The general two-year agreement for the supply of car radios for