EDV-System zur dynamischen Abbildung von Kunden-Lieferanten-Beziehungen


Diplomarbeit, 1998

113 Seiten, Note: 1.3


Leseprobe


Inhalt

1 Aufgabenstellung und Zielsetzung

2 Strukturierungsansätze kommerzieller PPS-Systeme
2.1 Die Standardsoftware SAPÒ R/3Ò
2.1.1 Beziehung zwischen den organisatorischen Einheiten
2.1.2 Abbildung und Aufgaben des Materialstamms
2.2 Realisierung von Kunden-Lieferanten-Beziehungen in SAPÒ R/3Ò
2.2.1 Umlagerung von Werk zu Werk
2.2.2 Entnahme in einem anderen Werk
2.2.3 Produktion in einem anderen Werk
2.3 Fazit

3 Konzeption der Stammdaten in Kunden-Lieferanten-Sicht
3.1 Anforderungsspezifikation
3.2 Der Klassenentwurf
3.2.1 Bäume
3.2.1.1 Terminologie
3.2.1.2 Darstellung von allgemeinen Bäumen
3.2.2 Baumstrukturen in Unternehmen
3.2.3 Oberklassen
3.2.3.1 Datenbank-Schnittstelle
3.2.3.2 Baum-Oberklasse
3.2.3.3 Ansichts-Oberklasse
3.2.3.4 Zusammenfassung
3.2.4 Allgemeine Klassen
3.2.4.1 Einheiten
3.2.4.2 Zahlungsmittel und Währung
3.2.5 Kunden-Lieferanten-Modul
3.2.5.1 Bedeutung von Produktdefinitionen in Kunden-Lieferanten-Modulen
3.2.6 Puffer und Bestand
3.2.7 Arbeitsstation, Produktionsmittel und Person
3.2.8 Kostenstelle
3.2.9 Produkt
3.2.9.1 Vorprodukt
3.2.9.2 Fertigprodukt
3.3 Datenhaltung

4 Konzeption der Abläufe für die Unternehmensumstrukturierung
4.1 Ein Beispielunternehmen
4.2 Fall (a): Kunden-Lieferanten-Module verschieben
4.2.1 Verwalten der Kunden-Lieferanten-Beziehungen
4.3 Fall (b): Module verschachteln
4.4 Fall (c): Verschachtelte Module auflösen
4.5 Fall (d): Übergeordnete Organisationseinheiten einfügen
4.6 Fall (e): Aufgaben eines zu löschenden KLM übernehmen
4.7 Fall (f): Arbeitsstationen neu organisieren
4.7.1 Arbeitsstationen auf einer Hierarchieebene verschieben
4.7.2 Arbeitsstationen über mehrere Hierarchieebenen verschieben
4.8 Fall (g): Aufgaben eines Moduls auf neue Module verteilen
4.9 Fall (h): Ein Modul wird übergeordnete Organisationseinheit

5 Konzeption der Bewegungsdaten und der Produktionsplanungsfunktionalität
5.1 Bestellungen
5.2 Planaufträge und Herstellaufträge
5.3 Produktionsprogramm
5.3.1 Aufgaben und funktionaler Ablauf
5.4 Bedarfsplanung
5.4.1 Ermittlung des Nettoprimärbedarfs
5.4.2 Stücklistenauflösung
5.4.2.1 Systemaufgaben und funktionale Zusammenhänge
5.4.3 Brutto-Netto-Rechnung und Quotierung
5.4.4 Losgrößenverfahren
5.4.5 Planaufträge generieren
5.4.6 Bestellvorschläge generieren
5.4.7 Auftragseröffnung bis zur Auftragsfreigabe
5.5 Bewegungsdaten in dynamischen Unternehmensstrukturen
5.6 Zusammenfassung

6 Konzeption der Benutzeroberfläche und - führung
6.1 Globale Sicht auf das Unternehmen
6.2 Sichten auf Unternehmensressourcen
6.3 Erzeugen und Verwalten der Unternehmensressourcen
6.4 Unternehmensstrukturen verändern

7 Realisierung
7.1 Die Entwicklungsumgebung
7.1.1 Das Dokument-Ansicht-Konzept
7.1.2 Realisierung
7.2 Die persistente Datenhaltung
7.2.1 Persistente Klassen und der PTXX Schema-Compiler
7.2.2 Dictionary und Datenbank
7.2.3 Realisierung
7.3 Die Benutzeroberfläche
7.3.1 Die Microsoft Foundation Class Library (MFC)
7.3.2 Realisierung
7.3.2.1 Rahmenfenster
7.3.2.2 Die Unternehmensansicht in Baumstruktur
7.3.2.3 Die grafischen Unternehmens- und Ressourcenansichten
7.3.2.4 Kontextsensitive Menüs
7.3.2.5 Dialoge und Referenzierung
7.4 Prototyp und Präsentationssoftware

8 Zusammenfassung und Ausblick

Literaturverzeichnis

Stichwortverzeichnis

1 Aufgabenstellung und Zielsetzung

Ein Konzept, das bei der Organisation von Unternehmen immer häufiger zum Einsatz kommt, ist das Lean Production Konzept. Lean Production ist ein Führungskonzept, das in der Produktion und Organisation des Unternehmens umgesetzt wird. Ein Arbeitsprinzip dieses Konzepts, ist die Bildung von Arbeitsgruppen [Bösenberg1992]: Es werden Arbeitsgruppen mit einem internen Kunden-Lieferanten-Verhältnis gegenüber den anderen Arbeitsgruppen gebildet. Jede Arbeitsgruppe und jedes Mitglied der Arbeitsgruppe ist für die Qualität des Produktionsergebnisses unmittelbar verantwortlich. Dadurch entstehen in der Produktion kleine, beherrschbare Schritte. Die Komplexität wird in organisatorischer Hinsicht aufgelöst. Zwischen den einzelnen Produktionsstätten entsteht ein ständiges Feedback und damit verbunden eine hohe Motivation.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 . 1 : Das Prinzip des internen Kunden beim Lean Management

Es existiert zwar eine Vielzahl an Produktionsplanungs- und -steuerungssystemen (PPS-Systeme), mit zum Teil weitreichender Funktionalität auf dem Markt, aber bei der Abbildung dieser Unternehmensanforderungen stoßen diese Systeme an ihre Grenzen.Heute eingesetzte PPS-Systeme sind als zentrale Planungs- und Steuerungswerkzeuge realisiert, d.h. sie stehen in den Durchführungsbereichen nicht zur Verfügung. Hierdurch entsteht das Problem, daß Entscheidungen losgelöst vom Geschehen in der Produktion getroffen werden, da oftmals Teile der Verantwortung dezentral, in den Durchführungsbereichen liegen [KIE1991].

