Tabellenaufbau Auftragsverwaltung praktischer Tipp

[AMaurer]

Hier Frage 3 zu meiner Auftragsverwaltung. Es handelt sich dabei mehr um einen Hinweis für eine Tabellenaufbau als um ein wirkliches Programmierproblem:

Beschreibung:
Unsere kleine Firma verkauft Artikel und Dienstleistungen. Die Artikel sind einem Artikelstamm erfasst. Es gibt Standarddienstleistungen (Servicestunden usw.) aber auch Sonderleistungen, die nur für diesen einen Auftrag geleistet werden und eigentlich nur händlich in die Arbeitspapiere eingetragen werden. Wie erfasse ich diese Leistungen geschickt in Tabellen, im Auftrag, im Lieferschein und in der Rechnung?

Bsp:
Pos 10, 2 Kugellager Typ xy Preis 30 €
Pos 20, 3 Servicestunden à x € = 3 * x €
Pos 30, 1 Lagersitzreparatur y €

Sicher hat jemand von Euch so etwas von einmal programmiert und kann mir den einen oder anderen Tipp geben.

Danke!

Andreas

[mkinzler]

Ich würde Dienstleistungen wie Artikel verwalten

[FredlFesl]

Jede Sonderleistung individuell?

Spendiere jeder Rechnungsposition einen optionalen Begleittext.

Dann ist die "Sonderleistung" ein Artikel, bei 'Menge' trägst Du die Stunden ein und im optionalen Begleittext die Beschreibung der Sonderleistung (Das 'Handgeschriebene').

[AMaurer]

... das bedeutet aber doch:

Bei einer Bestellung von Artikeln ist der Einzelpreis und die Bestellmenge bereits bei der Bestellung bekannt. Beim Serviceeinsatz nur der Stundensatz des Servicemonteurs. Bei der Sonderleistung nach Aufwand wird alles erst später bekannt, quasi mit dem Lieferschein bzw. der Rechnung.

Wo führe ich dann die Preise/Kosten?

Ich wollte diese bereits beim Auftrag in den Auftragspositionen mitführen. Die unbekannten Kosten abschätzen, so dass ich einen ungefähren Auftragswert habe, der vom Controlling verwendet werden kann.

Vielleicht ist es sinnvoll, wirklich alles in einer Tabelle zu führen und die Nummernkreise mit einem Präfix (A = Artikel, M = Monteur und S = Sonderleistung) übersichtlich zu gestalten. Damit könnten die Informationen für den User sogar in 3 unterschiedlichen Formularen geführt werden, die beim Auftrag, dem Lieferschein und der Rechnung "zusammenfließen".

Apropos: Preis und Kosten (auch für den Einkauf) in eine separate Tabelle, um Preisentwicklungen nachzuhalten?!

Viele Grüße

Andreas

[Jumpy]

Normalform-Konform würde zu einer Tabelle Artikel (in der zum Artikel auch der Verkaufspreis stünde) eine Tabelle Lieferanten gehören.
Diese beiden würden über eine dritte Tabelle Artikel-Lieferanten verknüpft, in der dann auch die EK-Preise festgehalten würden.

Deine Idee ist nun den Verkaufspreis nicht in der Tabelle Artikel zu haben, sondern auszulagern, um auch eine Art Historie der Preisentwicklung zu haben. Dies geht natürlich schon, doch musst du darauf achten, das nur einer der zu einem Artikel angegebenen Preise der aktuell gültige ist.
Alternativ kann man natürlich auch den Preis in der Tabelle Artikel belassen und seine DB oder Anwendung so programmieren, das wenn dieser Preis geändert wird, der alte Preis (mit einem passenden Datum) in einer Tabellen "Preise_Alt" oder so gespeichert wird.

Wenn man beginnt, solche Funktionalitäten einzubauen, kann der Spaß schnell komplex werden.

[jobo]

