Office: Datenmodell Auftragsabwicklung

Guten Morgen,
ich möchte gerne meine Auftragabwicklung umstellen. Bisher hatte ich eine Tabelle "tbl_Rechnungen" , "tbl_Rechnungabschnitte" und "tbl_Rechnungswerte". Über ein Statusfeld in der tbl_Rechnungen habe ich den Status "Angebot, Auftragbestätigung, Lieferschein, Rechnung, Gutschrift" eingestellt. Das klappte alles, reicht aber jetzt nicht mehr den Anforderungen. Ich möchte jetzt Verkaufsvorgänge abbilden, in dem ich eine Rechnung vom Angebot über den Auftrag zum Lieferschein bis zur Rechnung nachvollziehen kann. Es kann ja auch sein, dass es 2 Angebote bedarf bis es zu einem Auftrag kommt, oder es müssen 2 Lieferscheine erstellt werden, da nicht alle Ware vorhanden ist.

Ich habe mir fogendes überlegt: Ich muß zusätzlich zu meiner tbl_Rechnungen folgende Tabellen erstellen: tbl_Angebot, tbl_Auftrag, tbl_Lieferschein und diese Tabellen dann einer übergeordneten Tabelle "tbl_Vorgang" unterordnen. Somit kann ich über den Vorgang einen ganzen Verkaufsvorgang abbilden. Jetzt ergeben sich folgende Fragen:

1. Ich bin mir nicht sicher ob ich alle Tabellen in einer 1:n-Beziehung zu der Tabelle Vorgang stelle, oder ob ich nur die tbl_Angebot und tbl_Auftrag in eine 1:n-Beziehung zur tbl_Vorgang stelle und die tbl_Lieferscheine und tbl_Rechnungen zur tbl_Auftrag in Beziehung stelle.

2. Da ich eine gewisse Flexibilität brauche, kann nicht immer für jede Rechnung ein Angebot und Auftrag existieren.

3. Es müssen aus dem Auftrag evtl. Teillieferscheine und somit auch Teilrechnungen und Abschlagsrechnungen möglich sein. Ich denke für die Teillieferscheine und Teilrechnungen sowie evtl. Abschlagsrechnungen fehlen mir bestimmt noch Tabellen, oder?

Hat jemand von Euch hierzu Erfahrung und kann mir weiter helfen?

Gruß
Quint

:)

 

Hi,

meine selbstentwickelte Bauabrechnungssoftware hat dieses Problem wie folgt gelöst:

• Jedes Schriftstück, das ein- oder ausgeht, bildet ein sog. Dokument. Jedes Dokument ist einem Projekt (=Baustelle) zugeordnet. Bei dir dürften die Dokumente eher direkt am Kunden hängen.
• Sofern das Schriftstück aus "Menge*Preis-Zeilen" besteht, sind diese in den sog. Dokumentposten abgelegt. Die Posten nehmen dabei die Preise und Rabatte zum Umsatzzeitpunkt auf (Historisierung).
• Die Dokumentart (Lieferschein, Auftrag, Rechnung, ...) sowie die Richtung (eingehend/ausgehend) wird im Dokument durch eine Kennziffer abgelegt. Beides steuert die Validierung der Felder im Dokument und den Dokumentzeilen. So muss z.B. eine ausgehende Rechnung eine Rechnungsnummer und Posten haben, ein ausgehendes Angebot hingegen muss Posten haben, darf aber keine Rgnr haben.
• Dokumente können sich aufeinander beziehen (Parent-Child). So kann z.B. ein Auftrag aus einem Angebot entstehen und eine Rechnung aus einem Auftrag. Bei einem solchen Bezug werden defaultmäßig die Posten aus dem Elterndokument übernommen, können aber im Kinddokument verändert werden. So können ganze Dokuemntbäume entstehen.
• Dokumente mit Forderungs- oder Verbindlichkeitencharakter (abh. von der Dokumentart) werden beim Enstehen der Forderung "gebucht", d.h. sie lassen einen Forderungs- bzw Verbindlichkeitsposten ("offener Posten") enstehen und sperren zugleich das Dokument gegen Bearbeitung.
• Zahlungen werden auf Dokumente geleistet, ggf. wird vom User aufgesplittet. Der Saldo aus den "Einbuchungen" und den "Ausbuchungen" ((Teil)-Zahlung, Ausfall, Skonto etc) ist der offene Restbetrag. Dokumente mit offenem Restbetrag können verfolgt werden und erlauben ggf. eine Darstellung des Betrags im Zeitverlauf zur Feststellung von Verzugsschäden.
• Auch Dokumentzeilen können hierarchisch gegliedert sein, um Zwischensummen z.B. nach Gewerk oder nach "Varainten A,B C etc" zu ermöglichen.
• Es sind auch Freitextdokumente möglich, z.B. Stellungnahmen oder Gerichtssachen. Hier werden die entstehenden PDFs als Datei eingelinkt und sind dennoch im Programm auffindbar.

