ONTWIKKELING VAN EEN ACCURAAT, WAARHEIDSGETROUW EN FLEXIBEL REA ACCOUNTING INFORMATIESYSTEEM

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2008 – 2009

ONTWIKKELING VAN EEN ACCURAAT, WAARHEIDSGETROUW EN FLEXIBEL REA ACCOUNTING INFORMATIESYSTEEM Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur

Lies Bricout onder leiding van Prof. dr. G. Poels

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2008 – 2009

ONTWIKKELING VAN EEN ACCURAAT, WAARHEIDSGETROUW EN FLEXIBEL REA ACCOUNTING INFORMATIESYSTEEM Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur

Lies Bricout onder leiding van Prof. dr. G. Poels

PERMISSION

Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Lies Bricout

I

Woord vooraf

Reeds bij de aanvang van het eerste masterjaar handelsingenieur had ik, gelet op mijn doorgedreven interesse in het boekhouden en zijn verschijningsvormen, voor mezelf uitgemaakt dat ik een met accounting gerelateerde masterproef wilde schrijven.

De totstandkoming van dit werk mag dan al boeiend zijn geweest, het totstandkomingsproces heeft ook bloed, zweet en tranen gekost. Niet enkel mijn eigen inbreng, maar ook de steun van een aantal mensen heeft de verwezenlijking van dit werk mogelijk gemaakt.

In eerste instantie wil ik mijn promotor, prof. dr. Poels, bedanken. Hij was steeds bereid mij te woord te staan om extra uitleg en informatie te verschaffen.

Bijzondere dank gaat tevens uit naar mijn begeleider, Wim Laurier, die mij te allen tijde met raad en daad heeft bijgestaan.

Tot slot wil ik tevens mijn zus, ouders en grootouders bedanken voor hun onaflatende morele steun. Het is mede dankzij hun blijvende steun en motivatie dat ik mijn masterproef – en studies in het algemeen – tot een goed einde wist te brengen.

II

Inhoudsopgave Inleiding ...................................................................................................................................... 1 Hoofdstuk 1 - Situering REA ontologie .................................................................................. 3 1.1

Algemeen ......................................................................................................................... 3

1.2

Uitbreidingen en verbeteringen......................................................................................... 8

Hoofdstuk 2 - Ontwikkeling REA database .......................................................................... 11 2.1

Basisstructuur ................................................................................................................ 11

2.2

Toevoegingen ................................................................................................................ 12 2.2.1

2.3

Tabellen Resource – Decrement en Resource – Increment .............................. 12

Abstracties ..................................................................................................................... 13 2.3.1

Agentparticipatie in transfer events ................................................................... 13

2.3.2

Commitment deel .............................................................................................. 13

2.4

Elementen REA database .............................................................................................. 14

2.5

Modellering bedrijfsprocessen ........................................................................................ 15

2.6

2.5.1

Schets onderneming M ..................................................................................... 16

2.5.2

Schets onderneming D ...................................................................................... 17

Nut REA accounting informatiesysteem ......................................................................... 17

Hoofdstuk 3 - De individuele jaarrekening .......................................................................... 19 3.1

Concept .......................................................................................................................... 19

3.2

Courante exploitatiecyclus .............................................................................................. 20 3.2.1

Aankopen .......................................................................................................... 21 3.2.1.1 Registratie in de REA database ............................................................ 21 3.2.1.2 Het genereren van de relevante jaarrekeningposten ............................ 22

3.2.2

Betalingen aan leveranciers .............................................................................. 25 3.2.2.1 Registratie in de REA database ............................................................ 25 3.2.2.2 Het genereren van de relevante jaarrekeningposten ............................ 27

3.2.3

Creditnota‟s op aankopen.................................................................................. 27

3.2.4

Conversies ........................................................................................................ 28 3.2.4.1 Registratie in de REA database ............................................................ 28

3.2.5

Verkopen........................................................................................................... 30 3.2.5.1 Registratie in de REA database ............................................................ 30 3.2.5.2 Het genereren van de relevante jaarrekeningposten ............................ 32

3.2.6

Ontvangsten van klanten ................................................................................... 34 3.2.6.1 Registratie in de REA database ............................................................ 34

III 3.2.6.2 Het genereren van de relevante jaarrekeningposten ............................ 35 3.2.7 3.3

Creditnota‟s op verkopen................................................................................... 36

Afsluitingsverrichtingen................................................................................................... 36 3.3.1

Aankopen, verkopen en voorraad...................................................................... 37

3.3.2

Anticipatie- en uitstelposten met betrekking tot kosten en opbrengsten ............. 38

3.3.3

Vaste activa....................................................................................................... 39

3.3.4

Controle op de waardering van vorderingen en schulden .................................. 40

3.4

Resultaatbepaling en -verwerking .................................................................................. 40

3.5

Creatie grootboek ........................................................................................................... 41

3.6

Persoonlijke bevindingen................................................................................................ 41

Hoofdstuk 4 - Consolidatie ................................................................................................... 46 4.1

Concept .......................................................................................................................... 46

4.2

Uitwerking ...................................................................................................................... 48

4.3

4.2.1

FASE 1: Samenvoeging individuele jaarrekeningen .......................................... 48

4.2.2

FASE 2: Verwerking correcties .......................................................................... 51

4.2.3

FASE 3: Becijfering duplicaten geconsolideerde jaarrekening ........................... 53

Persoonlijke bevindingen................................................................................................ 53

Hoofdstuk 5 - Hypothesen voor toekomstig werk ............................................................... 55 Hoofdstuk 6 - Conclusie ....................................................................................................... 57 Lijst van de geraadpleegde werken ............................................................................................. I

IV

Lijst van de figuren

Figuur 1: Basisstructuur REA ontologie, overgenomen uit ISO (2006) ....................................... 4 Figuur 2: REA relaties, gebaseerd op Geerts & McCarthy (1997) .............................................. 5 Figuur 3: Illustratie economische uitwisseling, overgenomen uit ISO (2006) .............................. 6 Figuur 4: Vereenvoudigde waardeketen, overgenomen uit Vaassen (2002) .............................. 7 Figuur 5: REA referentieinformatiemodel, overgenomen uit Laurier & Poels (2009) ................ 11 Figuur 6: Structuur REA database, gebaseerd op Laurier & Poels (2009) ............................... 12 Figuur 7: De waardeketen, overgenomen uit Verra (1998) ...................................................... 16 Figuur 8: Deelgebieden accounting, volgens Siegel & Shim (2000) ......................................... 18 Figuur 9: Bills Of Materials onderneming M ............................................................................. 28

Bijlagen Bijlage 1: Tabel ‘/ Rekeningnummers’ ..................................................................................... I Bijlage 2: Aflossingstabel investeringslening ....................................................................... III Bijlage 3: Overzicht transacties in REA database ................................................................. IV Bijlage 4: Output eerste onderzoeksvraag ............................................................................ VI Bijlage 5: Queries in verband met handelsschulden .......................................................... VIII Bijlage 6: Queries in verband met handelsvorderingen ....................................................... XI Bijlage 7: Queries in verband met de inventarisverrichtingen .......................................... XIV Bijlage 8: Queries in verband met de resultaatverwerking............................................. XXVII Bijlage 9: Grootboek onderneming M (excl. inventarisverrichtingen) ............................ XXIX Bijlage 10: Correctie-queries geconsolideerde jaarrekening .......................................... XXXI Bijlage 11: 7-stappenmethode ............................................................................................. XLI Bijlage 12: Output tweede onderzoeksvraag ..................................................................... XLV

V

1

Inleiding

Ondanks de niet aflatende toename van netwerk- en informatietechnologieën vallen veel bedrijven nog steeds terug op afzonderlijke subsystemen om gespecialiseerde functies, zoals marketing-, accounting- en personeelsinformatiesystemen, te ondersteunen. Het is voor het gros der ondernemingen onmogelijk voorbij het principe van een afzonderlijk boekhoudsysteem – op basis van de basisbeginselen van het dubbel boekhouden – te kijken.

Dergelijk

afzonderlijk

boekhoudsysteem,

dat

dan

bestaat

naast

een

afzonderlijk

personeelsinformatiesysteem, een afzonderlijk voorraadinformatiesysteem e.d., biedt echter niet de mogelijkheden van een gecentraliseerd en geïntegreerd systeem. Een Enterprise Resource Planning systeem (hierna: ERP systeem) zou bijvoorbeeld de nood aan gestructureerde, semantische1 en databasegerichte bedrijfssystemen kunnen lenigen en bijgevolg dezelfde en zelfs meer informatie genereren dan een afzonderlijk boekhoudsysteem. ERP systemen helpen organisaties immers ook om te gaan met de verschillende stappen in de toeleveringsketen,

i.e.

goederenontvangst,

voorraadbeheer,

klantordermanagement,

productieplanning, goederenverzending, boekhouding en personeelsmanagement. (Somers & Nelson, 2003) Indien zou worden overgestapt op het gebruik van een centrale database (alle bedrijfsgegevens komen bij ERP softwarepakketten terecht in een centrale database), zou bijgevolg een geïntegreerd systeem worden bekomen waarbij het mogelijk is om allerlei gegevens te delen overheen de functionele domeinen.

Tijdens het datamodelleringsproces dient een database te worden opgesteld op zodanige wijze dat enkel de belangrijkste elementen van een organisatie en haar omgeving worden opgenomen. (Vaassen, 2002) Een reeds veel besproken ontologie2 die kan worden aangewend bij de constructie van een doordachte en standvastige centrale database, is de Resource Event Agent (hierna: REA) ontologie. De basis van deze ontologie werd gelegd in 1982 en is gebaseerd op alomgekende boekhoudprincipes. Rond 2000 werd de ontologie onderworpen aan verscheidene uitbreidingen, zodat uiteindelijk een volwaardige bedrijfsontologie werd bekomen.

1

Semantiek is de leer van de interpretatie van formele systemen. (Grote Van Dale)

2

Een ontologie is een expliciete specificatie van een conceptualisatie. (Gruber, 1993) Ontologieën voorzien in een interessante

theoretische en deductieve aanpak voor bedrijfsmodellering, dit in tegenstelling tot het patronen-gebaseerd modelleren waarin een empirische en inductieve aanpak wordt gehanteerd. (Laurier & Poels)

INLEIDING

2

“Business domain ontologies offer great opportunities for facilitating communication between people in business, for improving the enterprise system engineering processes and for creating interoperability between enterprise systems.” (Gailly & Poels, 2005, p. 1)

Dit citaat doet vermoeden dat een toepassing van de REA bedrijfsontologie in de praktijk (wat heden ten dage nog niet gebeurt) vele voordelen zou kunnen opleveren. Het zou mogelijk zijn vergaarde informatie op eenvoudige wijze te delen met alle bedrijfspartners, wat een vlotte communicatie in de hand zou werken. Bovendien zou het ook een groot voordeel zijn dat er interoperabiliteit wordt gecreëerd tussen bedrijfssystemen. Dit sluit aan bij het concept van een ERP systeem: verschillende software modules, die elk een bepaald functioneel domein van de organisatie betreffen, worden geïntegreerd met elkaar. (Nah, 2002)

Het is de bedoeling om in dit werk een overzicht te geven van de praktische mogelijkheden die de REA ontologie aanreikt. Er kan – en terecht – worden gesproken over een „proof of concept‟: de REA theorie zal worden getoetst aan de praktijk. Twee onderzoeksvragen worden in detail uitgewerkt. Via de eerste onderzoeksvraag wordt nagegaan in hoeverre de REA ontologie zich ertoe leent, aan de hand van een Access database, een boekhouding te voeren. Zal het systeem in de mogelijkheid verkeren om een jaarrekening te genereren? De tweede onderzoeksvraag heeft betrekking op een consolidatie: zal het mogelijk zijn, gebruik makend van de REA Access database, een consolidatie van twee of meer bedrijven te vergemakkelijken en eventueel te automatiseren? Voor beide onderzoeksvragen geldt dat telkens een kritische vergelijking met een traditioneel boekhoudsysteem wordt doorgevoerd. Alle mogelijke tekorten en verbeteringen van het REA accounting informatiesysteem worden aangehaald.

In eerste instantie werd de REA ontologie in detail bestudeerd. Een beknopt overzicht van de belangrijkste bevindingen wordt geschetst in het eerste hoofdstuk van deze masterproef. Op basis van de literatuurstudie werd een REA database geconstrueerd met behulp van het programma Microsoft Access. Uitleg over de structuur en werking van de database wordt meegegeven in hoofdstuk 2. Hoofdstuk 3 gaat dieper in op een mogelijke concrete toepassing van de REA ontologie in de praktijk, i.e. via het gebruik van de Access database. Er wordt nagegaan of individuele jaarrekeningen kunnen worden gegenereerd op basis van de database. Aansluitend worden de meest relevante conclusies meegegeven. De praktische uitwerking van een consolidatievoorbeeld komt aan bod in hoofdstuk 4, gevolgd door de belangrijkste conclusies. Het vijfde hoofdstuk omvat een overzicht van in de toekomst mogelijk te bestuderen punten. In een zesde en laatste hoofdstuk wordt het volledige werk toepasselijk afgesloten met een conclusie.

HOOFDSTUK 1 – SITUERING REA ONTOLOGIE

3

HOOFDSTUK 1 SITUERING REA ONTOLOGIE Eerder dan het verschaffen van een allesomvattende en diepgaande analyse van de REA ontologie, heeft dit hoofdstuk tot doel een duidelijke theoretische achtergrond aan te reiken teneinde de verdere uitwerking van de masterproef te verduidelijken.

1.1

Algemeen

McCarthy werkte als eerste het REA model uit. (McCarthy, 1982) Hij stelde hierbij in feite de nood aan het dubbel boekhouden in vraag. McCarthy argumenteerde dat de traditionele manier van dubbel boekhouden, op basis van het Debet-Credit-Account (DCA) accounting model, te veel gebreken vertoont en te veel focust op de accounting artefacts debet, credit en rekeningen.

Het belang van het REA accounting model kan worden teruggevonden in omgevingen waar zowel accountants als niet-accountants interesse hebben voor het handhaven en verkrijgen van dezelfde relevante bedrijfsinformatie. (McCarthy, 1982) Noden van verscheidene gebruikers kunnen immers worden ingevuld via een gedeelde toegang tot eenzelfde bedrijfssysteem. REA accounting ondersteunt zowel het financieel boekhouden als het beleidsboekhouden: er kan informatie worden verschaft aan derden en aan de onderneming zelf. (De Lembre, 2004a) De onderliggende structuur van de REA ontologie bestaat uit economische „resources‟, „events‟ en „agents‟: een economische agent beïnvloedt een economische resource via een economisch event. (McCarthy, 1982) (zie figuur 1)


Resource

Stockflow

Event

4

Participation

Agent

Duality Figuur Basisstructuur overgenomen uit ISO(Hruby, (2006)2006) Een „resource‟ is iets1:schaars dat nut REA heeft ontologie, voor de economische agents. „Resources‟ kunnen worden geleverd of opgebruikt door een bedrijf. (Dunn, Cherrington, & Hollander, 2005) Een resource kan worden gezien als een verzameling van bepaalde geassocieerde rechten (eigendomsrecht, gebruiksrecht of auteursrecht). In die zin zijn resources vergelijkbaar met activa. (Bagranoff et al., 2005) Om te bepalen of iets al dan niet als een resource kan worden beschouwd, worden twee handige vuistregels vooropgesteld. In eerste instantie moet de resource een object zijn dat een bepaalde waarde vertegenwoordigt, geassocieerd met een event. Daarnaast dient het interessant genoeg te zijn om nadere studie te verantwoorden. Resources worden bovendien vaak ingedeeld in subcategorieën. Zo worden de subtypes goederen (materialen, fondsen en vastgoed), diensten (menselijke diensten, transportdiensten…) en rechten (zoals intellectuele producten) naar voren geschoven. (ISO, 2006) Een „event‟ is een bedrijfsproces dat moet worden gepland, gecontroleerd, uitgevoerd en geëvalueerd. (Dunn et al., 2005) Het heeft impact op de jaarrekening van een onderneming en zit vervat in accounting transacties. (Bagranoff et al., 2005) Het doel van een event komt neer op een tijdelijke of permanente overdracht van bepaalde rechten, die geassocieerd worden met een resource, van een economische agent naar een andere. (Hruby, 2006) Hierdoor impliceert dit hetzij een toe- hetzij een afname van de waarde van de resources. Er wordt gesproken over respectievelijk increment (inflow relationship) en decrement (outflow relationship). (Hruby, 2006) Logischerwijs dient elk increment event te zijn gelinkt aan een decrement event en omgekeerd: indien een onderneming bepaalde goederen ontvangt (bijvoorbeeld door het aankopen van goederen), dient zij hiervoor iets in de plaats te geven (leveranciers van goederen moeten op de een of andere manier – in natura of in geld – worden vergoed). Dit is conform de boekhoudlogica rond debet/credit: met het aankopen van goederen (inflow relationship) bijvoorbeeld gaat een schuld aan de leverancier gepaard, die moet worden vereffend (outflow relationship). Deze relatie wordt vaak aangeduid met de term „exchange duality‟. Duality relationships bestaan bijgevolg tussen increment events en decrement events. Inflow


5

relationships en outflow relationship worden ook wel „stockflow relationships‟ genoemd. Ze stellen de relatie voor tussen de events en de resources. (Geerts & McCarthy, 1997) Een „agent‟ is een individu, een departement, een divisie of een organisatie, die participeert in de controle en de uitvoering van events. (Dunn et al., 2005) Agents hebben bijgevolg controle over bepaalde economische resources. (Hruby, 2006) Zij zijn betrokken bij de events. (Vaassen, 2002)

Ter verduidelijking kunnen een aantal voorbeelden worden aangereikt: -

Resources: geldmiddelen, contracten, voorraad, uitrusting, materiële vaste activa Er dient te worden opgemerkt dat accounts receivable en accounts payable niet als resources kunnen worden aanzien. Dit zijn immers „claims on resources‟. (Dunn et al., 2005) Een claim kan zich voordoen wanneer een increment event niet direct gelinkt is aan een decrement event. Dit tijdelijk onevenwicht wordt dan opgevangen door een claim tussen economische agents. Normalerwijze is het zelfs zo dat increment en decrement events niet simultaan plaats vinden. (Hruby, 2006)

-

Events: verkooporders, verkopen, aankooporders, aankopen, ontvangst van goederen, aanwerven van een werknemer.

-

Agents: werknemers, klanten, verkopers, managers, aandeelhouders, schuldeisers.

Een economisch event zal telkens gerelateerd zijn aan twee economische agents. Immers, er dient een „provide relationship‟ te bestaan evenals een „receive relationship‟: er zal telkens een economische agent in het spel zijn die economische resources zal verliezen en een andere die er zal ontvangen, en dit ten gevolge van het event. (Hruby, 2006) Deze derde soort relatie kan worden aangeduid met de term „participation relationship‟ of „control relationship‟ (Geerts & McCarthy, 1997).

Onderstaande figuur kan duidelijkheid scheppen wat betreft de drie verschillende relaties: Resource (+)

Resource (-)

Control

Stock-flow

Agent

Agent Increment Event

Decrement Event

Agent Duality Figuur 2: REA relaties, gebaseerd op Geerts & McCarthy (1997)

Agent


6

In figuur 3 wordt geïllustreerd wat feitelijk gebeurt in een economische uitwisseling, en is bijgevolg voornamelijk beschrijvend. Deze descriptieve componenten kunnen worden aangevuld met prescriptieve componenten. (ISO, 2006) Aan de basisobjecten worden thans typecomponenten toegevoegd ter detaillering.

Figuur 3: Illustratie economische uitwisseling, overgenomen uit ISO (2006)

Ongeacht het type goederen of diensten dat een bedrijf levert, worden altijd minstens drie bedrijfsprocessen doorlopen (Dunn et al., 2005): 1. het aankoop- en betalingsproces: de benodigde middelen worden door de onderneming aangekocht, onderhouden en betaald. 2. het conversieproces3: de aangekochte resources worden omgezet in goederen en diensten voor klanten. 3. het verkoop- en inningsproces: goederen (en diensten) worden verkocht (en geleverd) aan klanten en betalingen worden ontvangen. Een onderneming kan logischerwijs de waarde van haar middelen vermeerderen of verminderen door zowel uitwisselingen („transfers‟) als conversies („transformations‟). (Hruby, 2006) Een uitwisseling is een proces waarbij de onderneming economische resources (grondstoffen, geld) ontvangt van andere economische agents (leveranciers, klanten) in ruil voor economische 3

Handelsondernemingen vormen de uitzondering op de regel: zij zullen niet geconfronteerd worden met een conversieproces.


7

resources (geld, eindproducten). Uitwisselingspatronen impliceren bijgevolg dat er goederen kunnen worden aangekocht dan wel verkocht. Hiertoe kan een vereenvoudigde waardeketen 4

enige verduidelijking scheppen (Vaassen, 2002), waarvoor wordt verwezen naar figuur 4 .

Figuur 4: Vereenvoudigde waardeketen, overgenomen uit Vaassen (2002)

Het uittekenen van de waardeketen van een onderneming kan een groot inzicht verlenen in de onderneming. (Dunn et al., 2005) De missie, strategie en de bedrijfsoperaties kunnen erdoor worden blootgelegd. Het vergemakkelijken van strategische analyses is dan ook een doel van de REA ontologie. De gegevens die terug te vinden zijn in een REA accounting informatiemodel zullen telkens de primaire bedrijfsdata zijn, geassocieerd met uitwisselingen of conversies. (Hruby, 2006) Hier situeert zich één van de grootste voordelen van een REA model: door gebruik te maken van onbewerkte economische gegevens kunnen meer allesomvattende, meer accurate en meer upto-date rapporten worden opgesteld. In de meeste huidige bedrijfssoftware applicaties ligt de klemtoon immers op de accounting artefacts. In meerdere werken werd de semantische uitdrukkingskracht van de REA ontologie, die weergeeft hoe goed het REA model de onderliggende realiteit reflecteert, reeds onder de loep genomen. (Dunn & Grabski, 2000; Poels, Maes, Gailly, & Paemeleire, 2004) Er is gebleken dat het REA accounting model als meer semantisch wordt aanzien dan het DCA accounting model. Dit gaat gepaard met een 4

In de figuur worden economische events weergegeven door ovalen. De aanduidingen „I‟ en „D‟ staan respectievelijk voor

increment en decrement. Economische resources worden aangeduid door rechthoeken.


8

makkelijkere integratie met representaties van niet-financiële informatie, en zal tevens leiden tot een beter begrip van accounting systemen door de gebruikers.

1.2

Uitbreidingen en verbeteringen

Er werd reeds meermaals gesleuteld aan de oorspronkelijke REA ontologie, zoals was voorgesteld door William E. McCarthy. (McCarthy, 1982) Uitbreidingen werden uitgedokterd met als doel een beter model te verschaffen.

De originele ontologie werd meerdere keren verbeterd door McCarthy zelf, in samenwerking met Guido Geerts. (Geerts & McCarthy, 2000) Daarbij werden typecomponenten (i.e. groeperingen van werknemers…) geïntroduceerd en commitments (i.e. contracten en overeenkomsten) geïncorporeerd. Een commitment is een belofte of een verplichting van een economische agent om in de toekomst een economisch event uit te voeren. Men stelt zich optimistisch op: men gaat ervan uit dat de uitwisseling in de toekomst zal doorgaan. Een contract daarentegen is een doelverklaring dat het gedrag tussen organisaties en/of individuen regelt. In een contract kan gespecificeerd staan wat er dient te gebeuren indien beloften niet worden ingelost door schending van de commitments. Een voorbeeld kan verduidelijking scheppen: indien een bedrijf haar uitrusting grondig laat nakijken en zonodig verbeteren, hebben we te maken met een increment economisch event (de boekwaarde van de uitrusting na het onderhoud zal normaal gezien groter zijn dan voordien). Het is evenwel mogelijk dat de uitrusting tijdens het – goedwillige – onderhoud schade oploopt. Zo‟n situatie kon opgenomen zijn in een contract: er kon een decrement event gemodelleerd zijn om de daling in waarde van de resource op te vangen. (Hruby, 2006)

Uiteindelijk hebben Geerts & McCarthy (2002) het REA accounting model omgevormd tot een veelomvattende bedrijfsdomeinontologie5. Het zou kunnen dienst doen als fundering voor het uitbouwen van bedrijfssystemen die zowel informatie voor accounting doeleinden kunnen genereren als voor het merendeel der besluitvormingsprocessen. Voor ontologieën kan in het algemeen een dubbel – en contradictorisch – doel worden gespecificeerd (Gómez-Pérez & Rojas, 1999): ze moeten enerzijds algemeen genoeg zijn en

5

Domeinontologieën hebben tot doel het specificeren van een conceptualisatie van een domein, i.e. een specifiek deel van de

realiteit. (Guarino, 1998)


9

toepasbaar in verschillende applicaties („reusability‟) en anderzijds moeten ze tevens specifiek genoeg zijn om te kunnen worden toegepast in de praktijk („applicability‟). In 2007 spitsten Gailly en Poels (2007) zich toe op het verbeteren van de conceptuele representatie van de REA ontologie. Vroegere impliciete semantiek werd nu expliciet verwerkt in de conceptuele representatie, via het toepassen van enkele ontologie ontwikkelingsprincipes. In eerste instantie was er de nood om de REA ontologie te modelleren met behulp van een conceptuele modelleertaal (bijvoorbeeld UML). Dergelijke conceptuele modellering zou moeten leiden tot een verbeterde leesbaarheid en een begrijpelijker systeem. Bovendien werd ook het „double articulation principle‟ toegepast. (Jarrar, 2005) Dit stelt dat een domeinontologie zou moeten worden opgedeeld in een domein-axiomatisering6 en een aantal applicatieaxiomatiseringen, waarbij de domein-axiomatisering staat voor de beoogde betekenis van de ontologie voor het publiek. Applicatie-axiomatiseringen specificeren welke delen van een domein-axiomatisering

belangrijk

zijn

voor

een

bepaalde

applicatie

en

voegt

applicatiespecifieke regels toe. De toepasbaarheid van de REA ontologie in de praktijk werd hierdoor verbeterd.

Uit het gebruik van REA als een ontologisch raamwerk voor het formeel specificeren en definiëren van concepten die verband houden met bedrijfsprocessen, scenario‟s en de relaties tussen beiden, resulteert de „Open-edi (open - electronic data interchange) business transactions ontology‟. (ISO, 2006) Hiertoe moeten de componenten van de REA ontologie goed gedefinieerd worden, stabiel en welgekend zijn. Bovendien moeten ze onafhankelijk worden bekeken, i.e. van buiten de onderneming uit. Een bedrijfsproces kan worden geconstrueerd uit een set van fundamentele activiteiten: planning, identificatie, negotiatie, actualisering en post-actualisering. (ISO, 2002) In deze context zal de REA ontologie worden aangewend ter ondersteuning van de samenwerking binnen en tussen ondernemingen.