Ich würde das niemand antun, bei einer NEU(!)-Entwicklung mit Präfixen auf Nummern, Inhaltsverdrehungen (Stunde statt Stückzahl) usw. loszulegen! Never ever! Speicherplatz sollte heutezutage nicht das Problem sein und kann kein Grund für solche "Maßnahmen" sein..

Natürlich wird auf den ersten Blick das Datenmodell komplexer, aber Du "erntest" einfache Zugriffe auf Daten, Datenschreiben, Datenlesen, Reporting, Rechnungsstellung, Kontrolling, etc pp.
Was Du Dir mit einem redundanten Datenmodell einhandelst, bzw. dem Interpretationszwang, den Du da reingießt, badest Du später bei Programmierung, Maskenaufbau, Reporting mit endlosen if/then/else/decode/case Geschichten wieder aus. Nix gewonnen, nur verloren (Außer Du betrachtest das als Arbeitsplatzsicherung).

In Rechnung/bzw. Auftrag gehören Positionen, die Positionen stehen für Produkte (darunter können auch Dienstleistungen fallen). Dienstleistung nach Aufwand ist logischer Weise nicht zu bepreisen.
Waren gehen evtl. auf Kommision raus, werden darüber berechnet und ggF. rückerstattet. (beispielsweise)

Waren und Dienstleistungen unterscheiden sich durch eine entsprechende Klassifizierung (vlt noch weitere). Preise haben je Produkt eine Bezugsgröße als Einheit (Stunden, Stück, Kilo, laufende Meter usw. ) außerdem auch eine Mehrwertsteuerklasse, vlt. Rabatte usw usw.

Ich würde versuchen, mit einem kleinen, sauberen Modell anzufangen, was nach Bedarf ausgebaut wird. Freitexte sind schön und hilfreich für den Anwender, wenn sie ordentlich verwendet werden. Sie sollten aber nicht als Spielwiese für Maschineninterpretation und KI-Geschichten in den Workflow der Firma eingebunden sein.

[JohannesK]

Ich denke der Ansatz von Jumpy ist der effizienteste, da spätere Erweiterungen einfach und schnell zu realisieren sind.
Redundante Informationen in der gleichen Tabelle geben schnell Chaos.

Wir haben bei uns genau die gleiche Problematik und unser System über eine Struktur wie folgt aufgebaut:

Projekt/Auftrag
|-Rechnung 1
|-Rechnung 2
|-Position 1 ...

Artikel kommen aus Artikeltabelle (egal ob Dienstleistung oder Produkt), Lieferanten aus Lieferantentabelle, Preise aus Zuordnung Lieferant-Produkt.
Preishistorie etc. ist einfach und sicher dokumentiert, gleicher Stamm wird für Bestellwesen usw. verwendet.
Angebotstexte werden auch in einer eigenen Tabelle geführt.
Zusatzfunktionen wie die Bereitstellung von Daten für einen Webshop haben wir nachträglich einfach integriert.

Funktioniert sicher und ist flexibel. Für die Stammdatenpflege muss man natürlich ein wenig strukturiert arbeiten.

[AMaurer]

Eines vorab:
es ist nicht die erste DB, die ich erstelle. Vorher im Finanzbereich. Da war aber alles klar strukturiert. Jetzt gibt es Varianten bei deren Erfassung/Verarbeitung ich mir schwer tue.

@JohannesK:

Wenn ich Dich richtig verstanden habe, dann führt Ihr alles in einer Tabelle (Artikel und Dienstleistungen). Ihr vermischt also auch Stück und Stunden.

Dann hat aber eine Serviceleistung eine Artikelnummer oder wie zieht ihr diese bei der Auftragserfassung an? Was ist mit den Sonderleistungen? Die behandeln wie die Serviceleistungen und aus dem Artikelstamm ziehen oder sind das dann eher Teile der Angebotstexte?

Wie bereits geschrieben, kann die Bescheibung der Sonderleistung sehr ausführlich und lang sein.