Über das Programm wurde mindestens eine Diplomarbeit geschrieben *Smilie Ganz trivial ist es also nicht.

 

Hallo Martin,
momentan hängen meine Rechnungen natürlich am Kunden, das möchte ich aber ändern. Ich habe ja schon erläutert, dass es wohl sinnvoler ist Vorgänge zu erstellen in denen ich den ganzen Abwicklungsverlauf darstellen möchte.

Der Vorgang hängt am Kunden und hat eine Vorgangsnummer. Meine Frage war, ob ich jetzt die Tabellen " Angebote, Auftrag, Lieferscheine, Rechnungen" alle an den Vorgang hänge oder eben nur die "Angebote und Aufträge" und die "Lieferscheine und Rechnungen" an die Aufträge. Als zweites war die Frage, was ist wenn ich eine Rechnung (z. Bsp. Barverkauf im Laden) ohne Auftrag erstelle und brauche ich evtl. neue Tabellen für Teilfierscheine und Teilrechnungen. Ansonsten kann ich Deine Schilderungen verstehen, so in etwa habe ich mir das ja auch zurechtgedacht.

Gruß

Quintxl

 

Hi,

ich weiß ja nicht um welche Branche es geht, aber was soll denn dann "innerhalb" eines Vorgangs gleich bleiben? Anders gefragt: wann endet ein solcher Vorgang? Auf meinem Bauprojekt ist Ende, wenn der letzte Cent ausgeglichen ist (Gewährleistung mal ausgeneommen) so dass alle Dokumente zur Baustelle beisammenstehen. Eine neue Baustelle desselben Kunden ist "was neues vom alten Kunden". Und bei dir? Was ändert sich bei dir in einem neuen Vorgang?

sind m.E. allesamt unnötig. Wenn da morgen eine neue Dokumentart dazukommt, brauchst du neue Tabellen. Das sind alles Dokumente. Sie sehen auch im wesentlichen gleich aus. Details regeln dann die Dokumentart und die Dokumentzeilen.

Ganz einfach: das darf (bei mir) nicht sein. Bei dir könnte z.B. ein "Kunde" namens Barverkauf einen "Vorgang" namens Barverkauf haben. Also ein "Dummy". Bei mir werden die möglichen Dokuementarten in Abhängigkeit vom Elterndokument vergeben: Ein Angebot kann keine Rechnung unmittelbar nach sich ziehen! Wehe, wenn du das zulässt.

In meinem Konzept nicht. Die Mengen stehen ausschließlich (!) in den Dokumentposten. Dahin werden sie ggf. aus dem Ur-Auftrag vom programm kopiert und können dort auch verändert werden.

Dann mach es genauso *Smilie Das Konzept trägt. Sieht der Prof auch so *Smilie

 

Hallo Martin,

Die Branche ist doch egal, es sind Artikel und Dienstleistungen zu verkaufen. Mir geht es im Enddefekt nur um die Darstellung. Stell Dir vor, Du hast einen Kunden, der bestellt im Jahr 100 mal bei Dir. Wenn in aller Regel eine Bestellung folgenden Weg hat: Angebot->Auftrag->Lieferschein->Rechnung entstehen mindestens 400 DS. Das wird in der Kundenmaske ->Käufe doch sehr unübersichtlich, Du kannst eigentlich kein Angebot mehr einer Rechnung zuordnen. Also möchte ich, eigentlich wie Du Projekte (bei mir Verkaufsvorgänge) schaffen denen ich die dazugehörige DS zuordne. Der Verkaufsvorgang ist mit Geldeingang abgeschloßen. Ich hätte dann erst mal nur 100 DS (Vorgänge) sichtbar und nicht 400. Öffnest Du ein Vorgang, kommen dann nach Datum sortiert die Dokumente des Vorgangs schön übersichtlich zum Vorschein.

