Tabellenaufbau Auftragsverwaltung praktischer Tipp

[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.

...