Außerdem kann ein Auftrag auch rein aus einer Sonderleistung bestehen.
Anderseits können eine Menge Artikel in der Rechnung unter einer Position Ersatzteile zusammengefasst werden.

...

[JohannesK]

Wir führen alles als Artikel - auch Dienstleistungen, d.h. eine Dienstleistung hat eine Artikelnummer. Jeder Artikel hat auch Standardtexte, bis hin zu mehrseitigen Beschreibungen für Angebote. Im Normalfall wird der Standardtext übernommen. Weicht die Leistung von diesem ab, kann individuell für eine Rechung editiert werden, es wird auch grundsätzlich immer der effektive Rechnungstext abgelegt, nicht der Standardtext.
Jeder Artikel/Dienstleistung hat als Eigenschaft auch eine Verwendungseinheit in der die Verwaltung in der MaWi und auch die Fakturierung erfolgt. Wir haben also Stück, kg, Stunden, Liter usw. Die Preishistorie wird in €/ Verwendungseinheit oder Mehrfachen/Bruchteilen davon geführt (z.B. €/1000 Stück).

Bei Zusammenfassung mehrerer Positionen kann man mit Stücklisten und einem Summenpreis arbeiten.
Der Umfang der jeweils gedruckten Texte lässt sich ggf. über Flags in den Auftragspositionen regeln.

[AMaurer]

Das hört sich erst einmal gut an.

Vielleicht ist das in dem zuvor schon geschriebenen falsch verstanden worden:

Was spricht dann dagegen, dass ich der Artikelnummer ein Präfix mitführe. Der Benutzer merkt das doch nicht, da er in verschiedenen Formularen die gleiche Tabelle füllt.

Alternativ könnte ich ein Gruppierungsfeld mitführen für Artikel / Dienstleistung / Sonderleistung, um Auswertungen möglichst einfach zu machen.

[JohannesK]

Gruppierung ist immer gut für Auswertungen.
Wir führen zwei jeweils dreistufige, hierarchisch geordnete parametrierbare Gruppierungen mit, alle Auswertungen können damit strukturiert werden.
Beispiel:
Einkaufskategorien
Obergruppe Rohstoffe

Gruppe Malz

Untergruppe Gerstenmalz

Verkaufskategorien
Obergruppe Dienstleistungen

Gruppe Inbetriebnahme

Untergruppe Schulung

Dagegen dass ein Präfix Teil einer sprechenden Artikelnummer ist, spricht m.E. nichts. Wir haben damit eigentlich nur gute Erfahrungen gemacht. DL-INST-V-001 ist doch für Menschen verständlicher als 32490983232 :)

[AMaurer]

Na dann Prost ;-)

Vielen Dank für die Hilfe!

Andreas

[p80286]

Zitat:

Zitat von AMaurer (Beitrag 1104785)

Was spricht dann dagegen, dass ich der Artikelnummer ein Präfix mitführe. Der Benutzer merkt das doch nicht, da er in verschiedenen Formularen die gleiche Tabelle füllt.

a) spätestens wenn das einmal sinnvolle Präfix von der Entwicklung überholt wird, wirst Du bemerken, daß das nicht das Gelbe vom Ei ist!

b) Benutzer sind manchmal fixer als Du glaubst.

Ansonsten die knappe Skizze von Jobo scheint mir der beste Ansatz zu sein.
Und noch mal für die langsameren. Wer wichtige Informationen in Freitextfeldern unterbringt ist auf dem besten Wege einen elektronischen Zettelkasten zu basteln.
Das ist der Tod jeder Datenbank!
(Es soll auch heute noch Leute geben, die Name und Vorname, ganz zu schweigen von Adels- und akademischen-Titeln in ein Feld packen)

Gruß
K-H

[AMaurer]

@p80286

Ich verstehe Deinen Einwand. Die Frage ist aber doch die Alternative. Wenn ich mir unsere Aufträge anschaue, dann würden ohne Freitextfelder weiterhin 60% mit Word geschrieben werden, weil sich die Sonderleistungen nun mal nicht in einen festen Rahmen pressen lassen.

