Office: Auftragsverwaltung

Hallo,
Es würde mich freuen, wenn mir jemand zu u. abgebildetem Tabellenaufbau sagen könnte, ob ich damit glücklich werde.
Was ich darstellen möchte ist Folgendes:
Zu einem Auftrag gehören n Positionen
Zu einem Auftrag können n Belege verschiedener Art gehören
Zu jedem Beleg gehören wiederum n Positionen (in diesem Fall eine Teilmenge der Auftragspositionen)
Bitte entschuldigt, dass die Schlüsselfelder nicht gekennzeichnet sind, ergibt sich IMO aber aus den Beziehungen.
Vielleicht noch ein Wort zur Indexierung, da ich mir da auch unsicher bin.
Und zwar habe ich einen Mehrfelder-Index in Belege über "BelegArt" und "BelegNr" (da alle Belege den gleichen Nummernbereich belegen, - 1 bis n), und einen in PosBeleg über die vier Nummern-Felder.
Deshalb musste ich auch diese beiden Tabelle so verknüpfen wie dargestellt, da ich noch nicht herausgefunden habe, wie man einen Mehrfelderschlüssel 1:n verknüpft (wenn das überhaupt geht).
Wie Anfangs bereits gesagt, würde ich mich über Kommentare/Verbesserungen/Belehrungen freuen.
gruss ekkehard

:)

 

Hi,

die Beziehungen ergeben einen Kreis. Die Belege sind doch schon über den Weg Beleg-PosBeleg-PosAuftrag-Auftrag an den Auftrag gekoppelt. Die Zusatzkopplung der Belege direkt an den Auftrag ist damit widersinnig, da sie der anderen Zuordnung zuwiderlaufen könnte.

Belege selbst haben m.E. gar keinen direkten Auftragsbezug, sondern erhalten diesen erst über die Positionen.

Oder liege ich da falsch?

Wenn die 2 bzw. 4 Felder eindeutig sein sollen, müssen die deshlab nicht zwingend auch Primärschlüssel sein. Ein eindeutiger Index genügt, um Duplikate zu verhindern. Die Einbindung ins Beziehungsmodell sollte aber immer anhand möglichst kurzer und möglichst künstlicher (Schlüssel)felder erfolgen, da fachliche Schlüssel (Belegart/Nr) dazu neigen, sich mitunter zu ändern. Das hat dann u.U. unangenehme Folgen.

http://beyondrelational.com/quiz/sql...tural-key.aspx

Ums kurz zu machen: Primärschlüssel ist eine datenbanktechnische Anforderung. Eindeutigkeit ist eine geschäftslogische Anforderung. Für beides gibt es getrennte Lösungen.

Ceterum censeo: Beim Thema Nummernkreise beginne ich immer leicht zu würgen. Warum, zum Kuckuck, sollte man sich begrenzen in den Nummern? Was machst du, wenn der Nummernkreis platzt oder die darin abgebildeten Infos reorganisiert werden sollen? Nummernkreise sind Mist. Immer. Was immer sie darstellen sollen, gehört in separate Felder, alles andere ist Pfusch.

 

Hallo Martin,
Danke für Deine Anmerkungen/Erläuterungen.

Du meinst es so wie jetzt unten dargestellt?

Leuchtet ein, die Teilmenge an Positionen aus PosAuftrag ergibt einen Beleg. Der gehört für mich aber schon irgendwie zu dem Auftrag.

Sind sie ja auch nicht. Die PK in den vier Tabellen sind alle Autowert.

Wie würdest Du also die beiden Tabellen "PosBeleg" und "Belege" verknüpfen?

Ist bekannt, schreibst Du ja oft genug *wink.gif* .

Na, ich halte einen Longwert für Belegnummern nicht gerade für begrenzend; - jedenfalls nicht bei 500 Belegen/Monat. Da seh' ich auch so schnell keinen Platzer. Zu reorganisieren gibt es da IMO auch nichts, Belege sind Belege, Kunden sind Kunden, Artikel sind Artikel, und die haben eine Nummer, und die ändert sich nicht.

Angekommen.

Was meinst Du? Separat vom PK?

Eine Anschlussfrage hätte ich noch.
Das Feld "Lagerort" in "PosAuftrag". Müsste das nicht eher in die Tabelle "PosBeleg"? Spielt zwar z.Zt. keine Rolle, da nur ein Lager(ort) verwaltet wird, aber wenn es mal mehrere geben sollte, kann es ja auch sein, dass ein Artikel an mehreren Orten lagert, und dann müsste man die Positionen ja splitten, was so wie jetzt nicht möglich ist. Liege ich da richtig?

Nochmals Danke.
gruss ekkehard

 

Ja.

Das Irgendwie ist ja über den benannten "Pfad" schon gegeben. Eine Abkürzung (zweiter "Weg" des Belegs zum Auftrag) darf es da aber nicht geben, weil dieser Weg denselben Beleg zu einem anderen Auftrag routen könnte, was er nicht darf.