Jetzt wollte ich eine Tabelle tbl_Vorgang->VorgangID, KundenID erstellen und die Dokumente (bei mir Angebote, Aufträge, Lieferscheine und Rechnungen) an die Tabelle tbl_Vorgang binden. Ich denke es ist jetzt erst mal egal ob ich alle Dokumente in eine Tabelle lege oder pro Dokumentenart eine Tabelle erstelle. In der Auftragsabwicklung läuft die Abwicklung eines Auftrags in aller Regel doch so: Angebot->Auftrag-Lieferschein->Rechnung, also sind es doch nur 4 Tabellen (zusätzlich die Positionen). Ich denke es ist für die Performance besser, die Dokumente in die 4 Tabellen aufzuteilen, da doch ständig DS kopiert werden, und das von einer größeren Benutzerzahl. Also aus dem Angebot wird ein Auftrag generiert-> kopieren der Angebotsdaten und der Positionen, dann der Lieferschein -> kopieren der Auftragsdaten und der Positionen, dann die Rechnung -> kopieren der Lieferscheindaten und der Positionen.

Mir geht es jetzt um die Zuornung der Tabellen zu der Vorgangstabelle.

Gruß

Quintxl

 

zu deinem 1. Absatz:
Dann entspricht ein Vorgang bei dir einer Baustelle bei mir. Die kann auch mehrere Dokumente haben. Die Aussage Du kannst eigentlich kein Angebot mehr einer Rechnung zuordnen ist aber durch die baumartige Verhäkelung der Dokumente nicht richtig. Und gegen 400 Dokumente pro Vorgang/Baustelle habe ich auch keine Einwände. Es kommt immer auf die Darstellung an. Wenn der Kunde sich tatsächlich 80 Angebote machen lässt, bevor auch nur ein Bagger ausrückt, dann will ich das durchaus sehen können. Bei dir scheint aber jedes Angebot (das ja nicht zwingend angenommen wird) ein Vorgang zu werden.

Zu deinem 2. Absatz:

Erstens impliziert "in aller Regel" die Möglichkeit des Andersseins. Zweitens willst du ja auch Rechnungen ohne Auftrag und und Aufträge ohne Angebote können. Bei deiner Struktur wird das schwierig; bei meiner wäre das durch die Steuertabelle ("welche Dokuemntart darf welcher Dokuemntart vorangehen") möglich. Drittens kann jede der "nur" 4 Tabellen Positionen haben. Wenn du da nur eine Positionstabelle führst, wird es aber komplex, denn die ID kann ja eine Angebots-, Auftrags-, Lieferschein- oder RechnungsID sein. Da brauchst du wohl doch auch eine Dokumentart. Oder du hast je Art eine Postentabelle, was der Normalisierung schadet.

Du fragtest im übrigen nach Erfahrungen. Ich habe dir welche gegeben, versehen mit dem Hinweis, dass mein Modell trägt und durch 2 Profs (Wirtschafts- und Informatik) gutgeheißen wurde. Wenn du jemanden suchst, der dein Modell blind gutheißt, wirst du lange suchen müssen.

 

Hallo Martin,
wir reden irgendwie aneinander vorbei: Laut Deinem ersten Schaubild entspricht ein Vorgang bei mir einem Auftrag bei Dir. Nein, nicht jedes Angebot ist ein neuer Vorgang! ein Vorgang kann mehrere Angebote, Lieferscheine und Rechnungen haben, aber nur einen Auftrag!

Leider sind wir von meiner ersten Fragestellung abgekommen, trotzdem vielen Dank!

Quintxl

 

Das stimmt mich ein wenig nachdenklich, weil Aufträge doch bei dir aus Angeboten resultieren. Ein angenommes Angebot wird ein Auftrag und muss daher einen Vorgang in deinem Sinne anstoßen. Wo bringst du die früheren, nicht angenommenen Angebote zum gleichen Kunden unter? Sind das "tote" Vorgänge, die nie zur Ausführung gelangten?