Ein weiterer Mangel ergibt sich aus den sich ändernden Anforderungen an ein Unternehmen und damit an sich ändernde Unternehmensstrukturen. Derzeitige Systeme weisen eine eingeschränkte Flexibilität bezüglich der Abbildung und Änderung organisatorischer Strukturen auf. Sollen veränderte Unternehmens­strukturen im System abgebildet werden, so ist dies nur mit erheblichem Aufwand möglich [KIE1991].

Eine dezentrale, hierarchische Strukturierung von Systemen zur Produktionsplanung- und -regelung vereinfacht es, solche strukturellen und funktionalen Änderungen an den Systemen vorzunehmen [KIE1991]. Hierbei steht die Abbildung von strikten Kunden-Lieferanten-Beziehungen zwischen den Unternehmenseinheiten im Vordergrund.

Das Ziel dieser Arbeit ist die Konzeption eines Systems, mit dem die oben beschriebenen Anforderungen an ein Unternehmen abgebildet werden können. Dies ist im einzelnen der Entwurf eines dynamischen, hierarchischen Unternehmensmodels sowie die Bildung strikter Kunden-Lieferanten-Beziehungen zwischen den Unternehmenseinheiten. Desweiteren soll ein Ausschnitt der Produktionsplanungsfunktionalität, für das entworfene Datenmodell, exemplarisch entwickelt werden.

Zum Nachweis der Machbarkeit der Abbildung von dynamischen Unternehmenshierarchien, ist die Entwicklung eines Prototyps eine weitere Aufgabe dieser Arbeit.

Da die Mehrzahl der auf dem Markt existierenden Systeme schwer bedienbar und unhandlich ist, soll bei der Konzeption und Gestaltung der Benutzeroberfläche die Bedienerfreundlichkeit im Vordergrund stehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 . 2 : Zielsetzung

Zum Schluß dieses Kapitels möchte ich kurz auf den Aufbau dieser Arbeit eingehen. Das folgende Kapitel (Kapitel 2) versucht die Unterschiede zwischen dem zu entwerfenden System und bereits etablierten Systemen am Beispiel von SAPÒ R/3Ò aufzuzeigen. Die Konzeption und der Entwurf der Stammdaten wird im 3. Kapitel behandelt. Im 4. Kapitel wird auf die Problematik bezüglich der Stammdaten, die bei der Realisierung eines dynamischen Systems entsteht, eingegangen. Ein Ausschnitt aus dem Bereich Produktionsplanung wird im 5. Kapitel entwickelt. Der Entwurf der Funktionen und Bewegungsdaten für die Disposition und Bedarfsplanung steht hier im Vordergrund.

Die Konzeption der Oberfläche und der Benutzerführung sind Thema des 6. Kapitels. Das 7. und letzte Kapitel erläutert mit welchen Methoden, Werkzeugen und Hilfsmitteln der Prototyp realisiert wurde.

2 Strukturierungsansätze kommerzieller PPS-Systeme

In diesem Kapitel werden die Strukturierungsansätze und die Realisierung von Kunden-Lieferanten-Beziehungen am Beispiel des PPS-Systems SAP Ò R/3 Ò dargestellt. Aufgrund der Komplexität des R/3Ò-Systems , werden hier nur die für diese Arbeit relevanten Aspekte

- Abbildung der Unternehmensstruktur im Materialstamm,
- Aufgaben und Verwendung des Materialstamms, sowie
- Abbildung von Kunden-Lieferanten-Beziehungen in SAP R/3

betrachtet [SAPR3CD1996].

2.1 Die Standardsoftware SAPÒ R/3Ò

Die Organisationsstruktur eines Unternehmens wird in SAP R/3 durch eine Reihe definierter organisatorischer Einheiten festgelegt. Für den Funktionsumfang dieser Arbeit sind die folgenden Bestandteile des R/3-Systems relevant.

Die Unternehmensstruktur wird im SAP-System durch folgende organisatorische Einheiten abgebildet:

Mandant

Ein Mandant ist eine für sich handelsrechtlich, organisatorisch und datentechnisch abgeschlossene Einheit innerhalb eines R/3-Systems mit getrennten Stammsätzen und einem eigenständigen Satz von Tabellen.

Beispiel: Konzern

Buchungskreis

Ein Buchungskreis ist die kleinste organisatorische Einheit des externen Rechnungswesens, für die eine vollständige, in sich abgeschlossene Buchhaltung abgebildet werden kann. Dies beinhaltet die Erfassung aller buchungspflichtigen Ereignisse und die Erstellung aller Nachweise für einen gesetzlichen Einzelabschluß, wie Bilanzen sowie Gewinn- und Verlustrechnungen.

Beispiel: Firma, Tochtergesellschaft

Werk

Ein Werk ist eine organisatorische Einheit innerhalb eines Unternehmens, in der Materialien produziert, bzw. Waren und Dienstleistungen bereitgestellt werden.

Beispiel: Produktionsstätte, Außenstelle, Filiale

Lagerort

Ein Lagerort ist eine organisatorische Einheit, die eine Unterscheidung von Materialbeständen innerhalb eines Werkes ermöglicht.

Einkaufsorganisation

Eine Einkaufsorganisation ist eine organisatorische Einheit innerhalb eines Unternehmens, die Materialien bzw. Dienstleistungen beschafft, mit einem Lieferanten allgemeine Einkaufskonditionen aushandelt und für diese Geschäfte verantwortlich ist.

2.1.1 Beziehung zwischen den organisatorischen Einheiten

Die im SAP-System abgebildete Unternehmensstruktur ist hierarchisch aufgebaut. Auf der obersten Stufe ist der Mandant, der mehrere Buchungskreise umfassen kann. Einem Buchungskreis können mehrere Werke zugeordnet sein, die wiederum verschiedene Lagerorte umfassen können. Die folgende Abbildung stellt diese Zusammenhänge dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 1 : Unternehmensstruktur in SAP R/3

Die Einkaufsorganisation ist eine beliebige Gruppierung von Werken. Die Zuordnung von Werk zu Einkaufsorganisation ist nicht eindeutig, d.h. eine Einkaufsorganisation kann mehrere Werke versorgen und ein Werk kann von mehreren Einkaufsorganisationen versorgt werden. Juristisch muß die Einkaufsorganisation jedoch eindeutig einem Buchungskreis zugeordnet sein. In der folgenden Abbildung werden diese Zusammenhänge grafisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 2 : Unternehmensstruktur mit Einkaufsorganisation in SAP R/3

2.1.2 Abbildung und Aufgaben des Materialstamms

Der Materialstamm wird ebenfalls hierarchisch aufgebaut und gleicht in seiner Struktur der Organisationsstruktur des Unternehmens. Es gibt Materialdaten, die auf allen Organisations-ebenen gelten, während andere nur für bestimmte Ebenen gültig sind.

