Tabellenaufbau Auftragsverwaltung praktischer Tipp

[JohannesK]

Hansa bringt es im wesentlichen auf den Punkt.

Zitat von Hansa:

Die Preise haben nichts mit den Artikeln direkt zu tun, deshalb gehören sie in separate Tabelle. Leistungsbeschreibungen gehören weder zum Artikel, noch zu der Rechnung an sich. Das muss verknüpft werden mit der Rechnungsposition.

Preise (=Grundpreise/Einheit) haben natürlich mit den Artikeln zu tun, sonst müsste man sie nicht verwalten, gehören aber in sep. Tabelle und müssen in der Rechnungspos. editierbar sein.

Zitat von Hansa:

Da nicht jede Rechnungspos. einen Text erfordert, würde ich hingehen und die infrage kommenden Artikel mit einem boolschen Feld "Diverser" kennzeichnen. Das dann per Checkbox auswerten. Angehakt -> bei Auftrags/Rechnungsschreibung klappt Memo etc. auf und man kann Text eingeben, oder eben nur die Menge.

Noch einfacher: wenn nichts drin steht wird auch nichts gedruckt -> Standardfall
Wenn Zusatzinfos nötig - editieren und drucken
Menge / Anzahl braucht es in jedem Fall, egal ob Ergänzungstext oder nicht, wegen Menge*Einzelpreis = Gesamtpreis

[Hansa]

Zitat von JohannesK:

Preise (=Grundpreise/Einheit) haben natürlich mit den Artikeln zu tun, sonst müsste man sie nicht verwalten, gehören aber in sep. Tabelle und müssen in der Rechnungspos. editierbar sein.

Noch einfacher: wenn nichts drin steht wird auch nichts gedruckt -> Standardfall

Stimmt, aber nur zum Teil. Der Preis kann, muss aber nicht editierbar sein ! Das kommt eben drauf an. Nehmen wir mal Salatgurken, da wird sich der Preis momentan wohl stündlich ändern.

Da macht das eventuell Sinn, tatsächlich den Preis grundsätzlich editierbar zu machen. Normalerweise ist das aber eher Unsinn und führt zu unnötigen Fehlern. Womöglich kommt noch einer und behauptet, Dein Programm würde falsch rechnen. Den Preis hätte er nämlich nicht manuell verändert. Wahrscheinlich läufts sogar so, dass bei völliger Preisfreigabe (eventuell sogar mit zwangsweiser Bestätigung des Preisfeldes, d.h. man landet da sowieso drin), dass die das gnadenlos ausnutzen. D.h. jeder kriegt anderen Preis. Normalerweise gibt das Ärger. Deshalb "Diverser". Ist das true, dann ab ins Preisfeld, sonst nicht. Wie gesagt, bei Tagespreisen eventuell andere Standardvorgabe.

Die Findigkeit der User ist echt entsetzlich. Vor Ort gucke ich mir die Artikel an. Und da war einer der hiess ".". Ich hatte gefragt, ob ich den löschen solle, das wäre ja wohl ein Fehler. Aber Denkste! Es hiess "Finger weg ! Der wird gebraucht, damit man da was hinschreiben kann". Jo, Programm verlangt Artikel-Bezeichnung. Ach ja, den Artkel gabs auch schon : __________________________

[JohannesK]

Zitat von Hansa:

Da macht das eventuell Sinn, tatsächlich den Preis grundsätzlich editierbar zu machen. Normalerweise ist das aber eher Unsinn und führt zu unnötigen Fehlern. Womöglich kommt noch einer und behauptet, Dein Programm würde falsch rechnen. Den Preis hätte er nämlich nicht manuell verändert.

Ist sicher etwas das über Berechtigungen und eine Logdatei gelöst werden kann: wenn geändert -> INSERT in Logtabelle. Stammdaten bleiben ja unverändert.

Zitat von Hansa:

D.h. jeder kriegt anderen Preis. Normalerweise gibt das Ärger.

Wenn ein Laden so organisiert ist, braucht der eigentlich gar keine Datenbank, dann reicht Word.

Zitat von Hansa:

Die Findigkeit der User ist echt entsetzlich. Vor Ort gucke ich mir die Artikel an. Und da war einer der hiess ".". Ich hatte gefragt, ob ich den löschen solle, das wäre ja wohl ein Fehler. Aber Denkste! Es hiess "Finger weg ! Der wird gebraucht, damit man da was hinschreiben kann". Jo, Programm verlangt Artikel-Bezeichnung.

Jaja, kommt mir alles sehr bekannt vor . Wobei Artikelbezeichnungen aber eindeutig nur in den Stammdaten geändert werden dürften.

[angos]

[QUOTE=JohannesK;1104874][...]

Zitat von Hansa:

Zitat von Hansa:

D.h. jeder kriegt anderen Preis. Normalerweise gibt das Ärger.

Wenn ein Laden so organisiert ist, braucht der eigentlich gar keine Datenbank, dann reicht Word.
[...]

Nicht wirklich, es ist durchaus üblich den Preis (ich hoffe ihr sprecht vom VK öfters zu ändern (natürlich nicht immer und nach gut Dünken).
Das kann zB ein verhandelter Kundenrabatt sein, da wiederrum ein "immer" geltender (-> Stammdaten) oder ein einmaliger.
Rabatt könnte aber auch als eigenständige Position sichtbar sein, wo es auch wieder verschiedene Optionen gibt (Rabatt auf einzelposition, positionsgruppen, zwischensummen, gesamtsummen, etc..).



Zur Datenbank:
Ich würde für die verschiedenen Positionsarten (Artikel, Leistungen, etc) auch verschiedene Tabellen verwenden. So können Anpassungen für die verschiedenen Arten besser implementiert werden.
Prefixe holen dich irgendwann ein. Spar dir besser den Ärger!

Preise, wie schon gesagt, in eine separate Tabelle packen.

Texte: Es gibt feste Standardtexte für die Einzelnen Artikel, etc.... Geänderte Texte werden natürlich zur Auftragsposition gespeichert. Und man muss in der Lage sein jeden Text für eine Position anzupassen, das wird einfach häufig gebraucht.


Je nach gewünschtem Umfang kann das alles zusammen eine sehr sportliche Aufgabe werden.

Ich hoffe, dass ich ein bisschen helfen konnte.


Gruß
angos

[mkinzler]

Statt Prefixe wären auch eine extra Feld möglich ( z.B. mit FK auf Artentabelle)

[Hansa]

War klar, dass auch noch Rabatte auftauchen. Da geht das Spielchen genau so weiter wie gehabt : ein Rabatt ist grundsätzlich vereinbart, dann braucht man dafür eine Stamm-Table. Solche Strukturen sind dabei nicht unüblich : 10 % Rabatt auf Gemüse (als Waren-Hauptgruppe) und auf Gurken gibt es 15 % (Waren-Untergruppe) und wenn einer spanische Gurken will (Artikel), dann gibt es jetzt 30 % Rabatt. Um das umzusetzen braucht man dann 3 Tabellen.

Ein Sonderfall wäre nun kein Sonderfall, wenn er nicht noch einen Sonderfall hätte : einer will für die nächste Lieferung spanischer Gurken 50 % Rabatt, sonst würde er nichts bestellen. Und nun ? Wenn es irgendwie geht, dann würde ich sagen, man macht eine kurzfristige Änderung in der Rabattverwaltung, schreibt die Bestellung und speichert den Rabatt und dann wieder zurückändern. Aber, wer sieht den Haken an der Sache ? Wird später die Rechnung neu gedruckt, dann ist ja der Rabatt wieder bei den üblichen 30 %. Ergo : die ganze Geschichte muss auch wieder irgendwo bei den Rechnungspositionen untergebracht werden. Also für die genannten 3 Rabattarten noch 3 Tabellen.

Aber das ist nocht längst nicht alles. Sagen wir mal : bestellt werden : 10 x spanische Gurken, 10 x deutsche Gurken, 10 x Tomaten, 10 x Bohnen. Das Programm muss dann folgendes errechnen : es gibt auf 20 Einheiten 10 % (Bohnen+Tomaten), 15 % auf die deutschen Gurken und 30 % bzw. 50 % auf die spanischen Gurken. Kommen da jetzt auch noch möglicherweise beliebige Preise/Rabatte ins Spiel, dann gilt : Viel Vergnügen beim testen.

[angos]

JA, der Testaufwand für eine solche komplette Kalkualtion ist nicht Ohne (der ist sogar erfahrungsgemäß erschreckend hoch).

Ich verstehe noch nicht, wozu du für eine einmalige bestellung eine zusätzliche (du willst sogar drei) Tabelle brauchst. Der Rabatt wird der Position zugeordnet. Davon abgesehen muss auch in den anderen Fällen der Rabatt den Positionen zugeordnet werden, da dieser sich durchaus, auch bei ein un d dem selben Kunden/Produkt, ändert.
Man kommt nicht drumherum die Werte zu dem Dokument zu speichern, da sonst, wie du schon gesagt hast, ein erneuter Ausdruck, oder nur das Prüfen eines alten Dokuments (bezüglich zB einem neuen Angebot für den gleichen Kunden), falsche Werte liefert.

[AMaurer]

Es gefällt mir, wie sich die Diskussion entwickelt. Noch ein paar Meinungen und ich suche mir das aus, was mir am besten gefällt

Spaß beiseite:
Ich habe mal eine einfache Rechnungsverwaltung geschrieben. Eingangs- und Ausgangrechnungen wurden manuell erfasst. Die Ausgangsrechnungen sind per Excel geschrieben worden.

Da gab es die beschriebene Struktur: Kunden / Lieferanten / Banken / Zahlungsbedingungen usw. eben alles strukturiert. Normalisierung der DB kein Prüblem.

Jetzt handelt es sich um die Verwaltung im Sondermaschinenbau. Aktuell: Angebote per Word oder Excel / Lieferscheine / Rechnungen per Excel (bis vor 2 Jahren F&A in der DOS-Box - dort holt man sich immer noch die Auftragsnummern und erfasst Einkaufsartikel zu einem Auftrag).

Schaue ich mir die Angebote / Lieferscheine und Rechnungen an, dann kann ich verstehen, dass viel händisch gemacht wird.

Sondermaschinenbau und Sonderleistungen:
1) Angebotstext mit Leistungsbeschreibung 10 Seiten, 1 Preis, 4 Zahlungsziele. Lieferschein mit Lieferung der Anlage aber Rechnungen mit Abschlagszahlungen ohne Lieferschein usw.

