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.