Accounting Information for changing Business Needs Concepts of Business Logistics applied to Treasury Management Decisions Piet E.A Vandenbossche Uitgever: Labyrint Publications Postbus 334 2984 AX Ridderkerk Tel: 0180-463962 Drukwerk: Offsetdrukkerij Ridderprint B.V., Ridderkerk ISBN 90-5335-036-5 © 2004, P.E.A Vandenbossche Alle rechten voorbehouden Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieen, opnamen of enig andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever Rijksuniversiteit Groningen ACCOUNTING INFORMATION FOR CHANGING BUSINESS NEEDS Concepts of Business Logistics applied to Treasury Management Decisions Proefschrift ter verkrijging van het doctoraat in de Bedrijfskunde aan de Rijksuniversiteit Groningen op gezag van de Rector Magnificus, dr F Zwarts, in het openbaar te verdedigen op donderdag 13 januari 2005 om 16.15 uur door Piet Erik Adolf Vandenbossche geboren op 25 augustus 1969 te Kortrijk (België) Promotores: Prof dr ir J.C Wortmann Prof dr J van der Meer-Kooistra Beoordelingscommissie: Prof dr P Ribbers Prof dr R.W Scapens Prof dr E Vaassen TABLE OF CONTENTS Part I: Problem Statement 1 Problem Definition 1.1 INTRODUCTION 1.2 DIFFERENT APPROACHES TO SUPPORT CHANGING INFORMATION NEEDS IN ERP SYSTEMS 1.2.1 Focusing on the design of new algorithms 1.2.2 Focusing on the design of improved data organization frameworks 1.2.3 Which approach to prefer? 1.3 DOES THE PROBLEM OF LIMITED DATA REUSABILITY STILL EXIST IN PRACTICE? 1.3.1 No adoption of REA and ‘Grundrechnung’ concepts in data models of current business information systems according to the literature 1.3.2 Illustration of business process instance data storage in a sample ERP system 1.3.3 Approach chosen in this research 16 1.4 RESEARCH OBJECTIVES AND QUESTIONS 17 1.5 RESEARCH METHODOLOGY 19 1.6 RESEARCH DESIGN 20 1.7 RESEARCH RELEVANCE 22 1.7.1 Scientific Relevance of the Research Questions 23 1.7.2 Practical Relevance of the Research Questions 23 1.8 OUTLINE OF THIS DISSERTATION 24 Part II: Functional Architecture 29 The contract as the aspect of reality used in designing the data model 31 2.1 2.2 2.3 2.4 INTRODUCTION 31 LITERATURE REVIEW 31 REQUIREMENTS OF BUSINESS PROCESS INSTANCE DATA RECORDING 35 HISTORICAL OVERVIEW OF THE EVOLUTION OF BUSINESS INFORMATION NEEDS CURRENTLY SUPPORTED BY DOUBLE-ENTRY BOOKKEEPING DATA 38 2.5 WHY CONTRACTS ARE A USEFUL ASPECT OF REALITY TO DESIGN THE DATA MODEL 40 2.6 HOW CONTRACTS RELATE TO ORGANIZATIONS 44 2.6.1 Contracts are the formal information base of organizations 44 2.6.2 Contracts in relation to participants inside and outside organizations 45 2.6.3 Contract enforceability and the importance of internal contracts 46 2.6.4 Relationships between contracts: The Contract Portfolio 47 2.7 SUMMARY 50 Design Features of the Contract Data Model 53 3.1 INTRODUCTION 53 3.2 DESIGN FEATURES OF SINGLE CONTRACT DATA STORAGE 54 3.2.1 Contracts versus clauses 54 3.2.2 Roles of Clause Participants 55 3.2.3 Different types of Terms 56 3.2.4 Clause Life-Cycle Aspects 57 3.2.5 Clause Fulfilments 59 3.2.6 Summary: Overview of design features for single contract data storage 60 3.3 DESIGN FEATURES FACILITATING CONTRACT PORTFOLIO DEFINITION 61 3.3.1 Hierarchical relationships between contract clauses 61 3.3.2 Horizontal relationships between contract clauses 62 3.3.3 Summary: Overview of design features for contract clause portfolio definition 63 3.4 EXAMPLE OF BPI DATA STORAGE FOLLOWING THE CONTRACT DATA MODEL 63 3.4.1 Illustration of single contract data storage 63 3.4.2 Illustration of contract portfolio administration 66 3.5 CONTRACT DATA MODEL COMPARED TO REA AND ‘GRUNDRECHNUNG’ DATA STORAGE PRINCIPLES 68 3.5.1 Design features of the Contract Data Model compared to aspects of the extended REA Model 68 3.5.2 Compliance of the Contract Data Model with ‘Grundrechnung’ data storage principles 70 3.6 SUMMARY 71 Part III: Object Architecture 73 Static Object Model of the Contract Data Model 75 4.1 4.2 4.3 4.4 4.5 INTRODUCTION 75 CONTRACT CLAUSE MODEL 75 FULFILMENT MODEL 79 CONTRACT MODEL 82 SUMMARY 84 Part IV: Validation 87 Framework for hierarchical treasury management decision-making 91 5.1 INTRODUCTION 91 5.2 POSITION OF THE TREASURY MANAGEMENT APPLICATION IN THE CONTEXT OF THE VALIDATION 91 5.3 COMPARISON BETWEEN FINANCIAL AND OPERATIONAL RESOURCE OPTIMIZATION 93 5.4 SCOPE OF TREASURY MANAGEMENT DECISIONS 95 5.4.1 Decentralized treasury management decision-making 97 5.4.2 Centralized treasury management decision-making 99 5.4.3 Hybrid treasury management decision-making 101 5.5 THE HYBRID TREASURY MANAGEMENT DECISION-MAKING FRAMEWORK EXPLAINED IN DETAIL 103 5.6 SUMMARY 110 Accounting Information to support Treasury Management Decisions 115 6.1 INTRODUCTION 115 6.2 WHICH INFORMATION TO USE FOR TREASURY MANAGEMENT DECISION SUPPORT? 115 6.3 ASPECTS OF A TREASURY MANAGEMENT DECISION 116 6.4 ANALYSIS OF TREASURY MANAGEMENT DECISIONS 118 6.4.1 Introduction 118 6.4.2 Decision A Setting the Master Financing Schedule 118 6.4.3 Decision B Optimizing Financial Resource Inflow Orders 122 6.4.4 Decision C Optimizing Financial Resource Outflow Orders 124 6.4.5 Decision D Optimizing Financial Resource Surplus Orders 126 6.4.6 Decision E Optimizing Financial Resource Conversion Orders 127 6.4.7 Decision F Optimizing Financial Resource Capacity Expansion Orders 129 6.4.8 Decision G Optimizing Financial Resource Safety Stock Level 130 6.5 STATEMENT OF INFORMATION REQUIREMENTS TO SUPPORT TREASURY MANAGEMENT DECISIONS 131 6.6 SUMMARY 132 Algorithm to support Treasury Management Decisions with Relevant Costs 137 7.1 7.2 INTRODUCTION 137 IN SEARCH OF A SUITABLE ALGORITHM FOR HIERARCHICAL TREASURY MANAGEMENT DECISION-MAKING 137 7.3 DEFINITIONS 138 7.3.1 Relevant financial resource flows within manufacturing organizations 138 7.3.2 Indication of financial resource flow direction 141 7.3.3 MRP Netting Reservation Logic 141 7.4 DETERMINING THE REAL IMPACT OF THE TREASURY MANAGEMENT DECISION: FINANCIAL RESOURCE FLOWS 142 7.4.1 Introduction 142 7.4.2 Step 1: Identification of new demand for financial resources 143 7.4.3 Step 2: Solving the new demand for financial resources 143 7.4.4 Step 3: Processing the supply-side effect in the financial resource plan 147 7.4.5 Step 4: Processing the demand-side effect on the financial resource plan 149 7.5 DETERMINING THE FINANCIAL EQUIVALENT OF A TREASURY MANAGEMENT DECISION: CASH FLOW EQUIVALENTS 151 7.6 EXAMPLE 153 7.7 STATEMENT OF DATA REQUIREMENTS TO SUPPORT THE HCFEM ALGORITHM 158 7.8 SUMMARY 158 Can the Contract Data Model hold sufficient data to support Treasury Management Decisions? 163 8.1 8.2 INTRODUCTION 163 SUMMARY OF THE DATA REQUIREMENTS FOR HIERARCHICAL TREASURY MANAGEMENT DECISION SUPPORT 163 8.3 THE ‘SETTING THE MASTER FINANCING SCHEDULE (MFS)’ DECISION 164 8.4 THE ‘OPTIMIZING FINANCIAL RESOURCE OUTFLOW ORDERS’ DECISION 165 8.4.1 The financial resource outflow order is considered in the MFS 165 8.4.2 The financial resource outflow order is not considered in the MFS 166 8.5 EVALUATION OF THE SUITABILITY OF THE CONTRACT CLAUSE MODEL TO SUPPORT TREASURY MANAGEMENT DECISIONS 167 8.6 ENHANCEMENT OF THE CONTRACT MODEL TO SERVICE TREASURY MANAGEMENT DECISIONMAKING 168 8.7 SUMMARY 170 Part V: Conclusions 173 Conclusions 175 9.1 INTRODUCTION 175 9.2 RESEARCH GOALS 175 9.3 RESEARCH METHOD AND DESIGN REVISITED 175 9.4 RESEARCH RESULTS AND RECOMMENDATIONS FOR FUTURE RESEARCH 178 9.4.1 Reflection on the newly proposed accounting data model 178 9.4.2 Recommendations for future research in the context of the contract data model 179 9.4.3 Reflections on the application of hierarchical treasury management decision-making 180 9.4.4 Recommendations for future research in the context of the application of hierarchical treasury management decision-making 182 9.5 FINAL CONCLUSION 182 Bibliography 184 Appendices 191 APPENDIX 1: 192 APPENDIX 2: 195 APPENDIX 3: 197 Summary 199 Samenvatting 203 About the author 207 Part I: Problem Statement 195 Purchase Invoice 664 Attributes stored: document number: 664, document date: May 3rd, total invoice amount: USD 30,000; supplier: ‘Frame Supplies’, customer: ‘Wheel Chair Company’, terms of payment: by month end, defined for purchase order: 456 and delivery note: 152 The purchase invoice is characterized by the following data: the document number, the document date, the total invoice amount and the currency in which this amount is expressed, the tax amount (not further detailed in this example) the customer and supplier identification, the terms of payment and a reference to the purchase order Posting of the Purchase Invoice in the General Ledger The Accounting Department posts the invoice into the general ledger The following transaction lines are generated: May 8th: 300 Inventory USD 30,000 Purchase Invoice 664 May 8th: @ 400 Supplier USD 30,000 Purchase Invoice 664 Transaction lines are characterized by the following data: transaction line registration date, the general ledger account (e.g 300 is the ledger account for Inventory), the amount and the currency in which the amount is expressed and a reference to the purchase invoice Update Supplier Administration The Supplier Administration indicates the open invoices per supplier It is a subledger administration, which is automatically updated Attributes modified: supplier: ‘Frame Supplies’, invoice number: 664, invoice date: May 3rd, invoice amount: USD 30,000; due date: May 31st, purchase invoice: 664 The supplier administration contains the following data: the supplier identification, the invoice document number, the invoice date, the invoice amount and currency, the due date and a reference to the purchase invoice The supplier invoice is paid at the due date by a Bank Payment Draft Bank Check 879 The treasury department of Wheel Chair Company pays the open purchase invoice at the due date via a bank check Attributes stored: document number: 879, document date: May 31st, pay to: supplier ‘Frame Supplies’, sent by: ‘Wheel Chair Company’, amount to be paid: USD 30,000, subject: payment purchase invoice 664 The Bank Check is characterized by the following data: the check number, the payment date, the nature of the business transaction: payment, amount and currency and a reference to the purchase invoice Posting the Supplier Payment The posting of the supplier payment has the same characteristics as the posting of the purchase invoice Update Supplier Administration The Supplier Administration is updated with the supplier payment event The characteristics are the same as the creation of the open entry purchase invoice 196 197 Appendix 2: UML Notation Conventions Class: Class A n Class B Association: Class A Class B Cardinality (Multiple Associations): Class A 1 Class B Exactly One Class A n Class B Zero or More Class A n Class B One or More Class A Class B Zero or One 198 Aggregation: Class A Class B Composition: Class A Class B 1 Inheritance: SuperClass Subclass A Subclass B 199 Appendix 3: Contract Clause Model enriched with Treasury Management Decision Support Data Features Aggregated Location Location Family Resource 1 Contract Clause Relation n 1 n Party Person n n n n 1 n Clause n n n n Opposing Party 1 n n n -Type : -Res Conversion Rate : Supply -Amount Supplied : -Amount Demanded : n -Type : n Resource n 1 Demand n n n n Calendar Unit 1 Resource per Calendar Unit 1 n Currency Is reserved 1 by nReserves Reservation 1 n -Reservation State : Party CFE Supplied Rate 1 CFE Demanded Rate 1 n n n Supply n Demand Terms Opposing Party n From 1 To n Conversion Rate n 200 201 Summary This research concentrates on the question of defining an improved data model for ERP systems that can hold the data to service the business information needs of a wide user base from a single data environment Research into better data models has already been carried out by a large number of scientists Therefore, it was first investigated whether current ERP systems have adopted the available research results and whether limitations on data availability to service existing, new and/or changing information needs still apply This was approached through a literature analysis and was illustrated afterwards by an empirical evaluation of characteristics of business process instance data recording in a representative sample ERP system The following four findings were made There is no equivalent of the business process instance at data level Data on a single activity instance are persistently stored, but the activity instance network (i.e the business process instance) itself is lost at data level Each finished activity instance of the business process instance leads to business process instance state, domain-specific data recording This business process instance state data is stored in isolation and not as sub-category of a business process instance If data on a single business process instance are not stored structurally, then a structured data organization over different business process instances cannot be expected Business process instance data are not organized using REA or ‘Grundrechnung’ principles No other equivalent data storage object is used to organize business process instance data Double-entry bookkeeping is implemented as a data storage method to support financial information needs The literature analysis and the empirical evaluation of data storage in a current representative ERP system revealed that although several research initiatives have focused on finding improved data models there is still sufficient justification for additional research, as research results available today are not suitable for designing data models of large ERP systems The two main requirements for the data environment of ERP systems are that data stored in the data model have to be suitable to service existing, new and changing information needs and that the data model must be sufficiently robust to be suitable in the context of large ERP implementations In this research, the focus was on proposing a solution to the first question only The first part of the research relates to defining a new data model The first step taken in the process to define a suitable data model is finding an appropriate data organization paradigm In keeping with the advice of several authors, a data organization paradigm close to aspects of reality was chosen This data organization pattern is the ‘contract’, the formal administration of a resource exchange, and was found by investigating the recurring pattern of different types of business transactions, data of which are currently stored via double-entry bookkeeping Subsequently, a number of aspects of the contract principle were investigated, such as how contracts relate to organizations, why it is relevant to store internal contracts and how contracts relate to each other, resulting in the concept of the contract portfolio The act of recording contracts was described as contract-based accounting The second step in defining a new data model is the definition of essential data components as design features of the chosen data organization paradigm Two sets of design features were defined The first relates to design features of the contract pattern to accommodate data storage of a single business process instance Data of a single business process instance can be stored by detailing all aspects of an unrelated contract, like contract clauses, contract terms, contract participants, etc The second set of design features concern the data definition of the 202 relationships that can arise between business process instances These relationships are defined in the data model through design features based on relationships between contract clauses, which complete the concept of the contract portfolio as highlighted in the previous paragraph The third and final step in the definition of the new data model concerns the translation of the data organization paradigm and the design features into a data model architecture designed following a chosen data modelling technique This was achieved by proposing three specific object models, designed in UML The first model (i.e the Contract Clause Pattern Model) is a model that allows resource exchange data storage through contract clauses and the relationships between contract clauses The second model (i.e the Fulfilment Pattern Model) concerns the storage of resource exchange execution data (e.g invoicing, delivery, payment, etc.) The third and final model (i.e the Contract Pattern Model) is an integration of the Contract Clause Pattern Model and the Fulfilment Pattern Model and accommodates a full contract administration, as prescribed by contract-based accounting The second part of this research concerns the validation of the proposed contract data model As discussed above, the research objective focused on in this dissertation relates to the definition of a data model suitable to service new or changing information needs The process of validation is therefore initiated by defining a new application as the first step Step two is the requirement definition of this new application Step three refers to detailing an algorithm that supports the calculations required in the chosen application Finally, step four is the actual validation Whether sufficient data are stored in the new contract data model for servicing the information needs of the chosen application and enhancements as described was investigated Each of the four steps is then described in detail As highlighted in the previous paragraph, the first step in the validation process is the outline of a new application A new application was deliberately chosen over an existing application, as new applications have the same characteristics of changed information needs from a user perspective Hierarchical treasury management decision-making was chosen as the new application, as this approach had not yet been adopted in daily treasury practice and was therefore suitable as a new application Hierarchical treasury management decision frameworks were outlined for three different types of decision-making: centralized, decentralized and hybrid decision-making Hybrid decision-making was illustrated as the most appropriate for servicing real-life situations and was therefore used in the remainder of the validation process The following decisions were supported in the hybrid decision framework 1) Setting the Master Financing Schedule, 2) Optimizing Financial Resource Outflow Orders, 3) Optimizing Financial Resource Inflow Orders, 4) Optimizing Financial Resource Surplus Orders, 5) Optimizing Financial Resource Expansion Orders, 6) Optimizing Financial Resource Conversion Orders and 7) Optimizing Financial Resource Safety Stock Levels The second step in the validation process is the requirement definition of the chosen application In the previous paragraph, the application used for the validation of the contract data model was outlined as hierarchical treasury management decision-making Decisions can be supported by all kinds of information, varying from non-financial information to financial information This research chose to service these decisions with relevant cost information, specifically incremental costs and opportunity costs Detail was first presented on the scope of the decision for each of the seven treasury management decisions Which accounting information was required to support the decision with relevant cost information was then explained and finally, requirements for data availability were defined The requirement process was finalized by defining a generic statement of requirements for data availability applicable for all decisions The third step in the validation process was the definition of a calculation algorithm suitable for servicing the calculation of incremental and opportunity costs (i.e relevant costs) for each 203 of the seven treasury management decisions generically To define this algorithm, an algorithm from business logistics (i.e MRP Netting) was borrowed and redefined into a suitable algorithm for financial resource scheduling A new term (the Cash Flow Equivalent – CFE) was introduced to make financial resource flows with different characteristics mutually comparable The proposed algorithm (i.e the Hierarchical Cash Flow Equivalent Model) results in a CFE calculation framework that accommodates the calculation of the CFE outcome of each of the decision alternatives in a specific decision-making situation The fourth and final step in the validation of the contract data model is to investigate whether the data model still complies with the new requirements for data availability that result from the seven treasury management decisions on one hand, and from the definition of the HCFEM model on the other hand The following conclusions were made at the end of this validation process The proposed contract data model was able to hold appropriate base data to service hierarchical treasury management decisions with relevant cost information However, a number of enhancements had to be made to comply with specific features of hierarchical treasury management decisions (e.g the accommodation of features like aggregated locations and family financial resources) and with HCFEM model features (e.g the accommodation of MRP netting reservation logic together with calendar functionality) These enhancements were processed and an elaboration of the Contract Pattern Model was proposed as finalization of the validation process 204 205 Samenvatting Dit onderzoek behandelt de vraag hoe een verbeterd datamodel voor informatiesystemen kan worden gedefinieerd, dat in staat is wijzigende informatievragen van een breed gebruikerspubliek te voorzien met de nodige data vanuit één centrale dataomgeving Deze problematiek werd in het verleden reeds in verschillende onderzoeksprojecten behandeld Daarom wordt eerst onderzocht of bestaande ERP-systemen de beschikbare resultaten van voorgaand onderzoek bevatten, en of de problematiek van beperkingen wegens onvoldoende beschikbare gegevens om nieuwe en / of wijzigende informatievragen te ondersteunen, nog steeds actueel is Deze vraag wordt getoetst via literatuuronderzoek en via een empirische evaluatie van de kenmerken van gegevensregistratie van een procesinstantie in een representatief ERP-systeem De volgende vier vaststellingen kwamen naar voren: Er is geen equivalent van de procesinstantie op niveau van de gegevens Gegevens van een losstaande procesinstantie worden vastgehouden in het datamodel, maar de procesinstantie zelf (het netwerk van instanties van activiteiten) is verloren op niveau van het datamodel; Elke beëindiging van een actviteiteninstantie leidt tot een procesinstantie-‘state’, domein-specifieke dataregistratie Deze gegevensregistratie van een procesinstantie‘state’ wordt geïsoleerd opgeslagen en niet als subcategorie van de procesinstantie; Indien gegevens van één enkele procesinstantie niet zijn vastgelegd op een gestructureerde manier, dan kan een gestructureerde organisatie van gegevens over verschillende procesinstanties heen niet verwacht worden; Gegevens van een procesinstantie worden niet vastgelegd volgens principes van REA of ‘Grundrechnung’ Geen ander gelijksoortig gegevensregistratie-object is gebruikt om gegevens van een procesinstantie te structureren De data-organisatiemethode van dubbel boekhouden is geïmplementeerd voor de ondersteuning van financiële informatievragen De empirische evaluatie van de methode van dataregistratie in bestaande ERP systemen heeft aangeduid dat, niettegenstaande reeds verschillende onderzoeksinitiatieven zich hebben gericht op het vinden van verbeterde datamodellen, er nog steeds bijkomend onderzoek kan worden verantwoord, daar de beschikbare onderzoeksresultaten tot dusver niet geschik bleken voor het ontwerp van datamodellen van grote ERP-systemen De twee hoofdeisen aan de data-omgeving van grote ERP-systemen zijn: a Gegevens die geregistreerd worden in het datamodel moeten geschikt zijn om informatie te voorzien voor de ondersteuning van wijzigende informatiebehoeftes; b Het datamodel moet voldoende robust zijn zodat het geschikt is voor grote ERP-implementaties In dit onderzoek ligt de klemtoon enkel op het voorstellen van een oplossing voor de eerste vraag Het eerste deel van het onderzoek richt zich op de definitie van een nieuw datamodel voor de opslag van transactiegegevens De eerste stap die gezet moet worden in het ontwerpen van een geschikt datamodel, is het vinden van een geschikt data-organisatie-paradigma Volgens verschillende auteurs moet een data-organisatie-paradigma dicht tegen aspecten van de realiteit liggen Het gekozen data-organisatiepatroon is het ‘contract’ dat een formele registratie van een ruil van resources beschrijft Dit patroon wordt gevonden door het gelijksoortig object, dat zich voordoet in verschillende types van business-transactie-gegevens zoals die op heden geregistreerd worden via de techniek van dubbel boekhouden, te onderzoeken Vervolgens worden een aantal aspecten van het contractbeginsel onderzocht, zoals bijvoorbeeld: de relatie tussen contracten en de organisatie, waarom het relevant is om ook interne contracten te registreren, hoe contracten met elkaar verbonden zijn, wat uitmondt 206 in het concept van de contract-portefeuille De activiteit van het registreren van contracten is beschreven als: ‘Op Contracten-gebaseerde Accounting’ De tweede stap in de definitie van een nieuw datamodel, is de definitie van essentiële gegevenscomponenten van het gekozen data-organisatie-paradigma in de vorm van ontwerpkenmerken Twee sets van ontwerpkenmerken worden gedefinieerd De eerste set betreft de ontwerpkenmerken van het contractpatroon met betrekking tot de dataregistratie van één enkele procesinstantie Gegevens van niet-gelinkte procesinstanties kunnen geregistreerd worden via het detailleren van aspecten zoals: contract-clausules, contractcondities, contract-participanten, enzovoort De tweede set van ontwerpkenmerken betreft de gegevensdefinitie van relaties die kunnen bestaan tussen procesinstanties Deze relaties worden gedefinieerd in het datamodel via ontwerpkenmerken betreffende relaties tussen contract-clausules Alle relaties tussen contract-clausules samen definiëren het concept van de contract-portefeuille zoals eerder aangegeven in de vorige paragraaf De derde en laatste stap in de definitie van het nieuwe datamodel betreft de vertaling van het data organisatie-paradigma samen met de ontwerpkenmerken van essentiële gegevenscomponenten naar een architectuur van een datamodel dat ontworpen is in een gekozen datamodelleer techniek Dit wordt gerealiseerd door drie specifieke objectmodellen voor te stellen in UML Het eerste model (het Contract Clausule Model) is een model voor registratie van ruil van resources, vastgelegd in contract-clausules en de registratie van relaties tussen contract-clausules onderling Het tweede model (het Fulfillment Model) ondersteunt de dataregistratie van de uitvoering van resource uitwisseling (bijvoorbeeld: facturatie, levering, betaling, enzovoort) Het derde en laatste model (het Contract Model) betreft een integratie van het Contract Clausule Model en het Fulfillment Model, en ondersteunt een volledige contract-dataregistratie Het tweede deel in dit onderzoek gaat over de validering van het voorgestelde datamodel Het onderzoeksdoel waarop deze dissertatie zich richt, betreft de defintie van een datamodel dat in staat is om nieuwe en wijzigende informatievragen van gegevens te voorzien Het proces van validering start daarom met de definitie van een nieuwe applicatie als Stap Stap bestaat uit het uitschrijven van de eisen met betrekking tot beschikbaarheid van gegevens die nodig zijn voor de ondersteuning van deze nieuwe applicatie Stap betreft de definitie van een algoritme ter ondersteuning van de berekeningen die van toepassing zijn in de gekozen applicatie Ten slotte bestaat Stap uit de eigenlijke validatie van de bruikbaarheid van het datamodel Er wordt nagegaan of er voldoede informatie ter beschikking kan worden gesteld via het gedefinieerde datamodel en, indien niet, worden er uitbreidingen voorgesteld Elk van de vier stappen wordt hierna in detail beschreven De eerste stap in het proces van validering is de definitie van een nieuwe applicatie Er wordt bewust gekozen voor een nieuwe applicatie en niet voor de toetsing van een reeds bestaande, omdat een nieuwe applicatie dezelfde kenmerken heeft van een ‘gewijzigde informatievraag’ vanuit het perspectief van de gebruiker De keuze voor een nieuwe applicatie valt op hiërarchische Treasury Management besluitvorming omdat deze manier van besluitvorming nog niet toegepast wordt in de dagelijkse Treasury praktijk Hiërarchische Treasury Mangement beslissingsmodellen worden voorgesteld voor drie verschillende types van besluitvorming: gecentraliseerde, gedecentraliseerde en hybride besluitvorming De volgende beslissingen worden ondersteund in het hybride model voor Treasury Management besluitvorming: 1) Definiëren van het Hoofd-Financieringsplan; 2) Optimaliseren van betaalopdrachten van financiële resources; 3) Optimaliseren van ontvangstopdrachten van financiële resources; 4) Optimaliseren van beleggingsopdrachten van overschotten van financiële resources; 5) Optimaliseren van leningsopdrachten ten behoeve van uitbreiding van de hoeveelheid financiële resources; 6) Optimaliseren van conversieopdrachten van financiële resources; en 7) Optimaliseren van niveaus van veiligheidsvoorraaden van financiële resources 207 De tweede stap in het valideringsproces is de definitie van de eisen van de nodigde gegevens ten behoeve van de ondersteuning van de gekozen applicatie Beslissingen kunnen worden ondersteund door alle soorten informatie, gaande van niet-financiële informatie tot zuiver financiële informatie In dit onderzoek wordt gekozen om de beslissingen te ondersteunen met relevante kosten-informatie, namelijk: incrementele en opportunity kosten Voor elk van de zeven Treasury Management beslissingen wordt eerst de inhoud van de vraag beschreven Nadien wordt uitgelegd welke accounting-informatie er nodig is om de beslissingen met relevante kosten-informatie te ondersteunen Vervolgens worden de specifieke eisen aan gegevensbeschikbaarheid per beslissing opgesteld Tenslotte wordt een overzicht gegeven van alle eisen aan gegevensbeschikbaarheid voor de ondersteuning van alle Treasury Management eisen samen Als derde stap in het valideringsproces moet een geschikt algoritme opgesteld worden, dat de noodzakelijke berekeningen ondersteunt voor incrementele en opportunity kosten voor elk van de zeven Treasury Management beslissingen in het hiërarchisch Treasury Management beslissingsraamwerk Voor de definitie van dit algoritme wordt een algoritme van het domein Logistiek Management (namelijk MRP netting) geleend en geherdefinieerd zodat het geschikt wordt voor planning van financiële resources Een nieuwe term (geldstroomequivalent) wordt geïntroduceerd om financiële geldstromen met verschillende kenmerken onderling vergelijkbaar te maken Het voorgestelde algoritme (Hiërarchisch Geldstroom Equivalentenmodel) wordt vertaald in een geldstroom equivalenten calculatiemodel Dit calculatiemodel ondersteunt de berekening van een geldstroomequivalent van elk van de mogelijke beslissingsalternatieven in een specifieke besluitvormingssituatie De vierde en laatste stap in de validering van het contract datamodel is de vraag of het datamodel in staat is om gegevens ter beschikking te stellen om de zeven Treasury Management beslissingen te ondersteunen met incrementele en opportunity kosteninformatie enerzijds en om het Hiërarchisch Geldstroom Equivalentenmodel door te rekenen anderzijds Aan het einde van het valideringsproces kunnen de volgende conclusies getrokken worden Het voorgestelde contract datamodel is geschikt om basisgegevens te voorzien ter ondersteuning van hiërarchische Treasury Management besluitvorming met relevante kosteninformatie Maar een aantal uitbreidingen zijn noodzakelijk om te voldoen aan specifieke kenmerken van hiërarchische besluitvorming (bijvoorbeeld: de definitie van geaggregeerde locaties en families van financiële resources) Ook zijn een aantal uitbreidingen noodzakelijk gebleken om te voldoen aan kenmerken van het Hiërarchisch Geldstroom Equivalentenmodel (bijvoorbeeld de ondersteuning van MRP netting reserveringslogica, en kalenderfunctionaliteit) Deze uitbreidingen worden voorgesteld alsook een uitgebreide versie van het Contract Model als sluitstuk van de validatie 208 209 About the author Piet E.A Vandenbossche was born on August 25, 1969 in Kortrijk, Belgium He finished highschool in commercial informatics at the Heilig-Harthandelsinstituut in Waregem, Belgium, where he received the laureate price for the mayor (informatics) He graduated with honours degree as ‘Licentiaat in de Handels- en Financiële Wetenschappen, Accountancy’ (Master in Commercial and Financial Sciences with major in Accountancy) at the Economische Hogeschool Sint-Aloysius (EHSAL – Brussels, Belgium) At this institute, he also graduated as ‘Geaggregeerde voor het Hoger Secundair onderwijs – GHSO’ (Teachers Degree) and obtained the degree of ‘Certified Company Trainer’ He received the laureate price for his master’s thesis from the BBL Bank (subsidiary of the ING bank, the Netherlands) Afterwards, he finished the ‘Postgraduaat Financiewezen’ (Postgraduate in Financial Management) at the Katholieke Universiteit Leuven (Catholic University of Leuven, Belgium) He received the degree of Certified in Production and Inventory Management (CPIM) from the American Production and Inventory Control Society (APICS) He finalized a PhD dissertation on Accounting Data Models in ERP systems and treasury management decision-making based on concepts of business logistics under the supervision of professor dr ir Wortmann and professor dr van der Meer-Kooistra at the Rijksuniversiteit Groningen (University of Groningen, the Netherlands) Furthermore, he is doing Law Studies at the Open Universiteit (Open University, the Netherlands) where he received the ‘Propedeuse in Nederlands Recht’ (Candidate degree in Dutch Law Studies) He will continue the law studies with the goal to obtain the degrees of Bachelor in Law Studies (LLB) and Master in Law Studies (LLM) at the same university He is a frequent lecturer at the Financial Academy in ‘s Hertogenbosch (the Netherlands) in the post-graduate programs ‘Corporate Treasurer’ and ‘Corporate Controller’ He will continue conducting scientific research in Business Information Systems and Treasury Management decision-making to result in scientific publications in international and national journals He continues to specialize in Corporate- and Bankruptcy Law, and Intellectual Property Law He started his professional career in 1993 as controller of Deko Industries NV (Zele, Belgium) Afterwards, he joined Baan Company, currently owned by SSA Global Technologies where he became an expert in financial information systems and ERP systems in general He worked in different roles, such as software engineer, functional engineer, project leader, functional architect and alliance manager Currently he occupies the role of senior solution manager of SSA’s financial product portfolio In this capability, he is responsible for the global availability of over 100 financial software products in 15 different ERP product lines He is architect of a new financial product line called ‘SSA Financial Management’, now SSA’s financial flagship solution suite which is designed according to the principles of the financial value chain