Eén van de naderhand aangebrachte verbeteringen aan de REA ontologie verdient bijzondere aandacht, namelijk deze aangereikt door Wim Laurier en Geert Poels (Laurier & Poels, 2009). Zij definieerden een REA referentieinformatiemodel. Het referentiemodel beschouwt niet de onderneming als centrale entiteit, maar houdt rekening met de hele toeleveringsketen. Dit impliceert dat, naast de drie basisonderdelen van de REA ontologie (i.e. Resources, Events en Agents) tevens het concept „Economic Unit‟ moet worden geïntroduceerd. Economic units zijn entiteiten (ondernemingen, groepen, personen…) die een passieve rol spelen binnen het geheel als eigenaars van bepaalde middelen dewelke ze kunnen benutten via events. Een andere term hiervoor zou kunnen zijn „stakeholders‟.

6

Axiomatisering is een proces waarbij wordt gereduceerd tot een systeem van axioma‟s.


10

Stakeholders zijn individuen of groepen die de activiteiten van een organisatie kunnen beïnvloeden of erdoor zelf beïnvloed worden en omvatten met andere woorden werknemers, shareholders (investeerders), klanten, leveranciers en de omgeving (samenleving). (Svendsen, 1998) Stuart Cooper (2004) heeft een stakeholder raamwerk gedefinieerd via hetwelk „sociale bedrijfsperformantie‟ kan worden gemeten. Hij argumenteert dat niet louter de financiële performantie van een bedrijf moet worden onder de loep genomen, maar dat tevens belang moet worden gehecht aan niet-financiële maatstaven (i.e. ontastbare drivers van succes op lange termijn). Cooper streeft aldus een bredere voorstelling na, waarbij alle stakeholders in rekening worden gebracht (en niet louter de interessepunten van de shareholders worden beoogd). Het referentiemodel van Laurier en Poels (2009) voldoet aan deze voorstelling. Een onderscheid moet worden gemaakt tussen externe dan wel interne stakeholders. Hill en Jones (1997) definiëren interne stakeholders als zijnde de aandeelhouders en de werknemers van een onderneming, inclusief managers en bestuursleden. Externe stakeholders zijn – zoals de benaming laat vermoeden – geen onderdeel van de organisatie. Het betreft klanten, leveranciers, crediteuren (zoals banken en obligatiehouders), de regering, de omgeving (de maatschappij)… Via de tabel „Economic Unit‟ worden de bedrijven gemodelleerd waarvan de gegevens/transacties

worden

bijgehouden,

de

aandeelhouders

evenals

alle

externe

stakeholders. Daarnaast worden alle werknemers met naam en toenaam vermeld in de tabel „Agent‟. Op die manier worden alle stakeholders opgenomen in de database.

HOOFDSTUK 2 – ONTWIKKELING REA DATABASE

11

HOOFDSTUK 2 ONTWIKKELING REA DATABASE Teneinde de praktische uitwerking van de twee onderzoeksvragen mogelijk te maken, moest in eerste instantie een database, conform de REA ontologie, worden ontworpen.

2.1

Basisstructuur

Voor deze masterproef werd een Access database geconstrueerd in lijn met het door Laurier en Poels (2009) gedefinieerde REA referentieinformatiemodel (zie figuur 5).

Figuur 5: REA referentieinformatiemodel, overgenomen uit Laurier & Poels (2009)


12

Na de nodige aanpassingen (infra p. 12 en 13) aan het referentiemodel, werd een nieuwe REA database structuur (zie figuur 6) bekomen.

Figuur 6: Structuur REA database, gebaseerd op Laurier & Poels (2009)

2.2

Toevoegingen

2.2.1 Tabellen Resource – Decrement en Resource – Increment Aangezien het mogelijk is via een aankoopfactuur (1 tuple in de tabel Increment) verschillende goederen (2 of meer tuples in de tabel Resource) aan te kopen, was het noodzakelijk om een extra tabel „Resource – Increment‟ toe te voegen. Een analoge redenering kan uiteraard worden gemaakt wat betreft de verkoopfacturen, resulterend in de toevoeging van de tabel „Resource – Decrement‟. De additie van deze twee tabellen reikt tevens een oplossing aan voor het dualiteitsprobleem (Borch & Stefansen, 2004): het duality axioma7 impliceert dat er een een-op-eenrelatie bestaat tussen increment events en decrement events. Het probleem stelde zich immers dat het bijvoorbeeld mogelijk was een wagen aan te kopen in ruil voor cash of in ruil voor zowel een oude wagen als cash. In dit laatste geval moeten twee resources gelinkt zijn aan de betaling 7

Het duality axioma stelt dat alle outflow events uiteindelijk moeten gepaard gaan met inflow events. (Geerts & McCarthy, 2000)


13

van de aankoop (decrement event), wat kan worden opgelost via de extra tabel Resource – Decrement. Op die manier zal er inderdaad altijd een een-op-eenrelatie bestaan tussen increment events en decrement events.

2.3

Abstracties

2.3.1 Agentparticipatie in transfer events Laurier en Poels (2009) beschouwen de participatie van agents in events. Een event kan worden uitgevoerd door een of meerdere agents. In de REA database worden hieromtrent een aantal veronderstellingen gemaakt: -

Agents (bedienden of arbeiders) participeren niet in de transfer events, die een uitwisseling van goederen impliceren (bijvoorbeeld aan- en verkopen).

-

Agents (arbeiders) nemen wel deel aan conversion events. De assumptie wordt gemaakt dat er voor elke conversie slechts één arbeider nodig is.

Bovendien wordt abstractie gemaakt van de custody relatie die agents hebben met resources (i.e. agents houden middelen aan). Middelen worden immers allen gezien als eigendom van een economic unit, gezien het nooit de bedienden of arbeiders zullen zijn die de goederen bezitten.

2.3.2 Commitment deel Ondanks het feit dat de commitment kant in het referentiemodel expliciet wordt weergegeven, wordt deze niet opgenomen in de REA database. De reden hiervoor ligt in het feit dat het tijdsverspilling zou betekenen voor een organisatie indien alle commitment concepten (Commitment, Increment_Commitment, Decrement_Commitment en Reciprocity) consequent moeten worden bijgehouden. Er kan bovendien – terecht – worden opgemerkt dat het opnemen van materiële commitments (aan-

en

verkooporders)

in

de

database

voor

de

behandelde

onderzoeksvragen

boekhoudkundig geen nut heeft. Echter, in realiteit is het orderboek van een onderneming heel belangrijk. Op die manier kan de onderneming worden gewaardeerd: er kan worden ingeschat of de onderneming in de toekomst goed dan wel slecht zal boeren. Omwille van deze reden worden de twee Commitment tabellen toch geïncorporeerd, dit om het invoeren van aankoop-


14

en verkooporders mogelijk te maken. Dit zal de onderneming in staat stellen een blik op de toekomst te werpen.

2.4

Elementen REA database

De tabellen met bijhorende relaties weerspiegelen – zij het met de nodige toevoegingen en abstracties – de objectmodellen uit het referentieinformatiemodel van Laurier & Poels (2009). Elke „Resource‟ wordt gedefinieerd op basis van zowel een rekeningnummer (op basis van het alom gekende Minimum Algemeen Rekeningenstelsel, M.A.R.) als een objectnummer. De rekeningnummers die in deze database werden gebruikt, zijn opgenomen in een tabel „/ Rekeningnummers‟ (zie bijlage 1, p. I). Logischerwijs worden traditionele resources sowieso aanzien als resources: vaste activa (2rekeningen), voorraden (3-rekeningen), geldbeleggingen en liquide middelen (5-rekeningen). De vraag rijst uiteraard of alles als resources mag worden aanzien. Borch en Stefansen (2004) brachten een gebrek van de REA ontologie aan het licht: indien bepaalde zaken worden betaald (zoals belastingen en giften), is het duality axioma niet meer van kracht. Immers: indien belastingen worden betaald (de rekening 550000 wordt aangewend), stelt zich de vraag wat de onderneming hiervoor in ruil krijgt (welke resource?). Voor deze masterproef wordt er echter van uit gegaan dat deze zaken eveneens als resources mogen worden beschouwd: -

alle kostenrekeningen (leveringen van allerlei diensten en diverse goederen) die verband houden met waardevolle, fysische zaken: klein materiaal, EGW (elektriciteit, gas, water), bureelbenodigdheden, relatiegeschenken…

-

alle kostenrekeningen die daarbuiten vallen: belastingen, giften…8

-

kapitaal en allerhande leningen die de onderneming aangaan (1-rekeningen of 4rekeningen),

aangezien

het

financieringsproces

wordt

beschouwd

als

een

verkoopproces (infra p. 15) en een inbreng aan cash tot gevolg heeft Qua „Events„ zijn er meerdere mogelijkheden: het kan een goederentransfer, dan wel een geldtransfer, dan wel een conversie betreffen. Dit wordt geregistreerd in het attribuut „Type‟. Events worden aldus opgesplitst op basis van het type van de participerende agents: 8

Resources kunnen worden opgedeeld in subcategorieën. (ISO,2006) Een van die subtypes is „rechten‟. Het betalen van

belastingen bijvoorbeeld moet worden gezien als een aankoop. De onderneming koopt als het ware het recht aan om bepaalde zaken te eisen van de „leverancier‟, bijvoorbeeld de verwerving van het recht om handel te drijven. In die zin kunnen „belastingen‟ als waardevolle resources worden aanzien. Het schenken van giften gaat gepaard met het aankopen van een zeker aanzien en sociale status (goede doelen worden gesteund), evenals het aankopen van het recht op een mogelijks fiscaal voordeel.

HOOFDSTUK 2 – ONTWIKKELING REA DATABASE -

„Exchanges‟

(aankopen/verkopen/bankboekingen):

15 Deze

events

(goederen-

en

geldtransfers) worden uitgevoerd door bedienden. Er wordt in deze database echter abstractie gemaakt van de waarde die bedienden qua arbeid bijdragen via hun participatie. Aan bedienden wordt immers een vast maandloon uitbetaald, onafhankelijk van de prestaties. -

„Conversions‟: Arbeiders (die participeren in conversies) worden wel opgenomen.

Events worden, naast het eventtype, tevens gekarakteriseerd door een datum. Deze datum geeft weer wanneer het event exact werd uitgevoerd, en hoeft dus niet per se dezelfde te zijn als bijvoorbeeld de factuurdatum (opgenomen in de Increment of Decrement tabel). In de tabel „Agent‟ worden alle bedienden en arbeiders geregistreerd. De arbeiders zullen deelnemen aan conversie events.

Indien op de een of de andere manier een toename van de waarde van een of meer resources wordt geobserveerd, spreekt men over een Increment event. Het betreft onder andere aankopen, inkomende goederenstromen… Logischerwijs impliceren Decrement events aldus een afname van de waarde van een of meer resources. Via de „Duality‟ tabel wordt duidelijk gemaakt dat uiteindelijk elk increment event gepaard gaat met een decrement event (elke aankoopfactuur moet bijvoorbeeld worden vereffend door de betaling aan de desbetreffende leverancier uit te voeren). Het is evenwel mogelijk dat tijdelijke onevenwichten ontstaan.

2.5

Modellering bedrijfsprocessen

Het doel van de creatie van een REA database bestaat er uiteraard in de verschillende bedrijfsprocessen te modelleren op basis van die database. In 1985 kwam Porter op de proppen met zijn „value chain‟ (zie figuur 7). Deze waardeketen schept een inzicht in de opbouw van een organisatie, in het proces van waardetoevoeging in de organisatie en in de manier waarop waarde wordt toegevoegd tussen organisaties. (Verra, 1998) De bedrijfsprocessen, die uiteindelijk moeten worden geïntegreerd, dienen ruim te worden opgevat: het betreft alles op het gebied van human resources, financiën, productie, logistiek, verkoop en marketing. (Shanks, Seddon, & Willcocks, 2003)


16

Figuur 7: De waardeketen, overgenomen uit Verra (1998)

Dunn, Cherrington, en Hollander (Dunn et al., 2005) zien het allemaal iets kleiner en beknopter en onderscheiden vijf bedrijfsprocessen: het aankoop- en betalingsproces, het conversieproces, het verkoop- en inningsproces, het financieringsproces en het human resource bedrijfsproces. In wat volgt wordt het financieringsproces gezien als een verkoopproces. Een illustratie: indien nieuwe aandeelhouders worden aangetrokken (via het uitgeven van nieuw kapitaal, i.e. aandelen), dient dit te worden gecatalogeerd onder „verkopen‟. De aandeelhouders ontvangen immers, in ruil voor een kapitaalinbreng (increment event), aandelen (decrement event). Dezelfde redenering kan worden gemaakt voor leningen: een deel van de onderneming wordt verkocht aan de crediteur en de onderneming heeft een plicht (tot terugbetaling) aan de crediteur. Kapitaal en leningen worden bijgevolg eveneens gezien als resources. Het human resource bedrijfsproces op zijn beurt kan worden gezien als een onderdeel van het aankoop- en betalingsproces, aangezien arbeid wordt „aangekocht‟. Door deze twee bedrijfsprocessen te hercatalogeren, blijven er nog drie „kernprocessen‟ over. Hierna wordt de situatie geschetst van onderneming M (waarbij de M staat voor „moeder‟) en onderneming D (waarbij de D staat voor „dochter‟).

2.5.1 Schets onderneming M Hierna volgt een schets van de situatie van onderneming M, een van de ondernemingen die doorheen deze masterproef als illustratie werd gebruikt.

Onderneming M werd opgericht op 1 januari 2009; het boekjaar loopt van 1 januari tot 31 december.

Aangezien

de

onderneming

een

productieonderneming

is,

handelsgoederen niet aangekocht, maar zelf gefabriceerd door middel van conversies.

worden


17

Onderneming M is een Besloten Vennootschap met Beperkte Aansprakelijkheid (BVBA). Voor BVBA‟s gelden evenwel bepaalde verplichtingen die moeten worden in acht genomen: -

De minimale kapitaalinbreng bedraagt € 18.550 (in cash en/of natura). Onderneming M zal een kapitaalinbreng in cash van € 20.000 ontvangen. Er dient bijgevolg geen bedrijfsrevisor te worden ingehuurd om de waarde van een eventuele inbreng in natura te schatten.

-

Bij de oprichting van de BVBA wordt beroep gedaan op een notaris teneinde de statuten vast te leggen in een oprichtingsakte. De notaris wordt aangesteld om de authentieke akte op te stellen (± € 1.000).

-

Een inschrijving in zowel het Belgisch Staatsblad (€ 225) als in de Kruispuntbank voor Ondernemingen (€ 70) dient te gebeuren.

-

Bovendien moeten registratierechten worden betaald ten belope van 0,5% van de kapitaalinbreng (i.e. € 92,75).

Oprichtingskosten worden gedefinieerd als kosten die een vennootschap maakt bij de oprichting, uitbreiding (kapitaalverhoging of uitgifte van leningen) of herstructurering (De Lembre, 2004c). De totale oprichtingskosten voor deze BVBA bedragen bijgevolg € 1.387,75.

De onderneming moet uiteraard, om haar activiteiten te kunnen financieren, beschikken over bepaalde vermogensbronnen. De eigenaar van de onderneming zal vanuit zijn privépatrimonium contanten ter beschikking stellen van de onderneming. Bovendien zal de onderneming een investeringslening aangaan van € 10.000 op meer dan één jaar (vreemd vermogen). Deze lening zal worden verstrekt door een kredietinstelling. Er werd geopteerd voor vaste maandelijkse aflossingen. De overeengekomen jaarlijkse interestvoet bedraagt 8%, wat overeenkomt met een maandelijkse interestvoet van 0,67%. De duurtijd van de lening is 5 jaar, i.e. 60 maandelijkse aflossingen. Kredietinstellingen rekenen voor het verlenen van investeringleningen realiter een dossierkost aan. In dit geval bedraagt deze € 200 (excl. 21% BTW). Volledigheidshalve wordt eveneens de toepasselijke aflossingstabel meegegeven (zie bijlage 2, p. III).

2.5.2 Schets onderneming D Niettegenstaande het feit dat onderneming D veel gelijkenissen vertoont met onderneming M, betreft het hier een handelsonderneming.

2.6

Nut REA accounting informatiesysteem

Alle informatiesystemen, zowel traditionele systemen als toekomstige systemen gebaseerd op nieuwe ontologieën zoals de REA ontologie, moeten aan een aantal kenmerken voldoen. Een goede definitie van een informatiesysteem wordt aangereikt door Laudon, Laudon, van


18

Grembergen en Thiadens (2006, p. 16): “een informatiesysteem kan technisch worden gedefinieerd als een set aan elkaar gerelateerde componenten die informatie verzamelen, verwerken, opslaan en verspreiden ter ondersteuning van besluitvorming, coördinatie en controle binnen een organisatie”. Een accounting informatiesysteem is aldus een verzameling van gegevens en verwerkingsprocedures, die tot de benodigde informatie voor zijn gebruikers leidt. (Bagranoff, Simkin, & Norman, 2005) In overeenstemming met de zo-even genoemde definitie, is het doel van een accounting informatiesysteem drieledig: het beschikbaar stellen van informatie voor alle belanghebbenden, de juiste voorwaarden bepalen voor een goede besluitvorming en het verzekeren van het feit dat er geen activa illegaal de onderneming kunnen verlaten. (Vaassen, 2002) De term „accounting‟ omhelst daarbij een aantal deelgebieden, met name financiële boekhouding, bestuursboekhouding, audit en taxatie (zie figuur 8). (Siegel & Shim, 2000) Accounting

Financial Accounting (principally provides information to external parties or users)

Managerial accounting (principally provides information to internal parties or users)

Cost Accounting

Budgeting

Auditing

Taxation

Systems Study

Figuur 8: Deelgebieden accounting, volgens Siegel & Shim (2000)

Het is duidelijk dat meerdere personen nood hebben aan zowel financiële als niet-financiële informatie. Een degelijk informatiesysteem zou accurate informatie moeten kunnen verschaffen aan alle stakeholders. De geconstrueerde REA database biedt bijgevolg het grote voordeel, in vergelijking

met

traditionele

boekhoudsystemen,

dat

alle

belanghebbenden

worden

opgenomen. Daarnaast worden ook telkens onbewerkte economische gegevens opgeslagen, wat resulteert in een grotere accuraatheid van de op basis daarvan opgestelde rapporten.

Bovendien wordt vandaag de dag de nood aan het integreren van gegevens in grote databases alom erkend als een middel voor managers, accountants en mogelijke externe partijen om de benodigde informatie te verkrijgen voor het opstellen van strategische plannen, het nemen van dagdagelijkse beslissingen en het uitvoeren van controleoperaties. (Bagranoff et al., 2005) Dit illustreert uiteraard het belang van het ontwerpen van een goed onderbouwd accounting informatiesysteem dat gebruik maakt van een centrale database – wat in deze masterproef wordt betracht. De overstap van meerdere systemen naar één databasesysteem zou tevens bijdragen tot efficiëntere processen, een hogere rapporteringskwaliteit en vereenvoudigde communicatie. (Vaassen, 2002)

HOOFDSTUK 3 – GENERATIE JAARREKENING

19

HOOFDSTUK 3 DE INDIVIDUELE JAARREKENING 3.1

Concept

Dit hoofdstuk spitst zich toe op de uitwerking van de eerste onderzoeksvraag. Deze eerste onderzoeksvraag kan als volgt worden geëxpliciteerd: “Hoe kan een jaarrekening worden gegenereerd op basis van zowel het exchange als het conversie patroon?”

In bijlage 3 (p. IV) kan een overzicht worden teruggevonden van alle transacties die zijn geregistreerd in de REA database. De navolgende uiteenzetting zou voldoende moeten toelichten hoe de boekingen exact zijn gebeurd.

Er kunnen verschillende secties worden onderscheiden in een jaarrekening. De Nationale Bank van België stelt dat de hierna volgende elementen worden opgenomen: -

de elementen die toelaten de onderneming te identificeren – met de volledige lijst van bestuurders, zaakvoerders en commissarissen

-

de externe accountants, bedrijfsrevisoren, erkende boekhouders of erkende boekhouders en fiscalisten die een opdracht hebben uitgevoerd met betrekking tot de jaarrekening van de onderneming

-

de balans: via een balans wordt duidelijk wat de bezittingen van de onderneming zijn enerzijds en de financieringsbronnen anderzijds

-

de resultatenrekening: de resultatenrekening voorziet in een overzicht van de inkomsten en uitgaven gedurende een boekjaar

-

de tabel met de resultaatverwerking

-

de toelichting: voor een cijfermatig gedetailleerde en grondige analyse van de verscheidene rubrieken dient de toelichting te worden geraadpleegd

-

de sociale balans: in de sociale balans staat specifieke informatie over het personeelsbestand – hierin staat alles weergegeven omtrent het aantal tewerkgestelden, het personeelsverloop, de opleidingsniveaus en dergelijke


Deze

masterproef

concentreert

zich

op

20

het

genereren

van

de

balans-

en

resultatenrekeningposten met behulp van queries. Er wordt verondersteld dat de overige elementen die worden opgenomen in de jaarrekening (zoals de sociale balans), eenvoudig uit de database kunnen worden geabstraheerd en bijgevolg geen onderwerp dienen uit te maken van nadere studie.

Om een zo volledig mogelijke uitwerking van de eerste onderzoeksvraag aan te reiken, werden twee situaties bestudeerd. In eerste instantie werden alle transacties van een onderneming M gemodelleerd. Onderneming M, die geregistreerd is als Economic Unit 1 in de REA database, is een productieonderneming (supra p. 16). Daarnaast werd tevens een jaarrekening gegenereerd voor onderneming D (Economic Unit 2), een handelsonderneming. Tenzij uitdrukkelijk anders vermeld, wordt in wat volgt de jaarrekening van onderneming M besproken.

Voor het resultaat van de eerste onderzoeksvraag (zijnde de individuele jaarrekeningen van zowel onderneming D als onderneming M) kan worden verwezen naar bijlage 4 (p. VI).

3.2

Courante exploitatiecyclus

Aan de hand van de verschillende bedrijfsprocessen, zoals deze worden aangebracht door Dunn, Cherrington en Hollander (2005), wordt infra een analyse gemaakt van de wijze waarop een jaarrekening kan worden opgesteld. Nagenoeg alle voor deze masterproef geschreven queries zijn toevoegqueries (het resultaat wordt toegevoegd aan een tabel). De reden hiervoor is vrij logisch: door de resultaten van de queries toe te voegen aan tabellen, kan op basis van de verkregen tabel een rapport worden gemaakt. Op die manier wordt een overzichtelijke, begrijpbare output verkregen. Voor de eerste onderzoeksvraag kunnen de individuele jaarrekeningen in een duidelijk rapport worden gegoten, voor de tweede onderzoeksvraag geldt hetzelfde voor de geconsolideerde jaarrekening. Uiteraard was het vaak noodzakelijk om eerst selectiequeries te schrijven; deze waren echter hulp-selectiequeries en moesten bepaalde tussenstappen uitvoeren op basis waarvan daarna een toevoegquery kon worden geschreven.


21

3.2.1 Aankopen

3.2.1.1

Registratie in de REA database

Aankopen worden door bedienden van onderneming M en D ingevoerd in de database op de volgende manier: -

Stap 1: Controle wat betreft de Economic Unit (Is de leverancier met andere woorden reeds opgenomen in de database?)

-

Stap 2: Input van het transfer event (Input van de datum en het type event, i.e. „Good transfer‟, in de tabel Event)

-

Stap 3: Input van de factuur via de tabel Increment (Wie is de aankoper? Wat is de factuurdatum? Wat is het totaalbedrag (incl. BTW) van de factuur?)

-

Stap 4: Registratie van de aangekochte goederen (in de tabel Resource wordt opgeslagen welke, hoeveel en aan welke prijs (excl. BTW) goederen werden aangekocht; in de tabel Resource – Increment wordt de link gelegd tussen de aankoopfactuur en de aangekochte goederen)

Ter illustratie wordt weergegeven hoe de derde aankoopfactuur van onderneming M werd ingeboekt: -

Stap 1: Onderneming M (Economic Unit 1) koopt goederen (kosten verbonden met het aangaan van een lening) aan bij BANK Y (Economic Unit 19). Beide Economic Units werden geregistreerd:

-

Stap 2: De goederenoverdracht vond plaats op 6 januari 2009. Dit werd geregistreerd via Event_ID 11:

HOOFDSTUK 3 – GENERATIE JAARREKENING -

22

Stap 3: Via de Increment tabel vindt de feitelijke registratie van de aankoopfactuur plaats. Het totaalbedrag van de factuur (incl. BTW) bedraagt € 242. Economic_Unit_ID 1 verwijst naar de aankopende onderneming, onderneming M (uit stap 1) en Event_ID 11 verwijst naar het Event_ID uit stap 2 (conform de relaties in de REA database). De aankoopfactuur wordt ingevoerd onder Increment_ID 6:

Nota bene: Voor BANK Y diende de verkoop te worden geregistreerd in de Decrement tabel. De werkwijze wordt toegelicht in 3.2.5.1 Registratie in de REA database (infra p. 30). -

Stap 4: In een laatste stap moet worden geregistreerd welke goederen (aantal en eenheidsprijs) werden aangekocht. Dit geschiedde via de tabel Resource. Het aangekochte goed (bankkosten) krijgt het objectnummer 13 mee.

Een noodzakelijke link tussen Resource tabel en de Increment tabel diende te worden gemaakt via de tabel Resource – Increment:

3.2.1.2

Het genereren van de relevante jaarrekeningposten

Boekhoudkundig worden inkomende facturen op de volgende manier verwerkt (De Lembre, 2004c):


23 9

2-rekening, 4-rekening, 5-rekening of 6-rekening

€x

Terug te vorderen BTW

411 000

€x

@ Handelsschulden

440 000

€x

Activa- of kostenrekening

Er vindt, via de Increment tabel, een vermeerdering plaats van de in de onderneming aanwezige resources. De situatie zal uiteraard moeten uitwijzen welk rekeningnummer (uit het M.A.R.) wanneer moet worden gehanteerd.  Activa / Kosten Een opdeling die zich opdringt betreft de aard van de aangekochte goederen. Er is een verschil indien de gegevens activa dan wel kosten betreffen. Voor kosten geldt immers dat de boekingsdatum (de factuurdatum in de Increment tabel) tot het boekjaar moet behoren. Activa daarentegen

moeten

worden

opgenomen

zolang

de

boekingsdatum

valt

voor

de

afsluitingsdatum van het boekjaar.

Aangezien alle balansposten (exclusief de posten kredietinstellingen, handelsschulden en handelsvorderingen) en alle posten van de resultatenrekening exclusief BTW worden opgenomen in een jaarrekening, mag uiteraard geen rekening worden gehouden met het attribuut „Waarde‟ (incl. BTW) in de Increment tabel. Er moet rekening worden gehouden met het aantal aangekochte goederen en hun eenheidsprijs (excl. BTW), gegevens die terug te vinden zijn in de tabel Resource.

De correcte toevoegqueries luiden als volgt: 1. Een

eerste

query

selecteert,

gebaseerd

op

de

Rekeningnummer_ID‟s

(de

rekeningnummers moeten kleiner zijn dan 600000 en verschillend van 550000, kredietinstellingen) in de Resource tabel, alle aankopen van activa die ooit zijn gebeurd: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, Sum([Eenheidsprijs]*[Aantal]) AS Debet, 0 AS Credit FROM ([/ Rekeningnummers] INNER JOIN Resource ON [/ Rekeningnummers].ID = Resource.Rekeningnummer_ID) INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)<600000 And ([Resource – Increment].Rekeningnummer_ID)<>550000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")) GROUP BY [/ Rekeningnummers].Omschrijving, 0, [/ Rekeningnummers].ID; 9