Autowerte sind gute Kandidaten für PK. Müssens aber nicht sein.

Autowert-PK der einen mit Long-FK der andren.

Dann ist das ja auch wohl kein Nummernkreis. Longs, die keinen inneren Aufbau haben, sind gute Belegnummern. Aber wenn du der 1. Stelle irgendwas ansehen willst oder die Stornos im Beriech 5xxxxx liegen müssen, ist das eine Nummernkreis, vulgo die Pest.

Die "Bestandteile" eines für mich immer noch in Rede stehenden Nummernkreises.
Beispiel: Es seien Belegnummern 1-500 = rote Belege, 501-1000 = grüne Belege -> Belegfarbe einführen, Nummernkreise abschaffen

Zum Lager: ein Lager sollte sich nicht dafür interessieren, für welche Aufträge es Artikel hat. Ein Lager enthält Artikelmengen, Ende. Jeder Request einer Artikelmenge für einen Auftrag muss dann on demand zusammengestellt werden, es ist dabei herzlich egal, von welchem Regal die Artikel genommen wurden. Diese Inforamtion ist nur in dem Moment relevant, wo der Lagerist ein Riesenlager ablatschen muss, um den Artikel zu finden. Aber sobald der Auftragsartikel an die Produktion ausgeliefert ist, ist das obsolet.

Kurz:

• "Gib mir für Auftrag 4911 bitte 5 Schrauben M6x80, egal woher." -> Planung
• "Ich hole die Schrauben aus Regal 45, egal wofür". -> Lager

 

Hallo Martin,
Danke nochmal für Deine Ausführungen, sind soweit alle amgekommen und verstanden.

Ja, da bin ich völlig Deiner Meinung, aber

Woher bekommt der Lagerist denn die Info, wo er hinlatschen muss, wenn nicht von einer Packliste (Beleg!)? Und die Mengen müssen ja auch vom richtigen Lagerort abgebucht werden.
Hm, wo ich das jetzt so fragend schreibe, scheine ich da auch schon auf die Lösung zu kommen; - ich kann mir die Daten ja aus der Lagerverwaltung anhand der Artikelnummer bei Bedarf dazu holen. Sollte klappen. Falls nicht, melde ich mich wieder *wink.gif* .
gruss ekkehard

 

Hi,

der Lagerist muss natürlich wissen, wo wieviele Stücke welchen Artikels lagern. Das weiß er über ein Inventar/Lagerliste, das er selbst (!) fortschreiben kann (Summe aller Lagerumschläge).

Der Lagerist muss nicht wissen, wofür die Artikel requestet werden. Er bekommt lediglich die Anforderung: 4 Schrauben M6x80. Die holt er aus den (nur ihm bekannten) Lagerorten, händigt sie aus und erzeugt neue Umsätze im Lagerbuch ("Platz R/25, Artiikel 4811, M6x80, minus 4 Stück"). Damit ist sein Part erledigt. Und der Produktionsmensch muss sich nicht scheren, woher die Schrauben im Lager kommen oder wie viele noch da sind, das weiß das Lager. Neue Aufträge können sofort mit dem Bestand verglichen werden, um ggf. Nachschub zu ordern.

Außerdem hab ich eine nette kleine Demo zum Thema Lagerverwaltung geschrieben. Guck mal ins Codearchiv.

 

Hallo Martin,

Wir haben's nicht mit Produktion, wir machen Versandhandel. Und da werden die Artikel schon auftragsbezogen kommissioniert. Die Lagerbewegungen werden über die Belege gesteuert.

Das schau ich mir auf jeden Fall aber auch mal an.
Danke nochmal.
gruss ekkehard

 

Hallo Ekkehard,

dein Entwurf sieht ungefähr so aus, wie es auch bei uns verwendet wird.
Aber meine Anmerkungen dazu:
- bei mir heißen die Tabellen Auftraege und Auftragspositionen, bzw
Lieferscheine und Lieferpositionen
dadurch stehen die Tabellen in den Übersichten alphabetisch hintereinander
- bei Auftraege heißen deine PKs VorgangNr und POSNRG
bei den Belegen plötzlich edKey und edKey
wieso nicht BelegKey und BelegPosKey ?
- das Feld VorgangNr in PosBeleg scheint mir überflüssig

@Atrus :
"Die Belege sind doch schon über den Weg Beleg-PosBeleg-PosAuftrag-Auftrag an den Auftrag gekoppelt"

Nicht ganz richtig: Zu einem Auftrag wird zuerts ein Beleg (Lieferschein) angelegt, deshalb wird hier die Verknüpfung Autrag-Beleg benötigt.
Erst danach werden zum Beleg die Belegpositionen hinzugefügt, die auf eine Auftragsposition verweisen.