Daten auf Mandantenebene

Allgemeine Materialdaten, die für das ganze Unternehmen gelten, werden auf Mandantenebene gespeichert. Dazu gehört z.B. Warengruppe, Basismengeneinheit, Materialkurztexte und Umrechnungsfaktoren zu Alternativmengeneinheiten.

Daten auf Werksebene

Alle Daten, die innerhalb eines Werkes sowie für die zugehörigen Lagerorte gelten, werden auf Werksebene gespeichert. Dazu gehören z.B. die Disposition- und Prognosedaten.

Daten auf Lagerortebene

Alle Daten, die für einen bestimmten Lagerort gelten, werden auf der Lagerortebene gespeichert. Das sind im wesentlichen die Lagerortbestände.

Im SAP-System stellt der Materialstamm die Gesamtheit aller Informationen über sämtliche Materialien, die ein Unternehmen beschafft, fertigt, lagert und verkauft dar. Für das Unternehmen stellt der Materialstamm die zentrale Quelle zum Abruf materialspezifischer Daten dar. Die im Materialstamm enthaltenen Daten werden innerhalb des R/3-Systems u.a. für folgende Funktionen benötigt:

- im Einkauf für die Bestellabwicklung
- in der Bestandsführung für die Warenbewegungsbuchungen und Inventurabwicklung
- in der Rechnungsführung für das Buchen von Rechnungen
- im Vertrieb für die Auftragsabwicklung
- in der Produktionsplanung und -steuerung für die Bedarfsplanung, die Terminierung und die Arbeitsvorbereitung

Im folgenden wird betrachtet wie das SAP-System zwischen eigenzufertigenden und fremdzubeschaffenden Material unterscheidet.

Da Material auf Werksebene disponiert wird, werden auch die Dispositionsdaten des Materialstamms dort verwaltet. Neben den Attributen Disponent, Dispositionslosgröße [1], Serienfertigung sowie Meldebestand und Auffüllmenge wird hier die Beschaffungsart festgelegt.

Ob ein Material fremdbeschafft oder eigengefertigt wird, wird durch das Attribut Beschaffungsart im Material auf der Werksebene festgelegt. Jedes Material kann entsprechend seiner Eigenschaften in jedem Werk anders definiert sein. Es ist auch möglich, ein Material auf Grund seiner Materialart, sowohl als eigenzufertigendes als auch fremdzubeschaffendes Material zu kennzeichnen.

2.2 Realisierung von Kunden-Lieferanten-Beziehungen in SAPÒ R/3Ò

Um herauszufinden, wie streng im R/3-System die Kunden-Lieferanten-Beziehungen abgebildet werden, betrachten wir nun die Möglichkeiten der Beschaffung von Material. Grundsätzlich gibt es aus Sicht des Werkes für ein Material die Beschaffungsarten

- Eigenfertigung und
- Fremdbeschaffung.

Die Beschaffungsart wird, wie bereits gesagt, im Materialstamm auf Werksebene abgelegt. Jedoch kann die Beschaffung auch in interne und externe Beschaffung unterteilt werden. Dies veranschaulicht die folgende Abbildung. Durch die Sonderbeschaffungsart (im Materialstamm auf Werksebene) wird die Eigenfertigung oder Fremdfertigung weiter spezifiziert. Es sind u.a. folgende Sonderbeschaffungsarten möglich:

- Konsignation
- Lohnbearbeitung
- Umlagerung zwischen Werken
- Produktion in einem anderen Werk
- Entnahme in einem anderen Werk
- Direktfertigung

Durch das Attribut Quotierung wird für ein Material festgelegt, welche Bezugsquelle (z.B. Lieferant) einem Bestellvorschlag zugeordnet wird. Über die Quote können Bedarfe automatisch zu bestimmten Anteilen auf verschiedene Bezugsquellen verteilt werden. Damit ist es beispielsweise möglich, ein eigengefertigtes Material zu einem bestimmten Prozentsatz über Lieferanten, Konsignation usw. zu beschaffen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 3 : Formen der Beschaffung im SAP R/3-System

Die externe Beschaffung läuft in der Regel über eine Bestellung mit dem Positionstyp normal ab. Sonderbeschaffungsformen werden durch die Positionstypen Lohnbearbeitung, Konsignation und Strecke realisiert. Diese sind hier nicht von Bedeutung.

Für diese Arbeit ist die interne Beschaffung jedoch weitaus interessanter. Durch die werksübergreifende Planung ist es möglich, Materialien über Werksgrenzen hinweg zu planen und disponieren. Damit ist es zum einen möglich, die Produktion eines Erzeugnisses an ein Werk auszulagern, zum anderen können Materialien zwischen den Werken bewegt werden. Im einzelnen stehen folgende Abwicklungen zur Verfügung:

- Umlagerung zwischen Werken
- Entnahme in einem anderen Werk
- Produktion in einem anderen Werk

Die werksübergreifende Planung wird in der Disposition mit Hilfe von Sonderbeschaffungsarten durchgeführt.

An dieser Stelle ist zu bemerken, daß die Entnahme in einem anderen Werk und Produktion in einem anderen Werk im SAP-System der Beschaffungsart Eigenfertigung zugerechnet wird. Die Umlagerung zwischen Werken gilt hingegen als Fremdbeschaffung.

2.2.1 Umlagerung von Werk zu Werk

Bei der Umlagerungsabwicklung werden Waren innerhalb eines Unternehmens beschafft und geliefert. Das Werk, das die Waren empfangen soll (Empfangswerk), bestellt die Waren intern von einem anderen Werk, das die Waren liefern kann (Lieferwerk). Der Sekundärbedarf für die umzulagernden Komponenten wird im Empfangswerk ermittelt. Neben der Abwicklung in der Disposition über die Sonderbeschaffungsart Umlagerung (siehe oben), ist auch eine manuelle Abwicklung mit Umlagerungsbestellanforderungen, -bestellungen und -lieferplänen möglich.

Das folgende Beispiel zeigt den Ablauf einer Umlagerung.

Beispiel:

Ein Material erhält im Werk 0001 den Sonderbeschaffungsschlüssel Umlagerung. Damit wird festgelegt, daß das Material aus einem anderen Werk (im Beispiel Werk 0002) zu beschaffen ist. Ein Bedarf im Werk 0001 wird dann vom Lager des Werkes 0002 beschafft.

Bei der Planung passiert folgendes:

Das System generiert bei Unterdeckung im Werk 0001 eine Umlagerungsbestellanforderung im Werk 0001 und einen Abruf zur Bestellanforderung im Werk 0002. Der Termin des Abrufs wird mit Hilfe der Terminierung bestimmt. Bei der späteren Umsetzung der Umlagerungsbestellanforderung in eine Umlagerungsbestellung im Werk 0001 wird aus dem Abruf zur Bestellanforderung im Werk 0002 ein Abruf zur Bestellung.