Wenn du das so aufbaust:
Kunden 1:n Vorgänge
Vorgänge 1:n Angebote
Vorgänge 1:n Aufträge
Vorgänge 1:n Lieferscheine
Vorgänge 1:n Rechnungen,
dann kannst du festhalten, was woher kommt. Du wirst aber feststellen, dass sich die 4 Tabellen (An, Au, Li, Re) völlig gleichen. Zudem brauchst du in den Posten jeweils einen Verweis auf das Basisdokument, und wie hältst du da fest, ob die "2 Stück Artikel 4 á 10 EUR" jetzt zum Angebot Nr 30 oder zur Rechnung Nr. 30 gehören?

Wenn du es "linear" aufbaust:

Kunden 1:n Vorgänge
Vorgänge 1:n Aufträge
Aufträge 1:n Lieferscheine
Aufträge 1:n Rechnungen
,
dann wird es schwierig mit Dokumenten, die nicth diesem Linearschema folgen, z.B. Rechnungen ohne Auftrag.

Ich versteh nicht, warum du mit Gewalt an deinem Modell festhältst.

Performance ist in meinem Modell kein Problem. Richtig gesetzte Indizes helfen *Smilie Eine lange Tabelle ist nicht schlechter als 4 (oder mehr) kurze, gleichartige Tabellen.

 

Hallo Martin, jetzt sind wir ja fast auf einem Nenner, ich halte nicht starr an meinem Modell fest, obwohl ich Widder bin.

Der Vorgang entsteht mit Erstellung des Angebotes. Weitere Angebote zu dem Vorgang unterliegen auch dem Vorgang. Aber der Vorgang kann doch nur einen Auftrag haben, oder? Du arbeitest in Projekten die mehrere "Vorgänge" haben, bist damit praktisch eine Hierarchie über meinen Vorgängen die besser Verkaufsvorgang heissen sollten. Da den Tabellen Positionstabellen unterstehen, ist die Artikelzuordnung klar festgehalten. Bei dem Modell 1 zu n bei allen 4 Tabellen, müßte in den Tabellen Lieferschein, Rechnung ausser der VorgangsID immer auch die AuftragsID stehen, damit ich diese als Parent/Child darstellen kann.

Besser wohl Modell 2 "linear", die Abhängigkeiten sind ersichtlich und eindeutig. Ich müßte bei einer Rechnungsstellung ohne Angebot den Auftrag und den Lieferschein nach dem speichern der Rechnung erstellen lassen?!?. Bei beiden Modellen würden aber bei einer theoretischen Auftragslöschung die Angebote bestehen bleiben, ich will damit sagen, dass die Angebote frei im Vorgang rumschweben.

Zu meiner Starrheit: Ich habe keinen Vorschlag von Dir erhalten, wie würde denn in Deinem System meins dargestellt werden. Hiermit meine ich die Tabellenstruktur. ;-)

Gruß in den Taunus,

Quintxl

 

ist auch bei mir möglich, aber es kann eben auch ein Auftrag ohne Angebot entstehen.

Bei mir nicht. Und das ist auch gut so. Es gibt z.B. "Splitts" von einem Angebot in 2 Aufträge für das gleiche Projekt. Es könnte vielleicht auch bei dir "Teilannahmen" geben.

Modell 2 hat (wie 1) den Nachteil, dass du nur endlich tiefe "Bäume" anlegen kannst. Die Tiefe ist festgelegt. Wenn es dann z.B. Mahnungen (zu Rechnungen) gibt, Rechnungsrückläufer (= die Rechnung wird als falsch bemängelt und neu verlangt) oder gar freien Schrifteverkehr, sind das jeweils neue Tabellen. Meinem Modell ist das alles egal, da die "Intelligenz" nur darin liegt, welche Dokumentart welche Felder braucht. Die Db selbst ist auf alles gefasst. Neue Dokumentarten müssen nur benannt und in der Logiktabelle (was sind Pflichtfelder, Tabufelder, Kannfelder, welche Dokumentarten erlauben welche Nachfolger) erfasst werden.

Zum Modell: ich schlage als Kernmodell vor

• Kunden 1:n Dokumente
• Dokumente 1:n Dokumentzeilen
• Dokumentarten 1:n Dokumente
• Dokumentzeilen n:1 Artikel
• Dokumentartensteuertabelle n:1 Dokumentarten
• Dokumente 1:n Umsätze ("Einbuchungen" der Rechnungen)
• Konten 1:n Umsätze (Zahlungen der Kunden auf die Girokonten der Firma)