@Atrus:
"Longs, die keinen inneren Aufbau haben, sind gute Belegnummern. ...
ist das eine Nummernkreis, vulgo die Pest."

Andere Stimmen empfehlen eine GUID als PK.

Aber ich kann mir nicht vorstellen, daß ein Sachbearbeiter zum Suchen eines Auftrages einen Long-Wert oder eine GUID eingibt.

Bei uns sind die Auftragsnummer auf 5 Stellen festegelegt, Ergo von
"00000" bis "99999". Ist das für dich auch schon ein "Böser" Nummernkreis ?

@Atrus:
"Autowert-PK der einen mit Long-FK der andren."

Hier habe ich auch leichte Bauchschmerzen mit ( Obwohl es immer wieder empfohlen wird ), aber ich hatte mal versucht eine Datenbank zu exportieren (csv) und in ein anderes Datenbanksystem einzulesen ( welches natürlich neue Autowert-PKs vergeben hat ) und hatte damit Datenschrott. ( Ok ich war damals Jung und Unerfahren *wink.gif* )

 

Seltsame Methodik. Ein Lieferschein ist für mich eine Lieferbestätigung. Ein Auftrag ist ein Lieferwunsch. Wie kann ich beim Lieferwunscherteilen eine Lieferbestätigung bekommen?! Hängt aber wohl auch von euren Prozessen ab (die ich nicht kenne) und von der Bedeutung, die man Begriffen zuweist...

*tongue.gif*

Ja, ich auch. Access kann aber mit GUIDs nicht so besonders gut umgehen.

Beim Longwert hätte ich keine Probleme... beim GUID schon eher, ok, aber den gibt eh keiner zu Fuß ein. Eine gute Suchmaske ist halt wichtig.

Es ist zumidnest eine unnötige Einschränkung. Was macht ihr beim Auftrag 100000? Explodieren? Recyceln? Nenn mir einen Grund, warum Auftragsnummern überhaupt irgendein "Schema" haben müssen. Auftragsnummer ist, was du als Auftragsnummer bezeichnest. Egal ob 5 oder 292372. Dafür steht ja Auftragsnummer davor....

Migration auf andere Datenbanken oder -systeme ist immer mit Vorsicht zu genießen, v.a. wenn Autowerte im Spiel sind. "Rüberschubsen" alleine reicht nicht. Das hast du ja auch gemerkt. *Smilie

 

Etwas OT

Kannst du das bitte etwas mit Inhalt füllen, bzw. kurze Stichworte geben, wo es problematisch wird.

 

Jup, allgemeine Begriffsverwirrung *Smilie

Der Kunde erstellt in seinem System eine "Bestellung", die er uns zuschickt

Wir legen in unserem System einen "(Kunden)Auftrag" an mit 1..n "Auftragspositionen" und erzeugen eine "Auftragsbestätigung(Fax/PDF)" die wir ihm zurückschicken.

Wir beauftragen unser Lager, das Material zusammenzusuchen.
Wenn das Lager die Materialien bereitgestellt hat legen wir einen "Lieferschein" an, auf dem wir vermerken, welche konkrete Menge der Auftragspositionen wir jetzt liefern ( = Lieferpositionen )

Wir drucken den "Lieferschein(Papier)" aus und versenden diesen zusammen mit der Ware .

HTH

Klaus

 

Hallo,
@Klaus

Ist bei mir doch auch nicht anders.
Der Auftrag ist zunächst mal die Bestellung des Kunden (also resultiert daraus); die Positionen sind da so wie vom Kunden bestellt. Von diesem Auftrag ausgehend entstehen weitere Belege (Packliste, Lieferschein(e), Rechnung(en)). Deren Positionen sind eine Teilmenge des Auftrags, wobei auch Teilmengen vorkommen können, die Position also gesplittet werden muss. Da war mein ursprünglicher Gedanke eben: Auftrag 1:n Belege und Auftragpos. 1:n Belegpos. Das hat sich aber ja dank Martins Hinweisen aufgelöst.

Unsere Aufträge stammen aus verschiedenen Quellen (3 Onlineshops, Fax und Tel.). Die Onlineshops liefern alle andere Auftragsnummern, über die wir aber mit dem Kunden kommunizieren, und die dann bei uns zwangsläufig nicht mehr eindeutig sind. Diese wird im Feld AuftragNr gespeichert. Die VorgangsNr ist so zu sagen der zentrale Schlüssel, um alle Belege/Positionen miteinander zu verbinden.
Der PK POSNRG dient der Verteilung der Positionen auf die verschiedenen (Teil)belege.
Benamsung ist vielleicht nicht ganz glücklich.

Das geht mit diesem (geänderten) Modell auch so.
Ansonsten arbeiten wir auch so, wie Du es in Deinem letzten Posting schriebst.

@Martin
Deine Beispiel-DB habe ich mir schon mal runtergeladen, komme aber erst am WE dazu mir die anzuschauen.

gruss ekkehard