2) Auftrag ohne Angebot - dringend - Reparatur, Bauteil eines Kunden, das überhaupt nicht zum eigentlichen Artikelstamm gehört. Erst Bauteil spezifizieren, Artikelnummer vergeben usw.?


Ich würde gerne auch die Struktur finden, in die das alles hinein passt ...

Es scheint mir aber schlicht unmöglich. Man müsste das System nicht vor der Erfindungsgabe der Systemanwender schützen, sondern vor der der der Kunden, die immer wieder neue Ideen umgesetzt haben wollen (... zum Glück ist das so, denn gerade aus können viele).

[jobo]

Ah, ich hab schon befürchtet, Du nimmst Dir einen Strick, wenn Du alles durchgelesen hast.

Wenn ich das richtig verstanden habe, ist das eine interne Entwicklung für den Eigenbedarf (Firma). Damit aus der Anwendung kein Zettelkasten wird und man sich nicht komplett verzettelt am Ende, sollte doch am Anfang so etwas wie Zeit- und Geld- und Personalbudget geklärt werden.
Dann eine Anforderungsliste mit Prioritäten und ein Abgleich von allem. Es wird wie immer viele Themen auf der Wunschliste geben und nur ein paar wenige, die in einem ersten Projekt von vielleicht 3 Monaten einfließen können. Zu den Themen gibt es ja massig Material im Internet, sowie Religionskriege über die jeweiligen Entwicklungsphilosophien usw..