Im Lieferwerk erfolgt damit die Beschaffung. Die Auslagerung der bestellten Mengen erfolgt durch eine Umbuchung mit Bezug auf den Bestellabruf. Die Bewegungsart ist dabei Umbuchung ê Werk an Werk ê Transitbestand.

Der Transitbestand ist die Menge eines Materials, die aus dem Bestand des Lieferwerks entnommen wurde, aber im empfangenen Werk noch nicht angekommen ist. Im empfangenden Werk wird beim Erhalt der Ware ein Wareneingang zur Umlagerungsbestellung gebucht. Der Transitbestand geht damit dem Lager im Werk 0001 zu.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 4 : Umlagerung von Werk zu Werk

2.2.2 Entnahme in einem anderen Werk

Für eine Baugruppe kann festgelegt werden, daß Materialkomponenten in einem vom Planungswerk abweichenden Werk (Entnahmewerk) entnommen werden. Der Sekundärbedarf für diese Komponenten wird dann direkt im Entnahmewerk erzeugt. Diese Abwicklung stellt eine Alternative zur Abwicklung mit Umlagerungsbestellung dar, und ist insbesondere dann sinnvoll, wenn die Werke räumlich nah beieinander liegen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 5 : Entnahme in einem anderen Werk

Das folgende Beispiel zeigt den Ablauf der Entnahme in einem anderen Werk.

Beispiel:

Eine Baugruppe im Werk 0001 enthält zwei Komponenten. Die Komponente 2 erhält im Werk 0001 den Sonderbeschaffungsschlüssel Entnahme in einem anderen Werk. Damit wird festgelegt, daß die Komponente in einem anderen Werk entnommen wird (im Beispiel Werk 0002). Bei der Fertigung der Baugruppe im Werk 0001 wird also die Komponente 2 vom Lager des Werkes 0002 entnommen, die andere Komponente wird aus dem Lager des Werkes 0001 entnommen.

Bei der Planung passiert folgendes:

Das System generiert bei einem Bedarf für die Baugruppe einen Planauftrag im Werk 0001. Für die Komponente 1 wird ein Sekundärbedarf im Werk 0001 erzeugt, für die Komponente 2 mit Sonderbeschaffungsart Entnahme in einem anderen Werk wird ein Sekundärbedarf im Werk 0002 erzeugt.

Bei der Umsetzung des Planauftrags der Baugruppe in einen Fertigungsauftrag werden die Sekundärbedarfe der Komponenten in abhängige Reservierungen umgesetzt. Die Entnahme zum Fertigungsauftrag erfolgt für die Komponente 1 im Werk 0001, für die Komponente 2 im Werk 0002.

2.2.3 Produktion in einem anderen Werk

Für ein Erzeugnis kann festgelegt werden, daß es in einem vom Planungswerk abweichenden Werk (Produktionswerk) produziert wird. Die Planung des Erzeugnisses wird im Planungswerk durchgeführt, die Herstellung der Komponenten erfolgt im Produktionswerk. Die Stückliste des Erzeugnisses wird im Produktionswerk angelegt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 6 : Produktion in einem anderen Werk

Das folgende Beispiel zeigt den Ablauf der Produktion in einem anderen Werk.

Beispiel:

Im Beispiel erfolgt die Planung für das Material in Werk 0001 (Planungswerk) und die Produktion im Werk 0002 (Produktionswerk).

Bei der Planung passiert folgendes:

Das System generiert bei einem Bedarf im Werk 0001 für das Enderzeugnis einen Planauftrag. Im Werk 0002 wird die Stückliste aufgelöst und der Sekundärbedarf ermittelt. Der Planauftrag zum Enderzeugnis im Werk 0001 wird dann in einen Fertigungsauftrag umgesetzt. Der Sekundärbedarf im Werk 0002 wird in eine abhängige Reservierung umgewandelt, und die Produktion der Komponenten im Werk 0002 angestoßen. Beim Erfassen des Wareneingangs des Fertigungsauftrags erhöht sich der Bestand im Werk 0001.

2.3 Fazit

Zusammenfassend kann zur Abbildung der Unternehmensstrukturen mit dem SAP R/3-System folgendes gesagt werden:

1. Ein Unternehmen kann hierarchisch aufgebaut werden.
2. Es gibt fest vorgegebene organisatorische Einheiten, die in der entsprechenden Hierarchieebene angelegt werden müssen (1. Mandant, 2. Buchungskreis, usw.).
3. Die Höhe einer Unternehmenshierarchie ist auf drei Ebenen beschränkt; sieht man von der Einkaufs- und Verkaufsorganisation sowie von elementaren Ressourcen (Lagerort usw.) ab. Sollen weitere Hierarchien eingefügt oder ein Werk auf zwei Werke verteilt werden, stößt das System an seine Grenzen.
4. Jede Ebene hat definierte Aufgaben und einen fest vorgegebenen Funktionsumfang.

Diese Merkmale machen das SAP-System bezüglich der Abbildung und Änderung von Unternehmensstrukturen sehr starr.

Bei der Abbildung von Kunden-Lieferanten-Beziehungen sind folgende Anmerkungen zu machen:

1. Es wird zwischen interner und externer Beschaffung unterschieden - dabei gibt es noch eine Reihe von Sonderbeschaffungsformen.

2. Im SAP-System gibt es Möglichkeiten, Waren aus anderen Werken zu beschaffen, bzw. zu produzieren, die zur Kategorie Eigenfertigung zählen (‘Entnahme in anderem Werk’, ‘Produktion in anderen Werk’). Dadurch ist hier keine klare Abgrenzung der Unternehmenseinheiten durch Kunden-Lieferanten-Beziehungen gegeben.

3. Es ist eine werksübergreifende Planung möglich.

Klar abgegrenzte organisatorische Einheiten werden durch eine Reihe von Sonderregelungen und -funktionen wieder aufgeweicht.

3 Konzeption der Stammdaten in Kunden-Lieferanten-Sicht

Im ersten Teil dieses Kapitels werden die Anforderungen an die Stammdaten, für das zu entwickelnde EDV-System, aus der Sicht des Anwenders spezifiziert.

Der zweite Teil beschäftigt sich mit der Umsetzung in ein objektorientiertes System und mit der Problematik aus der Sicht des Informatikers. Hier wird in einem Einschub auch auf Ansätze der Baumtheorie und der Umsetzung im Klassenentwurf eingegangen.

Auf die persistente Haltung der Unternehmensdaten wird im dritten Teil eingegangen.

3.1 Anforderungsspezifikation

