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.