Tabellenaufbau Auftragsverwaltung praktischer Tipp

[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

[Sir Rufo]

MyDAC vs. C-API:

Die "grafischen" Komponenten muss man ja nicht als "grafische" Komponenten nutzen, macht aber teilweise durchaus Sinn.
Man kann diese auch zur Laufzeit erzeugen. Dann wird der Quellcode auch länger ;)

RaveReport:

Mit dem Teil habe ich nie Freundschaft geschlossen. Da ist FastReport wesentlich einfacher im Handling.
Zumal der FastReport-Desinger in die Anwendung eingebaut werden kann und die Reports vom Anwender angepasst werden können.

Negative Punkte bei FastReport:

RTF-Objekte werden als Grafik exportiert.

Die erzeugten PDFs sind dermassen miserabel, dass die nur mit dem Acrobat Reader angezeigt werden können.
Die Vorschau von OSX zeigt viele Sachen gar nicht an (z.B. Text mit fett oder kursiv wird nicht angezeigt).
Ein Import solch einer PDF lässt QuarkXPress abstürzen.

Ein Blick in die PDF-Datei selber offenbart dort dann auch die gesamte Grausamkeit ...

Nun ja, ein Ausdruck über einen PDF-Drucker und alles ist schick :)

Zum Thema Artikel/Dienstleistung will ich auch noch mal meinen Senf dazugeben:

Der Unterschied zwischen einer Dienstleistung und einem Artikel ist doch einzig allein der, dass es bei einer Dienstleistung niemals einen Lagerbestand gibt.
Somit ist eine Dienstleistung ein Artikel ohne Bestandsführung.

Entscheidend ist doch nur, dass die Preise für die jeweilige angegebene Preiseinheit gelten.
Und eine Dienstleistung hat dann halt eben die Einheit Stunden und die Preise müssen dann eben pro Stunde angegeben sein.

Mathematisch betrachtet sieht man dann auch warum:

Code:

10h x 40,00€/h = 400,00€ h/h = 400,00€
20km x 0,50€/km = 10,00€ km/km = 10,00€
5Stück x 3,00€/Stück = 15,00€ Stück/Stück = 15,00€

Aus diesem Grund ist auch ein Merkmal ob es sich um eine Dienstleistung oder einen Artikel handelt für die Basisfunktion überflüssig.
Für die Auswertung wäre das etwas anderes, aber da würde ich eher auf Warengruppen setzen und eine Warengruppe heisst dann eben "Dienstleistungen".

[AMaurer]

Die Integration der Dienstleistungen in die Artikel ist klar. Und dass jeweils nur die IDs verknüpft werden ist auch logisch. Die Sonderleistungen unterscheiden sich aber eben von Auftrag zu Auftrag und sind in keinen Rahmen zu pressen, oft pauschal und das macht mir die Vorstellung so schwer ...

Komponenten - C-API

Es geht mir bei der Verwendung der C-API nicht um langen Quellcode. Man weiß aber eben an jeder Stelle was da gerade passiert. Als Alternative hatte ich nur die kostenlosen ZEOs in der Alpha-Version mit allen Hinweisen in den Foren. Deswegen der Schwenk zu C-API.

Danke auch für den Hinweis zum ReportGenerator.

Dass ich jetzt aber zweimal Geld ausgeben soll (myDAC und FastReport) damit hat bei uns niemand gerechnet :oops:

[Jumpy]

Ist myDac nicht für MySQL? War nicht in einem der anderen Threads von MySQL abgeraten worden, wg. der Lizenz (oder war das ein anderer TE)? Bei einer anderen DB ständen ja evtl. andere Komponenten an.

Falls das ein anderer TE war: Es ging ja darum das MySQL nicht mehr kostenlos ist, sobal du es für ein kommerzielles Produkt benutzt. Ist evtl. bei dir ja nicht der Fall, da du ja eine Inhouse-Lösung entwickelst, aber aus dem was ich bei uns schon gelernt habe: Auch Inhouse-Lösungen kosten Zeit und Geld und man sollte sich die Option offen lassen, das Ergebnis auch zu Verkaufen, wenn einem was wirklich brauchbares gelingt.

[DeddyH]

Lizenzgebühren für MySQL fallen nur dann an, wenn das Programm nicht OS ist und die libmysql.dll verwendet (verkürzte Darstellung des Sachverhaltes, im Zweifel bei MySQL nachlesen). MyDAC benötigt diese DLL AFAIK nicht, deshalb hat man auch kein Lizenzproblem.

[Bernhard Geyer]

Zitat:

Zitat von DeddyH (Beitrag 1105007)

MyDAC benötigt diese DLL AFAIK nicht, deshalb hat man auch kein Lizenzproblem.

Genau. Jedenfalls hat man dieses Lizenzproblem nicht.

Jetzt gäbe es nur noch das Problem wenn man nur MySQL unterstützt und die App ohne DB nicht läuft und Closed Source hat. Hier hat MySQL (und vermutlich Oracle) eine etwas besondere Art von GPL-Definition. Und im Zweifel hat Oracle die besseren Anwälte bzw. den längeren Atem.

[Klaus01]

.. nicht so weit verbreitet postgreSQL aber ohne Lizenzgebühren zu benutzen und auch nicht schlechter als mySQL.

Grüße
Klaus

[angos]

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

Zitat:

Zitat von Hansa (Beitrag 1104865)

Zitat:

Zitat von Hansa (Beitrag 1104865)

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