Ein Unternehmen soll in klar abgegrenzte Einheiten, die im folgenden näher spezifiziert werden, abgebildet werden können. Diese Einheiten werden unter anderem dadurch gekennzeichnet, daß sie sich zueinander wie Kunden und Lieferanten verhalten. Sie erscheinen nach außen wie eigenständige Unternehmen. Von diesen Unternehmenseinheiten können Waren bestellt werden, und Einheiten können Waren liefern. Im folgendem wird diese Unternehmenseinheit Kunden-Lieferanten-Modul oder kurz Modul genannt.

Ein weiteres Merkmal, das diese Struktur auszeichnet, ist die Möglichkeit Kunden-Lieferanten-Module zu schachteln. Das bedeutet, Module können untergeordnete Module beinhalten, bzw. sind Bestandteil eines übergeordneten Moduls. Die Schachtelungstiefe und die Anzahl der untergeordneten Module innerhalb eines Moduls soll durch das System nicht eingeschränkt werden. Durch diese Anforderungen können Unternehmen hierarchisch aufgebaut und organisatorisch strukturiert werden. Diese Strukturen sollen möglichst keinen systemtechnischen Schranken unterliegen.

Jedes Kunden-Lieferanten-Modul kann entsprechend seiner Aufgaben durch eine Vielzahl von Ressourcen definiert werden:

1. Wie oben erläutert, kann ein Kunden-Lieferanten-Modul beliebig weitere Module aufnehmen für die es eine übergeordnete organisatorische Einheit bildet.
2. Arbeitsstationen: sie beinhalten alle Ressourcen, die für die Bearbeitung von Arbeitsgängen benötigt werden.
3. Vorprodukte: dies sind Waren die das Kunden-Lieferanten-Modul für die Herstellung von Fertigprodukten benötigt und von einem anderen Kunden-Lieferanten-Modul beziehen muß.
4. Fertigprodukte: Fertigprodukte sind Waren die durch bearbeiten eines Vorprodukts oder durch Zusammensetzen mehrerer Vor- und Fertigprodukte entstehen. Die hier beschriebenen Vor- und Fertigprodukte bilden nur eine Definitionsmenge der in diesem Kunden-Lieferanten-Modul zu beschaffenden, bzw. herzustellenden Produkte.
5. Puffer: Puffer beinhaltet ‘wirkliche’ Bestände, d.h. den zuvor beschriebenen Vor- und Fertigprodukte werden Mengen zugeordnet.
6. Kostenstellen: durch Kostenstellen ist es möglich, Kosten ihrem Entstehungsort zuzuordnen. Die Art und Weise wie Kostenstellen gebildet werden, soll durch das System nicht vorgegeben werden. Vielmehr soll dies durch die Anforderungen im Unternehmen erfolgen, etwa durch betriebliche Funktionen (Beschaffung, Fertigung, Verwaltung, Vertrieb), nach Verantwortungsbereichen, nach räumlichen Gesichtspunkten (Werkstatt) oder nach rechentechnischen Erwägungen.

Um Einheiten zu schaffen, die es ermöglichen Arbeitsgänge durchzuführen, wird die Arbeitsstation definiert. Arbeitsstationen beinhalten alle Ressourcen, die für die Bearbeitung von Arbeitsgängen benötigt werden.

Dies sind: Produktionsmittel, Personen und Energien. Eine Arbeitsstation hat eine Beschreibung (Namen) und einen Ort. Des weiteren können in Arbeitsstationen Kostensätze, Kapazitäten und Wartezeiten hinterlegt werden.

Der Puffer hat, wie oben schon gesagt, Bestände. Einem Bestand ist ein Vor- oder Fertigprodukt zugeordnet und versieht dieses mit einer Menge, einer Mengeneinheit, einem Mindestbestand und der Möglichkeit Bestände zu reservieren. Ein Puffer hat eine Beschreibung, einen Ort und eine Kapazität. Die Kapazität des Puffers darf volumenmäßig, gewichtsmäßig usw. nicht durch die Summe der Einzelbestände überschritten werden.

Um, neben der Kostenartenrechnung, eine Kostenstellenrechnung durchführen zu können, müssen in einem Unternehmen, und damit auch in einem EDV-System, Kostenstellen definiert werden. Kostenstellen werden entsprechend ihrer Anforderungen gebildet - ihnen werden Ressourcen zugewiesen. Dies bedeutet, daß durch das System möglichst wenig Einschränkungen vorgegeben werden sollen. Eine Kostenstelle hat eine Bezeichnung, eine Kostenstellennummer und Stundensätze für die entsprechende Ressourcen (Personal, Produktionsmittel). Die Ressource, für die eine Kostenstelle gebildet wird, ist der Kostenstelle zugewiesen.

Ein Vorprodukt wird durch eine ID und eine nähere Spezifikation des Produkts gekennzeichnet. Die ID ist im gesamten Unternehmen eindeutig. Weitere Attribute eines Vorprodukts sind der Einkaufspreis, die Lieferzeit, eine minimale Abnahmemenge und Lieferanten. Attribute für die Disposition sind das Dispositionsverfahren mit den zugehörigen Werten Sicherheitsbestand, Meldebestand und strategischer Vorhaltebestand.

Genau wie das Vorprodukt wird ein Fertigprodukt durch eine eindeutige ID und eine Produktspezifikation gekennzeichnet. Weiter wird ein Fertigprodukt durch die Attribute Verkaufspreis, Durchlaufzeit, Eigenfertigungszeit, Wiederbeschaffungszeit, sowie durch Stücklisten und Arbeitspläne beschrieben. Für die Disposition sind auch hier die Attribute Dispositionsverfahren, Sicherheitsbestand, Meldebestand und strategischer Vorhaltebestand vorhanden. Mit dem Attribut Losgrößenverfahren kann das Losgrößenverfahren festgelegt werden, zu dem die entsprechenden Werte, minimale, maximale und fixe Losgröße, gesetzt sein müssen.

Außerdem soll die Möglichkeit bestehen Vor- und Fertigprodukte um selbstdefinierte Attribute dynamisch zu erweitern.

Als Handelsware werden Produkte in Kunden-Lieferanten-Modulen bezeichnet, an denen keine Veränderungen vorgenommen werden, und die keinem Arbeitsgang zugeführt werden. Handelswaren haben einen Einkaufspreis, einen Verkaufspreis, eine Lieferzeit und eine Wiederbeschaffungszeit. Des weiteren werden hier die Attribute zur Bedarfsplanung benötigt.