quasi mein Modell ohne Projekte, da die "Baustelle" (Projekt) als zusammenfassendes Attribut bei dir kein sinnvolles Äquivalent hat.

Die Vorgänge scheinen da zu fehlen, aber in Wirklichkeit ist ein Vorgang nur die gesamte Nachfolgerschaft eines Angebots (Root = Angebot) oder eines Auftrags (Root = Auftrag).

 

Ich verstehe jetzt, Du baust somit ein Parent/Child - Gebilde auf. Das erste Dokument(Parent 0) ist die Root, und dann kannst Du über die DokID und ParentID Bäume darstellen. Dokumentzeilen ist die Hilfstabelle für die n:m Beziehungen.

Lustig, so habe ich ja meine Artikel-Kategorien aufgebaut ( wir waren damals auch in Kontakt).

Somit kannst Du natürlich alle Arten von Dokumenten hierarchisch darstellen. Das Problem ist, dass nur die Dokumente zugeordnet werden dürfen, die zu einem Vorgang passen. Das machst Du wohl mit der Dokumentartensteuertabelle?

Gruß
Quintxl

 

So ist es. Kunden haben Projekte (1:n), Projekte haben Dokumente (1:n). Die Dokumente eines Projketes sind reflexiv verbunden und bilden einen Baum. Die Dokumentzeilen eines Dokuments sind reflexiv verbunden und bilden einen Baum.

Wem oder was werden bei dir Dokumente zugeordnet? Doch wohl nur dem Kunden. Denn für das, was du Vorgang nennst, kenne ich keine Äquivalent bei mir; höchstens "Projekt", und das kommt ja nicht vor. Ein Vorgang ist bei mir am ehesten noch das erste Dokument im Projekt: "damit fängt alles an".

Die Dokumentartensteuertabelle steuert zwei Dinge:

• welche Felder sind Pflicht, Wahlfrei oder Tabu? Beispiel rechnung: RgNr Pflicht, Fälligkeitsdatum Pflicht; beispiel Angebot: RgNr Tabu, Fälligkeit Pflicht (Ende der Gültigkeit des Angebots).
• welche Dokumentart ist als Vorgänger zulässig (= wovon ist ein Auftrag "Kind"? Vom Angebot. Ist ein Auftrag auch ohne Vorgängerdokument möglich? Ja)

Kennen wir uns?!

 

Hi nochmal ein Bild wie das aussieht in einem Projekt (Baustelle). Die hier dargestellten Dokument werden anhand der Projektnummer "gefunden" und dann hier im Baum anhand der Parent-DokuemntID dargestellt. Man sieht, dass erst das dritte Angebot angenommen wurde und zu Auftrag und Abschlagsrechnung führt.

 

Hallo Martin,
ich mach mich jetzt mal an die Umsetzung und berichte Dir später.
Wir kennen uns von hier aus einem sehr intensivem Thread.
Schönen Tag

Quintxl

 

Martin,

ich musste gerade an Dich denken, lustigerweise hast Du Deine Diplomarbeit über ein Thema geschrieben, mit dem ich mich schon lange beschäftige - die Baubranche. Ich berate ein Abbruchunternehmen, da fallen viele Aufträge und Abrechnungen an. Wenn es um größere Aufträge geht, ist da mit einer normalen Angebotserstellung mit Artikelverwaltung schwer weiterzukommen, zumal bei großen Objekten der Kunde die Artikel vorgibt. Ich meine damit die GAEB-Dateien. Die Gaeb-Dateien sind praktisch die Ausschreibungsgrundlagen die aber leider nie 100% umgesetzt werden können oder bewusst nicht umgesetzt werden. Dieses Thema macht mich schier Wahnsinnig. Da stimmen die Aufmasse nicht, sind auf einmal Mehr-oder Minderflächen da und es werden so oft Rechnungen nur Teilbezahlt, da alles viel zu teuer geworden ist. Oft werden von meinem Kunden Kürzungen geschluckt, da Folgeaufträge winken. Steuerlich werden die Differenzen einfach ausgebucht, was ich für problematisch halte, dennn eigentlich müßten für diese Differenzen debitorische Gutschriften erfolgen..... So geht das Durcheinander unendlich weiter.

Schluck.... Was denkst Du?

Quintxl