Ich bin hier wirklich für jeden praktischen Tipp dankbar.

Wenn ich JoBo richtig verstehe: Dann nichts mischen. Okay. Dann ziehe ich aber Auftragspositionen aus verschiedenen Tabellen (Artikel, Dienstleistung usw), oder?

[JohannesK]

Zitat:

Wer wichtige Informationen in Freitextfeldern unterbringt ist auf dem besten Wege einen elektronischen Zettelkasten zu basteln. Das ist der Tod jeder Datenbank!

@p80286:
Völlig richtig, drum sollten Kategorien usw. nie in Textfeldern verwaltet werden sondern über eine Referenztabelle und Lookups, gespeichert werden nur die Referenz-ID's. Die Vorstellungen von Anwendern sind in dieser Hinsicht manchmal haarsträubend - "es geht doch in Outlook auch ..".

Zitat:

spätestens wenn das einmal sinnvolle Präfix von der Entwicklung überholt wird, wirst Du bemerken, daß das nicht das Gelbe vom Ei ist!

Die endgültige Artikelnummernsystematik habe ich bis jetzt noch nicht gefunden. Ein System unterliegt immer irgendwelchen Veränderungen. Wichtig sind eine ausreichende Feldgrösse und eine einfache Möglichkeit über entsprechende Routinen ein Nummernsystem auch anpassen zu können. Am einfachsten werden ohnehin nur die Tabellen-ID's als Referenz verwendet. Gibt ein bisschen mehr Abfrageaufwand aber es lohnt sich bei Datenanpassungen immer.

@AMaurer

Zitat:

Dann ziehe ich aber Auftragspositionen aus verschiedenen Tabellen (Artikel, Dienstleistung usw), oder?

Hat m.E. damit nichts zu tun.

Zitat:

Die Frage ist aber doch die Alternative. Wenn ich mir unsere Aufträge anschaue, dann würden ohne Freitextfelder weiterhin 60% mit Word geschrieben werden, weil sich die Sonderleistungen nun mal nicht in einen festen Rahmen pressen lassen.

Standardtext = Vorgabe eines Textbausteins, auch bei Sonderleistungen. Definitiver Text = effektiv erbrachte Leistung. Mit Freitextfeldern im Sinne der Datenstruktur und Indizierung hat das nichts zu tun, irgendwo muss die Leistung ja definiert werden.

@p80286:
Das hier gemeinte Freitextfeld beinhaltet lediglich die genaue Definition dessen, was beim Kunden geleistet wurde. Von daher geht es hier nicht anders - gewisse Dienstleistungen sind nicht in ein Schema zu pressen.

Die Auswertung läuft doch sicher über eine gewisse Gruppe von Sonderleistungen und deren Artikelnummern sowie die Rechnungsdaten.

[p80286]

Das kommt auf die Struktur der Dienstleistung an.
sobald man eine Dienstleistung in verschiedene Elemente aufteilen kann, die immer wieder erbracht werden, dann "Freitext ade".
Das die Benutzer / Erfasser dann natürlich stöhnen und schimpfen, kann dir egal sein, denn die wollen hinterher auch nicht wissen, wie sich ein Aftrag zusammen gesetzt hatte.
"Sonderleistungen" ist doch nichts unmögliches! Es wird nur nicht jeden Tag gemacht.

Du solltest eine Tabelle "Aufträge" und dann jeweils eine Tabelle "Dienstleistung" und "(Eigen)Produkte", "(Fremd)Produkte " usw. nutzen, aus denen sich Deine "Aufträge" zusammen setzen.

Gruß
K-H

[p80286]

Zitat:

Zitat von JohannesK (Beitrag 1104805)

Mit Freitextfelder im Sinne der Datenstruktur und Indizierung hat das nichts zu tun, irgendwo muss die Leistung ja definiert werden. Das hier gemeinte Freitextfeld beinhaltet lediglich die genaue Definition dessen, was beim Kunden geleistet wurde.