Eine Stückliste ist Bestandteil des Fertigprodukts und hat die folgenden Attribute. Eine ID, die der des Fertigprodukts entspricht, eine minimale Losgröße, eine maximale Losgröße und ein Zeitintervall, das als Gültigkeitsbereich bezeichnet wird. Außerdem besteht eine Stückliste aus einer beliebigen Menge von Stücklistenpositionen. Die Stücklistenposition gibt die Menge eines bestimmten Produkts an, die bei der Herstellung des Fertigprodukts benötigt wird. Somit besteht die Stücklistenposition aus der Menge für ein Produkt, dem Produkt selbst und einer laufenden Nummer. Das Produkt kann ein Vorprodukt aber auch ein Fertigprodukt sein. Außerdem wird das Attribut Alternative benötigt, die angibt um welche Stücklisten-Alternative es sich in dem Fertigprodukt handelt. In der Stückliste werden die Stücklistenpositionen nach der laufenden Nummer aufsteigend sortiert.

Auch der Arbeitsplan ist Bestandteil des Fertigprodukts. Er besteht ebenfalls aus einer ID, einer minimalen Losgröße, einer maximalen Losgröße und einem Gültigkeitsbereich. Desweiteren beinhaltet der Arbeitsplan Arbeitsgänge. Die Anzahl der Arbeitsgänge je Arbeitsplan ist nicht beschränkt. Ein Arbeitsgang hat die folgenden Attribute:

- Beschreibung
- Arbeitsgangnummer (laufende Nummer)
- Hauptzeit Personal
- Rüstzeit Personal
- Hauptzeit ausführende Einheit (Arbeitsstation/Kunden-Lieferanten-Modul)
- Rüstzeit ausführende Einheit
- Ausführende Einheit (Arbeitsstation/Kunden-Lieferanten-Modul)
- Stücklistenposition (aus der äquivalenten Stückliste; z.B. Alt. 1)

Einer Person können neben den allgemeinen Attributen (Name, Straße, Ort usw.) ausführende Einheiten (also Kunden-Lieferanten-Module und Arbeitsstationen) zugewiesen werden. Eine Person kann auch genau einer Arbeitsstation zugewiesen werden.

Zur Durchführung der Zeit- und Ressourcenplanung benötigt das EDV-System einen Jahresplan. Jahrespläne können archiviert werden.

Es ist angedacht, das System so flexibel zu machen, daß Attribute und evtl. auch Klassen zur Laufzeit erzeugt und von der Datenbank verwaltet werden können. Die Attribute und Klassen sollen dann mittels einer Makro-Sprache in die Funktionen integriert werden, bzw. es können neue Funktionen definiert werden.

Da diese Anforderungen für sich schon eine Arbeit beanspruchen würden, wird dieser Aspekt in dieser Arbeit nicht ausführlich behandelt.

Weitere Anforderungen

Das System soll auf die bevorstehenden Aufgaben, bezüglich der Euro-Einführung und der Jahrtausendwende, vorbereitet sein. Dies bedeutet, daß wahlweise mehrere Währungen verarbeitet werden können. Probleme mit der Jahrtausendwende werden über eine vierstellige Jahreszahl gelöst.

3.2 Der Klassenentwurf

In der Anforderungsspezifikation wird für Kunden-Lieferanten-Module gefordert, daß diese geschachtelt werden können, bzw. daß Hierarchien aufgebaut werden können. Weiter wird gefordert, daß diese Strukturen einfach änderbar sind. Um diese Forderung möglichst effektiv in einem EDV-System umsetzen zu können, muß man sich zuerst einmal Gedanken über die abzubildenden Datenstrukturen machen. Hier bieten sich Baumstrukturen an: das Unternehmen wird als Baum organisiert, im System kann dieser Baum abgebildet werden und die Baumstruktur wird auch in der Datenbank gespeichert. Zudem gibt es eine Vielzahl effizienter Algorithmen in Baumstrukturen. Bevor die Stammdaten-Klassen entworfen werden, wird sich ein kleiner Abschnitt mit der Baumtheorie befassen.

3.2.1 Bäume

Da eine vollständige Behandlung von Bäumen ganze Bücher füllen könnte, wird hier nur auf die, für das System wichtigen Eigenschaften eingegangen.

Bäume sind zweidimensionale verkettete Strukturen. Auf Bäume trifft man im alltäglichen Leben häufig. Zum Beispiel bei der Forschung nach den Vorfahren und Nachkommen in Familienstammbäumen. Oder bei der Organisation von Turnieren im Sport. Ein drittes Beispiel ist ein Syntaxbaum, der die Zerlegung eines Satzes in seine Bestandteile wiedergibt; dies hängt eng mit der Verarbeitung von Computersprachen zusammen (Parser, Compiler). Ein weiteres Beispiel ist die Organisation eines großen Unternehmens in Baumstruktur.

3.2.1.1 Terminologie

Es gibt eine Reihe äquivalenter Definitionen von Bäumen, sowie ein Reihe mathematischer Eigenschaften. Im folgenden wird eine Definition von Bäumen behandelt.

Ein Baum ist eine nichtleere Menge von Knoten und Kanten, die gewissen Forderungen genügen. Ein Knoten ist ein einfaches Objekt, das einen Namen hat und andere mit ihm verknüpfte Informationen tragen kann. Eine Kante ist eine Verbindung zwischen zwei Knoten. Ein Pfad in einem Baum ist eine Liste von unterschiedlichen Knoten, in der aufeinanderfolgende Knoten durch Kanten im Baum verbunden sind. Einer der Knoten im Baum wird als Wurzel bezeichnet. Die für die Definition eines Baums entscheidende Eigenschaft ist, daß es zwischen der Wurzel und jedem beliebigen Knoten im Baum genau einen Pfad gibt. Falls es zwischen der Wurzel und einem bestimmten Knoten mehr als einen Pfad gibt, oder falls es zwischen der Wurzel und einem Knoten keinen Pfad gibt, so spricht man von einem allgemeinen Graph und keinem Baum.

Jeder Knoten (außer der Wurzel) besitzt genau einen Knoten, der sich unmittelbar über ihm befindet und als sein direkter Vorgänger (parent) bezeichnet wird. Die Knoten unmittelbar unter einem Knoten werden seine direkten Nachfolger (children) genannt. Knoten ohne Nachfolger werden Blätter oder Endknoten genannt. Jeder Knoten ist die Wurzel eines Unterbaums, welcher aus ihm und den Knoten unter ihm besteht. Eine Menge von Bäumen wird Wald genannt.

Die Knoten eines Baums lassen sich in Ebenen (Stufen) einteilen. Die Ebene eines Knotens ist die Anzahl der Knoten auf dem Pfad von diesem zur Wurzel (ohne ihn selbst). Die Höhe eines Baumes ist die höchste Ebene, die unter allen Knoten im Baum auftritt (oder der maximale Abstand zwischen irgendeinem Knoten und der Wurzel).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 1 : Höhe und Ebenen in Bäumen

Falls jeder Knoten eine bestimmte Anzahl direkter Nachfolger haben muß, so hat man es mit einem n-ären Baum zu tun. Der einfachste Typ eines n-ären Baums ist der binäre Baum.

