Zusammenfassung
IFAS ist eine prototypisch realisierte, integrierte Entwicklungs- und Anwendungsumgebung für Finanzanalysesysteme. IFAS befreit den Entwickler eines Finanzanalysesystems weitgehend von den nicht betriebswirtschaftlichen Aspekten der Anwendungsentwicklung, z.B. dem Entwurf der Benutzungsoberfläche und der Datenmodellierung, ohne den Anwender zu zwingen, auf eine einheitlich zu bedienende, intuitive grafische Benutzungsoberfläche und das Sicherheitsniveau, das erreichbar ist, wenn die Datenbankzugriffe durch ein leistungsfähiges Datenbankmanagementsystem gesteuert werden, zu verzichten.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Die folgenden Abschnitte sind aus einer Überarbeitung und Erweiterung von [Schn96] und [Schn94a] hervorgegangen.
Die Systeme KALEM und FES wurden in den Jahren 1992–1994 am Lehrstuhl für Betriebswirtschaftslehre mit Schwerpunkt Wirtschaftsinformatik an der Justus-Liebig-Universität Gießen entwickelt. KALEM ist ein Finanzanalysesystem zur Unterstützung von KAuf/Leasing-Entscheidungen für Mobilien (vgl. [Schn92]). FES (Financial Engineering System) ist ein Entscheidungsun-terstützungssystem, das den Anwender sowohl bei der Erstellung und Analyse von Leasingangeboten unterstützt (siehe S. 14 und [WeDe94]). KALEM wurde 1993 mit dem Deutsch-Österreichischen Hochschul-Software-Preis ausgezeichnet.
Vgl. [MuMe94], S. 4 und [Brun79], S. 1099.
Dieser Ansatz wurde für ein typspezifisches Finanzanalysesystem in [Schn92] entwickelt.
Eine unterjährige Betrachtungsweise ist z.B. notwendig, wenn die Gefahr von Liquiditätsengpässen besteht, so daß eine genaue Finanzplanung erforderlich ist, oder die Ersetzung der pro rata temporis Abschreibung durch die Halbjahresvereinfachungsregel des Abschnitts 44 EStR Entscheidungsrelevanz besitzt. Siehe auch Abschnitt 3.1.1.
Die Implementation des Prototyps basiert auf einer Periodenlänge von einem Monat. Dies ist jedoch keine einschränkende Voraussetzung, sondern konzeptionell ist jede Periodenlänge denkbar, für die 1 Jahr ein ganzzahliges Vielfaches ist. Für ein kommerzielles Produkt wäre die Periodenlänge auch konfigurierbar zu implementieren.
stellung des Jahresabschlusses. Für diese Aufgabe wurde das Berufsbild des Bilanzbuchhalters geschaffen. Die Berufsbezeichnung „Bilanzbuchhalter“ setzt eine mehrjährige Berufspraxis in der Finanzbuchhaltung und eine Zusatzausbildung bei der Industrie-und Handelskammer voraus.
Zu den Erfolgswirkungen zählen auch die Substanz-und Verkehrsteuerzahlungen. Streng genommen paßt die Metapher des Finanzbuchhalters nicht ganz, da die Erfolgswirkungen in der Finanzbuchhaltung auf der Basis handelsrechtlicher Erträge und Aufwendungen ermittelt werden. Für eine Finanzanalyse mit korrekter Berücksichtigung von Steuerwirkungen ist aber die Ermittlung der Erfolgswirkungen auf Basis steuerlicher Betriebseinnahmen und -ausgaben relevant. Aufgrund des Maßgeblichkeitsprinzips fällt dieser Unterschied aber nicht so stark ins Gewicht, daß eine Verwendung dieser anschaulichen Metapher nicht mehr sinnvoll wäre.
Als Alternative bezeichnen wir ein zulässiges Aktionsprogramm Vgl. Abschnitt 1.1.2.
Aus diesen Gründen basiert auch die Datenhaltungskomponente von IFAS auf dem relationalen Datenmodell.
Wenn z.B. als Periodenlänge ein Jahr bestimmt ist, entspricht eine Periode einem Kalenderjahr. Wenn als Periodenlänge ein Monat bestimmt ist, dann entspricht eine Periode einem Kalendermonat, usw.
In den meisten Fällen wird der Zeitpunkt eines Jahresabschlusses auf das Ende eines Kalenderjahres fallen. Es können aber auch vom Kalenderjahr abweichende Wirtschaftsjahre abgebildet werden.
Zum Vergleich mit der betriebswirtschaftlichen Begriffsbelegung siehe z.B. [Eise93] und [Koch89].
Nur Buchungen mit einem Betrag ungleich Null sind ökonomisch sinnvoll.
Wenn ein Konto als T-Konto geführt wird, ist eine Sollbuchung demnach eine Buchung auf der Aktiv-Seite und eine Habenbuchung eine Buchung auf der Passiv-Seite des Kontos. Beim Blick auf die Kontoauszüge, die eine Bank einem Kunden ausstellt, erscheint dies zunächst verwirrend, da ein Guthaben des Kunden dort im Haben und eine Verbindlichkeit des Kunden im Soll erscheint. Dieser scheinbare Widerspruch löst sich jedoch auf, wenn berücksichtigt wird, daß Kontoauszüge die Sicht der Bank wiedergeben: Guthaben des Kunden sind aus Sicht der Bank Verbindlichkeiten, die auf der Passiv-Seite, d.h. im Haben ausgewiesen werden. Verbindlichkeiten des Kunden sind aus Sicht der Bank Forderungen, die auf der Aktiv-Seite, d.h. im Soll ausgewiesen werden.
DieserBegriff ist angelehnt an [Gera93].
Diese Darstellung erhalten wir durch einen natural join über das Attribut „Zeitpunkt“. Zum natural join vgl. z.B. [ScSt83], S. 140.
Die Annahme der Sicherheit kann möglicherweise bei einer Weiterentwicklung dieses Ansatzes aufgegeben werden.
Diese Annahme ist für die Vergleichbarkeit mehrerer Alternativen erforderlich.
Aufgrund der zu erwartenden Vorteile wird die Konzeption problemspezifischer Entwicklungsumgebungen auch in anderen Anwendungsgebieten als bedeutsam für die Softwareentwicklung angesehen. Vgl. dazu [Nag193].
Vgl. Abschnitt 1.1.4.
In Abbildung 4.2 sind die vom Entwickler zu erstellenden typspezifischen Planungsmodelle und Methoden schattiert und die unveränderlichen Systembestandteile fett umrandet dargestellt. Die Editoren für die Planungsmodelle und Methoden sind aus Gründen der Übersichtlichkeit nicht explizit dargestellt. Die Pfeile geben den Informationsfluß in IFAS wieder. Vgl. auch Abbildung 1.4.
Siehe Abschnitt 4.1.1.
Dieses ist Gegenstand des folgenden Abschnitts 4.2.2.
Der hier verfolgte Shell-Ansatz darf nicht mit der Idee der „Componentware“ verwechselt werden. Bei Componentware werden beliebige Anwendungssysteme aus einfachen, vorgefertigten Bausteinen — den Komponenten — zusammengesetzt.
Vgl. Abschnitt 1.1.4.
Siehe Seite 78.
Derzeit sind dies Rexx - als einfach zu erlernende Endbenutzersprache - und alle Sprachen, die Funktionen aus Dynamic Link Libraries (DLL), die in C erstellt sind, aufrufen können.
Die Integration von Methoden in IFAS wird in Abschnitt 4.2.4 ausführlich dargestellt.
Siehe Abschnitt 4.1.1.
In der Implementation des Prototyps entstehen die kontenorientierten Datenmodelle durch Erweiterung eines vorgegebenen, unveränderlichen Grundgerüsts. Dies sichert die Korrektheit der zwischen den erforderlichen Konten bestehenden Abschlußbeziehungen. Die Kontenbezeichner sind innerhalb dieses Grundgerüsts nicht änderbar. Diese Beschränkung kann aber durch eine flexiblere Lösung - so, wie für die Methoden realisiert - vermieden werden.
Gewerbesteuerliche Hinzurechnungen und Kürzungen werden mit speziellen KDL-Befehlen in einem Planungsmodell abgebildet (vgl. Abschnitt 4.2.3.2.3). Zur Gewerbeertragsteuer vgl. Abschnitt 2.2.1.2.1.
Siehe Abschnitt 3.2.3. Ausführlich dazu auch [Humm95].
[Loud94], S. 3. Unter Berechnung wird dabei von [Loud94], S. 4, ein Prozeß verstanden, der von einem Computer ausgeführt werden kann. Dieses Begriffsverständnis umfaßt nicht nur mathematische Berechungen, sondern alle Arten von Datenmanipulation, z.B. auch die Verwaltung von Datenbeständen, Text-und Bildverarbeitung, etc.
Siehe dazu [Loud94], S. 22 f.
Einen Überblick über formale Beschreibungsverfahren von Semantik gibt [Sebe93], S. 115 ff.
Siehe dazu [Loud94], S. 83 ff. und [Sebe93], S. 95 ff. 49 Beispiel nach [Debo95], S. 15.
Vgl. z.B. [AhSe94], S. 7.
Vgl. [Loud94], S. 90.
Dies ist z.B. für die Beschreibung der unterschiedlichen Priorität arithmetischer Operatoren bedeutsam. Siehe dazu [Loud94], 5. 92 ff. und [AhSe94], S. 205 ff.
Siehe dazu den Beitrag von [Klae94] über den Einfluß der Programmiersprache auf die Stabilität von Anwendungssystemen. Das Thema Software-Qualität ist auch mehr als 25 Jahre nach der Erkenntnis, daß die Entwicklung von Anwendungssystemen eine ingenieurmäßige Tätigkeit ist, aktuell. Schon die Messung von Software-Qualität ist noch Gegenstand wissenschaftlicher Forschung (siehe z.B. [HeHa97] und [SnRo96]). In jüngerer Zeit — auch vor dem Hintergrund der ISO 9000 ff. Normen — rückt verstärkt das Qualitätsmanagement in den Mittelpunkt des Interesses (siehe z.B. [BeSt96] und [Wa1196]).
Z.B. bei [Meye90], S. 2 ff. und [Klae94], S. 23.
Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit.
Diese Darstellung beruht auf [Sebe93], S. 7 ff., [Meye90], S. 1 ff. und [Loud94], S. 59 ff.
Als Beispiel dafür nennt [Sebe93], S. 11 die Programmiersprache ALGOL68.
Z.B. werden in FORTRAN alle Variablen deren Bezeichner mit ‘I’, ‘J’, ‘K’, ’L’, ’M’ oder ’N’ beginnen als INTEGER Variablen behandelt. In vielen BASIC-Dialekten werden Variablen, deren Bezeichner mit dem Zeichen ’$’ enden, implizit als Zeichenkette (String) deklariert.
Vgl. dazu [Sebe93], S. 145 und [Loud94], S. 131 ff.
Ein verbreitetes Beispiel dafür ist die Programmiersprache C.
Wegen der dabei entstehenden Parsebäume bezeichnen [AhSe94], S. 6, die Syntaxanalyse auch als hierarchische Analyse.
Die Assoziation eines Attributes zu einem Namen wird als „binden“ bezeichnet. Die Darstellung in Abbildung 4.6 ist insoweit eine starke Vereinfachung der Zusammenhänge, da i.d.R. nur ein Teil der Attribute zur Übersetzungszeit gebunden wird. Ein Teil der Bindeprozesse läuft dagegen üblicherweise erst nach der Übersetzung zur Binde-, Lade-oder Laufzeit des Programms ab. Der letzte Fall wird als dynamische Bindung, die anderen Fälle werden als statische Bindung des Programms bezeichnet. Zu den Grundlagen der Semantik und des Bindens siehe ausführlich [Loud94], S. 125 ff.
Aus diesem Grund wurden z.B. auch Interpreter für die Programmiersprache C entwickelt, obwohl Übersetzer für diese Sprache i.d.R. als Compiler realisiert werden (vgl. [Schi88], S. 8).
In [Schn94a] wurde hierfür der Terminus „Geschäftsprozeß“ verwendet. Dieser ist jedoch in der Wirtschaftsinformatik bereits anderweitig — mit einer starken Betonung ablauforganisatorischer Aspekte — belegt. Vgl. dazu [FeSi93] und [ScFi96].
Eine vollständige Syntaxbeschreibung enthält Anhang A.
Viele Programmiersprachen besitzen zusätzlich aggregierte Datentypen, z.B. Fel-der und Strukturen. Solche Variablen können mehr als einen Wert enthalten.
Vgl. 2.4.
Die KDL unterscheidet nicht zwischen Groß-und Kleinschreibung. Um die Lesbarkeit der Beispiele zu verbessern, schreiben wir aber Schlüsselworte und Kontenbezeichner in Großbuchstaben.
Auch die Transaktionskette start () kann an beliebiger Stelle innerhalb des Quellprogramms definiert werden.
Z.B. setzt eine Transaktionskette „Gebaeudeverkauf“ mindestens die Buchungen für die Beschaffung des zu verkaufenden Gebäudes voraus. Vgl. dazu auch das Beispiel in Anhang B.
Vgl. [Kurb90], S. 92.
Alternative Übergabemechanismen sind z.B. „call by reference“ und „call by name”. Diese Mechanismen konfligieren jedoch mit wichtigen Entwurfskriterien, z.B. Modularität und Einfachheit, und sind daher für die KDL ungeeignet. Eine ausführliche Darstellung verschiedener Übergabemechanismen findet sich bei [Loud94], S. 265 ff.
Eine Transaktionskette entspricht somit in gewisser Weise den Prozeduren in der Programmiersprache PASCAL.
Vgl. Abschnitt 4.2.5.
Siehe Abschnitt 4.2.3.2.1.
Bei der Bildung arithmetischer Ausdrücke folgt die KDL den mathematischen Prioritätsregeln. Die genaue Syntax kann in Anhang A nachgelesen werden.
Siehe S. 93.
Die obige Version der saldo-Funktion ist eine konzeptionelle Erweiterung des derzeit implementierten Sprachschatzes. Im aktuellen Release des KDL-Interpreters wird lediglich die Selektion aller Buchungen zwischen dem Beginn der Planungsrechnung und einem beliebigen Zeitpunkt unterstützt.
Zur Steuerung des Kontrollflusses vgl. ausführlich [Loud94], S. 241 ff.
Dies entspricht der Vorgehensweise der weit verbreiteten Programmiersprache C.
Z.B. die Programmiersprachen PASCAL und C.
Vgl. [Loud94], S. 244.
Vgl. Abschnitt 2.2.1.2.2.
In der aktuellen Implementation setzt der KDL-Interpreter für Quellprogrammdateien die Dateinamenserweiterung „KDL“ voraus, d.h. der vollständige Dateiname des referenzierten Quellprogramms ist „AFA.KDL”. Die Dateinamenserweiterung darf beim Aufruf von Transaktionsketten nicht mit angegeben werden.
Wenn das Wirtschaftsjahr dem Kalenderjahr entspricht, entspricht der Startmonat einem Kalendermonat. Dann kann z.B. der Startmonat „10“ direkt als Kalendermonat „Oktober” interpretiert werden. Bei Abweichungen zwischen Wirtschafts-und Kalenderjahr ist für diese Interpretation eine entsprechende Umrechnung erforderlich.
Die aktuelle Version des KDL-Interpreters unterstützt die lineare, die degressive und die degressiv-lineare Abschreibung für Mobilien nach §7 EStG — jeweils pro rata temporis und mit Halbjahres-Vereinfachungsregel nach Abschnitt 44 EStR. Andere Abschreibungsmethoden, z.B. für Immobilien, können durch Transaktionsketten wiederverwendbar beschrieben werden. Ein Beispiel hierfür enthält Anhang B.
Die algorithmische Lösung derartiger Aufgaben ist gerade für Nicht-Programmierer nicht trivial. Wenn dabei Probleme auftreten, ist dies häufig an „Kalenderjahren“ mit 11 oder 13 Monaten erkennbar.
Zu den Grundlagen der Statistik, insbesondere der Zeitreihenanalyse, vgl. ausführlich [BaBa87] und [RiIc86].
Technisch entspricht ein Bewertungsschema damit einem Stapelverarbeitungsauftrag.
Vgl. Abbildung 4.2.
Mit demselben Mechanismus kann prinzipiell auch die Implementation der Transaktionsketten von den kontenorientierten Datenmodellen getrennt werden. Bei einer solchen Designentscheidung muß jedoch der tradeoff zwischen Flexibiblität und Konsistenz beachtet werden. Die Transaktionsketten sind deshalb zugunsten konsistenter Kontenbezeichner fest an bestimmte kontenorientierte Datenmodelle gebunden.
Da ein API stark von der jeweiligen Programmiersprache geprägt wird, stellen wir an dieser Stelle nur die grundsätzlichen Konzepte vor. Eine genaue Beschreibung des API und ein Anwendungsbeispiel befindet sich in Anhang C. Das hier vorgestellte API ist eine noch nicht implementierte Überarbeitung der aktuell verfügbaren Version. Die aktuelle Version enthält eine zur oben dargestellten Funktion SALDO äquivalente Funktion STROM. Die aktuelle Funktion SALDO dient lediglich zur Ermittlung von Bestandsgrößen und wird zur Erhöhung der Orthogonalität ersatzlos gestrichen.
Vgl. S. 115.
Das KDL-Programm für den zugrundeliegenden Alternativentyp „Leasing mit forfaitierter Einmalzahlung aus Leasinggebersicht“ befindet sich in Anhang B. Zu den betriebswirtschaftlichen Grundlagen vgl. Abschnitt 2.4.
Monolithische Systeme werden oftmals im Zuge ihrer Wartung und Pflege zunehmend komplexer. Dies führt zu einem starken Anstieg der Wartungs-und Pflegekosten (vgl. [ScSc94], S. 548). Die nachträgliche Modularisierung ist des- halb eine wichtige Aufgabe bei der Sanierung von Anwendungssystemen. Zur Sanierung von Programmen vgl. ausführlich [StDr95].
So z.B. [ScSc94] und [Meye93].
Ein Prozeß ist ein in Ausführung befindliches Programm.
Dabei stellt der Serverprozeß Dienste bereit, die von einem oder mehreren Clientprozessen in Anspruch genommen werden können (vgl. z.B. [Thie95], S. 5 ff.). Die Kommunikation zwischen den Prozessen erfolgt nachrichtenbasiert über definierte Schnittstellen (wenn die Schnittstellendefinition herstellerunabhängig standardisiert ist, werden solche Systeme als offene Systeme bezeichnet), wobei die Serverprozesse passiv auf die Leistungsanforderungen der Clientprozesse warten.
Eine Einführung in die Konzepte der verteilten Künstlichen Intelligenz gibt [Mue194]. Zur Realisierung verteilter Problemlösungsprozesse vgl. auch [Roem97], S. 271 ff.
Die Bereitstellung von Finanzanalysesystemen auf elektronischen Märkten ist Gegenstand des Kapitels 5.
Vgl. Seite 86.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1999 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Schneider, J. (1999). Das Integrierte Finanzanalysesystem IFAS. In: Finanzanalysen in der Investitions- und Finanzierungsberatung. Information Age Economy. Physica, Heidelberg. https://doi.org/10.1007/978-3-662-01605-3_4
Download citation
DOI: https://doi.org/10.1007/978-3-662-01605-3_4
Publisher Name: Physica, Heidelberg
Print ISBN: 978-3-7908-1169-8
Online ISBN: 978-3-662-01605-3
eBook Packages: Springer Book Archive