Da hab ich so meine praktischen Zweifel. Wenn man Benutzer nicht dazu zwingt bestimmte Informationen zu erfassen, dann "steht das doch da, das ist doch damit gemeint"

Gruß
K-H

[AMaurer]

@80286.

Verstanden!

Wie ziehe dann technisch bei einer Auftragsposition mal aus der mal aus der anderen Tabelle meine Daten?

Über ein Feld indem ich den Inhalt der Position auswähle: zB. Artikel eigen, Aritkel fremd, Dienstleistung, Sonderleistung usw.?

[mkinzler]

Z.B. durch weiteres Feld in der Positionstabelle, welches angibt auf welche Feld der FK weist

[JohannesK]

Zitat:

Da hab ich so meine praktischen Zweifel. Wenn man Benutzer nicht dazu zwingt bestimmte Informationen zu erfassen, dann "steht das doch da, das ist doch damit gemeint"

Widerspricht sich das wirklich?
Lässt sich eine Dienstleistung in konkrete Schritte zerlegen, gibt es für jeden Schritt eine Artikelnummer, völlig einverstanden.
Alles was strukturierbar ist, gehört auch strukturiert abgelegt: Artikelnummern, Preise, Stückzahlen, Lieferdatum usw. Hier darf der Benutzer keinesfalls irgendwelche Freiheiten haben.

Anders ist doch die Situation wenn geringfügige Anpassungen an einem beschreibenden Text vorgenommen werden. Wird bei kleinen Textanpassungen jedesmal ein neuer Artikel eröffnet, ufert das System aus und die Anwenderakzeptanz sinkt.

Der Aufbau, den ich beschrieben habe funktioniert bei uns bestens für so unterschiedliche Themenkreise wie Software, Anlagenbau und Handel. Aufgrund der dahinterliegenden Artikelsystematik können wir auch aussagefähige Auswertungen machen. Im konkreten Fall ist es in einem kundenspezifischen Projekt doch egal, ob ich eine Schnittstelle über Datenbankzugriff, ActiveX oder Filetransfer realisiere. Ich will wissen, wieviel Umsatz mit Scnittstellen gemacht wurde und welcher Aufwand dagegen steht.

Ich verstehe den Einwand gegen Freitext durchaus, ich bin auch kein Freund davon weil einiges an der Disziplin der Benutzer hängt. Letztendlich muss Flexibilität gegen engmaschige Struktur abgewogen werden.

Einen Grund für getrennte Tabellen für Produkte und Dienstleistungen sehe ich immer noch nicht, das macht das System nur komplizierter.

[p80286]

Zitat:

Zitat von JohannesK (Beitrag 1104814)

Zitat:

Da hab ich so meine praktischen Zweifel. Wenn man Benutzer nicht dazu zwingt bestimmte Informationen zu erfassen, dann "steht das doch da, das ist doch damit gemeint"

Widerspricht sich das wirklich?

Leider ja!

Zitat:

Zitat von JohannesK (Beitrag 1104814)

Anders ist doch die Situation wenn geringfügige Anpassungen an einem beschreibenden Text vorgenommen werden. Wird bei kleinen Textanpassungen jedesmal ein neuer Artikel eröffnet, ufert das System aus und die Anwenderakzeptanz sinkt.

Wenn "geringfügige" Anpassungen notwendig sind, stimmt etwas mit der Grundstruktur nicht.
Neben der Diziplin der Anwender, die Vorraussetzung für die ordentliche Datenerfassung ist, darfst Du auch nicht vergessen, daß die unter Windows im allg eingesetzten Fonts es leicht machen, zwei Leerzeichen für eines zu halten usw.. Wer Da nicht mit Arial Monospace oder Courier vorbeugt, hat eigentlich schon gleich verloren.
Wenn Freitext, dann unbedingt in ein Kommentarfeld.
(Und diese sind "natürlich" nicht recherchierbar)

Gruß
K-H