Zoals reeds werd verondersteld (supra p. 14), wordt het aanwenden van bepaalde 4-rekeningen (zoals het inschrijven op

obligatieleningen) en alle 5-rekeningen (zoals het aankopen van aandelen van een andere onderneming) eveneens gezien als aankopen.


24

De output van deze query wordt weggeschreven naar de tabel // JAARREKENING M 31/12/2009 // (hier wordt de jaarrekening van onderneming M opgeslagen): Omschrijving

Debet

Credit

200 000 - Kosten van oprichting en kapitaalverhoging

1.387,75 €

0

231 000 - Machines

1.470,00 €

0

12.000,00 €

0

280 000 - Financiële vaste activa

2. Een tweede query selecteert, analoog aan de eerste query, alle aankopen van grondstoffen,

hulpstoffen,

handelsgoederen,

diensten

en

diverse

goederen

(rekeningnummers groter of gelijk aan 600000) die dat boekjaar zijn gebeurd: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, Sum([Eenheidsprijs]*[Aantal]) AS Debet, 0 AS Credit FROM ([/ Rekeningnummers] INNER JOIN Resource ON [/ Rekeningnummers].ID = Resource.Rekeningnummer_ID) INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000) AND ((Event.Type)="Good transfer") AND ((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1)) GROUP BY [/ Rekeningnummers].Omschrijving, 0, [/ Rekeningnummers].ID;

De output van deze query wordt weggeschreven naar de tabel // JAARREKENING M 31/12/2009 //: Omschrijving

Debet

Credit

600 001 - Aankopen van grondstof 1

3.500,00 €

0


500,00 €

0


500,00 €

0

601 001 - Aankopen van hulpstof 1

900,00 €

0

650 000 - Rente, commissies en kosten verbonden aan schulden

200,00 €

0

 Terug te vorderen BTW Het totaal terug te vorderen BTW-bedrag (rekening 411000) kan worden becijferd op basis van het verschil tussen het totaalbedrag van de factuur (incl. BTW) en de totaalwaarde van de aankopen (aantal x eenheidsprijs) (excl. BTW). Dit verschil moet dus worden gehaald uit de database door gebruik te maken van de tabellen Increment, Resource – Increment en Resource


25