Du solltest irgendwann zu einem detaillierten und wasserdichten Datenmodell kommen.
Dabei sollte unter anderem rauskommen, was z.B. kombinierte Feldinhalte (Artikelnummer mit Präfix usw.) bringen.
Ich weiß, dass es (früher) Usus war, in eine solche Nummer alles mögliche rein zu codieren. Jede Firma hat da eine eigene Philosophie/ Historie. Ein alter Hase aus der Produktion kann dann anhand der Nummer auf dem Lenkgestänge sagen, dass der Kalle die gebaut hat, auf Linie 3, an dem Montag nachdem er und seine Frau 40. Hochzeitstag gefeiert hatten. (Da war der Kalle noch nich wieder ganz nüchtern)
Das macht heute NULL Sinn. Man arbeitet mit technischen ID und mglw. zusätzlich mit menschen-lesbaren. Das hat fallweise durchaus seine Berechtigung, aber es spricht überhaupt nichts dagegen, solche Nummern dann virtuell aus verschiedenen Bestandteilen echter Daten (respektive echten Datenfelder) zusammenzusetzen. Dies kann sogar versionsübergreifend in verschiedenen Spalten dargestellt und suchbar angelegt sein. Solange es nur Formatanweisungen für virtuelle Spalten sind, kann man diese beliebig ändern und ist immer bereit für die skurrilsten Kundenwünsche, und natürlich für die standardisierte Verarbeitung der Daten, denn die entsprechen in Ihrer Struktur Deinem Entwurf und Deinen Regeln und greifen nicht auf seltsame, zusammengesetzte Codes zu, sondern auf die wirklichen Datenfelder.

Ganz grob solltest Du als Faustregel unterscheiden zwischen Feldern, die für automatisierte Abläufe, Standardreports, Rechnungsabteilung , .. nötig sind und daher stark kontrolliert und geregelt sein müssen und "Komfortfeldern", die einfach den Nutzen der Anwendung verstärken, ohne dass die Funktion davon >abhängig< ist.
Wenn Du einen guten Grundstein gelegt hast, kannst Du das nach und nach erweitern.

Ich vermute niemand hier wird Dir ein brauchbares Modell liefern können. Wenn Du zu einem bestimmten Entwurf kommst, oder zwischen 2 Szenarien entscheiden musst oder bei der Umsetzung einer bestimmten, präferierten Lösung Probleme hast, dann solltest Du das hier wieder vortragen.
Aber die Arbeit, ein solides, im Plan realisierbares Modell aufzustellen, kann Dir hier keine abnehmen. Und wie schon angerissen, es gibt nicht den einen, großen Wurf, selbst wenn Du Dir hier das beste aussuchst, Du wirst recht schnell die Mängel und Umsetzungsschwierigkeiten feststellen.

Und ganz nebenbei gibt es ja außer Deiner Frage nach dem Modell auch noch die Frage des Framework, mit dem Du das Frontend aufsetzt. Nicht zu unterschätzen, auch wenn das Forum eine gewisse Vorliebe erkennen lässt.

[AMaurer]

Jo:

Du hast das schon richtig erkannt. Zum Glück bin ich kein SQL-Newbie und hatte schon einiges mit DBs zu tun. Deshalb sollte das Modell, wenn die Ideen dann mal niedergeschrieben sind, kein Problem sein. Zudem ist das für mich ein wenig Hobby

Dass es DIE Lösung nicht gibt haben wir schon gemerkt, als wir uns unterschiedliche "Fertigprodukte" angeschaut haben. Die waren alle aufwendig anpassbar

Ansprochen auf die anderen Threads:
1. Ich habe mir myDAC heruntergeladen und ein wenig gespielt. Interessantes DBGrid mit Sortieren, filtern usw. feritg. Bei den ZEOs gibt des dieses DBGrid halt nicht ...

2. Trotzdem finde ich es schade, dass ich keine Report-Möglichkeit für die C-API-Version gefunden habe. Zumal RaveReport auch nicht gerade übersichtlich zu programmieren ist.

Ich finde den Quellcode mit C-API wenn auch länger, verständlicher als mit den grafischen Komponenten.

Ich werde also klein anfangen und versuchen möglichst schnell einen einfachen Nutzen zu erzielen.

Vielen Dank für Eure Hilfe.

Andreas