[JohannesK]

Zitat:

Wenn Freitext, dann unbedingt in ein Kommentarfeld.

Ich denke wir sind nicht wirklich unterschiedlicher Meinung. Alle Kriterien nach denen gefiltert, gesucht, indiziert oder ausgewertet wird dürfen natürlich keinen Freitext enthalten. Die grundlegende Artikel(oder Dienstleistungs-)definition gehört in den Artikel.

Ich mache mal ein banales Beispiel:
Artikel "DL-IMP-1234"; "Importroutine für Daten aus einer csv-Datei"; Einheit: Stück;
Grundtext:
"Import von 4 Datenspalten aus einer csv-Datei, Delimiter Semikolon"

Jetzt wird eine Dienstleistung erbracht bei der 5 Spalten importiert werden und der Preis geringfügig anders ist. Rechtfertigt das einen neuen Artikel oder steht im Auftragstext (und nur im konkreten Auftrag) einfach
"Import von 5 Datenspalten aus einer csv-Datei, Delimiter Semikolon" ?

Artikelnummer "DL-IMP-1234" und Artikelbezeichnung "Importroutine für Daten aus einer csv-Datei" ändern nicht, nur der ergänzende, beschreibende Text.

Das meine ich mit geringfügigen, auftragsbezogenen Anpassungen. Wenn der gleiche Artikel verwendet wird für z.B. einen Export einer csv stimmt wirklich was mit der Struktur nicht.

Hier sind natürlich betriebliche Vorgaben nötig, wie und wann ein eigenständiger Artikel definiert wird. Die Software muss sich dem durch editierbare oder eben nicht editierbare Felder anpassen können - von strikt bis eher leger.
Die Verantwortung für den Grad der Flexibilität liegt bei der Geschäftsleitung des Anwenders und nicht bei der Software. Diese hat aber möglich Nachteile fehlender Strukturen klar zu benennen.

Gruss,
JK

[Jumpy]

Was Artikel, Dienstleistung usw. in einer Tabelle angeht. Es hindert einen ja nichts daran, dieser Tabelle ein weiteres Feld "Kategorie" oder so mitzugeben, bei dem dann eingstellt wird, um was es sich handelt. Im Gebrauch ist es doch eh so, das man eine Position angeben möchte und sich zunächst über Kategorien o.ä. zum Gewünschten hangelt, wobei jede Auswahl die Ergebnisse einschränkt, so dass man schnell dahinkommt wohin man möchte.

Eine Alternative zum Abändern von Standardtexten könnten abschließende Kommentare sein, ähnl. wie Fußnoten, z.B. "Zu Position 3: Abweichend wird ein 2m langes Kabel mitgeliefert."

Sonderfälle sind dann immer so eine Sache. p80286 zufolge, kann man alles (alle Workflows z.B.) so aufspalten, das man auch vermeintliche Sonderfälle daraus zusammenbauen kann. Das erfordert sehr viel Vorarbeit und Analyse dessen was man denn in der Praxis so macht und ist für kleine Firmen, wo mal eben für eine Sonderleistung ein Preis geschätzt wird, sicher aufwendig. Umgekehrt ist es natürlich auch Aufwendig, jedes mal einen neuen Sondertext zu verfassen, so dass sich der Aufwand schon irgendwann lohnt.

Am praktischsten ist daher der goldene Mittelweg wie von JohannesK: Soviel standardisieren wie möglich, und so wenig individuelle Abweichungen wie möglich.

[p80286]

Zitat:

Zitat von JohannesK;1104832Ich mache mal ein banales Beispiel:
Artikel "DL-IMP-1234"; "Importroutine für Daten aus einer csv-Datei"; Einheit: Stück;
Grundtext:
"Import von 4 Datenspalten aus einer csv-Datei, Delimiter Semikolon"