3.2.1.2 Darstellung von allgemeinen Bäumen

Die Darstellung binärer Bäume wird relativ einfach realisiert, in dem jeder Knoten zwei Verkettungen zu seinen untergeordneten Knoten besitzen. Im Normalfall werden für die Verkettungen die Namen l und r verwendet (für links und rechts). In einem leeren binären Baum existiert nur die Wurzel, deren Verkettungen auf sich selbst zeigen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 2 : Darstellung binärer Bäume

Doch wie verfährt man bei allgemeinen Bäumen, oder Wäldern, in denen Knoten eine beliebige Anzahl von Verkettungen, zu den Knoten weiter unten erfordern kann? Aus diesem Dilemma gibt es zwei recht einfache Auswege.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 3 : Darstellung eines allgemeinen Baums

Häufig bewegt man sich in Anwendungen im Baum nicht abwärts, sondern nur aufwärts. In solchen Fällen benötigt man nur eine Verkettung für jeden Knoten zu seinem direkten Vorgänger. Die folgende Abbildung zeigt den allgemeinen Baum in dieser Darstellung. Das Feld a enthält die Information, die mit jedem Datensatz verknüpft ist, und das Feld dad enthält die Verkettung zu den direkten Vorgängern. Folglich ist die Information, die mit dem direkten Vorgänger von a[i] verknüpft ist, in a[dad[i]] enthalten. Es wird vereinbart, daß die Wurzel auf sich selbst zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 4 : Darstellung eines Baumes mit Hilfe von Verkettungen zum direkten Vorgänger

Um einen Baum für die Top-Down-Verarbeitung darzustellen, braucht man einen Weg zur Behandlung der direkten Nachfolger jedes Knotens. Die direkten Nachfolger eines Knotens können als verkettete Liste dargestellt werden. Dann umfaßt jeder Knoten zwei Verkettungen: eine für die verkettete Liste, die ihn mit seinen Geschwistern verbindet, und eine für die verkettete Liste seiner direkten Nachfolger (der sich am weitesten links befindet). Der letzte Zeiger der Geschwister-Verkettung zeigt auf seinen Parent-Knoten (diese Verkettung muß allerdings markiert werden, um sie von Geschwister-Verkettungen zu unterscheiden). So ergibt sich die Möglichkeit, sich im Baum ebenso aufwärts wie abwärts zu bewegen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 5 : Darstellung eines Baumes mit Hilfe der Verkettung zum linken direkten Nachfolger und zum rechten Bruder

3.2.2 Baumstrukturen in Unternehmen

Die Eigenschaften eines Unternehmensbaums werden durch die folgenden Faktoren beeinflußt:

- in einem Unternehmen können beliebig viele untergeordnete Strukturen aufgebaut werden
- die Anzahl der Ebenen und die Höhe eines Baumes, sowie die Anzahl der unmittelbaren Nachfolger eines Knotens (children) werden durch die Struktur des abzubildenden Unternehmens vorgegeben. Nicht der Typ des Baumes darf die Struktur vorgeben.
- Auf der obersten Hierarchieebene gibt es im allgemeinen mehrere Unternehmens-einheiten (Knoten). Diese Knoten bilden jeweils die Wurzel eines eigenständigen Baumes. Demzufolge besteht ein Unternehmen aus einer Menge von Bäumen Ù Wald.

Bei einem Unternehmen handelt es sich um einen Wald nicht ausgeglichener (balanced ), allgemeiner Bäume. Es kann i.A. kein bestimmter n-närer Baum für ein Unternehmen definiert werden, somit ist die Anzahl der direkten Nachfolger eines Knotens nicht definiert.

3.2.3 Oberklassen

Die Objektorientierung bietet eine einfache Möglichkeit Eigenschaften und Methoden Objekten verschiedener Klassen zur Verfügung zu stellen: die Vererbung (inheritance ). Die Klassen, die diese Eigenschaften zur Verfügung stellen, werden Oberklassen genannt. Für dieses EDV-System sind drei Oberklassen sinnvoll, welche die abgeleiteten Klassen mit bestimmten Grundeigenschaften ausstatten. Zum einen soll eine Oberklasse definiert werden, die die Objekte mit den Eigenschaften eines Knotens in einem allgemeinen Baum ausstattet. Eine Ansichts-Oberklasse enthält die Eigenschaften und Methoden zur Darstellung von Objekten auf einer grafischen Benutzeroberfläche. Und da bereits festgelegt wurde, daß das System auf der Basis einer objektorientierten Datenbank zum Einsatz kommen soll, wird eine Oberklasse definiert, die die Schnittstelle zur Datenbank darstellt. Alle Oberklassen werden als rein virtuell definiert, d.h. von diesen Klassen können keine Instanzen erzeugt werden.

3.2.3.1 Datenbank-Schnittstelle

Diese Oberklasse stattet Objekte, welche direkt oder indirekt von dieser Klasse abgeleitet wurden, mit der Fähigkeit aus, sich selbst in einer Datenbank zu speichern. Dabei ist es hier noch nicht von Interesse, welches objektorientierte Datenbankmanagementsystem (OODBMS) bei der Realisierung zum Einsatz kommt. Bei der Realisierung braucht diese Oberklasse wiederum nur von der Klasse des OODBMS abgeleitet zu werden, die die Eigenschaften persistenter Objekte zur Verfügung stellt.

Eine weitere Aufgabe dieser Datenbank-Schnittstelle besteht darin, virtuelle Methoden der OODBMS-Klasse zu überladen und allen abgeleiteten Klassen zur Verfügung zu stellen.

Die Klasse für die Datenbank-Schnittstelle wird ProjectObject genannt und hat zur Zeit noch keine Attribute.

3.2.3.2 Baum-Oberklasse

Diese Oberklasse stellt den Objekten, der direkt oder indirekt abgeleiteten Klassen, Knoteneigenschaften eines allgemeinen Baumes zu Verfügung.

Wie zuvor gesehen, kann durch Knoten mit zwei Verkettungen ein allgemeiner Baum dargestellt werden. Dieser Baum kann sowohl aufwärts als auch abwärts durchlaufen werden. Mit Hilfe dieser Erkenntnis, wird eine Oberklasse für Knoten in einem Baum definiert.

In fast allen objektorientierten Datenbankmanagementsystemen existieren bereits Konstrukte, mit deren Hilfe man Objektmengen abbilden und verwalten kann. Einer dieser Konstrukte ist der Set. Ein Set ist eine Menge von Objekten desselben Typs oder verschiedener Typen. Die Anzahl der zu verwaltenden Objekte ist nur durch das System begrenzt. Desweiteren bietet der Set standardmäßig Methoden zum durchlaufen, suchen und bestimmte Datenbankoperationen an.