(de rekeningnummers mogen alle rekeningen10 betreffen) en wordt berekend met behulp van een hulp-selectiequery: SELECT Sum([Waarde]/[Aant]-[Aantal]*[Eenheidsprijs]) AS [Terug te vorderen BTW] FROM Resource INNER JOIN ((Event INNER JOIN (Increment INNER JOIN [/Aantal objectID per incrementID] ON Increment.Increment_ID = [/Aantal objectID per incrementID].Increment_ID) ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE (((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer"));

Het resultaat luidt als volgt: Terug te vorderen BTW 1.776,13 €

 Handelsschulden Indien goederen worden aangekocht en aankoopfacturen worden ontvangen, heeft de onderneming een schuld aan de leverancier. Op het einde van het boekjaar zal de onderneming waarschijnlijk tot de conclusie komen dat er een openstaand saldo is aan handelsschulden. Dit wordt als volgt berekend: Eindsaldo handelsschulden = beginsaldo handelsschulden + aankopen – creditnota‟s op aankopen – betalingen aan leveranciers + ontvangsten betalingen creditnota‟s op aankopen In bijlage 5 (p. VIII) wordt weergegeven hoe het saldo van deze balanspost wordt becijferd aan de hand van de toepasselijke hulp-selectiequeries.

3.2.2 Betalingen aan leveranciers

3.2.2.1


De ondernemingen houden er een „no cash-beleid‟ op na. Dit impliceert dat er geen kasgelden aanwezig zijn: de ondernemingen betalen niets cash. Indien een betaling aan een leverancier plaats vindt, moet dit tevens geregistreerd worden in de REA database. Hierboven (supra p. 21) werd geïllustreerd hoe een aankoopfactuur (Increment_ID 6) werd geregistreerd. De boeking van de betaling hiervan wordt nu geïllustreerd. 10

Er wordt verwacht dat enkel de increment events met betrekking tot activa en kosten mogen worden in aanmerking genomen.

Echter, indien een creditnota op een verkoop wordt geregistreerd, gebeurt dit tevens via de Increment tabel en wordt er eveneens gebruik gemaakt van de rekening 411000: 7-rek

€x

Terug te vorderen BTW

411 000

€x

@ Handelsvorderingen

400 000

€x

Verkopen en dienstprestaties


26

Stap 1: Input van het transfer event (Input van datum en het type event, i.e. „Money transfer‟, in de tabel Event). De aankoopfactuur werd betaald op 7 januari 2009, via Event_ID 12:

-

Stap 2: Input van de betaling via de tabel Decrement (Wat is de betalingsdatum? Wat is het totaalbedrag van de betaling?). Het wordt duidelijk dat onderneming M op 7 januari 2009 € 242 aan resources verloor:

-

Stap 3: De voorlaatste stap bestaat erin weer te geven welke resources werden verminderd via het decrement event. Aangezien het een geldtransfer betreft, wordt sowieso de bankrekening aangewend. In de tabel Resource wordt opgeslagen dat de rekening 550000 (kredietinstellingen) wordt aangewend. Het objectnummer 14 wordt hieraan toegekend:

Ook hier moet de link worden gelegd tussen de tabellen Resource en Decrement via de tabel Resource – Decrement:


-

27

Stap 4: Verduidelijking via de Duality tabel welke betaling het betreft. De betaling betreft een aankoopfactuur met Increment_ID 6. De verbinding van Increment_ID 6 en Decrement_ID 6 geschiedt via de Duality tabel:

Er dient te worden opgemerkt dat bij het invoeren van een betaling noch de hoeveelheid, noch de eenheidsprijs per resource (in dit geval de bankrekening 550000) wordt opgeslagen, dit omwille van het feit dat er hier niet kan worden gesproken over eenheden.

3.2.2.2


Alle money transfers gebeuren via de rekening 550000. Telkens de rekening 550000 (in de Resource tabel) wordt aangewend, wordt noch een aantal noch een eenheidsprijs ingegeven. Voor deze post diende aldus een query te worden geschreven, die rekening hield met het attribuut „Waarde‟ in de Decrement tabel. Uitgaande geldstromen worden logischerwijs geboekt via de Decrement tabel. Een hulpselectiequery moet duidelijk maken hoeveel geld er ooit wegvloeide uit de onderneming: SELECT Sum(Decrement.Waarde) AS [Kredietinstellingen -] FROM Decrement INNER JOIN [Resource – Decrement] ON Decrement.Decrement_ID = [Resource – Decrement].Decrement_ID WHERE ((([Resource – Decrement].Rekeningnummer_ID)=550000) AND ((Decrement.Economic_Unit_ID)=1));

Het resultaat: Kredietinstellingen 19.366,18 €

3.2.3 Creditnota’s op aankopen Het invoeren van creditnota‟s op aankopen gebeurt op een analoge manier als het invoeren van verkopen (infra p. 30).


28

3.2.4 Conversies

3.2.4.1


Voor onderneming M moeten conversies in rekening worden gebracht. Voorlopig produceert de onderneming slechts twee verkoopbare handelsgoederen (HA1 en HA2) op basis van drie grondstoffen (G1, G2 en G3) en een hulpstof (H1). Een „Bill Of Materials‟ (zie figuur 9) is een sleutelcomponent van het productieplanningsysteem van een onderneming. (Burton & Bragg, 2000) Het omvat een lijst met de componentonderdelen die worden gebruikt om een product te fabriceren. HA2 HA1 6 x G2 1 x G1 6 x G3 1 x G2 6 x H1 H1

Figuur 9: Bills Of Materials onderneming M

Op 2 januari 2009 assembleerde Lieve Boels (een arbeider van onderneming M) 6 eenheden van handelsgoed 1. Hierbij werden, de bill of materials in acht nemende, 6 eenheden van zowel grondstof 1 als grondstof 2 verbruikt. De registratie in de database gebeurde als volgt: -

Stap 1: Controle wat betreft de agent (Is de arbeider met andere woorden reeds opgenomen in de database?), via de tabel Agent:

-

Stap 2: Input van het conversion event (Input van de datum en het type event, i.e. „Conversion‟, in de tabel Event)


29

Stap 3: Input van het verbruik van resources via de tabel Decrement (Wat is de datum waarop de conversie plaats vindt? Wat is de totale kostprijs (excl. BTW) van de verbruikte goederen?)

-

Stap 4: Registratie van de verbruikte goederen. In de tabel Resource wordt opgeslagen welke, hoeveel en aan welke prijs (excl. BTW) goederen werden verbruikt.

In de tabel Resource – Decrement werd de noodzakelijke link gelegd tussen de tabellen Decrement en Resource:

-

Stap 5: Input van de productie van resources via de tabel Increment (Wat is de datum waarop de conversie plaats vindt? Wat is de totale kostprijs (excl. BTW) van de geproduceerde goederen?)


-

30

Stap 6: Registratie van de geproduceerde goederen. In de tabel Resource wordt opgeslagen welke, hoeveel en aan welke prijs (excl. BTW) goederen werden gefabriceerd:

In de tabel Resource – Increment wordt de noodzakelijke link gelegd tussen de tabellen Increment en Resource:

-

Stap 7: In de Duality tabel wordt geregistreerd welk verbruik van goederen (Decrement_ID 8) heeft geleid tot de productie van goederen (Increment_ID 9):

3.2.5 Verkopen

3.2.5.1


Het registreren van verkoopfacturen verloopt analoog met het registreren van aankoopfacturen:


31

Stap 1: Controle van de Economic Unit (Is de klant met andere woorden reeds opgenomen in de database?)

-

Stap 2: Input van het transfer event (Input van de datum en het type event, i.e. „Good transfer‟, in de tabel Event)

-

Stap 3: Input van de factuur via de tabel Decrement (Wie is de aankoper? Wat is de factuurdatum? Wat is het totaalbedrag (incl. BTW) van de factuur?)

-

Stap 4: Registratie van de verkochte goederen (in de tabel Resource wordt opgeslagen welke, hoeveel en aan welke prijs (excl. BTW) goederen werden verkocht; in de tabel Resource – Decrement wordt de link gelegd tussen de verkoopfactuur en de verkochte goederen)

In lijn met de geïllustreerde aankoop van onderneming M bij BANK Y, wordt hier weergegeven hoe de verkoop van BANK Y aan onderneming M werd ingeboekt: -

Stap 1: Zowel onderneming M als BANK Y werden reeds met naam en toenaam opgenomen in de database; onderneming M kreeg het Economic_Unit_ID 1 mee en BANK Y kreeg het ID 19 mee.

-

Stap 2: De goederenoverdracht vond plaats op 6 januari 2009. Dit werd geregistreerd via Event_ID 11.

-

Stap 3: Via de Decrement tabel vindt de feitelijke registratie van de verkoopfactuur plaats. Het totaalbedrag van de factuur (incl. BTW) bedraagt € 242. De verkoopfactuur wordt ingevoerd onder Decrement_ID 21:

-

Stap 4: In een laatste stap moet worden geregistreerd welke goederen (aantal en eenheidsprijs) werden verkocht. Dit gebeurde via de tabel Resource. Het verkochte goed krijgt het objectnummer 51 mee.

Een noodzakelijke link tussen Resource tabel en de Decrement tabel diende te worden gemaakt via de tabel Resource – Decrement:

HOOFDSTUK 3 – GENERATIE JAARREKENING 3.2.5.2

32


Boekhoudkundig worden uitgaande facturen op de volgende manier verwerkt (De Lembre, 2004c): Handelsvorderingen

€x

400 000 11

@ Passiva - of opbrengstenrekening

1-rekening, 4-rekening

Te betalen BTW

of 7-rekening

€x €x

451 000

Er vindt, via de Decrement tabel, een vermindering plaats van de in de onderneming aanwezige resources. De situatie zal uiteraard moeten uitwijzen welk rekeningnummer (uit het M.A.R.) wanneer moet worden gehanteerd.  Handelsvorderingen Op het einde van het boekjaar zal de onderneming waarschijnlijk tot de conclusie komen dat er een openstaand saldo is aan handelsvorderingen. Dit wordt als volgt berekend: Eindsaldo handelsvorderingen = beginsaldo handelsvorderingen + verkopen - ontvangsten In bijlage 6 (p. XI) wordt weergegeven hoe het saldo van deze balanspost wordt becijferd aan de hand van de toepasselijke hulp-selectiequeries.  Passiva / Opbrengsten Een opdeling die zich opdringt betreft de aard van de verkochte goederen (bij verkopen). Er is een verschil indien de gegevens passiva dan wel opbrengsten betreffen. Voor opbrengsten geldt immers dat de boekingsdatum (de factuurdatum in de Decrement tabel) tot het boekjaar moet behoren. Passiva daarentegen moeten worden opgenomen zolang de boekingsdatum valt voor de afsluitingsdatum van het boekjaar.

De correcte toevoegqueries luiden als volgt: 1. Een

eerste

query

selecteert,

gebaseerd

op

de

Rekeningnummer_ID‟s

(de

rekeningnummers moeten kleiner zijn dan 600000 en verschillend van 550000, kredietinstellingen) in de Resource tabel, alle „verkopen‟ van passiva12 die ooit zijn gebeurd: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, 0 AS Debet, Sum([Eenheidsprijs]*[Aantal]) AS Credit

11

1-rekeningen en 4-rekeningen (passiva) moeten eveneens worden opgenomen bij de verkopen. De financieringscyclus (het

uitgeven van kapitaal, het aangaan van leningen…) is namelijk onderdeel van de verkoopscyclus. 12

De registratie van passiva dient ook te gebeuren via het registreren van verkopen. Indien bijvoorbeeld aandeelhouders worden

aangetrokken (via het uitgeven van aandelen), dient dit te worden gecatalogeerd onder „verkopen‟. De aandeelhouders ontvangen immers, in ruil voor een kapitaalinbreng, aandelen. De ondernemingen „verkopen‟ als het ware passiva.


33

FROM ([/ Rekeningnummers] INNER JOIN Resource ON [/ Rekeningnummers].ID = Resource.Rekeningnummer_ID) INNER JOIN (Event INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)<600000 And ([Resource Decrement].Rekeningnummer_ID)<>550000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY [/ Rekeningnummers].Omschrijving, 0, [/ Rekeningnummers].ID;

De output van deze query wordt weggeschreven naar de tabel // JAARREKENING M 31/12/2009 // (hier wordt de jaarrekening van M opgeslagen): Omschrijving

Debet

Credit

100 000 - Geplaatst kapitaal

0

20.000,00 €

173 000 - Schulden op > 1 jaar - kredietinstellingen

0

10.000,00 €

2. Een tweede query selecteert, analoog aan de eerste query, alle verkopen en dienstprestaties die dat boekjaar zijn gebeurd: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, 0 AS Debet, Sum([Eenheidsprijs]*[Aantal]) AS Credit FROM ([/ Rekeningnummers] INNER JOIN Resource ON [/ Rekeningnummers].ID = Resource.Rekeningnummer_ID) INNER JOIN (Event INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) AND (Resource.Object_ID = [Resource - Decrement].Object_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=600000) AND ((Event.Type)="Good transfer") AND ((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY [/ Rekeningnummers].Omschrijving, 0, [/ Rekeningnummers].ID;

De output van deze query wordt weggeschreven naar de tabel // JAARREKENING M 31/12/2009 //: Omschrijving

Debet

Credit


0

25,00 €

700 001 - Verkopen van handelsgoed 1

0

8.000,00 €

 Te betalen BTW Het totaal te betalen BTW-bedrag (rekening 451000) kan worden becijferd op een soortgelijke manier als het becijferen van het totaal terug te vorderen BTW-bedrag.


34

De nodige input wordt gehaald uit de tabellen Decrement, Resource – Decrement en Resource (de rekeningnummers mogen alle rekeningen13 betreffen) en wordt berekend met behulp van een hulp-selectiequery: SELECT Sum([Waarde]/[Aant]-[Aantal]*[Eenheidsprijs]) AS [Te betalen BTW] FROM Resource INNER JOIN (Event INNER JOIN ((Decrement INNER JOIN [/Aantal objectID per decrementID] ON Decrement.Decrement_ID = [/Aantal objectID per decrementID].Decrement_ID) INNER JOIN [Resource Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE (((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer"));

Het resultaat luidt als volgt: Te betalen BTW 1.685,25 €

3.2.6 Ontvangsten van klanten

3.2.6.1


De ondernemingen houden er een „no cash-beleid‟ op na. Klanten worden aldus verplicht via banccontact of overschrijving hun schulden te vereffenen. Analoog aan de boeking van betalingen aan leveranciers geschiedt de boeking van ontvangsten van klanten. Er wordt eveneens een illustratie gegeven aan de hand van de ontvangst van de betaling van onderneming M aan BANK Y. -

Stap 1: Input van het transfer event (Input van datum en het type event, i.e. „Money transfer‟, in de tabel Event). De betaling werd ontvangen op 7 januari 2009 (Event_ID 12).

-

Stap 2: Input van de betaling via de tabel Increment (Wat is de betalingsdatum? Wat is het totaalbedrag van de betaling?). BANK Y won op 7 januari 2009 € 242 aan resources:

13

Er wordt verwacht dat enkel de decrement events met betrekking tot passiva en opbrengsten worden in aanmerking genomen.

Echter, indien een creditnota op een aankoop wordt geregistreerd, gebeurt dit tevens via de Decrement tabel en wordt er eveneens gebruik gemaakt van de rekening 451000: Handelsschulden @ Activa- of kostenrekening Te betalen BTW

440 000

€x

2-rek of 6-rek

€x

451 000

€x


35

Stap 3: De voorlaatste stap bestaat erin weer te geven welke resources werden vermeerderd via het increment event. Aangezien het een geldtransfer betreft, wordt sowieso de bankrekening aangewend. In de tabel Resource wordt opgeslagen dat de rekening 550000, kredietinstellingen, wordt aangewend. Het objectnummer 14 wordt hieraan toegekend. Ook hier moet de link worden gelegd tussen de tabellen Resource en Increment via de tabel Resource – Increment:

-

Stap 4: Via de Duality tabel wordt duidelijk op welke inkomst (verkoop…) deze inkomende geldstroom betrekking heeft. De ontvangst (Increment_ID 22) moet op die manier worden gelinkt aan de verkoopfactuur (Decrement_ID 21):

3.2.6.2


Telkens een money transfer plaats vindt, wordt de rekening 550000 aangewend. Er wordt noch een aantal noch een eenheidsprijs ingegeven. Voor deze post moest aldus een query worden geschreven, die rekening hield met het attribuut „Waarde‟ in de Decrement tabel. Aangezien inkomende geldstromen worden geboekt via de Increment tabel, moet een hulpselectiequery duidelijk maken hoeveel geld er ooit werd ontvangen op de bankrekening: SELECT Sum(Increment.Waarde) AS [Kredietinstellingen +] FROM Increment INNER JOIN [Resource – Increment] ON Increment.Increment_ID = [Resource – Increment].Increment_ID WHERE ((([Resource – Increment].Rekeningnummer_ID)=550000) AND ((Increment.Economic_Unit_ID)=1));

Het resultaat: Kredietinstellingen + 39.680,00 €

Om in de jaarrekening de post kredietinstellingen te kunnen invoegen, moeten alle inkomende en alle uitgaande geldstromen op de bankrekening in rekening worden gebracht (op basis van de twee hulp-selectiequeries, supra p. 27 en p. 35). De finale toevoegquery ziet er uit als volgt:


36

INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "550 000 - Kredietinstellingen" AS Rekening, [Kredietinstellingen +]-[Kredietinstellingen -] AS Debet, 0 AS Credit FROM [/550 000: Kredietinstellingen -], [/550 000: Kredietinstellingen +];

En levert als resultaat: Rekening 550 000 - Kredietinstellingen

Debet 20.313,82 €

Credit 0

Het eindsaldo op de bankrekening bedraagt blijkbaar € 20.313,82; dit wordt eveneens toegevoegd aan de tabel // JAARREKENING M 31/12/2009 //.

3.2.7 Creditnota’s op verkopen Het invoeren van creditnota‟s op verkopen gebeurt op analoge wijze als het invoeren van aankopen.

3.3

Afsluitingsverrichtingen

Inventarisverrichtingen (De Lembre, 2004c) vinden jaarlijks plaats, i.e. bij het afsluiten van het boekjaar, en hebben betrekking op: -

Aankopen, verkopen en voorraad

-

Anticipatie- en uitstelposten met betrekking tot kosten en opbrengsten

-

Vaste activa

-

Controle op de waardering van vorderingen en schulden

Afsluitingsverrichtingen worden niet expliciet geregistreerd in de database; er worden hiervoor met andere woorden geen increment en decrement events toegevoegd. Dit is logisch, aangezien voor inventarisverrichtingen niet aan het duality axioma wordt voldaan. Bij afschrijvingen van vaste activa bijvoorbeeld vermindert de waarde van de activa wel, maar er staat geen decrement event tegenover. De afsluitingsverrichtingen worden bijgevolg becijferd aan de hand van hulp-selectiequeries en worden voor de volledigheid en juistheid toegevoegd aan de jaarrekening.

In bijlage 7 (p. XIV) kan een overzicht worden teruggevonden van alle queries betreffende de afsluitingsverrichtingen.


37

3.3.1 Aankopen, verkopen en voorraad Er kan zich op het einde van het jaar een situatie voordoen waarin de onderneming bepaalde goederen of diensten reeds heeft ontvangen/verkocht tijdens het boekjaar, terwijl er nog geen factuur/creditnota is opgesteld. Indien deze situatie zich voordoet, moet de onderneming een pro-formafactuur inboeken, teneinde ervoor te zorgen dat alle aan- en verkopen (en correcties erop) aan de juiste boekhoudperiode worden toegekend. Er kan worden gebruikt gemaakt van de rekeningen „444 000 – Te ontvangen facturen‟, „404 100 – Te ontvangen creditnota‟s‟, „404 000 – Te innen opbrengsten‟ en „444 100 – Op te maken creditnota‟s‟. Wat betreft ondernemingen M en D werden alle noodzakelijke boekhoudkundige stukken reeds ontvangen en opgemaakt in het boekjaar. Indien dit niet het geval zou zijn geweest, moesten pro forma facturen en/of creditnota‟s worden ingeboekt. Dit kan gebeuren via de tabellen Increment Commitment en Decrement Commitment. Om een onderscheid te kunnen maken tussen bestelformulieren/offertes (die normalerwijze via deze tabellen worden geregistreerd) en pro forma facturen kan in de Increment Commitment en Decrement Commitment tabel een attribuut „Pro forma?‟ worden toegevoegd. Bij het inboeken zal aldus kunnen worden meegegeven of het al dan niet een pro forma factuur/creditnota betreft. Bij de afsluiting van het boekjaar

kan

dan

ook

expliciet

worden

rekening

gehouden

met

deze

pro-

formafacturen/creditnota‟s.

Voorraden moeten volgens de Belgische wetgeving (De Lembre, 2004b) worden gewaardeerd tegen aanschaffingswaarde. De onderneming kiest ervoor om de grond- en hulpstoffen te waarderen aan een gewogen gemiddelde aankoopprijs. Afgewerkte producten worden gewaardeerd tegen marktwaarde. Niettegenstaande het feit dat onderneming M, als zijnde een productieonderneming, zelf instaat voor het produceren van afgewerkte producten, zal zij nooit geconfronteerd worden met voorraad goederen in bewerking. De reden hiervoor is dat een afgewerkt product op een dermate simpele wijze kan worden gefabriceerd dat de volledige productie van een product telkens zal kunnen worden afgerond binnen een tijdspanne van een uur. Arbeiders worden aldus aangespoord ervoor te zorgen dat op het einde van de werkdag geen halfafgewerkte producten blijven liggen tot de volgende werkdag (bijvoorbeeld stukloon in plaats van uurloon). De onderneming opteert bovendien voor een jaarlijkse inventaris14. Na de eindvoorraden te vergelijken met de beginvoorraden, moeten eventuele voorraadwijzigingen (zie bijlage 7, p. XIV) worden geboekt. Alles is hierbij gesteund op de volgende logische redenering:

14

Dit houdt in dat de voorraadrekeningen tijdens de boekhoudkundige periode niet worden aangepast aan de werkelijke aanwezige

voorraad.


38

Eindvoorraad = beginvoorraad + aankopen – verbruik (voor conversie en voor verkoop)

Er dient vermeld te worden dat onderneming D een handelsonderneming is. De meest gangbare manier om voorraden handelsgoederen te waarderen is een waardering tegen de aankoopprijs. (Siau & Mercken, 2005)

Bovendien stelde Georges Honoré in 2000: “De toeleveringen, de afgewerkte producten, de goederen (…) worden gewaardeerd tegen hun aanschaffingswaarde of tegen de marktwaarde op de datum van de afsluiting van het boekjaar, wanneer deze marktwaarde lager ligt dan de aanschaffingswaarde.” Een potentiële inventarisverrichting houdt bijgevolg in dat waardeverminderingen op voorraden kunnen worden geboekt. Op het einde van het boekjaar stelt onderneming D vast dat de realisatiewaarde van de aangekochte handelsgoederen enigszins is gezakt. Aangezien de onderneming een zo getrouw mogelijk beeld van haar bezittingen dient te verschaffen, dringt er zich een waardevermindering op. De werkwijze hiervoor kan eveneens worden teruggevonden in bijlage 7 (p. XIV).

3.3.2 Anticipatie- en uitstelposten met betrekking tot kosten en opbrengsten Anticipatie- en uitstelposten dienen ertoe bij te dragen dat alle kosten en de ermee overeenstemmende opbrengsten, en alle opbrengsten en de ermee overeenstemmende kosten juist (i.e. gedurende de correcte boekhoudperiode) geboekt zijn. Deze situatie kan zich bijvoorbeeld voordoen indien op 1 december huurgelden worden ontvangen voor 3 maanden (december – januari – februari) of indien een autoverzekering wordt afgesloten op 1 mei voor 12 maanden. Er dient gebruik te worden gemaakt van overlopende rekeningen. Voor zowel onderneming M als onderneming D zijn overlopende rekeningen (nog) niet van belang. Echter, het zou makkelijk kunnen worden in rekening gebracht via het schrijven van extra toevoegqueries, die gebaseerd zijn op een controle van de event datum. De event datum geeft namelijk weer wanneer bepaalde aan- of verkopen zijn ontvangen/verzonden. Indien bijvoorbeeld een autoverzekering voor een jaar wordt afgesloten op 1 mei, zal de datum in de event tabel 30 april zijn voor het daaropvolgende boekjaar. Op die dag zal immers de aankoop „volledig‟ zijn ontvangen. Op basis daarvan kan een vergelijking worden gemaakt met de increment datum (de factuurdatum) en kunnen de nodige correcties worden aangebracht. Een alternatieve manier om dit euvel op te vangen is de volgende: de „jaarlijkse‟ autoverzekering zou via een conversie event kunnen worden geconverteerd naar een


39

„maandelijkse‟ autoverzekering. Alzo zouden twaalf verzekeringen voor een maand worden gekomen, die dan maandelijks worden verbruikt.

3.3.3 Vaste activa Er wordt uitgegaan van een lineair afschrijvingsregime. Dit impliceert dat een actief elk jaar met eenzelfde bedrag in waarde vermindert. Het Belgisch boekhoudrecht stelt dat voor de berekening van de boekhoudkundige afschrijvingen steeds de aanschaffingswaarde (i.e. de historische

aankoopprijs

plus

bijkomende

kosten,

of

de

vervaardigingsprijs,

of

de

inbrengwaarde) als afschrijvingsbasis moet worden genomen. (Bruggeman & Everaert, 2006) Indien wordt geïnvesteerd in de aankoop van een actief, moet telkens een levensduur worden gedefinieerd. De standaard levensduur van investeringen bedraagt 10 jaar. Er zijn echter een aantal uitzonderingen, waarbij een versnelde afschrijving (Cerfontaine, Boute, & Laforce, 2005) kan plaats vinden: -

Oprichtingskosten: 5 jaar Materiële vaste activa

-

Informatica-apparatuur o

Hardware: 3 jaar; hardware wordt gecatalogeerd onder de noemer „machines‟

o

Software: 5 jaar; software wordt gecatalogeerd onder de noemer „uitrusting‟

-

Klein materieel: 3 jaar

-

Rollend materieel (personenwagen…): 5 jaar Immateriële vaste activa (maximum 5 jaar)

-

Kosten van onderzoek: 5 jaar

Voor de becijfering van de jaarlijkse afschrijvingen wordt eveneens gerefereerd aan bijlage 7 (p. XIV).

Tot slot dient ook vermeld te worden dat aan gebouwen een levensduur van 40 jaar wordt toegekend. Terreinen daarentegen hebben een onbeperkte levensduur. Het is evenwel mogelijk om, indien terreinen een depreciatie ondergaan, een waardevermindering te boeken. Dit wordt hier echter buiten beschouwing gelaten, aangezien de registratie van een waardevermindering op vaste activa in het verlengde ligt van een registratie van een waardevermindering op voorraden.


40

3.3.4 Controle op de waardering van vorderingen en schulden Deze inventarisverrichtingen dringen zich op indien waarderingen in vreemde valuta van belang zijn. Negatieve of positieve koersevoluties moeten immers in rekening worden gebracht. Deze elementen zouden op eenzelfde omslachtige wijze moeten worden in rekening gebracht als herwaarderingen. Dergelijke boekingen moeten nagenoeg handmatig worden ingegeven. Voor een negatieve koersevolutie15 moeten de rekeningen 400000 (handelsdebiteuren) en 655000 (resultaten uit de omrekening van vreemde valuta) worden gecorrigeerd, voor een positieve evolutie16 de rekeningen 400000 (handelsdebiteuren) en 497000 (positieve omrekeningsverschillen). Ondernemingen M en D worden hier niet mee geconfronteerd, er is bijgevolg geen nood om deze boekingen in queries uit te werken.

De onderneming moet voldoen aan de BTW-wetgeving, met dien verstande dat BTW moet worden betaald op de verkopen, en moet worden teruggevorderd op de aankopen. Op het einde van het boekjaar moet vervolgens een afrekening (zie bijlage 7, p. XIV) worden gemaakt, afhankelijk van het feit of de onderneming nog BTW schuldig is, dan wel BTW te veel heeft betaald.

3.4

Resultaatbepaling en -verwerking

Op het einde van het boekjaar zal moeten worden vastgesteld of de onderneming winst heeft gerealiseerd dan wel verlies heeft geleden. Indien de onderneming een verlies dient te verwerken, moet dit worden overgedragen naar het volgende boekjaar op volgende manier: Overgedragen verlies (-)

141 000

€x

@ Over te dragen verlies

793 000

€x

In geval van winst, zijn er diverse bestemmingen mogelijk:

15

-

Uitkeren aan belanghebbenden (personeel, bestuurders, eigenaars)

-

Overdragen naar volgend jaar („reserveren‟)

In geval van een negatieve koersevolutie met betrekking tot een verkoop moet op het einde van het boekjaar worden geboekt:

Resultaten uit de omrekening van vreemde valuta

655 000

€x

@ Handelsdebiteuren

400 000

€x

Bij de heropening van het nieuwe boekjaar vindt de tegenboeking plaats. 16

In geval van een positieve koersevolutie met betrekking tot een verkoop moet op het einde van het boekjaar worden geboekt:

Handelsdebiteuren

400 000

€x

@ Positieve omrekeningsverschillen

497 000

€x

Bij de heropening van het nieuwe boekjaar vindt de tegenboeking plaats.


41

Aangezien onderneming M zich nog maar in de start-up fase bevindt, wordt ervoor gekozen de winst over te dragen: Over te dragen winst

693 000

€x

@ Overgedragen winst

140 000

€x

Op die manier wordt er in feite aan „zelffinanciering‟ gedaan.

In bijlage 8 (p. XXVII) worden deze twee mogelijkheden geïllustreerd aan de hand van de geschreven queries voor de REA database.

3.5

Creatie grootboek

Volgens De Lembre (2004c) wordt het grootboek gevormd door het geheel van alle rekeningen die in een onderneming worden gebruikt. In een grootboek wordt van elke grootboekrekening als het ware een overzicht bijgehouden van de wijzigingen die zich gedurende een bepaalde periode voordeden. In deze masterproef werd, met behulp van hulp-selectiequeries en toevoegqueries analoog aan de hierboven besproken queries, een grootboek (zie bijlage 9, p. XXIX) ontworpen voor onderneming M waarin alle verrichtingen (exclusief de inventarisverrichtingen) werden opgenomen.

Per

grootboekrekening

werden

de

boekingen

uiteraard

chronologisch

weergegeven. Het voorzien van de mogelijkheid om een grootboekoverzicht te kunnen opvragen, kadert binnen de idee dat computersystemen verscheidene rapporten zouden moeten kunnen genereren teneinde gedetailleerde informatie voor besluitvormingsprocessen aan te reiken. (Rosli, Ahmi, & Mohamad, 2009)

3.6

Persoonlijke bevindingen

Er dient voor ogen te worden gehouden dat in het Belgisch boekhoudrecht meerdere basisbeginselen wettelijk zijn bepaald. Uiteraard dient een nieuw accounting informatiesysteem te garanderen hieraan te voldoen. Er bestaan verscheidene „generally accepted accounting principles‟ (GAAP) (Ots, 2004): -

Het toerekeningsbeginsel, ook wel aangroeiingsbeginsel genoemd, komt erop neer dat ondernemingen hun kosten en opbrengsten moeten toerekenen aan de boekhoudjaren waarop ze betrekking hebben. Er zijn overlopende rekeningen in het leven geroepen om te kunnen voldoen aan dit principe.


42

Het matching-beginsel is een verdere uitwerking van het toerekeningsbeginsel wat betreft de kosten: een onderneming mag uitgaven niet als kosten beschouwen indien de opbrengsten uit hoofde van die uitgaven nog niet zijn gerealiseerd. Deze uitgaven moet de onderneming activeren op de balans.

-

Een niet te versmaden principe is het voorzichtigheidsbeginsel. Dit principe stelt dat bij waarderingen de nodige voorzichtigheid in acht moet worden genomen: zowel te hoge als te lage waarderingen van activa en passiva moeten worden vermeden. Winsten mogen aldus slechts worden ingeschreven als het voldoende zeker is dat ze behaald zijn. Analoog moet een onderneming verwachte verliezen direct als gerealiseerd beschouwen.

-

Het realisatiebeginsel heeft betrekking op de toerekening van opbrengsten aan perioden. Een onderneming moet een opbrengst verantwoorden in die periode waarin de prestatie is geleverd en als ze de opbrengst met voldoende zekerheid kan vaststellen.

-

Het continuïteitsbeginsel of going-concernbeginsel impliceert dat wordt verondersteld dat een onderneming het geheel van haar activiteiten zal kunnen voortzetten. Indien immers door omstandigheden het liquidatiestandpunt zou moeten worden ingenomen, zou een veel lagere waardering worden verkregen.

De onderneming moet bijgevolg een getrouw beeld schetsen van zowel haar vermogen (door een correcte toepassing van het voorzichtigheidsbeginsel) als haar resultaat (door een correcte toepassing van het matching-beginsel). Door een toepassing van de REA database, wordt aan bovenstaande principes voldaan, immers: -

De REA database kan rekening houden met overlopende rekeningen. Bijgevolg kunnen kosten en opbrengsten altijd aan de juiste periode worden toegerekend.

-

Het

matching-principe

wordt

correct

nageleefd,

vermits

investeringen

werden

geactiveerd en afgeschreven. -

Aangezien

een

waardevermindering

van

de

voorraad

handelsgoederen

werd

vastgesteld bij onderneming D, moest dit ook worden verwerkt in de jaarrekening (conform het voorzichtigheidsbeginsel). Dit bleek geen probleem te zijn. -

Er wordt verondersteld dat het continuïteitsbeginsel geen problemen stelt, noch voor onderneming M noch voor onderneming D.

De Lembre (2004a) definieert bovendien ook enkele principes in verband met rapportering (principe van de periodiciteit, principe van de vergelijkbaarheid en het principe van het getrouw beeld). Deze zijn vergelijkbaar met het bestendigheidsbeginsel. (Ots, 2004) Dit beginsel komt erop neer dat, eenmaal er gekozen is voor bepaalde grondslagen van waardering,


43

winstbepaling en presentatie, men deze grondslagen moet handhaven in de toekomst. Het REA accounting informatiesysteem past deze principes correct toe. Mijn – uiteraard vrij beperkte – ervaring met boekhoudsystemen (Vero, Jurisoft en Ciel) heeft mij geleerd dat er, op het vlak van het invoeren en bijhouden van transacties en het genereren van jaarrekeningen, veel verbeteringen mogelijk zijn aan bestaande boekhoudsystemen.

Vooreerst stellen bovengenoemde systemen de gebruiker niet in staat om via het boekhoudpakket de voorraden op te volgen. Een REA accounting informatiesysteem biedt in se dus het voordeel dat veel meer wordt gefocust op het concept resource: bij aan- en verkopen wordt overzichtelijk bijgehouden welke resources worden aangekocht en verkocht. Additioneel wordt, naast de factuurdatum, telkens ook de datum van ontvangst en verzending geregistreerd (het is immers niet de factuurdatum die belangrijk is bij het bepalen van de finale voorraad). Bovendien wordt het verbruik en de productie van resources eveneens opgeslagen via de conversie events. Dit draagt bij tot een heel accuraat en waarheidsgetrouw voorraadsysteem via hetwelk voorraadwijzigingen automatisch kunnen worden becijferd. Daarnaast is het mogelijk, dankzij de focus op het concept van resources, om aan elk goed een objectnummer toe te kennen. Dit zal het mogelijk maken een fysieke lokalisatie van de goederen te realiseren. Een REA accounting informatiesysteem kan bijgevolg onontbeerlijke input leveren voor een voorraadbeheersysteem of logistiek planningssysteem. Met behulp van de REA database is het mogelijk afschrijvingen automatisch te becijferen op basis van standaard lineaire afschrijvingstermijnen per activaklasse. Dit is iets dat bij traditionele accounting informatiesystemen handmatig moet worden uitgerekend. Via een dergelijke automatische becijfering van de afschrijvingen zal een meer waarheidsgetrouw systeem kunnen worden bekomen (fraude is immers uitgesloten).

Niet alleen voorraadwijzigingen en afschrijvingen kunnen automatisch worden uitgerekend, maar ook de winst of het verlies van het boekjaar kan op een vrij eenvoudige wijze worden becijferd. In principe biedt een balans een momentopname van de financiële positie van een onderneming op een specifiek ogenblik, i.e. het einde van het boekjaar. (Smart & Megginson, 2008) Op basis van de REA database kunnen inventarisverrichtingen (afschrijvingen, becijfering voorraadwijzigingen…) echter op gelijk welk ogenblik worden opgevraagd. Het is bijgevolg mogelijk de balans steeds up-to-date te houden en te allen tijde een pro-formabalans op te vragen.


44

Huidige boekhoudsystemen beschouwen enkel het uitwisselingspatroon. Ze houden immers enkel bij wat de onderneming verkrijgt en verlaat. Een REA accounting informatiesysteem houdt ook rekening met interne conversies.

Het gebruik van een REA accounting informatiesysteem gaat tevens gepaard met een aantal nadelen.

Er kan terecht de bedenking worden gemaakt dat deze REA structuur ervoor zal zorgen dat de nummering van bijvoorbeeld aankoopfacturen niet volledig zal zijn. Aan elke registratie in de Increment tabel wordt immers een nummer toegekend: zowel aankoopfacturen, inkomende geldstromen… worden geregistreerd als increment events. Dit wordt hier geïllustreerd:

Via Increment_ID‟s 1 en 2 worden aankoopfacturen ingeboekt. Increment_ID‟s 3, 4 en 5 weerspiegelen echter geldontvangsten (rekening 550 000 wordt aangewend). Vandaar krijgt de volgende aankoopfactuur Increment_ID 6 mee. Hieruit blijkt dat de volgnummers die worden toegekend aan aankoopfacturen elkaar niet opvolgen. De lijn kan tevens worden doorgetrokken naar alle te registreren transacties (verkoopfacturen, bankrekeninguittreksels…): ook hier zullen de toegekende nummers elkaar niet opvolgen. Uiteraard zal de nummering wel een chronologische volgorde respecteren, zodat de ernst van dit nadeel kan worden geminimaliseerd. In de toekomst zal dit gebrek bovendien kunnen worden opgevangen door, bij het ontwikkelen van een boekhoudprogramma, een dubbele primaire sleutel toe te kennen aan de verschillende elementen in de Increment en Decrement tabellen. Alle aankoop-, verkoopfacturen en bankrekeninguittreksels zouden bijvoorbeeld standaard respectievelijk het voorvoegsel “AF”, “VF” en “B” kunnen meekrijgen.


Een

tweede

niet

onbelangrijk

nadeel

houdt

45

in

dat

het

uitvoeren

van

sommige

inventarisverrichtingen nog steeds niet automatisch kan verlopen. Zo is bijvoorbeeld de manier voor het invoeren van herwaarderingen vrij omslachtig. Dit argument kan worden weerlegd: het is uiteraard niet mogelijk om herwaarderingen automatisch te laten verlopen, aangezien niet automatisch en evenmin op voorhand kan geweten zijn wat de nieuwe waarde van voorraden/vaste activa zal zijn.

Het wordt al snel duidelijk dat de voordelen die een REA accounting informatiesysteem aanreikt, de nadelen ver overstijgen.

HOOFDSTUK 4 - CONSOLIDATIE

46

HOOFDSTUK 4 CONSOLIDATIE 4.1

Concept

Via de eerste onderzoeksvraag werd aangetoond dat op een eenvoudige manier een standaard jaarrekening kan worden opgesteld. Inventarisverrichtingen kunnen bovendien ook makkelijk worden geïntegreerd, zodat een volwaardige jaarrekening wordt gekomen. Naast het genereren van een traditionele jaarrekening verdient het tevens aandacht om te kijken naar de manier waarop een consolidatie zou kunnen worden uitgevoerd met behulp van de REA database. Ondernemingen kiezen er vandaag de dag vaak bewust voor andere – vaak kleinere – ondernemingen te verwerven. Geconsolideerde financiële rapporten geven de financiële positie en resultaten van een groep bedrijven weer alsof de groep een enkele entiteit was. Een groep bestaat uit een moederbedrijf en haar dochterondernemingen. (Pierce & Brennan, 2003) Geconsolideerde financiële rapportering heeft een dubbel doel. (Plateau & Van Herck, 1996) Vanuit een juridisch oogpunt wordt het doel van de consolidatie toegelicht als “het voorleggen van een jaarrekening waarbij een geheel van ondernemingen waartussen een affiliatieverband bestaat, voorgesteld wordt alsof het om één enkele onderneming gaat, en waarbij de afzonderlijke rechtspersoonlijkheid van zowel de consoliderende onderneming als van de dochterondernemingen terzijde wordt gelaten”. Anderzijds wordt tevens een kwaliteitsverhoging van informatie nagestreefd: het doel van de geconsolideerde rekeningen is om de financiële positie en resultaten van een groep gecontroleerd door een moederonderneming te rapporteren aan haar aandeelhouders en aan derden. In het kader van deze consolidatieproblematiek werden er „International Accounting Standards‟ gedefinieerd.


47

De International Accounting Standards Board (IASB), gevestigd te Londen, heeft tot doel het ontwikkelen van standaarden voor financiële verslaggeving van hoge kwaliteit die leiden tot transparante en vergelijkbare informatie in de jaarrekening. (Blomme, Carlier, & Weets, 2008) De laatste decennia is aldus voor de IASB – ten gevolge van de toenemende internationalisatie – de nood aan internationale regels steeds duidelijker geworden. Via internationale bepalingen zou moeten worden gestreefd naar wereldwijde vergelijkbaarheid en consistentie. De International Reporting Standards (IFRS) normen, ook wel International Accounting Standards (IAS) normen genoemd, zijn de boekhoudnormen uitgevaardigd door de IASB. (Siau & Mercken, 2005)

In juli 2002 kwam een IAS-verordening tot stand. Deze impliceert dat Europese beursgenoteerde ondernemingen of ondernemingen die een beursnotering voorbereiden, vanaf 2005 hun geconsolideerde jaarrekening moeten opstellen overeenkomstig de IAS normen. (Siau & Mercken, 2005) De Europese Jaarrekeningrichtlijnen (met betrekking tot de waarderingsregels voor de jaarrekening en de geconsolideerde jaarrekening) worden tevens continu aangepast, en dit met het oog op het streven van de Europese Commissie naar toepassing van de IAS normen. Deze verandering belangt niet alleen beursgenoteerde ondernemingen aan, maar raakt alle Europese ondernemingen. (Aerts, 2002) Dit brengt met zich mee dat het zeer interessant is om ook de consolidatieproblematiek in deze masterproef te verwerken. Voor deze onderzoeksvraag wordt ervan uitgegaan dat op 01/01/2009 onderneming M de controle verwerft over 60% van onderneming D. Onderneming M legt hiervoor € 12.000 op tafel. In de database worden tevens alle boekingen van onderneming D opgenomen vanaf 01/01/2009. Er is sprake van een „integrale consolidatie‟: alle actief- en passiefbestanddelen evenals alle kosten en opbrengsten van de consoliderende onderneming en de dochtervennootschappen worden integraal opgenomen in de geconsolideerde jaarrekening. (Plateau & Van Herck, 1996) De werkwijze die wordt gehanteerd is conform de door Carl Rombaut (2004) gedefinieerde methode.

Zowel onderneming M als onderneming D hanteren geen historisch kostprijsmodel (na de opname van een materieel vast actief wordt het geboekt tegen zijn kostprijs, verminderd met eventuele geaccumuleerde afschrijvingen en bijzondere waardeverminderingen), zoals dit


48

traditioneel het geval was. Er is echter geopteerd voor een herwaarderingsmodel (IAS 1617): een investering zal in den beginne worden opgenomen tegen kostprijs. Na de opname van het materieel vast actief zal het actief worden geboekt tegen zijn „fair value‟, i.e. de reële waarde op het moment van de herwaardering, verminderd met eventuele latere geaccumuleerde afschrijvingen en bijzonder waardeverminderingen. Deze fair value is met andere woorden de marktconforme waarde van het actief, i.e. de waarde in het economisch verkeer. (Siau & Mercken, 2005) Het feit dat balanselementen zullen worden opgenomen op basis van hun fair value impliceert uiteraard dat resultaatgerichte boekhoudbeginselen (zoals het realisatie- en voorzichtigheidsbeginsel) naar de achtergrond verschuiven en aan belang zullen moeten inboeten. (Aerts, 2002) Beide ondernemingen kiezen bewust voor een toepassing van het herwaarderingsmodel, aangezien anders het risico bestaat tot creatie van een hybride waarderingsmodel. (Aerts, 2002) Immers, volgens IAS 39 moeten financiële activa hoofdzakelijk worden geboekt tegen hun „fair value‟. Indien andere balanselementen zouden worden geboekt volgens de historische kostprijs, ontstaat uiteraard een hybride model.

4.2

Uitwerking

4.2.1 FASE 1: Samenvoeging individuele jaarrekeningen IAS 27 moet worden toegepast bij de opstelling en presentatie van de geconsolideerde jaarrekening van een groep entiteiten waarover de moedermaatschappij zeggenschap heeft. “Zeggenschap wordt verondersteld te bestaan indien de moedermaatschappij direct of indirect via dochterondernemingen meer dan de helft van de stemrechten van een entiteit bezit, tenzij duidelijk kan worden aangetoond dat het bezit van die stemrechten geen zeggenschap inhoudt.” Aangezien onderneming M 60% van de aandelen van onderneming D bezit, heeft onderneming M zeggenschap over onderneming D. IAS 27 stelt vast dat de consolidatieprocedure in eerste instantie neerkomt op het combineren van de financiële staten van de moeder- en de dochteronderneming. In de praktijk gaat dit in zijn werk door het lijn voor lijn optellen van zowel de balansposten als de posten van de resultatenrekening. Hierbij dienen er echter een aantal eliminaties (infra p. 51) in rekening te worden gebracht.

17

IAS 16 stelt elke entiteit voor de keuze om ofwel het kostprijsmodel ofwel het herwaarderingsmodel als grondslag te gebruiken

voor haar financiële verslaggeving.


49

In eerste instantie was het voor de tweede onderzoeksvraag dus een kwestie van het post per post optellen van de saldo‟s van de twee individuele jaarrekeningen. Teneinde het geheel in een correcte output (een rapport) te kunnen gieten, moesten een aantal stappen worden doorlopen: -

Stap 1: Een toevoegquery zorgt ervoor dat alle jaarrekeningposten van de moederonderneming M (alle rijen uit de tabel // JAARREKENING M 31/12/2009 //) worden toegevoegd aan de geconsolideerde jaarrekening (tabel // JAARREKENING CONSOLIDATIE 31/12/2009 //). Zowel de balansposten als de posten van de kosten- en opbrengstenrekening worden op die manier toegevoegd. Er zijn een aantal posten van de jaarrekening van onderneming M die echter niet worden toegevoegd aan de geconsolideerde jaarrekening. Het betreft de posten 280 000, 693 000, 793 000, 440 000 en 400 000. De reden hiervoor wordt uit de doeken gedaan in bijlage 10 (p. XXXI). INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [// JAARREKENING M 31/12/2009 //].Rekening, [// JAARREKENING M 31/12/2009 //].Debet, [// JAARREKENING M 31/12/2009 //].Credit FROM [// JAARREKENING M 31/12/2009 //] WHERE ((([// JAARREKENING M 31/12/2009 //].Rekening)<>"280 000 - Financiële vaste activa" And ([// JAARREKENING M 31/12/2009 //].Rekening)<>"693 000 - Winst van het boekjaar" And ([// JAARREKENING M 31/12/2009 //].Rekening)<>"793 000 - Verlies van het boekjaar" And ([// JAARREKENING M 31/12/2009 //].Rekening)<>"440 000 - Handelsschulden" And ([// JAARREKENING M 31/12/2009 //].Rekening)<>"400 000 - Handelsvorderingen")) ORDER BY [// JAARREKENING M 31/12/2009 //].Rekening, [// JAARREKENING M 31/12/2009 //].Debet, [// JAARREKENING M 31/12/2009 //].Credit;

De rijen die worden toegevoegd aan de tabel voor de geconsolideerde jaarrekening zijn de volgende: Rekening

Debet

Credit


0,00 €

20.000,00 €

140 000 - Winst van het huidige boekjaar

0,00 €

6.807,45 €


0,00 €

10.000,00 €

1.387,75 €

0,00 €

0,00 €

277,55 €

1.470,00 €

0,00 €

0,00 €

490,00 €

2.250,00 €

0,00 €

900,00 €

0,00 €

2.000,00 €

0,00 €

90,88 €

0,00 €

20.313,82 €

0,00 €


3.500,00 €

0,00 €


500,00 €

0,00 €

200 000 - Kosten van oprichting en kapitaalverhoging 200 009 - Geboekte afschrijvingen op oprichtingskosten (-) 231 000 - Machines 231 009 - Geboekte afschrijvingen op machines (-) 300 000 - Grondstoffen 310 000 - Hulpstoffen 330 000 - Gereed product 411 000 - Terug te vorderen BTW 550 000 - Kredietinstellingen


50


500,00 €

0,00 €


875,00 €

0,00 €

609 000 - Voorraadwijziging grondstoffen

0,00 €

2.250,00 €

609 100 - Voorraadwijziging hulpstoffen

0,00 €

900,00 €

630 000 - Afschrijvingen op oprichtingskosten

277,55 €

0,00 €

630 230 - Afschrijvingen op installaties, machines en uitrusting

490,00 €

0,00 €


200,00 €

0,00 €


0,00 €

8.000,00 €

713 000 - Voorraadwijziging gereed product

0,00 €

2.000,00 €

-

Stap 2: Analoog aan de eerste stap, zorgt een toevoegquery ervoor dat alle jaarrekeningposten van de dochteronderneming D worden toegevoegd aan de geconsolideerde jaarrekening. Zowel de balansposten als de posten van de kosten- en opbrengstenrekening worden op die manier toegevoegd. Ook hier worden enkele posten (100 000, 693 000, 793 000, 440 000 en 400 000) buiten beschouwing gelaten. INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [// JAARREKENING D 31/12/2009 //].Rekening, [// JAARREKENING D 31/12/2009 //].Debet, [// JAARREKENING D 31/12/2009 //].Credit FROM [// JAARREKENING D 31/12/2009 //] WHERE ((([// JAARREKENING D 31/12/2009 //].Rekening)<>"100 000 - Geplaatst kapitaal" And ([// JAARREKENING D 31/12/2009 //].Rekening)<>"693 000 - Winst van het boekjaar" And ([// JAARREKENING D 31/12/2009 //].Rekening)<>"793 000 - Verlies van het boekjaar" And ([// JAARREKENING D 31/12/2009 //].Rekening)<>"440 000 - Handelsschulden" And ([// JAARREKENING D 31/12/2009 //].Rekening)<>"400 000 - Handelsvorderingen")) ORDER BY [// JAARREKENING D 31/12/2009 //].Rekening, [// JAARREKENING D 31/12/2009 //].Debet, [// JAARREKENING D 31/12/2009 //].Credit;

De rijen die worden toegevoegd aan de tabel voor de geconsolideerde jaarrekening zijn de volgende: Rekening 140 000 - Winst van het huidige boekjaar

Debet

Credit

0,00 €

3.462,50 €

7.500,00 €

0,00 €

0,00 €

187,50 €

2.650,00 €

0,00 €

0,00 €

400,00 €

1.281,00 €

0,00 €

12.135,00 €

0,00 €

604 001 - Aankopen van handelsgoed 1

2.500,00 €

0,00 €


250,00 €

0,00 €


250,00 €

0,00 €


500,00 €

0,00 €

0,00 €

2.650,00 €

221 000 - Gebouwen 221 009 - Geboekte afschrijvingen op gebouwen (-) 340 000 - Handelsgoederen 349 000 - Handelsgoederen: geboekte waardeverminderingen (-) 411 000 - Terug te vorderen BTW 550 000 - Kredietinstellingen

609 400 - Voorraadwijziging handelsgoederen


51

630 210 - Afschrijvingen op gebouwen

187,50 €

0,00 €

631 000 - Waardeverminderingen op voorraden: toevoeging

400,00 €

0,00 €

704 001 - Verkopen van handelsgoed D1

0,00 €

3.500,00 €


0,00 €

500,00 €


0,00 €

500,00 €


0,00 €

400,00 €

Via deze twee stappen wordt eigenlijk reeds een gewone consolidatie uitgevoerd.

4.2.2 FASE 2: Verwerking correcties Het opstellen van een geconsolideerde jaarrekening houdt uiteraard meer in dan het simpelweg lijn per lijn optellen van alle posten van de jaarrekening. IAS 27 stelt dat een aantal eliminaties moeten worden doorgevoerd. Om het overzicht te behouden, wordt voor een opsomming van de verschillende queries met betrekking tot deze eliminaties (en een korte toelichting erbij) verwezen naar bijlage 10 (p. XXXI). Een eerste eliminatie die dient te gebeuren, betreft het eigen vermogen van de dochteronderneming (IAS 27, paragraaf 18 (a)): het aandeel van de moedermaatschappij in het eigen vermogen van de dochteronderneming moet worden geëlimineerd ten overstaan van de boekwaarde van de investering van de moederonderneming in de dochteronderneming. IFRS 3 bepaalt hoe de eventuele resterende goodwill moet worden verwerkt. Dit is hier echter niet van toepassing, aangezien 60% van het eigen vermogen van de dochteronderneming (60% van € 20.000) overeenkomt met de boekwaarde van de investering van de moederonderneming in de dochteronderneming (€ 12.000). Desalniettemin wordt de mogelijkheid tot het bekomen van een positieve goodwill (i.e. het verschil tussen het bedrag dat de moederonderneming heeft neergeteld voor de overname van 60% van de dochteronderneming en de waarde van het overgenomen deel van de dochteronderneming – 60% van het kapitaal van de dochteronderneming) opgenomen; deze komt dan terecht op de rekening 221 000 van de immateriële vaste activa. In de praktijk wordt logischerwijs vaak een situatie van positieve goodwill aangetroffen. Dit betekent immers dat de moederonderneming meer betaalt voor de dochteronderneming dan deze effectief waard is. De reden hiervoor is tweevoudig: enerzijds verwacht de moederonderneming synergieën in de toekomst en anderzijds vermoedt de moederonderneming dat de activa van de dochteronderneming ondergewaardeerd zijn. In paragraaf 4 van IAS 27 wordt het begrip „minderheidsbelang‟ gedefinieerd als zijnde “het eigen

vermogen

in een

dochteronderneming

dat

niet

direct

of

indirect

aan

een

moedermaatschappij kan worden toegerekend”. Dit minderheidsbelang, ook wel „aandeel van


52

derden‟ of „belang van derden‟ (Plateau & Van Herck, 2003) genoemd, wordt niet als eigen vermogen aangemerkt en bijgevolg geboekt op een rekening van het vreemd vermogen. (Vijn, 2003) Voor alle duidelijkheid wordt het nummer 180 000 toegekend aan deze rekening.

Aangezien onderneming M 60% van onderneming D heeft verworven, worden de twee bovenstaande eliminaties samen als volgt veruitwendigd:

Een tweede eliminatie die dient te gebeuren, houdt in dat ‘intragroup’ transacties18 moeten worden geëlimineerd. Ze moeten worden geëlimineerd omdat de groep geen vordering, schuld, kost of opbrengst tegenover zichzelf kan hebben. Het komt erop neer dat indien de moederonderneming

een

handelsschuld

heeft

aan

de

dochteronderneming

(en

de

dochteronderneming dus een handelsvordering op de moederonderneming), dit moet worden geëlimineerd. Ook de omgekeerde situatie moet worden geëlimineerd. Ook opbrengsten en kosten die voortvloeien uit transacties tussen beide ondernemingen moeten uiteraard worden geneutraliseerd. Paragraaf 18 van IAS 27 stelt dat “minderheidsbelangen in de winst of het verlies van geconsolideerde

dochterondernemingen

over

de

verslagperiode

moeten

worden

geïdentificeerd”. Er zal aldus een opsplitsing worden gemaakt tussen winst/verlies van de groep en van de minderheid (i.e. het deel van de dochteronderneming dat niet werd overgenomen door de moederonderneming). In deze illustratie komt het er bijgevolg op neer als volgt een onderscheid te maken (Plateau & Van Herck, 2003): -

de winst/het verlies van onderneming M vermeerderd met 60% van de winst/het verlies van onderneming D op de rekening “aandeel van de groep in het resultaat” (XVI).

-

40% van de winst/het verlies van onderneming D p de rekening “aandeel van derden in het resultaat” (XV).

Dit geschiedt in een derde en laatste correctie.

18

Intragroup transacties zijn verrichtingen tussen de groepsleden. (De Lembre & Podevijn, 2006)


53

4.2.3 FASE 3: Becijfering duplicaten geconsolideerde jaarrekening Er moet voor ogen worden gehouden dat elke jaarrekeningpost slechts één maal mag voorkomen in de finale geconsolideerde jaarrekening. Als gevolg van zowel fase 1 (onderneming M en onderneming D hadden beiden een saldo staan op de rekening 550 000, kredietinstellingen) als fase 2 (bepaalde posten, die reeds in de geconsolideerde jaarrekening voorkwamen, werden opnieuw toegevoegd) kwamen bepaalde jaarrekeningposten meermaals voor in de geconsolideerde jaarrekening. Voorlopig werd dus eigenlijk een geconsolideerde proefbalans bekomen. Via deze derde fase zal deze worden herleid tot een saldibalans: voor de posten die meermaals voorkomen, worden saldi berekend. Een vrij omslachtige, maar wel effectieve, manier om de geconsolideerde jaarrekening te corrigeren is via een 7-stappenmethode19. Deze methode wordt in het lang en breed toegelicht in bijlage 11 (p. XLI).

Voor de finale output van de tweede onderzoeksvraag wordt gerefereerd aan bijlage 12 (p. XLV).

4.3

Persoonlijke bevindingen

Dat een trend van toegenomen internationalisering van het bedrijfsleven wordt vastgesteld, kan niemand tegenspreken. De term internationalisering heeft betrekking op meerdere zaken: import, export, directe buitenlandse investeringen en internationale samenwerkingsverbanden. (Hessels & Stigter, 2004) Deze masterproef heeft voornamelijk oog voor het belang van de internationale samenwerkingsverbanden. Er wordt vastgesteld dat deze samenwerkingsvormen niet alleen betrekking hebben op grote multinationals, maar ook meer en meer op Kleine en Middelgrote Ondernemingen (KMO‟s). KMO‟s zien immers in toenemende mate het belang in van internationalisering, waarbij de toegang tot nieuwe en grotere markten (zowel wat betreft de grondstoffenmarkt, de arbeidsmarkt, de technologiemarkt… ) uiteraard een grote rol speelt.

Gezien deze trend van internationalisering zou het voor bedrijven een groot voordeel opleveren indien consolidaties automatisch kunnen worden uitgevoerd door een computerprogramma. Overwegende dat het gros van de huidige boekhoudsystemen dergelijke functionaliteit niet 19

Het is de opmerkzame lezer misschien opgevallen dat deze stappen ook voor de individuele jaarrekeningen moeten zijn

doorlopen. Onderneming M had immers aankoopfacturen voor hulpstoffen (ter waarde van € 900) evenals een creditnota op aankopen hulpstoffen (ter waarde van € 25) ingeboekt. In de jaarrekening resulteerde dit in de toevoeging van twee lijnen. Echter, in de finale individuele jaarrekening werden deze twee lijnen voor de post „601 001 - Aankopen van hulpstof 1‟ herleid tot één lijn met een debetbedrag van € 875. Dit was eveneens ten gevolge van een soortgelijke 7-stappenmethode.


54

aanbieden, kan dit voor de REA ontologie deuren openen. Indien met andere woorden bovenstaande methode, de basisconsolidatie en de verwerking van de correcties gevolgd door de 7-stappenmethode, wordt geïntegreerd in een boekhoudprogramma, kan een consolidatie automatisch gebeuren.

Er dient vermeld te worden dat in België verscheidene consultancy bedrijven zich bezighouden met het ontwikkelen van consolidatiepakketten. Deze pakketten zijn normalerwijs modulair (verschillende modules kunnen afzonderlijk worden aangeschaft) opgebouwd. (Rombaut, 2004) Bovendien wordt vaak consolidatiesoftware van Amerikaanse makelij aangekocht. Deze pakketten worden echter gekenmerkt door een aantal tekortkomingen, waarvan de belangrijkste is dat de Europese regelgeving niet voldoende wordt nageleefd en opgevolgd.

Het feit dat het referentieinformatiemodel (Laurier & Poels, 2009) het concept van economic units integreert, zorgt ervoor dat alle stakeholders worden opgenomen in het systeem. Dit draagt ertoe bij dat allerhande simulaties eveneens automatisch kunnen worden uitgevoerd. Indien meerdere ondernemingen hun transacties registreren volgens het hierboven uitgewerkte model, kan immers worden nagegaan wat het resultaat zou zijn van bijvoorbeeld een fusie tussen twee ondernemingen.

HOOFDSTUK 5 – HYPOTHESEN VOOR TOEKOMSTIG WERK

55

HOOFDSTUK 5 HYPOTHESEN VOOR TOEKOMSTIG WERK Een eerste element dat nog verder zou moeten worden uitgediept, maar dat beter wordt overgelaten aan een informaticus, bestaat uit het uitwerken van een boekhoudprogramma (inclusief de consolidatiefunctionaliteit) op basis van de aangereikte REA database en de queries. Deze nood past binnen de door Borch en Stefansen (2004) gedefinieerde methode om ontologieën te ontwikkelen en te evalueren: na het onderzoeken en testen van realistische scenario‟s (wat in deze masterproef werd betracht) moeten realistische applicaties worden geïmplementeerd.

Voor deze masterproef was het integreren van commitments niet van belang. In de toekomst zou het systeem echter kunnen worden uitgebreid door increment en decrement commitments op te nemen. Op die manier kan een geïntegreerd waarderingsmodel worden bekomen.

Het effect van het opnemen van de participatie van alle agents (i.e. zowel bedienden als arbeiders) zou nog moeten worden onderzocht. Op die manier zal de productiviteit van elke werknemer kunnen worden nagegaan, maatstaven zullen kunnen worden vooropgesteld… Dit kan nuttig blijken indien bepaalde werknemers bijvoorbeeld werkelijk ondermaats presteren of geen goede kwaliteit leveren. Momenteel is er ook geen beloningssysteem voor arbeiders uitgedokterd. Dat moet uiteraard wel mogelijk zijn. Arbeiders kunnen immers op eenvoudige wijze worden verloond op basis van het aantal geproduceerde units (dit kan uit de tabel Resource worden gehaald via increment conversie events). Uiteraard dringen kwaliteitssystemen zich in dit geval op: er moet nauwlettend in het oog worden gehouden dat arbeiders zich zowel concentreren op het nastreven van een maximaal kwaliteitsniveau als op het bereiken van een hoge productiviteit.

In hoofdstuk 3 van deze masterproef werden een aantal inventarisboekingen besproken. Er werd telkens een link gelegd met de REA database en een methode om deze elementen te

HOOFDSTUK 5 – HYPOTHESEN VOOR TOEKOMSTIG WERK

56

integreren in de jaarrekening werd aangereikt. Toch werden deze boekingen niet altijd in detail uitgewerkt, aangezien onderneming M en onderneming D niet geconfronteerd werden met deze zaken. Het betreft het inboeken en het in rekening brengen van pro-formafacturen en proformacreditnota‟s,

anticipatie-

en

uitstelposten

(overlopende

rekeningen),

waardeverminderingen op terreinen en negatieve/positieve koersevoluties. Deze elementen werden louter voor de volledigheid geïntegreerd in deze masterproef, maar een verdere uitwerking ervan via queries viel buiten de opdracht.

HOOFDSTUK 6 - CONCLUSIE

57

HOOFDSTUK 6 CONCLUSIE Zoals McCarthy in 1982 reeds opperde, zouden we onszelf moeten uitdagen tot het kritisch onder de loep nemen van de toekomst van het boekhouden. Overwegende dat er steeds meer technologieën voorhanden zijn (de wet van Moore stelt dat het aantal transistors op een computerchip elke twee jaar verdubbelt door de technologische vooruitgang), mogen we niet vasthouden aan verouderde ontologieën. Eerder dan te focussen op wat in financiële informatie moet aanwezig zijn, zou bijzondere aandacht moeten uitgaan naar het volledig doorgronden van de bedrijfsprocessen.

De REA ontologie verstrekt een uniek perspectief via het creatief modelleren van de essentiële aspecten van de economische realiteit. De focus ligt namelijk op de bedrijfsprocessen, met name op een identificatie van economische events, middelenstromen en agentparticipatie in events. Indien accounting informatiesystemen, gebaseerd op de REA ontologie, onderdeel zouden uitmaken van databasegerichte bedrijfssystemen, zou een geïntegreerd systeem worden bekomen. Het grootste voordeel komt er in se uiteraard op neer dat gegevens overheen de verschillende functionele domeinen (logistiek, accounting, marketing…) worden gedeeld. Een niet te versmaden voordeel van de REA ontologie is dat primaire bedrijfsgegevens constant worden opgeslagen, wat resulteert in meer relevante en accurate rapporten.

Op basis van een literatuurstudie en een proof of concept werden de mogelijkheden van de REA ontologie in de praktijk aan het licht gebracht. Het opstellen van individuele jaarrekeningen evenals de uitvoering van een automatische consolidatie werden bestudeerd en uitgewerkt.

Alle posten van de jaarrekening, die verband hielden met de courante exploitatiecyclus (aankopen, verkopen…), konden op een heel eenvoudige en korte wijze uit de database worden geëxtrapoleerd: aan de hand van een aantal – zo eenvoudig mogelijke – queries werden

alle

relevante

gegevens

geselecteerd.

Ook

het

toevoegen

van

de


58

inventarisverrichtingen bleek overigens niet onmogelijk. Niet alleen was het realiseerbaar om volledige, waarheidsgetrouwe en accurate jaarrekeningen op te stellen (conform de GAAP), het REA accounting informatiesysteem had meer voordelen in petto. Zo bracht de focus op het concept van resources meerdere voordelen aan het licht. Vooreerst is, via het toekennen van objectnummers aan resources, fysieke lokalisatie mogelijk. Bovendien wordt

een

accuraat

en

waarheidsgetrouw

voorraadsysteem

bekomen,

aangezien

voorraadwijzigingen (via verkopen en dergelijke) nauwkeurig kunnen worden bijgehouden. In tegenstelling tot traditionele boekhoudpakketten konden vele inventarisverrichtingen (voorraadwijzigingen, afschrijvingen en winst/verlies van het boekjaar) automatisch worden becijferd. Een toepassing van de REA ontologie op een accounting informatiesysteem zal ertoe bijdragen dat zowel financiële als niet-financiële informatie (zoals een sociale balans) te allen tijde zal kunnen worden gegenereerd, wat de transparantie ontegensprekelijk in de hand werkt.

Via het doorlopen van een aantal fasen konden de jaarrekeningen van twee ondernemingen worden geconsolideerd. De nodige correcties konden eveneens worden geïncorporeerd. De voornaamste conclusie met betrekking tot het consolidatieprobleem is dat consolidaties aan de hand van een aantal queries automatisch kunnen worden uitgevoerd. Daarnaast schuilt de kracht van het REA accountinginformatiesysteem in het feit dat alle stakeholders worden opgenomen in het systeem.

De kracht van het gegenereerde REA accounting informatiesysteem schuilt uiteraard ook in het feit dat niet alleen aan- en verkopen worden geregistreerd maar ook het verbruik en de productie van middelen via conversies.

Een element dat in deze masterproef niet expliciet aan bod komt, maar niet over het hoofd mag worden

gezien,

betreft

de

toekomst.

Via

het

gebruik

van

een

REA

accounting

informatiesysteem kunnen data met betrekking tot toekomstige events (aankoop- en verkooporders) eveneens worden in rekening gebracht. Traditionele boekhoudpakketten houden hier geen rekening mee. Dit zou echter bijdragen tot een meer allesomvattende en flexibele weergave van de realiteit.

Blijkbaar draagt de toepassing van REA bij tot het creëren van betrouwbare externe financiële rapporten, waarop besluitvormers hun analyses kunnen baseren. Dergelijke financiële informatie blijkt bovendien meer waarheidsgetrouw en transparant te zijn dan informatie verkregen via traditionele accounting informatiesystemen.


59

O‟Brien (2007, p. 13) verwoordde het als volgt: “We should employ our intellectual abilities, broaden our horizons and imaginations, and expand our concentration on financial reporting to include more discussion about what is essential to capture in models of business reality; the resources, events, and agents.”

Hopelijk heeft deze masterproef er aldus toe bijgedragen dat de opportuniteiten die de REA ontologie biedt aan het licht worden gebracht. Het vasthouden aan de basisbeginselen van het dubbel boekhouden louter en alleen omwille van het feit dat deze methodiek al lang worden gehanteerd, is af te keuren, en zou immers een situatie van „irrational escalating commitment‟20 creëren.

20

Mensen gaan irrationele beslissingen nemen gebaseerd op een rationele beslissing uit het verleden; ze hebben de neiging vast te

houden aan vroeger gekozen richtingen (ook al blijken die niet te werken). Mensen hebben het er aldus moeilijk mee om hun fouten toe te geven en een andere weg te bewandelen. (Street, Robertson, & Geiger, 2004)

I

Lijst van de geraadpleegde werken

Aerts, W. (2002). Fair value accounting: Perspectieven en toepassingsdomeinen. Antwerpen: Garant. Bagranoff, N.A., Simkin, M.G., & Norman, C.S. (2005). Core Concepts of Accounting Information Systems. New York: John Wiley & Sons, Inc. Blomme, W., Carlier, T., & Weets, V. (2008). IFRS op zak 2008: in overeenstemming met EU-vertaling. Mechelen: Kluwer – Deloitte. Borch, S.E., & Stefansen, C. (2004). Evaluating the REA Enterprise Ontology from an Operational Perspective. CAiSE Workshop. Bruggeman, W., & Everaert, P. (2006). Kostprijscalculatie en Management Accounting. Antwerpen/Apeldoorn: Garant. Burton, E.J., & Bragg, S.M. (2000). Sales and Operations for Your Small Business. New York: John Wiley & Sons, Inc. Cerfontaine, J., Boute, T., & Laforce, B. (2005). Vennootschapsrecht: Editie 2005. Brussel: Larcier. Chang, C.J., & Ingraham, L.R. (2007). Modeling and Designing Accounting Systems: Using Access to Build a Database. New York: John Wiley & Sons, Inc. Cooper, S. (2004). Corporate Social Performance: A Stakeholder Approach. Burlington: Ashgate. De Lembre, E. (2004a). Boek 1 – De algemeen aanvaarde boekhoudbeginselen en financiële rapporteringsstandaarden in België en internationaal. Mechelen: Wolters Plantyn. De Lembre, E. (2004b). Boek 4 – Grondige studie van de jaarrekening naar Belgisch recht. Mechelen: Wolters Plantyn. De Lembre, E. (2004c). Boek 3 –Basisbeginselen van de boekhoudtechniek. Mechelen: Wolters Plantyn.

LIJST VAN DE GERAADPLEEGDE WERKEN

II

De Lembre, E., & Podevijn, S. (2006). Grondige studie van de geconsolideerde jaarrekening naar Belgisch recht en naar IFRS. Deurne: Wolters Plantyn. Dunn, C.L., Cherrington, J.O., & Hollander, A.S. (2005). Enterprise information systems – a pattern-based approach. New York: The McGraw-Hill Companies, Inc. Dunn, C.L., Grabski, S.V. (2000). Perceived semantic expressiveness of accounting systems and task accuracy effects. International Journal of Accounting Information Systems, 1(2), 79-87. Gailly, F., & Poels, G. (2005). Development of a formal REA-ontology Representation. Proceedings EMOI Workshop (CAISE 2005), Porto, Portugal. Gailly, F., & Poels, G. (2007). Ontology-driven Business Modelling: Improving the Conceptual Representation of the REA Ontology. Working paper, Ghent University. Geerts, G.L., & McCarthy, W.E. (1997). Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates. Business Object Design and Implementation, Springer-Verlag, London, 94-113. Geerts, G.L., & McCarthy, W.E. (2000). The Ontological Foundation of REA Enterprise Information Systems. Working paper, Michigan State University. Geerts, G.L., & McCarthy, W.E. (2002). An Ontological Analysis of the Primitives of the Extended-REA Enterprise Information Architecture. The International Journal of Accounting Information Systems, 3, 1-16. Gómez-Pérez, A., & Rojas, M.D. (1999). Ontological Reengineering and Reuse. 11the European Workshop on Knowledge Acquisition, Modeling and Management (EKAW ’99), Springer-Verlag, Berlin, 139-156. Gruber, T.R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 199-220. Guarino, N. (1998). Formal Ontology and Information Systems. Proceedings of FOIS ‘98, Trento, Italy. Hessels, J., & Stigter, H. (2004). Internationalisering nu en in de toekomst. EIM, Zoetermeer.


III

Hill, C.W.L., & Jones, G.R. (1997). Strategic Management Theory: An Integrated Approach. New York: Houghton Mifflin. Honoré, G. (2000). Verminderingen op voorraden. Pacioli, 83. Verkregen op 25 juni, 2009, via http://www.ipcf.be/page.aspx?pageID=1429&language=NL Hruby, P. (2006). Model-Driven Design Using Business Patterns. Berlijn: Springer. ISO (2002). ISO/IEC 15944-4: 2002 Information technology – Business agreement semantic descriptive techniques – Part 1: Operational aspects of Open-edi for implementation ISO (2006). ISO/IEC 15944-4: 2006 Information technology – Business agreement semantic descriptive techniques – Part 4: Open-edi business transaction ontology. Jarrar, M. (2005). Towards Methodological Principles for Ontology Engineering. Vrije Universiteit Brussel (STARLab). Laudon, K.C., Laudon, J.P., van Grembergen, W., & Thiadens, T. (2006). Bedrijfsinformatiesystemen. Amsterdam: Pearson Education. Laurier, W., & Poels, G. (2009). The Resource-Event-Agent Reference Information Model for Intra- and Inter-Enterprise Value Chains. Working paper, Ghent University. Laurier, W., & Poels, G. Persoonlijke communicatie in verband met Ontology based business modeling: a conceptual analysis. Ghent University. McCarthy, W.E. (1979). An Entity-Relationship View of Accounting Models. The Accounting Review, 54(4), 667-686. McCarthy, W.E. (1982). The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review, 57(3), 554-578. Nah, F. (2002). Enterprise resource planning solutions and management. Hershey: IRM Press. O‟Brien, A. (2007) Simply Stated: REA and Useful Accounting Information from Ann O’Brien. University of Wisconsin, submission to REA 25: A Celebration of the REA Enterprise Model Ots, H.J. (2004). Externe financiële verslaggeving. Amsterdam: Pearson Education Benelux.


IV

Pierce, A., & Brennan, N. (2003). Principles and Practice of Group Accounts: A European Perspective. Londen: Thomson Learning. Plateau, S., & Van Herck, G. (1996). Handboek Consolidatie juridisch en boekhoudtechnisch. Leuven: Acco. Plateau, S., & Van Herck, G. (2003). Consolidatieboekhouden. Antwerpen/Apeldoorn: Garant. Poels, P., Maes, A., Gailly, F., & Paemeleire, R. (2004). Construction and Pre-Test of a Semantic Expressiveness Measure for Conceptual Models. Working Paper, Ghent University. Rombaut, C. (2004). Consolidatie. Antwerpen: De Boeck. Rosli, K., Ahmi, A., & Mohamad, L. (2009). Resource-Event-Agent (REA) Modelling in Revenue Information System (RiS) Development: Smart Application for DirectSelling Dealers and SMEs. Journal for the Advancement of Science & Arts, 1 (1). Shanks, G., Seddon, P.B., & Willcocks, L.P. (2003). Second-Wave Enterprise Resource Planning Systems: Implementing for Effectiveness. Cambridge: Cambridge University Press. Siau, C., & Mercken, R. (2005) Boekhouding en financiële rapportering – Boek 1. Met bespreking van de IAS/IFRS-normen. Antwerpen/Apeldoorn: Garant. Siau, C., & Mercken, R. (2005). Boekhouding en financiële rapportering - Boek 1. Met bespreking van de IAS/IFRS-normen. Leuven: Garant. Siegel, J.G., & Shim, J.K. (2000). Dictionary of Accounting Terms. Hauppage, New York: Barron‟s Educational Series Inc. Smart, S.B., Megginson, W.L. (2008). Corporate Finance. Londen: Cengage Learning EMEA. Somers, T., & Nelson, K. (2003). The impact of strategy and integration mechanisms on enterprise system value: Empirical evidence from manufacturing firms. European Journal of Operations Research, 146, 315-338. Street, M.D., Robertson, C., & Geiger, S.W. (2004). Ethical Decision Making: The Effects of Escalating Commitment. Journal of Business Ethics, 16(11), 1153-1161.


V

Svendsen, A. (1998). The Stakeholder Strategy. San Francisco: Berrett-Koehler Publishers. Vaassen, E. (2002). Accounting Information Systems: A Managerial Approach. New York: John Wiley & Sons, Inc. Verra, G.J. (1998). Account management in de praktijk. Deventer: Kluwer. Vijn, R.M. (2003). Kengetallen: een leidraad voor de beoordeling van gepubliceerde jaarrekeningen met behulp van kengetallen. Deventer: Kluwer.

I

Bijlagen Bijlage 1: Tabel ‘/ Rekeningnummers’ ID

/ Rekeningnummers Omschrijving

100000 100 000 - Geplaatst kapitaal 140000 140 000 - Winst van het huidige boekjaar 173000 173 000 - Schulden op > 1 jaar - kredietinstellingen 174000 174 000 - Schulden op > 1 jaar - overige leningen 200000 200 000 - Kosten van oprichting en kapitaalverhoging 200009 200 009 - Geboekte afschrijvingen op oprichtingskosten (-) 210000 210 000 - Immateriële vaste activa 220000 220 000 - Terreinen 221000 221 000 - Gebouwen 221009 221 009 - Geboekte afschrijvingen op gebouwen (-) 230000 230 000 - Installaties 231000 231 000 - Machines 231009 231 009 - Geboekte afschrijvingen op machines (-) 232000 232 000 - Uitrusting 240000 240 000 - Meubilair 241000 241 000 - Rollend materieel 280000 280 000 - Financiële vaste activa 300000 300 000 - Grondstoffen 310000 310 000 - Hulpstoffen 330000 330 000 - Gereed product 340000 340 000 - Handelsgoederen 400000 400 000 - Handelsvorderingen 411000 411 000 - Terug te vorderen BTW 416000 416 000 - Diverse vorderingen 420000 420 000 - Schulden op > 1 jaar die binnen het jaar vervallen 440000 440 000 - Handelsschulden 510000 510 000 - Aandelen 550000 550 000 - Kredietinstellingen 570000 570 000 - Kas 600000 600 000 - Aankopen 600001 600 001 - Aankopen van grondstof 1 600002 600 002 - Aankopen van grondstof 2 600003 600 003 - Aankopen van grondstof 3 601001 601 001 - Aankopen van hulpstof 1 602000 602 000 - Aankopen van diensten, werk en studies 603000 603 000 - Algemene onderaannemingen 604001 604 001 - Aankopen van handelsgoed 1 604002 604 002 - Aankopen van handelsgoed 2 604003 604 003 - Aankopen van handelsgoed 3 604004 604 004 - Aankopen van handelsgoed 4 605000 605 000 - Aankopen van onroerende goederen bestemd voor verkoop 608000 608 000 - Ontvangen kortingen, ristorno's en rabatten 609000 609 000 - Voorraadwijziging grondstoffen 609100 609 100 - Voorraadwijziging hulpstoffen

BIJLAGEN

II

ID

/ Rekeningnummers Omschrijving

609400 609 400 - Voorraadwijziging handelsgoederen 610000 610 000 - Huur terreinen en gebouwen 610010 610 010 - Huurlasten (verzekering, gemeenschappelijke kosten, enz) 611000 611 000 - Onderhoud en herstellingen terreinen en gebouwen 611100 611 100 - Onderhoud en herstellingen installaties, machines en uitrusting 630000 630 000 - Afschrijvingen op oprichtingskosten 630210 630 210 - Afschrijvingen op gebouwen 630230 630 230 - Afschrijvingen op installaties, machines en uitrusting 650000 650 000 - Rente, commissies en kosten verbonden aan schulden 693000 693 000 - Winst van het boekjaar 700000 700 000 - Verkopen 700001 700 001 - Verkopen van handelsgoed 1 700002 700 002 - Verkopen van handelsgoed 2 704001 704 001 - Verkopen van handelsgoed D1 704002 704 002 - Verkopen van handelsgoed D2 704003 704 003 - Verkopen van handelsgoed D3 704004 704 004 - Verkopen van handelsgoed D4 713000 713 000 - Voorraadwijziging gereed product 751000 751 000 - Opbrengsten uit vlottende activa

BIJLAGEN Bijlage 2: Aflossingstabel investeringslening

III

BIJLAGEN Bijlage 3: Overzicht transacties in REA database

IV

BIJLAGEN

V

BIJLAGEN

VI

Bijlage 4: Output eerste onderzoeksvraag

JAARREKENING M 31/12/2009 Rekening

Debet

Credit


0,00 €

20.000,00 €


0,00 €

6.807,45 €

173 000 - Schulden op > 1 jaar - kredietinstellingen 200 000 - Kosten van oprichting en kapitaalverhoging 200 009 - Geboekte afschrijvingen op oprichtingskosten (-) 231 000 - Machines 231 009 - Geboekte afschrijvingen op machines (-)

0,00 €

10.000,00 €

1.387,75 €

0,00 €

0,00 €

277,55 €

1.470,00 €

0,00 €

0,00 €

490,00 €

280 000 - Financiële vaste activa

12.000,00 €

0,00 €

300 000 - Grondstoffen

2.250,00 €

0,00 €

900,00 €

0,00 €

2.000,00 €

0,00 €

400 000 - Handelsvorderingen

0,00 €

0,00 €

411 000 - Terug te vorderen BTW

90,88 €

0,00 €

440 000 - Handelsschulden

0,00 €

2.837,45 €

550 000 - Kredietinstellingen

20.313,82 €

0,00 €


3.500,00 €

0,00 €


500,00 €

0,00 €


500,00 €

0,00 €


875,00 €

0,00 €


0,00 €

2.250,00 €


0,00 €

900,00 €


277,55 €

0,00 €


490,00 €

0,00 €


200,00 €

0,00 €

6.807,45 €

0,00 €


0,00 €

8.000,00 €


0,00 €

2.000,00 €

310 000 - Hulpstoffen 330 000 - Gereed product

693 000 - Winst van het boekjaar

53.562,45 €

53.562,45 € IN BALANS

Donderdag 13 augustus 2009

Pagina 1 van 1

BIJLAGEN

VII

JAARREKENING D 31/12/2009 Rekening

Debet

Credit


0,00 €

20.000,00 €

140 000 - Winst van het huidige boekjaar 221 000 - Gebouwen 221 009 - Geboekte afschrijvingen op gebouwen (-) 340 000 - Handelsgoederen 349 000 - Handelsgoederen: geboekte waardeverminderingen (-) 400 000 - Handelsvorderingen

0,00 €

3.462,50 €

7.500,00 €

0,00 €

0,00 €

187,50 €

2.650,00 €

0,00 €

0,00 €

400,00 €

484,00 €

0,00 €


1.281,00 €

0,00 €


12.135,00 €

0,00 €


2.500,00 €

0,00 €


250,00 €

0,00 €


250,00 €

0,00 €


500,00 €

0,00 €

0,00 €

2.650,00 €


187,50 €

0,00 €


400,00 €

0,00 €


693 000 - Winst van het boekjaar

3.462,50 €

0,00 €


0,00 €

3.500,00 €


0,00 €

500,00 €


0,00 €

500,00 €


0,00 €

400,00 €

31.600,00 €

31.600,00 € IN BALANS


Pagina 1 van 1

BIJLAGEN

VIII

Bijlage 5: Queries in verband met handelsschulden

Om het openstaand saldo handelsschulden op het einde van het boekjaar te becijferen, moesten een aantal tussenstappen worden gemaakt: 1. Berekening van de totale waarde van de aankopen (incl. BTW) die ooit zijn gebeurd: SELECT Sum([Waarde]/[Aant]) AS Aankopen FROM Resource INNER JOIN ((Event INNER JOIN (Increment INNER JOIN [/Aantal objectID per incrementID] ON Increment.Increment_ID = [/Aantal objectID per incrementID].Increment_ID) ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<700000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")) OR ((([Resource Increment].Rekeningnummer_ID)>=200000 And ([Resource Increment].Rekeningnummer_ID)<=280000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")); Aankopen 22233,88

Waarbij [Aant] staat voor het aantal verschillende resources per Increment_ID: SELECT [Resource - Increment].Increment_ID, Count([Resource - Increment].Object_ID) AS Aant FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE (((Increment.Economic_Unit_ID)=1)) GROUP BY [Resource - Increment].Increment_ID; Increment_ID

Aant 1

3

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

1

10

1

11

1

17

1

BIJLAGEN

IX

2. Berekening van de totale waarde van de creditnota’s op aankopen (incl. BTW) die ooit zijn ingeboekt: SELECT Sum([Waarde]/[Aant]) AS [Aankopen CN] FROM Resource INNER JOIN (Event INNER JOIN ((Decrement INNER JOIN [/Aantal objectID per decrementID] ON Decrement.Decrement_ID = [/Aantal objectID per decrementID].Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=600000 And ([Resource Decrement].Rekeningnummer_ID)<700000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")) OR ((([Resource Decrement].Rekeningnummer_ID)>=200000 And ([Resource Decrement].Rekeningnummer_ID)<=280000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")); Aankopen CN 30,25

Waarbij [Aant] staat voor het aantal verschillende resources per Decrement_ID: SELECT Decrement.Decrement_ID, Count([Resource - Decrement].Object_ID) AS Aant FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE (((Decrement.Economic_Unit_ID)=1)) GROUP BY Decrement.Decrement_ID; Decrement_ID

Aant 1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

2

9

2

10

1

3. Berekening van de totale waarde aan betalingen aan leveranciers (incl. BTW) die ooit zijn gebeurd: SELECT Sum(([Decrement].[Waarde]/[Aant])) AS [Betalingen AK] FROM ((Increment INNER JOIN [/Aantal objectID per incrementID] ON Increment.Increment_ID = [/Aantal objectID per incrementID].Increment_ID) INNER JOIN ((Decrement INNER JOIN Duality ON Decrement.Decrement_ID = Duality.Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Increment.Increment_ID =

BIJLAGEN

X Duality.Increment_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID WHERE ((([Resource - Decrement].Rekeningnummer_ID)=550000) AND (([Resource Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<700000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Decrement.Economic_Unit_ID)=1)) OR ((([Resource Increment].Rekeningnummer_ID)>=200000 And ([Resource Increment].Rekeningnummer_ID)<=280000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Decrement.Economic_Unit_ID)=1)); Betalingen AK 19366,18

4. Berekening van de totale waarde aan ontvangsten van creditnota’s op aankopen (incl. BTW) die ooit hebben plaats gevonden: SELECT Sum(([Increment].[Waarde]/[Aant])) AS [Betalingen CN] FROM (Increment INNER JOIN (((Decrement INNER JOIN [/Aantal objectID per decrementID] ON Decrement.Decrement_ID = [/Aantal objectID per decrementID].Decrement_ID) INNER JOIN Duality ON Decrement.Decrement_ID = Duality.Decrement_ID) INNER JOIN [Resource Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Increment.Increment_ID = Duality.Increment_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID WHERE ((([Resource - Increment].Rekeningnummer_ID)=550000) AND (([Resource Decrement].Rekeningnummer_ID)>=600000 And ([Resource Decrement].Rekeningnummer_ID)<700000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Decrement.Economic_Unit_ID)=1)) OR ((([Resource Decrement].Rekeningnummer_ID)>=200000 And ([Resource Decrement].Rekeningnummer_ID)<=280000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Decrement.Economic_Unit_ID)=1)); Betalingen CN

5. Een selectiequery zal het finale saldo aan handelsschulden berekenen (door het verschil te becijferen tussen wat diende te worden betaald en wat reeds is betaald): SELECT [Aankopen]-[Betalingen AK]-[Aankopen CN] AS Handelsschulden, [/440 000: Handelsschulden betalingen CN].[Betalingen CN] FROM [/440 000: Handelsschulden AK], [/440 000: Handelsschulden betalingen AK], [/440 000: Handelsschulden betalingen CN], [/440 000: Handelsschulden CN];

(Er waren geen ontvangsten van creditnota‟s op aankopen.) 6. Uiteindelijk zal de volgende toevoegquery het saldo schrijven naar de gepaste tabel: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "440 000 - Handelsschulden" AS Rekening, 0 AS Debet, [440 000: Handelsschulden].Handelsschulden AS Credit FROM [440 000: Handelsschulden] GROUP BY "440 000 - Handelsschulden", 0, [440 000: Handelsschulden].Handelsschulden; Rekening 440 000 - Handelsschulden

Debet 0

Credit 2837,45

BIJLAGEN

XI

Bijlage 6: Queries in verband met handelsvorderingen

Om het openstaand saldo handelsvorderingen op het einde van het boekjaar te becijferen, moesten een aantal tussenstappen worden gemaakt: 1. Berekening van de totale waarde van de verkopen (incl. BTW) die ooit zijn gebeurd: SELECT Sum([Waarde]/[Aant]) AS Verkopen FROM Resource INNER JOIN (Event INNER JOIN ((Decrement INNER JOIN [/Aantal objectID per decrementID] ON Decrement.Decrement_ID = [/Aantal objectID per decrementID].Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE (((Decrement.Datum)<=#12/31/2009#) AND (([Resource Decrement].Rekeningnummer_ID)>=700000 And ([Resource Decrement].Rekeningnummer_ID)<708000) AND ((Decrement.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")); Verkopen 9680

Waarbij [Aant] staat voor het aantal verschillende resources per Decrement_ID: SELECT Decrement.Decrement_ID, Count([Resource - Decrement].Object_ID) AS Aant FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE (((Decrement.Economic_Unit_ID)=1)) GROUP BY Decrement.Decrement_ID;

2. Berekening van de totale waarde van de creditnota’s op verkopen (incl. BTW) die ooit zijn ingeboekt: SELECT Sum([Waarde]/[Aant]) AS [Verkopen CN] FROM Resource INNER JOIN ((Event INNER JOIN (Increment INNER JOIN [/Aantal objectID per incrementID] ON Increment.Increment_ID = [/Aantal objectID per incrementID].Increment_ID) ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE (((Increment.Datum)<=#12/31/2009#) AND (([Resource Increment].Rekeningnummer_ID)>=700000 And ([Resource Increment].Rekeningnummer_ID)<708000) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Good transfer")); Verkopen CN

Waarbij [Aant] staat voor het aantal verschillende resources per Increment_ID: SELECT [Resource - Increment].Increment_ID, Count([Resource - Increment].Object_ID) AS Aant

BIJLAGEN

XII FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE (((Increment.Economic_Unit_ID)=1)) GROUP BY [Resource - Increment].Increment_ID;

3. Berekening van de totale waarde aan ontvangsten van klanten (incl. BTW) die ooit hebben plaats gevonden: SELECT Sum([Increment].[Waarde]/[Aant]) AS [Betalingen VK] FROM (Increment INNER JOIN (((Decrement INNER JOIN [/Aantal objectID per decrementID] ON Decrement.Decrement_ID = [/Aantal objectID per decrementID].Decrement_ID) INNER JOIN Duality ON Decrement.Decrement_ID = Duality.Decrement_ID) INNER JOIN [Resource Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Increment.Increment_ID = Duality.Increment_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID WHERE ((([Resource - Increment].Rekeningnummer_ID)=550000) AND (([Resource Decrement].Rekeningnummer_ID)>=700000 And ([Resource Decrement].Rekeningnummer_ID)<708000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1) AND ((Increment.Economic_Unit_ID)=1)); Betalingen VK 9680

4. Berekening van de totale waarde aan betalingen van creditnota’s op verkopen (incl. BTW) die ooit zijn gebeurd: SELECT Sum(([Decrement].[Waarde]/[Aant])) AS [Betalingen CN] FROM ((Increment INNER JOIN [/Aantal objectID per incrementID] ON Increment.Increment_ID = [/Aantal objectID per incrementID].Increment_ID) INNER JOIN ((Decrement INNER JOIN Duality ON Decrement.Decrement_ID = Duality.Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Increment.Increment_ID = Duality.Increment_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID WHERE ((([Resource - Decrement].Rekeningnummer_ID)=550000) AND (([Resource Increment].Rekeningnummer_ID)>=700000 And ([Resource Increment].Rekeningnummer_ID)<708000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Decrement.Economic_Unit_ID)=1) AND ((Increment.Economic_Unit_ID)=1)); Betalingen CN

5. Een selectiequery zal het finale saldo aan handelsvorderingen berekenen (door het verschil te becijferen tussen het geld dat diende te worden geïnd en hetgeen reeds werd ontvangen van klanten): SELECT [Verkopen]-[Betalingen VK] AS Handelsvorderingen FROM [/400 000: Handelsvorderingen betalingen CN], [/400 000: Handelsvorderingen betalingen VK], [/400 000: Handelsvorderingen CN], [/400 000: Handelsvorderingen VK];

(Er waren geen creditnota‟s op verkopen.)

BIJLAGEN

XIII

6. Uiteindelijk zal de volgende toevoegquery het saldo schrijven naar de gepaste tabel: INSERT INTO [// JAARREKENING D 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "400 000 - Handelsvorderingen" AS Rekening, [D 400 000: Handelsvorderingen].Handelsvorderingen AS Debet, 0 AS Credit FROM [D 400 000: Handelsvorderingen] GROUP BY "400 000 - Handelsvorderingen", [D 400 000: Handelsvorderingen].Handelsvorderingen, 0; Rekening 400 000 - Handelsvorderingen

Debet

Credit 0

0

Blijkbaar hebben alle klanten de verkoopfacturen heeft snel vereffend, en moet onderneming M van geen enkele klant nog betaling ontvangen.

BIJLAGEN

XIV

Bijlage 7: Queries in verband met de inventarisverrichtingen

Aankopen, verkopen en voorraad Bij de jaarlijkse inventaris wordt vastgesteld hoeveel de voorraad gewijzigd is gedurende het boekjaar. Hiertoe dient de voorraad gewaardeerd te worden aan de gewogen gemiddelde aankoopprijs (grond- en hulpstoffen) of de marktwaarde (eindproducten).

De waarderingsmaatstaf werd bepaald met behulp van een aantal queries: -

Bepaling van de gewogen gemiddelde aankoopprijs van grondstoffen (indien 10 goederen worden aangekocht tegen een prijs van € 10/stuk en nogmaals 10 goederen tegen een prijs van € 20/stuk, bedraagt de gemiddelde aankoopprijs € 15/stuk): SELECT [Resource - Increment].Rekeningnummer_ID, Sum([Aantal]*[Eenheidsprijs])/Sum([Aantal]) AS Eenheidswaarde FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<601000) AND ((Increment.Economic_Unit_ID)=1)) GROUP BY [Resource - Increment].Rekeningnummer_ID;

Het resultaat is het volgende: Rekeningnummer_ID

-

Eenheidswaarde

600001

35

600002

10

600003

10

Bepaling van de gewogen gemiddelde aankoopprijs van hulpstoffen: SELECT [Resource - Increment].Rekeningnummer_ID, Sum([Aantal]*[Eenheidsprijs])/Sum([Aantal]) AS Eenheidswaarde FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=601000 And ([Resource Increment].Rekeningnummer_ID)<602000) AND ((Increment.Economic_Unit_ID)=1)) GROUP BY [Resource - Increment].Rekeningnummer_ID;

Een analoog resultaat wordt bekomen, zij het dan voor de hulpstoffen: Rekeningnummer_ID

Eenheidswaarde

601001

-

Bepaling van de marktwaarde van gereed product:

4,5

BIJLAGEN

XV SELECT Resource.Rekeningnummer_ID, Sum([Aantal]*[Eenheidsprijs])/Sum([Aantal]) AS Marktwaarde FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE (((Resource.Rekeningnummer_ID)>=700000 And (Resource.Rekeningnummer_ID)<701000) AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY Resource.Rekeningnummer_ID;

Een analoog resultaat wordt bekomen, zij het dan voor de afgewerkte producten: Rekeningnummer_ID

Marktwaarde

700001

200

Vervolgens werd voor elke voorraadcategorie nagegaan met hoeveel het voorraadniveau (het saldo aan aankopen minus het verbruik wordt becijferd) wijzigde: 1. Grondstoffen -

Aankopen: SELECT Resource.Rekeningnummer_ID, Sum(Resource.Aantal) AS [Aangekocht aantal], Sum([Aantal]*[Eenheidswaarde]) AS [Waarde aangekocht aantal] FROM ([/300 000: Grondstoffen eenheidswaarde] INNER JOIN Resource ON [/300 000: Grondstoffen eenheidswaarde].Rekeningnummer_ID = Resource.Rekeningnummer_ID) INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<601000) AND ((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Event.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)=1)) GROUP BY Resource.Rekeningnummer_ID;

Deze query berekent op basis van de gegevens uit de Increment tabel hoeveel grondstoffen er het desbetreffende boekjaar zijn aangekocht via goederentransfers. De waarde van de aangekochte grondstoffen wordt becijferd door gebruik te maken van de berekende gewogen gemiddelde aankoopprijs: Rekeningnummer_ID

Aangekocht aantal

Waarde aangekocht aantal

600001

100

3500

600002

50

500

600003

50

500

 Totale aankopen grondstoffen: SELECT Sum([/300 000: Grondstoffen AK].[Waarde aangekocht aantal]) AS [Aankopen grondstoffen] FROM [/300 000: Grondstoffen AK];

BIJLAGEN

XVI De totale waarde van de aankopen wordt becijferd door de waarde van de aangekochte grondstoffen te sommeren: Aankopen grondstoffen 4500

-

Verbruik: SELECT [Resource - Decrement].Rekeningnummer_ID, Sum(Resource.Aantal) AS [Verbruikt aantal], Sum([Aantal]*[Eenheidswaarde]) AS [Waarde verbruikt aantal] FROM Resource INNER JOIN (Event INNER JOIN (Decrement INNER JOIN ([/300 000: Grondstoffen eenheidswaarde] INNER JOIN [Resource - Decrement] ON [/300 000: Grondstoffen eenheidswaarde].Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=600000 And ([Resource Decrement].Rekeningnummer_ID)<601000) AND ((Event.Datum)<=#12/31/2009#) AND ((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Event.Type)="Conversion") AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY [Resource - Decrement].Rekeningnummer_ID;

Deze query berekent op basis van de gegevens uit de Decrement tabel hoeveel grondstoffen er het desbetreffende boekjaar zijn verbruikt via conversion events. De waarde van de verbruikte grondstoffen wordt becijferd door gebruik te maken van de berekende gewogen gemiddelde aankoopprijs: Rekeningnummer_ID

Verbruikt aantal

Waarde verbruikt aantal

600001

50

1750

600002

50

500

 Totaal verbruik grondstoffen: SELECT Sum([/300 000: Grondstoffen verbruik].[Waarde verbruikt aantal]) AS [SomVanWaarde verbruikt aantal] FROM [/300 000: Grondstoffen verbruik];

De totale waarde van het verbruik wordt becijferd door de waarde van de verbruikte grondstoffen te sommeren: Verbruik grondstoffen 2250

-

Voorraadwijziging (deze wordt becijferd door uit te rekenen hoeveel het verschil bedraagt tussen de aankopen van grondstoffen en het verbruik ervan): SELECT Sum([Aankopen grondstoffen]-[Verbruik grondstoffen]) AS Grondstoffen FROM [/300 000: Grondstoffen AK totaal], [/300 000: Grondstoffen verbruik totaal]; Grondstoffen 2250

 Toevoegqueries voorraadwijziging:

BIJLAGEN

XVII INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "300 000 - Grondstoffen" AS Rekening, [300 000: Grondstoffen].Grondstoffen AS Debet, 0 AS Credit FROM [300 000: Grondstoffen] GROUP BY "300 000 - Grondstoffen", [300 000: Grondstoffen].Grondstoffen, 0; Rekening

Debet

300 000 - Grondstoffen

Credit 2250

0

en INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "609 000 - Voorraadwijziging grondstoffen" AS Rekening, 0 AS Debet, [300 000: Grondstoffen].Grondstoffen AS Credit FROM [300 000: Grondstoffen] GROUP BY "609 000 - Voorraadwijziging grondstoffen", 0, [300 000: Grondstoffen].Grondstoffen; Rekening

Debet


Credit 0

2250

2. Hulpstoffen (de becijfering van de voorraad hulpstoffen geschiedt volledig analoog aan de becijfering van de voorraad grondstoffen) -

Aankopen: SELECT Resource.Rekeningnummer_ID, Sum(Resource.Aantal) AS [Aangekocht aantal], Sum([Aantal]*[Eenheidswaarde]) AS [Waarde aangekocht aantal] FROM Resource INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN ([/310 000: Hulpstoffen eenheidswaarde] INNER JOIN [Resource - Increment] ON [/310 000: Hulpstoffen eenheidswaarde].Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) ON Increment.Increment_ID = [Resource Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=601000 And ([Resource Increment].Rekeningnummer_ID)<602000) AND ((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Event.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)=1)) GROUP BY Resource.Rekeningnummer_ID;

Resultaat: Rekeningnummer_ID

Aangekocht aantal

601001

Waarde aangekocht aantal

200

900

Totale aankopen hulpstoffen: SELECT Sum([/310 000: Hulpstoffen AK].[Waarde aangekocht aantal]) AS [Aankopen hulpstoffen] FROM [/310 000: Hulpstoffen AK]; Aankopen hulpstoffen 900

-

Verbruik:

BIJLAGEN

XVIII SELECT [Resource - Decrement].Rekeningnummer_ID, Sum(Resource.Aantal) AS [Verbruikt aantal], Sum([Aantal]*[Eenheidswaarde]) AS [Waarde verbruikt aantal] FROM Resource INNER JOIN (Event INNER JOIN (Decrement INNER JOIN ([/300 000: Grondstoffen eenheidswaarde] INNER JOIN [Resource - Decrement] ON [/300 000: Grondstoffen eenheidswaarde].Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=601000 And ([Resource Decrement].Rekeningnummer_ID)<602000) AND ((Event.Datum)<=#12/31/2009#) AND ((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Event.Type)="Conversion") AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY [Resource - Decrement].Rekeningnummer_ID;

Resultaat: Er werden geen hulpstoffen verbruikt. Totaal verbruik hulpstoffen: SELECT Sum([/310 000: Hulpstoffen verbruik].[Waarde verbruikt aantal]) AS [SomVanWaarde verbruikt aantal] FROM [/310 000: Hulpstoffen verbruik];

-

Voorraadwijziging: SELECT Sum([/310 000: Hulpstoffen AK totaal].[Aankopen hulpstoffen]) AS Hulpstoffen FROM [/310 000: Hulpstoffen AK totaal], [/310 000: Hulpstoffen verbruik totaal]; Hulpstoffen 900

 Toevoegqueries voorraadwijziging: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Debet, Credit, Rekening ) SELECT [310 000: Hulpstoffen].Hulpstoffen AS Debet, 0 AS Credit, "310 000 Hulpstoffen" AS Rekening FROM [310 000: Hulpstoffen] GROUP BY [310 000: Hulpstoffen].Hulpstoffen, 0, "310 000 - Hulpstoffen"; Rekening

Debet

310 000 - Hulpstoffen

Credit 900

0

en INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "609 100 - Voorraadwijziging hulpstoffen" AS Rekening, 0 AS Debet, [310 000: Hulpstoffen].Hulpstoffen AS Credit FROM [310 000: Hulpstoffen] GROUP BY "609 100 - Voorraadwijziging hulpstoffen", 0, [310 000: Hulpstoffen].Hulpstoffen; Rekening 609 100 - Voorraadwijziging hulpstoffen

3. Gereed product -

Productie:

Debet

Credit 0

900

BIJLAGEN

XIX SELECT [Resource - Increment].Rekeningnummer_ID, Sum(Resource.Aantal) AS [Geproduceerde aantal], Sum([Aantal]*[Marktwaarde]) AS [Waarde geproduceerd aantal] FROM Resource INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN ([/330 000: Gereed product marktwaarde] INNER JOIN [Resource - Increment] ON [/330 000: Gereed product marktwaarde].Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) ON Increment.Increment_ID = [Resource Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=700000 And ([Resource Increment].Rekeningnummer_ID)<701000) AND ((Event.Datum)<=#12/31/2009#) AND ((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Increment.Economic_Unit_ID)=1) AND ((Event.Type)="Conversion")) GROUP BY [Resource - Increment].Rekeningnummer_ID;

Deze query berekent op basis van de gegevens uit de Increment tabel hoeveel afgewerkte producten er het desbetreffende boekjaar zijn geproduceerd via conversion events. De waarde van de geproduceerde producten wordt becijferd door gebruik te maken van de berekende marktprijs: Rekeningnummer_ID

Geproduceerde aantal

700001

Waarde geproduceerd aantal 50

10000

Totale productie gereed product: SELECT Sum([/330 000: Gereed product productie].[Waarde geproduceerd aantal]) AS Productie FROM [/330 000: Gereed product productie]; Productie 10000

-

Verkopen: SELECT [Resource - Decrement].Rekeningnummer_ID, Sum(Resource.Aantal) AS [Verkocht aantal], Sum([Aantal]*[Marktwaarde]) AS [Waarde verkocht aantal] FROM Resource INNER JOIN (Event INNER JOIN (Decrement INNER JOIN ([/330 000: Gereed product marktwaarde] INNER JOIN [Resource - Decrement] ON [/330 000: Gereed product marktwaarde].Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=700000 And ([Resource Decrement].Rekeningnummer_ID)<701000) AND ((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Event.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Decrement.Economic_Unit_ID)=1)) GROUP BY [Resource - Decrement].Rekeningnummer_ID;

Deze query berekent op basis van de gegevens uit de Decrement tabel hoeveel afgewerkte

producten

er

het

desbetreffende

boekjaar

zijn

verkocht

via

goederentransfers. De waarde van de verkochte producten wordt becijferd door gebruik te maken van de berekende marktprijs:

BIJLAGEN

XX Rekeningnummer_ID

Verkocht aantal

700001

Waarde verkocht aantal 40

8000

Totale verkopen gereed product: SELECT Sum([/330 000: Gereed product VK].[Waarde verkocht aantal]) AS Verkopen FROM [/330 000: Gereed product VK]; Verkopen 8000

-

Voorraadwijziging: SELECT Sum([Productie]-[Verkopen]) AS [Gereed product] FROM [/330 000: Gereed product productie totaal], [/330 000: Gereed product VK totaal]; Gereed product 2000

 Toevoegqueries voorraadwijziging: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "330 000 - Gereed product" AS Rekening, [330 000: Gereed product].[Gereed product] AS Debet, 0 AS Credit FROM [330 000: Gereed product] GROUP BY "330 000 - Gereed product", [330 000: Gereed product].[Gereed product], 0; Rekening 330 000 - Gereed product

Debet

Credit 2000

0

en INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "713 000 - Voorraadwijziging gereed product" AS Rekening, 0 AS Debet, [330 000: Gereed product].[Gereed product] AS Credit FROM [330 000: Gereed product] GROUP BY "713 000 - Voorraadwijziging gereed product", 0, [330 000: Gereed product].[Gereed product]; Rekening 713 000 - Voorraadwijziging gereed product

Debet

Credit 0

2000

Vermits onderneming D een handelsonderneming is, diende de voorraadwaardering hier anders te gebeuren, met name tegen de aankoopprijs. De werkwijze verloopt geheel analoog aan deze voor de becijfering van de eindvoorraden grondstoffen en hulpstoffen van onderneming M: -

Aankoopprijs handelsgoederen: SELECT Resource.Rekeningnummer_ID, Sum([Aantal]*[Eenheidsprijs])/Sum([Aantal]) AS Aanschaffingsprijs FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID)

BIJLAGEN

XXI WHERE (((Resource.Rekeningnummer_ID)>=604000 And (Resource.Rekeningnummer_ID)<605000) AND ((Increment.Economic_Unit_ID)=2)) GROUP BY Resource.Rekeningnummer_ID; Rekeningnummer_ID

-

Aanschaffingsprijs

604001

5

604002

2,5

604003

2,5

604004

1

Aankopen: SELECT Resource.Rekeningnummer_ID, Sum(Resource.Aantal) AS [Aangekocht aantal] FROM Resource INNER JOIN ((Event INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN ([D /340 000: Handelsgoederen aanschaffingsprijs] INNER JOIN [Resource - Increment] ON [D /340 000: Handelsgoederen aanschaffingsprijs].Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE (((Resource.Rekeningnummer_ID)>=604000 And (Resource.Rekeningnummer_ID)<605000) AND ((Increment.Datum)>=#1/1/2009# And (Increment.Datum)<=#12/31/2009#) AND ((Event.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)=2)) GROUP BY Resource.Rekeningnummer_ID; Rekeningnummer_ID

-

Aangekocht aantal

604001

500

604002

100

604003

100

604004

500

Verkopen: SELECT [Resource]![Rekeningnummer_ID]-100000 AS Rekening, Sum(Resource.Aantal) AS [Verkocht aantal] FROM Resource INNER JOIN (Event INNER JOIN (Decrement INNER JOIN [Resource Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) ON (Resource.Object_ID = [Resource Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=704000 And ([Resource Decrement].Rekeningnummer_ID)<705000) AND ((Decrement.Datum)>=#1/1/2009# And (Decrement.Datum)<=#12/31/2009#) AND ((Event.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Decrement.Economic_Unit_ID)=2)) GROUP BY [Resource]![Rekeningnummer_ID]-100000;

De veronderstelling die hierbij wordt gemaakt is dat (de aankoop van) handelsgoed 604001 overeenkomt met (de verkoop van) handelsgoed 704001, enzovoort. Rekening

Verkocht aantal

BIJLAGEN

-

XXII 604001

100

604002

50

604003

50

604004

100

Bepaling van het aantal handelsgoederen in de eindvoorraad, via het bepalen van het verschil tussen het aangekocht aantal en het verkocht aantal handelsgoederen: SELECT [D /340 000: Handelsgoederen AK].Rekeningnummer_ID, Sum([Aangekocht aantal][Verkocht aantal]) AS [Aantal eindvoorraad] FROM [D /340 000: Handelsgoederen aanschaffingsprijs] INNER JOIN ([D /340 000: Handelsgoederen VK] INNER JOIN [D /340 000: Handelsgoederen AK] ON [D /340 000: Handelsgoederen VK].Rekening = [D /340 000: Handelsgoederen AK].Rekeningnummer_ID) ON ([D /340 000: Handelsgoederen aanschaffingsprijs].Rekeningnummer_ID = [D /340 000: Handelsgoederen VK].Rekening) AND ([D /340 000: Handelsgoederen aanschaffingsprijs].Rekeningnummer_ID = [D /340 000: Handelsgoederen AK].Rekeningnummer_ID) GROUP BY [D /340 000: Handelsgoederen AK].Rekeningnummer_ID; Rekeningnummer_ID

-

Aantal eindvoorraad

604001

400

604002

50

604003

50

604004

400

Bepaling van de waarde van handelsgoederen in de eindvoorraad, door het aantal handelsgoederen in de eindvoorraad te vermenigvuldigen met de becijferde aanschaffingswaarde van de handelsgoederen: SELECT [D /340 000: Handelsgoederen eindvoorraad in aantallen].Rekeningnummer_ID, Sum([Aanschaffingsprijs]*[Aantal eindvoorraad]) AS Waarde FROM [D /340 000: Handelsgoederen eindvoorraad in aantallen] INNER JOIN [D /340 000: Handelsgoederen aanschaffingsprijs] ON [D /340 000: Handelsgoederen eindvoorraad in aantallen].Rekeningnummer_ID = [D /340 000: Handelsgoederen aanschaffingsprijs].Rekeningnummer_ID GROUP BY [D /340 000: Handelsgoederen eindvoorraad in aantallen].Rekeningnummer_ID; Rekeningnummer_ID

Waarde

604001

2000

604002

125

604003

125

604004

400

Finaal levert dit de volgende waarde aan eindvoorraad op: Handelsgoederen 2650

Toevoegqueries voorraadwijziging: INSERT INTO [// JAARREKENING D 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "340 000 - Handelsgoederen" AS Rekening, [D 340 000: Handelsgoederen].Handelsgoederen AS Debet, 0 AS Credit

BIJLAGEN

XXIII FROM [D 340 000: Handelsgoederen] GROUP BY "340 000 - Handelsgoederen", [D 340 000: Handelsgoederen].Handelsgoederen, 0; Rekening

Debet

340 000 - Handelsgoederen

Credit 2650

0

en INSERT INTO [// JAARREKENING D 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "609 400 - Voorraadwijziging handelsgoederen" AS Rekening, 0 AS Debet, [D 340 000: Handelsgoederen].Handelsgoederen AS Credit FROM [D 340 000: Handelsgoederen] GROUP BY "609 400 - Voorraadwijziging handelsgoederen", 0, [D 340 000: Handelsgoederen].Handelsgoederen; Rekening

Debet


Credit 0

2650

Onderneming D stelde vast dat de realisatiewaarde van de aangekochte handelsgoederen in zekere mate was gezakt. Tijdens het boekjaar werden 500 eenheden van handelsgoed 1 aangekocht, aan een aankoopprijs van € 5 per stuk. Er werden reeds 100 stuks verkocht. De eindvoorraad bestaat bijgevolg uit 400 stuks. Nu blijkt dat onderneming D nog slechts € 4 per stuk zou kunnen krijgen bij verkoop. Een waardevermindering van € 400 moet worden geboekt: -

In eerste instantie werd vastgesteld hoeveel de reële voorraadwijziging bedroeg; Dit gegeven wordt opgehaald door de waarde bekomen via de selectiequery ter bepaling van de eindvoorraad van handelsgoederen te verminderen met € 400: SELECT Sum([Waarde])-400 AS Handelsgoederen FROM [D /340 000: Handelsgoederen eindvoorraad in waarde];

De correcte voorraadwijziging bedroeg aldus: Handelsgoederen 2250

-

Vervolgens moeten twee extra toevoegqueries in werking treden (de eerste zal de activarekening toevoegen aan de jaarrekening van onderneming M ter correctie van de activarekening handelsgoederen, de tweede zal de gepaste kostenrekening „waardeverminderingen op voorraden‟ hier tegenover stellen en wordt dus eveneens toegevoegd aan de jaarrekening): INSERT INTO [// JAARREKENING D 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "349 000 - Handelsgoederen: geboekte waardeverminderingen (-)" AS Rekening, 0 AS Debet, [D 340 000: Handelsgoederen]![Handelsgoederen]-[D 340 000: Handelsgoederen na waardevermindering]![Handelsgoederen] AS Credit FROM [D 340 000: Handelsgoederen], [D 340 000: Handelsgoederen na waardevermindering]

BIJLAGEN

XXIV GROUP BY "349 000 - Handelsgoederen: geboekte waardeverminderingen (-)", 0, [D 340 000: Handelsgoederen]![Handelsgoederen]-[D 340 000: Handelsgoederen na waardevermindering]![Handelsgoederen]; Rekening

Debet

349 000 - Handelsgoederen: geboekte waardeverminderingen (-)

Credit 0

400

en INSERT INTO [// JAARREKENING D 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "631 000 - Waardeverminderingen op voorraden: toevoeging" AS Rekening, [D 340 000: Handelsgoederen]![Handelsgoederen]-[D 340 000: Handelsgoederen na waardevermindering]![Handelsgoederen] AS Debet, 0 AS Credit FROM [D 340 000: Handelsgoederen], [D 340 000: Handelsgoederen na waardevermindering]; Rekening 631 000 - Waardeverminderingen op voorraden: toevoeging

Debet

Credit 400

0

Anticipatie- en uitstelposten met betrekking tot kosten en opbrengsten Niet van toepassing.

Vaste activa Indien wordt gedacht aan inventarisverrichtingen in verband met vaste activa, wordt spontaan de link gelegd met afschrijvingen. Afschrijvingen dienen immers jaarlijks te gebeuren, op basis van een vooraf gedefinieerde afschrijvingsmethode (hier de lineaire methode) en vastgestelde levensduurtijden. Per activarekening moest een query worden geschreven die de afschrijvingen zou becijferen. De werkwijze ter bepaling van de afschrijvingen op machines (voor onderneming M) zal hierna worden toegelicht. Aangezien er tijdens het boekjaar een computer (hardware) werd aangekocht, moest deze een eerste maal worden afgeschreven in 2009. Rekening houdend met de aankoopprijs van de computer (excl. BTW) (die uit de database kon worden gehaald via de Increment tabel) en de standaard levensduur van hardware van 3 jaar, kon een query worden geconstrueerd die voor een reeks van boekjaren21 de afschrijvingen becijferde: SELECT [/ Boekjaren].Boekjaar, Sum(([Aantal]*[Eenheidsprijs])/3) AS [Geboekte afschrijvingen op machines] FROM [/ Boekjaren], Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource -

21

Er werd een tabel „/ Boekjaren‟ aangemaakt. Indien een vast actief immers wordt aangekocht in het jaar 2010, moet er rekening

mee worden gehouden dat de afschrijvingen slechts van dan af aan beginnen te lopen. Bovendien mogen ze ook niet oneindig doorlopen (er moet rekening worden gehouden met de levensduur van het actief).

BIJLAGEN

XXV

Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)=231000) AND (([/ Boekjaren].Boekjaar)=DatePart("yyyy",[Datum])) AND ((Increment.Economic_Unit_ID)=1)) GROUP BY [/ Boekjaren].Boekjaar;

Deze query leverde als resultaat: Boekjaar

Geboekte afschrijvingen op machines

2009

490

2010

490

2011

490

De toevoegqueries die de afschrijvingen aan de jaarrekening van onderneming M moesten toevoegen, moesten uiteraard rekening houden met het huidige boekjaar, i.e. 2009. Een eerste toevoegquery voegt de correctierekening „231 009 - Geboekte afschrijvingen op machines (-)‟ toe: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "231 009 - Geboekte afschrijvingen op machines (-)" AS Rekening, 0 AS Debet, [231 009: Geboekte afschrijvingen op 231 000].[Geboekte afschrijvingen op machines] AS Credit FROM [231 009: Geboekte afschrijvingen op 231 000] WHERE ((([231 009: Geboekte afschrijvingen op 231 000].Boekjaar)=2009)) GROUP BY "231 009 - Geboekte afschrijvingen op machines (-)", 0, [231 009: Geboekte afschrijvingen op 231 000].[Geboekte afschrijvingen op machines]; Rekening

Debet

231 009 - Geboekte afschrijvingen op machines (-)

Credit 0

490

De tweede toevoegquery voegt de daarmee samenhangende kostenrekening „630 230 Afschrijvingen op installaties, machines en uitrusting‟ toe: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "630 230 - Afschrijvingen op installaties, machines en uitrusting" AS Rekening, [231 009: Geboekte afschrijvingen op 231 000].[Geboekte afschrijvingen op machines] AS Debet, 0 AS Credit FROM [231 009: Geboekte afschrijvingen op 231 000] WHERE ((([231 009: Geboekte afschrijvingen op 231 000].Boekjaar)=2009)) GROUP BY "630 230 - Afschrijvingen op installaties, machines en uitrusting", [231 009: Geboekte afschrijvingen op 231 000].[Geboekte afschrijvingen op machines], 0; Rekening 630 230 - Afschrijvingen op installaties, machines en uitrusting

Debet

Credit 490

0

Controle op de waardering van vorderingen en schulden Op het einde van het boekjaar moet een afrekening worden gemaakt. Moet onderneming M BTW betalen of kan zij BTW terugvorderen? Er werd uitgerekend dat, rekening houdend met alle mogelijk aankoopfacturen, verkoopfacturen, creditnota‟s op aankopen en creditnota‟s op verkopen, volgende saldi werden bekomen:

BIJLAGEN

XXVI

-

Terug te vorderen BTW: € 1.776,13

-

Te betalen BTW: € 1.685,25

Dit resulteert in een saldo terug te vorderen BTW van € 90,88. In de database kon dit uiteraard eveneens worden becijferd op basis van de twee hulpqueries die bepaalden hoeveel BTW er terug te vorderen was en hoeveel BTW er te betalen was. Op voorhand kan niet geweten zijn of er BTW terug te vorderen zal zijn dan wel te betalen. Twee scenario’s werden gemodelleerd: -

Indien het bedrag terug te vorderen BTW groter is dan het bedrag te betalen BTW, moet de rekening 411 000 een positief saldo vertonen. Dit wordt nagegaan als volgt: SELECT [Terug te vorderen BTW]-[Te betalen BTW] AS [Terug te vorderen BTW saldo] FROM [/411 000: Terug te vorderen BTW totaal], [/451 000: Te betalen BTW totaal] WHERE ((([/411 000: Terug te vorderen BTW totaal].[Terug te vorderen BTW])>[Te betalen BTW]));

De toevoegquery voor rekeningnummer 411 000 zal het saldo terug te vorderen BTW toevoegen: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "411 000 - Terug te vorderen BTW" AS Rekening, [411 000: Terug te vorderen BTW].[Terug te vorderen BTW saldo] AS Debet, 0 AS Credit FROM [411 000: Terug te vorderen BTW] GROUP BY "411 000 - Terug te vorderen BTW", [411 000: Terug te vorderen BTW].[Terug te vorderen BTW saldo], 0; Rekening 411 000 - Terug te vorderen BTW

-

Debet 90,88 €

Credit 0

Indien het bedrag te betalen BTW groter is dan het bedrag terug te vorderen BTW, moet de rekening 451 000 een positief saldo vertonen. Dit wordt nagegaan als volgt: SELECT [Te betalen BTW]-[Terug te vorderen BTW] AS [Te betalen BTW saldo] FROM [/411 000: Terug te vorderen BTW totaal], [/451 000: Te betalen BTW totaal] WHERE ((([/451 000: Te betalen BTW totaal].[Te betalen BTW])>[Terug te vorderen BTW]));

De toevoegquery voor rekeningnummer 451 000 zal het saldo te betalen BTW toevoegen: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "451 000 - Te betalen BTW" AS Rekening, 0 AS Debet, [451 000: Te betalen BTW].[Te betalen BTW saldo] AS Credit FROM [451 000: Te betalen BTW] GROUP BY "451 000 - Te betalen BTW", 0, [451 000: Te betalen BTW].[Te betalen BTW saldo];

Dit saldo is logischerwijs (er is namelijk reeds een saldo terug te vorderen BTW) nul. Bij het uitvoeren van deze query wordt bijgevolg geen lijn toegevoegd aan de jaarrekening van onderneming M.

BIJLAGEN

XXVII

Bijlage 8: Queries in verband met de resultaatverwerking

Om te bepalen of onderneming M in het boekjaar 2009 verlies heeft geleden dan wel winst heeft gemaakt, moet rekening worden gehouden met alle geregistreerde kosten- en opbrengstenrekeningen. Voor onderneming M werd het volgende bekomen: // JAARREKENING M 31/12/2009 // Rekening

Debet

Credit


3.500,00 €

0,00 €


500,00 €

0,00 €


500,00 €

0,00 €


0,00 €

25,00 €


900,00 €

0,00 €


0,00 € 2.250,00 €


0,00 €

900,00 €


277,55 €

0,00 €


490,00 €

0,00 €


200,00 €

0,00 €


0,00 € 8.000,00 €


0,00 € 2.000,00 €

Het becijferen van de opbrengsten gebeurt door voor alle rekeningen (in de tabel met de jaarrekening van onderneming M) die starten met het cijfer 7 het saldo credit - debet te berekenen: SELECT Sum([Credit]-[Debet]) AS Opbrengsten FROM [// JAARREKENING M 31/12/2009 //] WHERE (((Left([Rekening],1))=7)); Opbrengsten 10.000,00 €

Het becijferen van de kosten gebeurt door voor alle rekeningen (in de tabel met de jaarrekening van onderneming M) die starten met het cijfer 6 het saldo debet - credit te berekenen: SELECT Sum([Debet]-[Credit]) AS Kosten FROM [// JAARREKENING M 31/12/2009 //] WHERE (((Left([Rekening],1))=6)); Kosten 3.192,55 €

Analoog aan de bepaling van de terug te vorderen/te betalen BTW, worden ook hier twee scenario‟s gemodelleerd. Het is immers vooraf niet geweten of er een verlies of een winst zal worden geboekt. -

Scenario 1: het winstscenario (indien de opbrengsten de kosten overtreffen) SELECT [Opbrengsten]-[Kosten] AS [Over te dragen winst] FROM [/140 000 of 141 000: Opbrengsten], [/140 000 of 141 000: Kosten]

BIJLAGEN

XXVIII WHERE ((([/140 000 of 141 000: Opbrengsten].Opbrengsten)>=[Kosten])) GROUP BY [Opbrengsten]-[Kosten]; Over te dragen winst 6.807,45 €

Twee toevoegqueries worden in het leven geroepen om de gepaste lijnen toe te voegen aan de jaarrekening van onderneming M: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "140 000 - Winst van het huidige boekjaar" AS Rekening, 0 AS Debet, [140 000: Overgedragen winst].[Over te dragen winst] AS Credit FROM [140 000: Overgedragen winst]; Rekening

Debet


Credit 0

6.807,45 €

en INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "693 000 - Winst van het boekjaar" AS Rekening, [140 000: Overgedragen winst].[Over te dragen winst] AS Debet, 0 AS Credit FROM [140 000: Overgedragen winst]; Rekening 693 000 - Winst van het boekjaar

-

Debet

Credit

6.807,45 €

0

Scenario 2: het verliesscenario (indien de kosten de opbrengsten overtreffen) SELECT [Kosten]-[Opbrengsten] AS [Over te dragen verlies] FROM [/140 000 of 141 000: Opbrengsten], [/140 000 of 141 000: Kosten] WHERE ((([/140 000 of 141 000: Kosten].Kosten)>[Opbrengsten])) GROUP BY [Kosten]-[Opbrengsten];

Twee toevoegqueries worden in het leven geroepen om de gepaste lijnen toe te voegen aan de jaarrekening van onderneming M: INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "141 000 - Verlies van het huidige boekjaar (-)" AS Rekening, [141 000: Overgedragen verlies].[Over te dragen verlies] AS Debet, 0 AS Credit FROM [141 000: Overgedragen verlies];

en INSERT INTO [// JAARREKENING M 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "793 000 - Verlies van het boekjaar" AS Rekening, 0 AS Debet, [141 000: Overgedragen verlies].[Over te dragen verlies] AS Credit FROM [141 000: Overgedragen verlies];

Uiteraard worden bij het uitvoeren van deze queries geen lijnen toegevoegd aan de jaarrekening, aangezien er winst was geboekt tijdens het boekjaar 2009.

BIJLAGEN

XXIX

Bijlage 9: Grootboek onderneming M (excl. inventarisverrichtingen)

Grootboek Omschrijving

Datum


1/01/2009

20.000,00 €

18


6/01/2009

10.000,00 €

19

200 000 - Kosten van oprichting en kapitaalverhoging

6/01/2009

1.387,75 €

20

231 000 - Machines

9/01/2009

1.470,00 €

14

280 000 - Financiλle vaste activa

1/01/2009

12.000,00 €

2

400000 Handelsvorderingen

3/01/2009

9.680,00 €

11

400000 Handelsvorderingen

3/01/2009

411000 Terug te vorderen BTW

1/01/2009

945,00 €

2


2/01/2009

105,00 €

10


6/01/2009

42,00 €

19


6/01/2009

291,43 €

20


9/01/2009

308,70 €

14


20/01/2009

84,00 €

2

440000 Handelsschulden

1/01/2009

12.000,00 €

2


1/01/2009

5.445,00 €

2


1/01/2009

12.000,00 €

2


1/01/2009

5.445,00 €

2


2/01/2009

605,00 €

10


3/01/2009


6/01/2009

242,00 €

19


6/01/2009

1.679,18 €

20


6/01/2009

242,00 €

19


6/01/2009

1.679,18 €

20


9/01/2009

1.778,70 €

14


20/01/2009

484,00 €

2

451000 Te betalen BTW

3/01/2009

1.680,00 €

11

451000 Te betalen BTW

3/01/2009

5,25 €

10


1/01/2009

12.000,00 €

2


1/01/2009


2/01/2009


5/01/2009

9.680,00 €

11


6/01/2009

10.000,00 €

19


Debet

Credit

9.680,00 €

30,25 €

Stakeholder ID

11

10

20.000,00 €

18 5.445,00 €

2

Pagina 1 van 2

BIJLAGEN

XXX

Omschrijving

Datum

Credit

Stakeholder ID


7/01/2009

Debet

242,00 €

19


8/01/2009

1.679,18 €

20


1/01/2009

3.500,00 €

2


1/01/2009

500,00 €

2


1/01/2009

500,00 €

2


2/01/2009

500,00 €

10


3/01/2009


20/01/2009

400,00 €

2


6/01/2009

200,00 €

19


3/01/2009

25,00 €

8.000,00 €

90.990,31 €

10

11

90.990,31 €

IN BALANS


Pagina 2 van 2

BIJLAGEN

XXXI

Bijlage 10: Correctie-queries geconsolideerde jaarrekening De allereerste stappen bij het opstellen van de geconsolideerde jaarrekening bestonden erin de jaarrekeningen van de te consolideren ondernemingen toe te voegen aan de geconsolideerde jaarrekening. De aandachtige lezer zal hebben opgemerkt dat in de toevoegqueries van de jaarrekeningen van zowel onderneming M als onderneming D verscheidene posten niet werden toegevoegd aan de geconsolideerde jaarrekening. Het betreft de posten winst van het boekjaar (693000), verlies van het boekjaar (793000), handelsvorderingen (400000) en handelsschulden (44000). De investering van de moederonderneming in de dochteronderneming (post 280000 – financiële vaste activa) en het kapitaal van de dochteronderneming (100000) werden eveneens niet toegevoegd. De eenvoudigste manier om de noodzakelijke correcties op te vangen, is immers door deze posten in den beginne niet toe te voegen. De reden hiervoor is dat deze posten in de correctieboekingen sowieso moeten worden weggelaten of opnieuw moeten worden becijferd.

Correctie 1 In deze eerste correctie moet het kapitaal van de dochteronderneming worden geëlimineerd ten overstaan van de investering van de moederonderneming, het minderheidsbelang en de eventuele goodwill. Door het kapitaal van de dochteronderneming (100000) en de investering van de moederonderneming in de dochteronderneming (280000) niet meer op te nemen in de geconsolideerde jaarrekening, dringen zich slechts twee extra toevoegqueries op.

Om de goodwill te becijferen, zijn enkele tussenstappen nodig. Vooreerst wordt becijferd hoeveel de investering van de moederonderneming in de dochteronderneming (rekening 280000) bedroeg: SELECT Sum(Increment.Waarde) AS Investering FROM Resource INNER JOIN (((Event INNER JOIN Decrement ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)=280000) AND ((Increment.Economic_Unit_ID)=1) AND ((Decrement.Economic_Unit_ID)=2)); Investering 12.000,00 €

Het aandeel dat de moederonderneming heeft in het kapitaal van de dochteronderneming (60% van het kapitaal van de dochteronderneming) wordt vervolgens berekend met behulp van de Decrement, Resource – Decrement en Resource tabellen: SELECT Sum([Waarde])*0.6 AS Aandeel

BIJLAGEN

XXXII

FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)=100000) AND ((Decrement.Economic_Unit_ID)=2)); Aandeel 12000

Op basis hiervan kan de goodwill (i.e. het verschil tussen de boekwaarde van de investering van

de

moederonderneming

in

de

dochteronderneming

en

het

aandeel

van

de

moedermaatschappij in het eigen vermogen van de dochteronderneming ) worden becijferd: SELECT [Investering]-[Aandeel] AS Goodwill FROM [CONSO correctie 1 - aandeel van M in kapitaal D], [CONSO correctie 1 - investering van M]; Goodwill 0,00 €

Op analoge wijze kan het minderheidsbelang (i.e. het aandeel in het kapitaal van de dochteronderneming waarvoor de moederonderneming geen zeggenschap heeft – hier bedraagt dit bijgevolg 40% van het kapitaal van de dochteronderneming) worden berekend: SELECT Sum([Waarde])*0.4 AS Aandeel FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)=100000) AND ((Decrement.Economic_Unit_ID)=2)); Aandeel 8000

Dir resulteert finaal in: -

de toevoegquery in verband met de goodwill: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "212 000 - Goodwill" AS Rekening, [CONSO correctie 1 - berekening goodwill].Goodwill AS Debet, 0 AS Credit FROM [CONSO correctie 1 - berekening goodwill]; Rekening 212 000 - Goodwill

-

Debet

Credit

0,00 €

0

de toevoegquery in verband met het minderheidsaandeel: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Credit, Debet ) SELECT "180 000 - Minderheidsbelang" AS Rekening, [CONSO correctie 1 - minderheidsbelang van M in kapitaal D].Aandeel AS Credit, 0 AS Debet FROM [CONSO correctie 1 - minderheidsbelang van M in kapitaal D];

BIJLAGEN

XXXIII Rekening

Credit

180 000 - Minderheidsbelang

Debet 8000

0

Correctie 2 Correctie 2 stipuleert dat schulden, vorderingen, kosten en opbrengsten tussen de te consolideren ondernemingen niet mogen worden in rekening gebracht in de geconsolideerde financiële staten.  In eerste instantie moeten aldus de saldi handelsvorderingen en handelsschulden opnieuw worden becijferd, maar nu zonder rekening te houden met transacties tussen onderneming M en onderneming D. De werkwijze is geheel analoog aan de werkwijze om voor individuele jaarrekeningen deze posten te bepalen, mits enkele kleine aanpassingen. Wat betreft de handelsschulden: 1. Berekening van de totale waarde van de aankopen van ondernemingen M en D (incl. BTW), exclusief aankopen van M van D en van D van M: SELECT Sum([Increment]![Waarde]/[Aant]) AS Aankopen FROM Resource INNER JOIN (((Event INNER JOIN Decrement ON Event.Event_ID = Decrement.Event_ID) INNER JOIN (Increment INNER JOIN [CONSO correctie 3 /Aantal objectID per incrementID] ON Increment.Increment_ID = [CONSO correctie 3 /Aantal objectID per incrementID].Increment_ID) ON Event.Event_ID = Increment.Event_ID) INNER JOIN [Resource Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<700000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Decrement.Economic_Unit_ID)<>1 And (Decrement.Economic_Unit_ID)<>2) AND ((Increment.Economic_Unit_ID)=1 Or (Increment.Economic_Unit_ID)=2)) OR ((([Resource - Increment].Rekeningnummer_ID)>=200000 And ([Resource - Increment].Rekeningnummer_ID)<=280000) AND ((Increment.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Decrement.Economic_Unit_ID)<>1 And (Decrement.Economic_Unit_ID)<>2) AND ((Increment.Economic_Unit_ID)=1 Or (Increment.Economic_Unit_ID)=2));

Waarbij [Aant] staat voor: SELECT [Resource - Increment].Increment_ID, Count([Resource - Increment].Object_ID) AS Aant FROM Resource INNER JOIN (Increment INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Increment].Rekeningnummer_ID) GROUP BY [Resource - Increment].Increment_ID;

2. Berekening van de totale waarde van de creditnota’s op aankopen (incl. BTW):

BIJLAGEN

XXXIV SELECT Sum([Decrement]![Waarde]/[Aant]) AS [Aankopen CN] FROM Resource INNER JOIN ((Event INNER JOIN ((Decrement INNER JOIN [CONSO correctie 3 /Aantal objectID per decrementID] ON Decrement.Decrement_ID = [CONSO correctie 3 /Aantal objectID per decrementID].Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=600000 And ([Resource Decrement].Rekeningnummer_ID)<700000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)<>1 And (Increment.Economic_Unit_ID)<>2) AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2)) OR ((([Resource Decrement].Rekeningnummer_ID)>=200000 And ([Resource Decrement].Rekeningnummer_ID)<280000) AND ((Decrement.Datum)<=#12/31/2009#) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)<>1 And (Increment.Economic_Unit_ID)<>2) AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2));

Waarbij [Aant] staat voor: SELECT Decrement.Decrement_ID, Count([Resource - Decrement].Object_ID) AS Aant FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) GROUP BY Decrement.Decrement_ID;

3. Berekening van de totale waarde aan betalingen aan leveranciers (incl. BTW): SELECT Sum([Waarde]/[Aant]) AS Betalingen FROM (([CONSO correctie 3 /Aantal objectID per incrementID] INNER JOIN Increment ON [CONSO correctie 3 /Aantal objectID per incrementID].Increment_ID = Increment.Increment_ID) INNER JOIN ([CONSO correctie 3 /Handelsschulden betalingen decrement IDs] INNER JOIN Duality ON [CONSO correctie 3 /Handelsschulden betalingen decrement IDs].Decrement_ID = Duality.Decrement_ID) ON Increment.Increment_ID = Duality.Increment_ID) INNER JOIN [Resource - Increment] ON Increment.Increment_ID = [Resource - Increment].Increment_ID WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<700000)) OR ((([Resource Increment].Rekeningnummer_ID)>=200000 And ([Resource Increment].Rekeningnummer_ID)<=280000));

Waarbij [Decrement_ID] staat voor we decrement_ID‟s die money transfer events waren: SELECT Decrement.Decrement_ID FROM (Event INNER JOIN Decrement ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID WHERE (((Event.Type)="Money transfer") AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2) AND ((Increment.Economic_Unit_ID)<>1 And (Increment.Economic_Unit_ID)<>2));

BIJLAGEN

XXXV

4. Een selectiequery zal het finale saldo berekenen: SELECT [Aankopen]-[Betalingen]-[Aankopen CN] AS Handelsschulden FROM [CONSO correctie 3 /Handelsschulden AK], [CONSO correctie 3 /Handelsschulden CN], [CONSO correctie 3 /Handelsschulden betalingen];

(Er waren geen ontvangsten van creditnota‟s op aankopen.) 5. Uiteindelijk zal de volgende toevoegquery het saldo schrijven naar de gepaste tabel: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "440 000 - Handelsschulden" AS Rekening, 0 AS Debet, [CONSO correctie 3 handelsschulden].Handelsschulden AS Credit FROM [CONSO correctie 3 - handelsschulden] GROUP BY "440 000 - Handelsschulden", 0, [CONSO correctie 3 handelsschulden].Handelsschulden; Rekening

Debet

440 000 - Handelsschulden

Credit 0

2353,45

Wat betreft de handelsvorderingen: 1. Berekening van de totale waarde van de verkopen van ondernemingen M en D (incl. BTW), exclusief verkopen van M aan D en van D aan M: SELECT Sum([Decrement]![Waarde]/[Aant]) AS Verkopen FROM Resource INNER JOIN ((Event INNER JOIN ((Decrement INNER JOIN [CONSO correctie 3 /Aantal objectID per decrementID] ON Decrement.Decrement_ID = [CONSO correctie 3 /Aantal objectID per decrementID].Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE (((Decrement.Datum)<=#12/31/2009#) AND (([Resource Decrement].Rekeningnummer_ID)>=700000 And ([Resource Decrement].Rekeningnummer_ID)<708000) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)<>1 And (Increment.Economic_Unit_ID)<>2) AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2));

Waarbij [Aant] staat voor: SELECT Decrement.Decrement_ID, Count([Resource - Decrement].Object_ID) AS Aant FROM Resource INNER JOIN (Decrement INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource Decrement].Rekeningnummer_ID) GROUP BY Decrement.Decrement_ID;

2. Berekening van de totale waarde aan ontvangsten van klanten (incl. BTW): SELECT Sum([Waarde]/[Aant]) AS Betalingen FROM ((Decrement INNER JOIN [CONSO correctie 3 /Aantal objectID per decrementID] ON Decrement.Decrement_ID = [CONSO correctie 3 /Aantal objectID per decrementID].Decrement_ID) INNER JOIN ([CONSO correctie 3 /Handelsvorderingen betalingen increment IDs] INNER JOIN

BIJLAGEN

XXXVI Duality ON [CONSO correctie 3 /Handelsvorderingen betalingen increment IDs].Increment_ID = Duality.Increment_ID) ON Decrement.Decrement_ID = Duality.Decrement_ID) INNER JOIN [Resource - Decrement] ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID WHERE ((([Resource - Decrement].Rekeningnummer_ID)>=700000));

Waarbij [Increment_ID] staat voor we increment_ID‟s die money transfer events waren: SELECT Increment.Increment_ID FROM (Event INNER JOIN Decrement ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID WHERE (((Event.Type)="Money transfer") AND ((Increment.Economic_Unit_ID)=1 Or (Increment.Economic_Unit_ID)=2) AND ((Decrement.Economic_Unit_ID)<>1 And (Decrement.Economic_Unit_ID)<>2));

3. Een selectiequery zal het finale saldo berekenen: SELECT [Verkopen]-[Betalingen] AS Handelsvorderingen FROM [CONSO correctie 3 /Handelsvorderingen VK], [CONSO correctie 3 /Handelsvorderingen betalingen];

(Er waren geen creditnota‟s op verkopen.) 4. Uiteindelijk zal de volgende toevoegquery het saldo schrijven naar de gepaste tabel: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "400 000 - Handelsvorderingen" AS Rekening, [CONSO correctie 3 handelsvorderingen].Handelsvorderingen AS Debet, 0 AS Credit FROM [CONSO correctie 3 - handelsvorderingen] GROUP BY "400 000 - Handelsvorderingen", [CONSO correctie 3 handelsvorderingen].Handelsvorderingen, 0; Rekening 400 000 - Handelsvorderingen

Debet

Credit 0

0

 Een tweede deel van de correctie bestaat erin de opbrengsten en kosten voorvloeiend uit transacties tussen onderneming M en onderneming D te elimineren. Via een eerste toevoegquery wordt gezocht naar intragroup kosten (i.e. kosten resulterend uit transacties tussen moeder- en dochteronderneming) en deze worden in mindering gebracht in de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, -Sum([Eenheidsprijs]*[Aantal]) AS Debet, 0 AS Credit FROM Resource INNER JOIN (((Event INNER JOIN Decrement ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) INNER JOIN ([/ Rekeningnummers] INNER JOIN [Resource - Increment] ON [/ Rekeningnummers].ID = [Resource Increment].Rekeningnummer_ID) ON Increment.Increment_ID = [Resource - Increment].Increment_ID) ON (Resource.Object_ID = [Resource - Increment].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Increment].Rekeningnummer_ID) WHERE ((([Resource - Increment].Rekeningnummer_ID)>=600000 And ([Resource Increment].Rekeningnummer_ID)<700000) AND ((Increment.Datum)<=#12/31/2009#) AND

BIJLAGEN

XXXVII

((Event.Type)="Good transfer") AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2) AND ((Increment.Economic_Unit_ID)=1 Or (Increment.Economic_Unit_ID)=2)) GROUP BY [/ Rekeningnummers].Omschrijving, 0; Omschrijving

Debet

Credit


-3.500,00 €

0


-500,00 €

0


-500,00 €

0


-400,00 €

0

Via een tweede toevoegquery wordt gezocht naar intragroup opbrengsten (i.e. opbrengsten resulterend uit transacties tussen moeder- en dochteronderneming) en deze worden in mindering gebracht in de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [/ Rekeningnummers].Omschrijving, 0 AS Debet, -Sum([Eenheidsprijs]*[Aantal]) AS Credit FROM Resource INNER JOIN ((Event INNER JOIN (Decrement INNER JOIN ([/ Rekeningnummers] INNER JOIN [Resource - Decrement] ON [/ Rekeningnummers].ID = [Resource - Decrement].Rekeningnummer_ID) ON Decrement.Decrement_ID = [Resource - Decrement].Decrement_ID) ON Event.Event_ID = Decrement.Event_ID) INNER JOIN Increment ON Event.Event_ID = Increment.Event_ID) ON (Resource.Object_ID = [Resource - Decrement].Object_ID) AND (Resource.Rekeningnummer_ID = [Resource - Decrement].Rekeningnummer_ID) WHERE (((Decrement.Datum)<=#12/31/2009#) AND (([Resource Decrement].Rekeningnummer_ID)>=700000 And ([Resource - Decrement].Rekeningnummer_ID)<708000) AND ((Event.Type)="Good transfer") AND ((Increment.Economic_Unit_ID)=1 Or (Increment.Economic_Unit_ID)=2) AND ((Decrement.Economic_Unit_ID)=1 Or (Decrement.Economic_Unit_ID)=2)) GROUP BY [/ Rekeningnummers].Omschrijving, 0; Omschrijving

Debet

Credit


0

-3.500,00 €


0

-500,00 €


0

-500,00 €


0

-400,00 €

Het in rekening brengen van het tweede deel van deze tweede correctie (i.e. het elimineren van kosten en opbrengsten) is in feite een nuloperatie: logischerwijs is de correctie van de kostenrekeningen even groot als deze van de opbrengstenrekeningen (een verkoop van onderneming D aan onderneming M gaat gepaard met een aankoop van onderneming M bij onderneming D). Deze correctie mag echter niet zomaar achterwege worden gelaten, want de geconsolideerde jaarrekening wijzigt er wel degelijk door: zowel de kosten als de opbrengsten zullen lagere bedragen reflecteren (de kosten- en de opbrengstenrekeningen zijn met een bepaald bedrag gedaald).

BIJLAGEN

XXXVIII

Correctie 3 Ook de resultaatverwerking moet een kleine correctie ondergaan. Er moet duidelijk naar voor komen hoeveel de groepswinst/groepsverlies bedraagt en hoeveel het aandeel van derden in het resultaat is. Hiertoe wordt gebruik gemaakt van de hulpqueries die voor zowel onderneming M als onderneming D de winst of het verlies becijferden. Aangezien hier de posten van de resultatenrekening met betrekking tot de winst of het verlies van het boekjaar (rekeningen 693 000 en 793 000) opnieuw worden becijferd, moesten deze logischerwijs ook niet worden gekopieerd van de individuele jaarrekeningen naar de geconsolideerde jaarrekening. In geval van winst zullen deze toevoegqueries de gepaste bedragen toevoegen aan de geconsolideerde jaarrekening: Deze query becijfert de groepswinst (100% van de winst van de moederonderneming gesommeerd met 60% van de winst van de dochteronderneming) en voegt dit bedrag toe aan de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "693 000 - Groepswinst van het boekjaar" AS Rekening, Sum([// JAARREKENING M 31/12/2009 //]![Debet]+0.6*[// JAARREKENING D 31/12/2009 //]![Debet]) AS Debet, 0 AS Credit FROM [// JAARREKENING D 31/12/2009 //], [// JAARREKENING M 31/12/2009 //] WHERE ((([// JAARREKENING D 31/12/2009 //].Rekening)="693 000 - Winst van het boekjaar") AND (([// JAARREKENING M 31/12/2009 //].Rekening)="693 000 - Winst van het boekjaar")) GROUP BY "693 000 - Groepswinst van het boekjaar", 0; Rekening 693 000 - Groepswinst van het boekjaar

Debet

Credit

8884,95

0

en Deze query becijfert het aandeel van derden in het resultaat (40 % van de winst van de dochteronderneming) en voegt dit bedrag toe aan de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT "693 000 - Aandeel van derden in het resultaat" AS Rekening, 0.4*[// JAARREKENING D 31/12/2009 //]![Debet] AS Debet, 0 AS Credit FROM [// JAARREKENING D 31/12/2009 //] WHERE ((([// JAARREKENING D 31/12/2009 //].Rekening)="693 000 - Winst van het boekjaar")) GROUP BY "693 000 - Aandeel van derden in het resultaat", 0.4*[// JAARREKENING D 31/12/2009 //]![Debet], 0; Rekening 693 000 - Aandeel van derden in het resultaat

Debet

Credit 1385

0

In geval van verlies zullen deze toevoegqueries de gepaste bedragen toevoegen aan de geconsolideerde jaarrekening:

BIJLAGEN Deze

XXXIX query

becijfert

moederonderneming

het

groepsverlies

gesommeerd

met

(100% 60%

van van

het het

verlies verlies

van

de

van

de

dochteronderneming) en voegt dit bedrag toe aan de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Credit, Debet ) SELECT "793 000 - Groepsverlies van het boekjaar" AS Rekening, Sum([// JAARREKENING M 31/12/2009 //]![Credit]+0.6*[// JAARREKENING D 31/12/2009 //]![Credit]) AS Credit, 0 AS Debet FROM [// JAARREKENING D 31/12/2009 //], [// JAARREKENING M 31/12/2009 //] WHERE ((([// JAARREKENING D 31/12/2009 //].Rekening)="793 000 - Verlies van het boekjaar") AND (([// JAARREKENING M 31/12/2009 //].Rekening)="793 000 - Verlies van het boekjaar")) GROUP BY "793 000 - Groepsverlies van het boekjaar", 0;

en Deze query becijfert het aandeel van derden in het resultaat (40 % van het verlies van de dochteronderneming) en voegt dit bedrag toe aan de geconsolideerde jaarrekening: INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Credit, Debet ) SELECT "793 000 - Aandeel van derden in het resultaat" AS Rekening, Sum(0.4*[// JAARREKENING D 31/12/2009 //]![Credit]) AS Credit, 0 AS Debet FROM [// JAARREKENING D 31/12/2009 //] WHERE ((([// JAARREKENING D 31/12/2009 //].Rekening)="793 000 - Verlies van het boekjaar")) GROUP BY "793 000 - Aandeel van derden in het resultaat", 0;

Een overzicht van de volledige werkwijze met betrekking tot de correcties wordt hieronder weergegeven:

BIJLAGEN

XL

BIJLAGEN

XLI

Bijlage 11: 7-stappenmethode

De 7-stappenmethode zorgt ervoor dat jaarrekeningposten (voorkomend in de te consolideren jaarrekeningen)22 en correctieposten (voortvloeiend uit fase 2 van de consolidatie) samengevoegd worden, zodat in de finale geconsolideerde jaarrekening enkel en alleen saldi voorkomen (en geen twee bedragen per jaarrekeningpost). -

Stap 1: Via een selectiequery wordt gezocht naar die jaarrekeningposten die meermaals voorkomen in de geconsolideerde jaarrekening. Dit impliceert dat deze posten zowel in de jaarrekening van M als deze van D voorkomen: zowel onderneming M als onderneming D hebben in de REA database deze resources aangewend. Zo hebben beide ondernemingen via decrement en increment events de rekening 550000 (kredietinstellingen) aangewend, en is het dus niet onlogisch dat bij beide ondernemingen een saldo op deze rekening aanwezig is. Deze stap gebeurt automatisch. SELECT First([// JAARREKENING CONSOLIDATIE 31/12/2009 //].[Rekening]) AS [Rekening Veld], Count([// JAARREKENING CONSOLIDATIE 31/12/2009 //].[Rekening]) AS AantalDuplicaten FROM [// JAARREKENING CONSOLIDATIE 31/12/2009 //] GROUP BY [// JAARREKENING CONSOLIDATIE 31/12/2009 //].[Rekening] HAVING (((Count([// JAARREKENING CONSOLIDATIE 31/12/2009 //].[Rekening]))>1));

Het resultaat: Rekening Veld

-

22

AantalDuplicaten


2


2


2


2


2


2


2


2


2


2


2

Stap 2: Voor elke rekening wordt het totale debetbedrag berekend:

Indien bijvoorbeeld zowel onderneming M als onderneming D bureelbenodigdheden hadden aangekocht, werd dit geregistreerd

via de tabellen Increment, Resource – Increment en Resource. In de geconsolideerde jaarrekening mag deze post slechts eenmaal voorkomen. Het komt er in se op neer om – niet expliciet – de twee transacties (van onderneming M en onderneming D) samen te voegen in de REA database.

BIJLAGEN

XLII SELECT [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening, Sum([// JAARREKENING CONSOLIDATIE 31/12/2009 //].Debet) AS [Som debet] FROM [// JAARREKENING CONSOLIDATIE 31/12/2009 //] INNER JOIN [FASE 3 /stap 1 Duplicaten zoeken CONSO] ON [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening = [FASE 3 /stap 1 Duplicaten zoeken CONSO].[Rekening Veld] GROUP BY [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening; Rekening

Som debet

140 000 - Winst van het huidige boekjaar 411 000 - Terug te vorderen BTW 550 000 - Kredietinstellingen

0,00 € 1.371,88 € 32.448,82 €


0,00 €


0,00 €


0,00 €


-

475,00 €


0,00 €


0,00 €


0,00 €


0,00 €

Stap 3: Voor elke rekening wordt het totale creditbedrag berekend: SELECT [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening, Sum([// JAARREKENING CONSOLIDATIE 31/12/2009 //].Credit) AS [Som credit] FROM [// JAARREKENING CONSOLIDATIE 31/12/2009 //] INNER JOIN [FASE 3 /stap 1 Duplicaten zoeken CONSO] ON [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening=[FASE 3 /stap 1 Duplicaten zoeken CONSO].[Rekening Veld] GROUP BY [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening; Rekening 140 000 - Winst van het huidige boekjaar

-

Som credit 10.269,95 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €


0,00 €

Stap 4: In de vierde stap wordt een afzonderlijke tabel („FASE 3 /stap 4 Tabel saldi dubbele records CONSO‟) gecreëerd. In deze tabel zullen de saldi tijdelijk worden opgeslagen.

BIJLAGEN -

XLIII

Stap 5: De saldo‟s van de dubbele records worden becijferd (aan de hand van het feit of het debetbedrag groter is dan het creditbedrag of vice versa) en toegevoegd aan de afzonderlijke tabel uit stap 4. INSERT INTO [FASE 3 / stap 4 Saldi dubbele records CONSO] ( Rekening, Debet, Credit ) SELECT [FASE 3 /stap 1 Duplicaten zoeken CONSO].[Rekening Veld], IIf([Som debet]>=[Som credit],[Som debet]-[Som credit],0) AS Debet, IIf([Som debet]<[Som credit],[Som credit]-[Som debet],0) AS Credit FROM [FASE 3 /stap 3 Duplicaten som credit] INNER JOIN ([FASE 3 /stap 2 Duplicaten som debet] INNER JOIN [FASE 3 /stap 1 Duplicaten zoeken CONSO] ON [FASE 3 /stap 2 Duplicaten som debet].Rekening = [FASE 3 /stap 1 Duplicaten zoeken CONSO].[Rekening Veld]) ON [FASE 3 /stap 3 Duplicaten som credit].Rekening = [FASE 3 /stap 1 Duplicaten zoeken CONSO].[Rekening Veld]; Rekening Veld

Debet


0,00 €

10.269,95 €

1.371,88 €

0,00 €

32.448,82 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €

475,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €

411 000 - Terug te vorderen BTW 550 000 - Kredietinstellingen


-

Credit

Stap 6: Via een verwijderquery worden de jaarrekeningposten die twee maal voorkwamen in de geconsolideerde jaarrekening verwijderd uit deze geconsolideerde jaarrekening (om in stap 7 terug te worden toegevoegd, zij het dan alleen met de saldi). DELETE [// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening, * FROM [// JAARREKENING CONSOLIDATIE 31/12/2009 //] WHERE ((([// JAARREKENING CONSOLIDATIE 31/12/2009 //].Rekening) In (SELECT [Rekening Veld] FROM [FASE 3 /stap 1 Duplicaten zoeken CONSO])));

Uit de tabel met de geconsolideerde jaarrekening worden volgende rijen verwijderd: Rekening 140 000 - Winst van het huidige boekjaar

Debet

Credit

0,00 €

3.462,50 €

1.281,00 €

0,00 €

12.135,00 €

0,00 €


0,00 €

3.500,00 €


0,00 €

500,00 €


0,00 €

500,00 €


0,00 €

400,00 €


0,00 €

6.807,45 €


BIJLAGEN

XLIV


90,88 €

0,00 €

20.313,82 €

0,00 €


3.500,00 €

0,00 €


500,00 €

0,00 €


500,00 €

0,00 €


875,00 €

0,00 €


-3.500,00 €

0,00 €


-500,00 €

0,00 €


-500,00 €

0,00 €


-400,00 €

0,00 €


0,00 €

-3.500,00 €


0,00 €

-500,00 €


0,00 €

-500,00 €


0,00 €

-400,00 €


-

Stap 7: In een laatste stap worden de becijferde saldi van de dubbele records (die via stap 5 in een afzonderlijke tabel waren opgenomen) opnieuw toegevoegd aan de geconsolideerde jaarrekening. INSERT INTO [// JAARREKENING CONSOLIDATIE 31/12/2009 //] ( Rekening, Debet, Credit ) SELECT [FASE 3 / stap 4 Saldi dubbele records CONSO].Rekening, [FASE 3 / stap 4 Saldi dubbele records CONSO].Debet, [FASE 3 / stap 4 Saldi dubbele records CONSO].Credit FROM [FASE 3 / stap 4 Saldi dubbele records CONSO]; Rekening 140 000 - Winst van het huidige boekjaar

Debet

Credit

0,00 €

10.269,95 €

1.371,88 €

0,00 €

32.448,82 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €

475,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €



BIJLAGEN

XLV

Bijlage 12: Output tweede onderzoeksvraag

GECONSOLIDEERDE JAARREKENING 31/12/2009 Rekening

Debet

Credit


0,00 €

20.000,00 €


0,00 €

10.269,95 €


0,00 €

10.000,00 €

180 000 - Minderheidsbelang

0,00 €

8.000,00 €

1.387,75 €

0,00 €

0,00 €

277,55 €

200 000 - Kosten van oprichting en kapitaalverhoging 200 009 - Geboekte afschrijvingen op oprichtingskosten (-) 212 000 - Goodwill

0,00 €

0,00 €

7.500,00 €

0,00 €

0,00 €

187,50 €

1.470,00 €

0,00 €

0,00 €

490,00 €

2.250,00 €

0,00 €

900,00 €

0,00 €

330 000 - Gereed product

2.000,00 €

0,00 €

340 000 - Handelsgoederen

2.650,00 €

0,00 €

349 000 - Handelsgoederen: geboekte waardeverminderingen (-)

0,00 €

400,00 €

400 000 - Handelsvorderingen

0,00 €

0,00 €

221 000 - Gebouwen 221 009 - Geboekte afschrijvingen op gebouwen (-) 231 000 - Machines 231 009 - Geboekte afschrijvingen op machines (-) 300 000 - Grondstoffen 310 000 - Hulpstoffen


1.371,88 €

0,00 €

0,00 €

2.353,45 €

32.448,82 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


475,00 €

0,00 €


2.500,00 €

0,00 €


250,00 €

0,00 €


250,00 €

0,00 €


500,00 €

0,00 €


0,00 €

2.250,00 €


0,00 €

900,00 €


0,00 €

2.650,00 €


277,55 €

0,00 €

440 000 - Handelsschulden 550 000 - Kredietinstellingen


Pagina 1 van 2

BIJLAGEN

Rekening

XLVI

Debet

Credit


187,50 €

0,00 €


490,00 €

0,00 €


400,00 €

0,00 €


200,00 €

0,00 €

693 000 - Aandeel van derden in het resultaat

1.385,00 €

0,00 €

693 000 - Groepswinst van het boekjaar

8.884,95 €

0,00 €


0,00 €

8.000,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

0,00 €


0,00 €

2.000,00 €

67.778,45 €

67.778,45 € IN BALANS


Pagina 2 van 2

ONTWIKKELING VAN EEN ACCURAAT, WAARHEIDSGETROUW EN FLEXIBEL REA ACCOUNTING INFORMATIESYSTEEM

Recommend Documents