Jetzt wird eine Dienstleistung erbracht bei der 5 Spalten importiert werden und der Preis geringfügig anders ist. Rechtfertigt das einen neuen Artikel oder steht im Auftragstext (und [B

nur[/B] im konkreten Auftrag) einfach
"Import von 5 Datenspalten aus einer csv-Datei, Delimiter Semikolon" ?

Artikelnummer "DL-IMP-1234" und Artikelbezeichnung "Importroutine für Daten aus einer csv-Datei" ändern nicht, nur der ergänzende, beschreibende Text.

Auch wenn es übertrieben erscheint, die 4 oder 5 sollten in einem Feld "Anzahl" gespeichert werden.
Denn spätestens wenn solche Aufträge zu Dutzenden kommen will niemand mehr jeden Text lesen, sondern die Daten "Maschinengerecht" vorliegen haben.

Ansonsten eine Geschäftsführung muß ja auch eine Daseinsberechtigung haben ;-)

Gruß
K-H


Edith:

Zitat:

Was Artikel, Dienstleistung usw. in einer Tabelle angeht. Es hindert einen ja nichts daran, dieser Tabelle ein weiteres Feld "Kategorie" oder so mitzugeben, bei dem dann eingstellt wird, um was es sich handelt.

Sobald unterschiedliche Bezugsgrößen (Stunden/Anzahl) ins Spiel kommen, könnte das schief gehen! GGf kann man spezifische Bezugsgrößen ja auch in eine weitere Tabelle auslagern.

[JohannesK]

Ich denke so eine Lösung schafft mehr Unübersichtlichkeit als Ordnung. Im Beispiel wurde ja die Dienstleistung nicht 4- oder 5-mal verkauft sondern nur einmal mit geringfügig anderer Ausgestaltung.
Wird z.B. ausgewertet über die Anzahl der verkauften Artikel, gibt das eine falsche Aussage - im Beispiel wären dann 9 Schnittstellen verkauft worden und nicht 2.

Bei materiellen Gütern funktioniert es natürlich, aber Dienstleistungen lassen sich nicht in einem gleich starren System behandeln.

Gruss

[p80286]

Zitat:

Zitat von JohannesK (Beitrag 1104838)

Wird z.B. ausgewertet über die Anzahl der verkauften Artikel, gibt das eine falsche Aussage - im Beispiel wären dann 9 Schnittstellen verkauft worden und nicht 2.

Da hast Du recht, weil in diesem Fall das "Volumen" der Dienstleistung beschrieben wurde und nicht die "Anzahl" der Dienstleistungen.

Ein Grund mehr, sich genau zu überlegen welche Daten erfassungswürdig sind.
Wenn ein Feld je nach Kathegorie/Gruppe anders interpretiert wird, ist das Sparsamkeit am falschen Platz.

Gruß
K-H

[Hansa]

Zitat:

Zitat von AMaurer (Beitrag 1104777)

Ihr vermischt also auch Stück und Stunden.

Deshalb geht man ja auch hin und spendiert jedem Artikel eine Stückbezeichnung. Also "Stück", "St.", "kg".

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. Auch hier gilt Verknüpfung Text -> Rechnungspos. über ID der Rechnungspos.und Texte kommen natürlich auch in eigene Table. 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.

Alles andere ist zu unflexibel. Das wird von den Usern nicht akzeptiert. Die sind erfinderischer, als man denkt!

[JohannesK]

Hansa bringt es im wesentlichen auf den Punkt.

Zitat:

Zitat von Hansa (Beitrag 1104846)

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:

Zitat von Hansa (Beitrag 1104846)

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:

Zitat von JohannesK (Beitrag 1104853)

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. :lol:

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. 8-) 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. :mrgreen: 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. 8-) Ach ja, den Artkel gabs auch schon : __________________________ :mrgreen:

[JohannesK]

Zitat:

Zitat von Hansa (Beitrag 1104865)

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:

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.

Zitat:

Zitat von Hansa (Beitrag 1104865)

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 :mrgreen:. Wobei Artikelbezeichnungen aber eindeutig nur in den Stammdaten geändert werden dürften.

[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