Um sich diese Eigenschaften zunutze zu machen, wird die Geschwister-Verkettung (s.o.) eines Knotens durch einen Set realisiert. Die verkettete Liste der direkten Nachfolger wird dadurch realisiert, daß der Geschwister-Pointer-Set Bestandteil (is part of)des Knotens ist. Nun fehlt nur noch die parent-Verkettung des rechten Knotens aus der Geschwister-Verkettung um den Baum aufwärts durchlaufen zu können. Diese wird durch einen einfachen Zeiger auf ein Knoten-Objekt (parent) realisiert.

Die Klasse für die Knoten eines Baums wird NodeObject genannt. NodeObject wird von der Datenbank-Schnittstellen-Klasse ProjectObject abgeleitet. Somit erhalten alle abgeleiteten Knoten-Objekte die Fähigkeit der Persistenz.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 6 : Aufbau eines NodeObject -Objekts

Die Modellierung der Klassen wird mit Hilfe des Object Relationship Model (ORM ) nach der Object-Oriented Systems Analysis (OSA ) von Embley, Kurtz und Woodfield [Embley1992] durchgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 7 : Modellierung der NodeObject -Klasse

3.2.3.3 Ansichts-Oberklasse

Als letztes wird die Oberklasse zur Darstellung von Objekten auf einer grafischen Benutzeroberfläche definiert. Diese Klasse wird ViewObject genannt und stellt Attribute und Methoden zur grafischen Ausgabe zur Verfügung. Das Attribut PosInView beinhaltet die aktuellen Fensterkoordinaten eines Objekts und speichert diese, da ViewObject von ProjectObject abgeleitet wird, in der Datenbank.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 8 : Modellierung der ViewObject -Klasse

3.2.3.4 Zusammenfassung

Mit Hilfe dieser drei Oberklassen ist es nun möglich den Objekten einer Klasse durch Einfach- oder Mehrfachvererbung (multiple inheritance ) die gewünschte Funktionalität zu geben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 9 : Ableitungen der Oberklassen

Wird eine Klasse A von der Klasse ProjectObject abgeleitet, so erhalten deren Objekte ausschließlich Datenbank-Funktionalität. Mit Objekten der Klasse B können Bäume dargestellt und in der Datenbank gespeichert werden. Die Klasse C wird durch Mehrfachvererbung von den Klassen NodeObject und ViewObject abgeleitet. Diese Objekte können Bäume abbilden und grafisch dargestellt werden. Indirekt ist diese Klasse auch von der Klasse ProjectObject abgeleitet und hat somit alle Datenbank-Eigenschaften geerbt. Objekte der Klasse D können grafisch dargestellt und in der Datenbank gespeichert werden.

3.2.4 Allgemeine Klassen

Dieser Abschnitt befaßt sich mit Klassen, von denen jeweils nur eine Instanz je Unternehmen erzeugt wird.

3.2.4.1 Einheiten

Oft kommt es vor, daß ein Kunde ein Produkt z.B. in Kilogramm bestellt, der Lieferant aber in Tonnen liefert. Um dieses Problem mit dem System abzudecken, wird ein Einheitensystem entworfen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 10 : Die Klassen Einheit, EinheitenTupel und Einheiten

Für jedes Unternehmen im System wird eine Instanz der Klasse Einheiten erzeugt und in der zentralen Datenbank gespeichert.

Die im Klassenentwurf angegebenen Basiseinheiten und Alternativeinheiten werden vorgegeben und die Umrechnungsfaktoren (Faktor) berechnet. Natürlich hat der Anwender die Möglichkeit zur Laufzeit die Basiseinheit zu ändern oder weitere Alternativeinheiten (z.B. Zoll, Fuß, Barrol, Gallone usw.) einzugeben. Differenzen, z.B. zwischen Einheiten von Produkten der Kunden und Lieferanten, werden so behoben. Denkbar ist weiterhin, die Erweiterung der Einheiten z.B. um Druck-Einheiten. Da dieses EDV-System jedoch keine physikalisch/technische Anwendung ist, wird zu diesem Zeitpunkt davon abgesehen.

3.2.4.2 Zahlungsmittel und Währung

Um das System mehrwährungsfähig zu machen, müssen Klassen entworfen werden, die verschiedene Währungen verwalten und die jeweiligen Umrechnungen durchführen können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 11 : Die Klassen Währung und Zahlungsmittel

Für jedes Unternehmen wird eine Instanz der Klasse Zahlungsmittel erzeugt und in der zentralen Datenbank abgelegt. Als Basiswährung wird das Zahlungsmittel bezeichnet, mit dem das Unternehmen intern rechnet. Die Basiswährung stellt auch die Basis für die Umrechnung auf Fremdwährungen dar. Es können beliebig viele Fremdwährungen eingegeben und verwaltet werden.

3.2.5 Kunden-Lieferanten-Modul

Das Kunden-Lieferanten-Modul wird von den Oberklassen NodeObject und ViewObject direkt abgeleitet. Indirekt werden die Eigenschaften der Klasse ProjectObject an die Klasse Kunden-Lieferanten-Modul vererbt. Somit hat ein Kunden-Lieferanten-Modul die Eigenschaft grafisch dargestellt und in der Datenbank gespeichert zu werden. Da das Kunden-Lieferanten-Modul die Organisationseinheit in dem EDV-System ist, mit der die Unternehmensstrukturen abgebildet werden, erhält es natürlich die Eigenschaften eines Knotens in einem allgemeinen Baum.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 . 12 : Entwurf der Klasse Kunden-Lieferanten-Modul

Neben untergeordneten Kunden-Lieferanten-Modulen kann ein Kunden-Lieferanten-Modul Arbeitsstationen und Puffer beinhalten. Um Vor- und Fertigprodukt in einem Kunden-Lieferanten-Modul zu definieren, können auch diese aufgenommen werden.

[...]


[1] Die Dispositionslosgröße legt fest, nach welchem Losgrößenverfahren die Losgröße ermittelt werden soll.

Ende der Leseprobe aus 113 Seiten

Details

Titel
EDV-System zur dynamischen Abbildung von Kunden-Lieferanten-Beziehungen
Hochschule
Technische Hochschule Köln, ehem. Fachhochschule Köln
Note
1.3
Autor
Jahr
1998
Seiten
113
Katalognummer
V185154
ISBN (eBook)
9783656997740
ISBN (Buch)
9783867460590
Dateigröße
1391 KB
Sprache
Deutsch
Schlagworte
edv-system, abbildung, kunden-lieferanten-beziehungen
Arbeit zitieren
Thomas Hoffmann (Autor:in), 1998, EDV-System zur dynamischen Abbildung von Kunden-Lieferanten-Beziehungen, München, GRIN Verlag, https://www.grin.com/document/185154

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: EDV-System zur dynamischen Abbildung von Kunden-Lieferanten-Beziehungen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden