Können wir BestellAnforderung und BestellAnforderungsNummer umbenennen? Eine Nummer ist keine Entität.

Ich würde was du BestellAnforderungsNummer nennst schlicht "Bestellung" nennen, (und eine solche Entität hat selbstverständlich eine BestellNummer, meinetwegen auch zusätzlich eine BestellAnforderungsNummer, die vom globalen Proggi vergeben wird)
Und was du BestellAnforderung nennst, sind doch die einzelnen Posten auf einer Bestellung - oder verstehe ich was falsch? - also BestellAnforderung sollte BestellPosten heißen.

In deinem Diagramm fehlt mir eine Relation zwischen BestellPosten und Artikel, denn ohne Verweis auf den Artikel, den man haben will, macht ein Bestellposten nicht viel Sinn.

Artikel->BestellPosten

Dann habe ich das mit den fehlenden Artikeln noch nicht verstanden. Wenn ein bekannter Artikel unter seinen Mindestbestand fällt, creiert ein Besteller einen Bestellposten.
Wenn aber ein neuer Artikel als erforderlich erfunden wird, schreibt ein Arbeiter den Bestellposten dafür?

Ich fänds ja logischer, wenn der Arbeiter mw. den Artikel anlegt (kannerdas ühaupt? Da muß man doch voll die Kataloge wälzen, oder?).
Der neue Artikel ist natürlich sofort unter seinem Mindestbestand, und das sollte ja eh einen Besteller aktivieren, den zu bestellen.

In meiner Vorstellung würde sowieso ein Arbeiter keinen Artikel anlegen, sondern er würde zu einem Besteller hin, sagen was gebraucht wird, und der Besteller legt dann den Artikel an, und den Bestellposten.

Ich red immer nur von Bestellposten, nie von Bestellung. Ich stell mir nämlich vor, das Prog könnte intelligent genug sein, beim Erzeugen eines Bestellpostens auch gleich eine Bestellung an diesen Lieferanten zu generieren, bzw. wenns schon sone Bestellung gibt, die herauszufinden und zuzuordnen.

Ansonsten kannichmir das schon vorstellen, was du skizziert hast.

Ah -

HerrFrie schrieb:

Artikel – m:n – Lieferant(muss noch weiter bearbeitet werden)

Ist das so? Bezieht ihr denselben Artikel von verschiedenen Lieferanten?
Dann fehlt deinem Bildchen nicht nur die Relation Artikel->Bestellposten, sondern dann brauchst du noch eine klassische Mittler-Tabelle Artikel_Lieferant, mit den Relationen
Artikel->Artikel_Lieferant
Lieferant->Artikel_Lieferant

Etwas unklar ist mir auch die Relation Mitarbeiter->Bestellposten: Soll das so sein, dass für jeden einzelnen Bestellposten ein Mitarbeiter verantwortlich ist, aber zur Bestellung insgesamt keiner?
Oder fehlt da auch eine Relation?

Meine Gedanken im Bild:

Also die kleinen Schlüsselchen sind die 1 - Seite jeweils einer 1:n-Relation

Ach, eiglich kannich auch gleich die xsd anhängen, dann kannste weiter dran werkeln, zB die Benamung auf Rainers System umstellen (und gucken, ob das besser ist ;)) .

solltesich nach entpacken bei doppelklick mittm vs öffnen

Welche Attribute gehören jetzt dort rein wen es mit den erm so weit steht??

@ zn-gong

Das ERM steht aber noch nicht und daher sind Attribute zu diesem Zeitpunkt immer noch unwichtig.
@ HerrFrie

Werde mich heute oder morgen näher dazu äußern ... kann im Moment noch nicht ganz klar denken wegen einer Feier gestern.

Gruß

Rainer

Erstmal abwarten, bis wirklich fertig ist.

1. Du hast im Dataset die Relation Artikel->Bestellposten falschrum.
   Ein Artikel kann viele male auf Bestellposten aufgeführt sein, aber ein Bestellposten hat genau einen Artikel.
   
   
2. Dass zu jedem Bestellposten ein Arbeiter gehört, dem Bescheid gesagt werden soll, wenn der Artikel reinkommt, will mir nicht in die Birne.
   Nach deiner Erklärung wird dann bestellt, wenn der Lagerbestand eines Artikels unter die Mindestmenge fällt. Welchem Arbeiter soll dann bescheid gesagt werden??
   Das mit dem Bescheid sagen hat ja nur Sinn, wenn extra auf Initiative eines Arbeiters was bestellt wird. Vielleicht kommt man da zu einer neuen Entität, die dann wirklich Bestell-Anforderung heißt, und die vom Arbeiter ausgeht, und die ein Besteller bearbeiten muß, und der kann dann auch im BestellPosten einen "SagBescheidWennReinkommt-Arbeiter" setzen, aber optional.
   Solche Relationen sind auch inne Datenbank möglich, nämlich wenn man auf referenzielle Integrität verzichtet.
   
   
3. Aber ich bin jetzt durch die Diskussion über mein KassenProg beeinflusst, wennich sage, man sollte Arbeiter und Besteller nicht als 2 verschiedene Entitäten auffassen, sondern sind alles Mitarbeiter. Nur der Besteller-Mitarbeiter hat ein besonderes Recht, nämlich Bestellungen zu verfassen.
   Denn ein Besteller muß dieselbe Art von Buchung machen wie der Arbeiter, nur der Besteller bucht zu und der Arbeiter ab.
   

Das mit dem SagBescheidArbeiter habe ich jetzt angedeutet, indem ein BestellPosten einer Anforderung untergeordnet werden kann.
Müssteman noch überlegen - evtl. soll ja auch mehreren Arbeitern Bescheid gesagt werden - dann liefe es auf eine weitere Mittler-Tabelle hinaus, zw. Bestellposten und Arbeiter.

Nachdem was ich hier gelesen habe, hänge ich mal meinen ersten Ansatz für ein passendes ERM anbei.

Dazu folgende Erklärungen:

Alle Aktionen wie Entnahmen aus dem Lager, Artikeleingänge und aber auch Bestellungen laufen über das Table Buchungen und unterscheiden sich durch die Zuordnung des entsprechenden BuchungsTyp aus dem Table Buchungstypen. Bestellanforderungsnummer kann hier als Vorgangsnummer erfasst werden, aber auch Lieferscheinummern oder andere Belegnummern. Was die Vorgangsnummer genau darstellt ergibt sich dann zwangsläufig aus dem zugeordneten BuchungsTyp. Das hier dem Table Buchungen die Lieferanten zugeordnet sind aus dem Table Firma dient dem Sinn und Zweck das es möglich ist Lieferungen zu einem Artikel die von unterschiedlichen Lieferanten stammen zu erfassen.

Jede Buchung kann mehrere Positionen beinhalten. Das stellt das Table ArtikelBewegungen dar. Das Table nimmt auch gleichzeitig den Lagerort, die Stückzahl des Artikels und den Preis des Artikels. Ob die Stückzahl nun ein Zugang, Abgang oder eine offene Bestellung ist ergibt sich hier auch wieder aus dem BuchungsTyp der im Table Buchungen zugeordnet wurde. Zusätzlich stellt dieses Table die Verbindung zwischen Buchung und Artikel da.

Jetzt muss nur noch eine Lösung her wenn eine Bestellung geliefert wird. Man kann das über ein Flag im Table Buchungen (z.B. BestellungErledigt BOOLEAN) regeln oder über eine rekursive Beziehung in dem Lieferungen als Buchung einer Bestellung als Buchung zugeordnet werden können. Letzteres würde mir persönlich eher liegen, da man so auch gut Teillieferungen erfassen kann und einen Abgleich zwischen bestellter Menge und tatsächlich gelieferter Menge erstellen kann. Damit man zu einer Bestellung auch mehrere Lieferungen oder zu einer Lieferung mehrere Bestellungen erfassen kann ist die Rekursion als m:n Beziehung ausgelegt un wird über das Zwischentable tbl_MN_Buch2Buch aufgelöst.

Ergibt auch ein nettes Komfortfeature ... der User wählt beim Lieferungseingang eine Bestellanforderung aus und bekommt alle Artikel-Positionen aufgelistet und kann nun bequem auswählen welcher wurde geliefert (z.B. per CheckBox) und wieviel Stück davon und kann dann die Auswahl als einzelne Positionen in die aktuelle Buchung übernehmen.

Ich denke das müsste mal so als erster Ansatz passen. Baut natürlich darauf auf das gewisse logische Eingabevalidierungen im GUI erfolgen, wie z.B. das eine Buchung vom Typ Lieferung immer einen Lieferanten als Angabe benötigt, aber eine Buchung von Typ Inventurdifferenz keinen Lieferant als Angabe enthält.

Zur Überprüfung ob das ERM wirklich taugt jetzt bitte extrem kritische Fragestellung dazu.

Gruß

Rainer

EDIT

@ Erfinder und Rainer, ich hoffe so hattet ihr das für weitere Hilfe gedacht ?

Genauso war es richtig/perfekt um jetzt ganz konkret Hilfestellung geben zu können.

Sehr interessant.

Aber könnemer da auch wieder was umbenennen? Was du Buchung nennst, würde ich als Vorgang bezeichnen. Weil eine Buchung ist in meinem Verständnis immer die Dokumentation eines Zu- oder Abgangs.

Auch ArtikelBewegung passt nicht recht, denn zB. bei einer Bestellung gibts ja garkeine Bewegung, sondern erst bei Lieferung. Daher würde ich deine Tabelle ArtikelBewegung als "ArtikelMenge" bezeichnen.

So, jetzt mein Verständnis deines Konzeptes:
Egal, was einer macht - es ist immer zunächst mal ein Vorgang.
Vorgang kann sein: Entnahme/Zurücklegung, Lieferung, Bestellung, etc..
Jeder Vorgang hat mit keiner oder mehreren ArtikelMengen zu tun.
IMO bischen unschön, dass bei jedem Vorgang ein Lieferant involviert ist - aber zb bei Entnahmen interessiert der Lieferant garnet.

Unklar ist mir auch, warum Lager den ArtikelMengen übergeordnet ist, und nicht den Artikeln. Ich hatte Herrfrie so verstanden, dass streng festgelegt ist, welche Artikel in welches Lager gehören.
So wie du modelliert hast, kann man einen Artikel mal hier, mal dorthin tun.

Fehlen IMO noch die 2 Extras: der "SagbescheidWennGeliefert"-Arbeiter-Verweis und die Bestellanforderung, also wenn ein Arbeiter einen Artikel braucht, der noch gar nicht im Repertoire ist.

HerrFrie schrieb:

hmm, jetzt kam ich gerade gut zurecht mit Erfinders Diagramm und du bist quasi schon einen Schritt weiter. Will sagen, du bist nicht mehr nur bei den Enitäten und deren Beziehungen, sonder bist schon bei den Attributen.

Ich weiss, aber in diesem Falle habe ich die paar Attribute dazu getan damit sich der Sinn des Tables besser von alleine erklärt.

1. Zwischen Artikel und Lagerort existiert in deinem ERM keine direkte Beziehung, sondern nur über die Artikelbewegung. Müßte aber nicht eine direkte Beziehung da hin ?

Jein ... machst Du eine direkte Beziehung zwischen Lagerort und Artikel, dann KANN ein Artikel NUR in einem einzigen Lager liegen. Halte ich nicht für sinnvoll. In dem Modell kann ein Artikel nur in einem Lager liegen aber auch auf mehrere Läger unterschiedlich verteilt sein.

Und aus Realitätssicht ist auch sinniger, da Du ja nicht den Artikel selber in ein Lager packst sondern immer nur Stückzahl X von einem Artikel kommen ins Lager A. Und es wird nicht ein Artikel aus dem Lager entnommen, sondern es werden X Stück des Artikels Y aus dem Lager entnommen. Du kannst halt so flexibeler auf alle Anforderungen die auftreten können reagieren.

2. Zu meinem Verständnis. Wenn eine Buchung immer nur EINEN Artikel beträfe, wäre die tblArtikelBewegung nicht nötig, weil ich deren Attribute mit in die tblBuchungen integrieren könnte ?

Juup, exakt richtig. Aber komm ja nicht auf die Idee das zu tun.

Du beisst sonst irgendwann in den Hintern wenn du auf einmal realen Beleg hast der mehrere Artikel umfasst und Du musst nun den realen Beleg auf xx Buchungen aufteilen.

@ ErfinderDesRades

Aber könnemer da auch wieder was umbenennen?

Das kann jeder machen wie er mag.

Was du Buchung nennst, würde ich als Vorgang bezeichnen. Weil eine Buchung ist in meinem Verständnis immer die Dokumentation eines Zu- oder Abgangs

Aber genau das ist das was das Table Buchungen darstellt: Die Dokumentation eines Zu- oder Abganges. Nur das es auch in der Lage ist zukünftige Zustände heute erfassbar und darstellbar zu machen ... wie eben die Bestellung die einen Wareneingang auslöst oder auch die Planung das in 6 Wochen X Stück von Artikel XYZ für ein bestimmtes vorhaben gebraucht werden und daher heute die zukünftige Lagerveränderung um x Stück erfassbar ist.

Auch ArtikelBewegung passt nicht recht, denn zB. bei einer Bestellung gibts ja garkeine Bewegung, sondern erst bei Lieferung. Daher würde ich deine Tabelle ArtikelBewegung als "ArtikelMenge" bezeichnen.

Hast Du sicherlich Recht ... Bestellung ist erstmal keine Bewegung, aber wird zukünftig zu einer Bewegung. Daher eben die Zusammenfassung in einem Table damit schnell auswertbar ist wieviel Stück von Artikel sind aktuell vorhanden und wieviel sind als Eingang bereits in Planung.

ArtikelMenge fände ich jetzt auch nicht passend da das Table ja auch den ArtikelPreis erfasst.

Da erscheint mir dann ein allgemeinerer Begriff wie z.B. ArtikelPositionen griffiger, weil er genau das ausdrückt was im Table abgebildet wird: Eine ArtikelPosition einer Buchung (oder eines Vorganges).

Egal, was einer macht - es ist immer zunächst mal ein Vorgang.

Korrekt.

Vorgang kann sein: Entnahme/Zurücklegung, Lieferung, Bestellung, etc.

Auch korrekt.

Jeder Vorgang hat mit keiner oder mehreren ArtikelMengen zu tun.

Korrekt.

MO bischen unschön, dass bei jedem Vorgang ein Lieferant involviert ist - aber zb bei Entnahmen interessiert der Lieferant garnet.

Das ist wieder Logik-Validierung und erfolgt über's GUI. Das Datenmodell muss nur abbilden ob IMMER ein Lieferant zu erfassen ist oder ob ein Lieferant erfasst werden KANN. In dem Falle ist es kein Pflicht-Feld sondern ein Kann-Feld und die Ausfüllung muss daher über's GUI erfolgen.

Du kannst es nicht anders lösen ausser Du fängst an das zu tun was noch weitaus unschöner ist: Gleiche Entitäten in unterschiedliche Tables aufzuteilen.

Unklar ist mir auch, warum Lager den ArtikelMengen übergeordnet ist, und nicht den Artikeln. Ich hatte Herrfrie so verstanden, dass streng festgelegt ist, welche Artikel in welches Lager gehören.
So wie du modelliert hast, kann man einen Artikel mal hier, mal dorthin tun.

Richtig, das folgt aber rein dem Prinzip "Never say never". HerrFrie kann nur einen heutigen Workflow benennen, aber in die Zukunft sehen ist schwierig. Daher halte ich mich eben an das vorgenannte Motto und modelliere so das alle Anforderungen erfüllt werden können und bin damit auch für die Zukunft auf der absolut sicheren Seite.

Fehlen IMO noch die 2 Extras: der "SagbescheidWennGeliefert"-Arbeiter-Verweis und die Bestellanforderung, also wenn ein Arbeiter einen Artikel braucht, der noch gar nicht im Repertoire ist

Hhhmmmm... eigentlich nicht.

Wem Bescheid gesagt werden muss wenn geliefert ergibt sich automatisch durch die Beziehung Mitarbeiter zu Buchung/Vorgang des Types Bestellung. Man kann also immer den Mitarbeiter benachrichtigen lassen der die Buchung erfasst/eingegeben hat. Man bräuchte nur eine separate Beziehung wenn der Mitarbeiter des als Verantwortlicher für die Buchung Bestellung eingetragen ist ein anderer wäre als der Mitarbeiter der die Bestellung haben will. Aber selbst wenn eben einem anderen Mitarbeiter als dem für die Bestellung Verantwortlichen Bescheid gegeben werden muss, würde ich das auf gar keinen Fall als Beziehung lösen sondern nur als Attribut im Table Buchungen das dann eine weitere MitarbeiterID abspeichert und gut ist ... es besteht ja keine Notwendigkeit, bzw. kein Sinn dafür eine referentielle Integrität zu errichten.

Bestellanforderung für einen neuen Artikel ist aber bereits gelöst. Du musst es kombinatorisch sehen ... wer einen neuen Artikel der noch nicht vorhanden ist bestellen will, muss zuerst die Artikeldaten eingeben und kann dann dazu die Bestellung erfassen. Das kann man auch nett in einem eigenen Formular verpacken und wenn das Formular gespeichert wird, dann wird im Hintergrund ein DS im Table Artikel, ein Eintrag im Table Buchungen und der passende Verknüfpungseintrag im Table ArtikelPositionen/ArtikelMengen/ArtikelBewegungen eingetragen. für den User sieht es aus als wenn er nur einen Vorgang erstellt hätte, aber die Hintergrundlogik splittet das in die 3 nötigen Einzelvorgänge auf und speichert diese in den passenden Tables ab.

Einem User in einem GUI einen geschlossenen Vorgang darzustellen obwohl es letztendlich mehrere Einzelvorgänge sind die sich auf verschiedene Tables aufteilen ist ein ganz normales Vorgehen in einer DB basierten App. Es erspart das Problem Tables vorzuhalten die letztendlich nur die Daten der Einzelvorgänge redunant vorhalten. Du kannst ja letztendlich pro Formular Recordsets oder DataSets in unbegrenzter Anzahl im Hintergrund mit laufen lassen und jeden Recordset/Dataset nur die Formular-Daten zuweisen die es letztendlich auch betreffen. Ich bevorzuge aber die gelöste Version, einfach alle Felder ausfüllen lassen, nach Click auf Save-Button die Validierung ausführen und wenn okay dann kurz und knapp 3 INSERT-Statements über die Connection abzufeuern und Thema durch.

Gruß

Rainer

Habe jetzt heute nochmal kurz durchgelesen und dabei ist mir aufgefallen das die Erinnerung für Mitarbeiter die nicht die Bestellung eingegeben haben eine Anforderung ist. Sorry, war mir gestern durchgegangen.

Habe daher das Modell passend abgeändert und gleich so angelegt das man zu einer Bestellung mehrere Mitarbeiter anlegen kann die informiert werden sollen und genauso zu einem Mitarbeiter mehrere unterschiedliche Erinnerungen anlegen kann. Das müsste dann alle Anforderungen die jemals an Erinnerungen auftreten könnten abbilden.

Gruß

Rainer

Also mir gefällts (bis auf die Benamung ;)).
Aber nochmal zur Bestell-Anforderung: Ein Arbeiter stellt fest, er braucht einen neuen Artikel.
Dann musser ihn anlegen, sonst kanner keine BestellAnforderung dazu machen.
Aber möglicherweise kann der den Artikel nicht korrekt bezeichnen - er hat ja nur eine Vorstellung, von was er braucht. Die korrekte Bezeichnung kann nur der Besteller einbringen. Wird dann der Besteller den vom Arbeiter angelegten Artikel korrigieren?
Muss ein Artikel nicht besonders gekennzeichnet sein, solange noch garnicht feststeht, obs ihn in dieser Form gibt, und ob er ühaupt bestellt werden wird?
Oder reicht vlt. als Kennzeichnung, dasser noch niemals je geliefert worden ist?

ErfinderDesRades schrieb:

Also mir gefällts (bis auf die Benamung ;)).

Danke ... und ja, die Benamsung wird eh immer ein Thema bleiben.

Ich weiss das ich für viele zu lang benamse. In NET mit IntelliSense kein wirkliches Thema, aber in SQL ohne InteliSense wird es ein echtes Thema. Anderseits kann ich dadurch aber sprechende Namen erzeugen und habe bis jetzt mehrfach gehört das meine ERM's sehr gut zu lesen und schnell zu verstehen sind.

Aber halt eben ... eines der wenigen Dinge die in der Computerwelt wirklich eher Geschmackssache sind.

Aber nochmal zur Bestell-Anforderung: Ein Arbeiter stellt fest, er braucht einen neuen Artikel.
Dann musser ihn anlegen, sonst kanner keine BestellAnforderung dazu machen.
Aber möglicherweise kann der den Artikel nicht korrekt bezeichnen - er hat ja nur eine Vorstellung, von was er braucht. Die korrekte Bezeichnung kann nur der Besteller einbringen. Wird dann der Besteller den vom Arbeiter angelegten Artikel korrigieren?

Guter Einwand/Überlegung.

So oder so ähnliche Themen hat man immer wieder mal und die schlußendlich Quintessenz ist schlicht das kann man nicht über's ERM abfangen, wenn man nicht pfuschen will (redunante Datenhaltung). Artikel erst in einem Table ArtikelBestellungen zu erfassen um diese dann nur 1 zu 1 bearbeitet in das richtige Table Artikel zu übertragen ist eben Pfusch. Daten des gleichen Typs sind immer in derselben Entität und nirgendwo anders.

Meistens regelt man das über ein Attributs-Flag, z.B. ein boolsches Feld das automatisch bei Neuanlage eines DS im Table Artikel mit True bestückt wird. Über DB-Zugriffsregelungen (also wer darf was in der DB) kann man dann bestimmten Usern die Erlaubnis geben das sie dieses boolsche Feld verändern dürfen, z.B. in dem Falle nur für User die als Besteller klassifiziert sind und natürlich den Admins (natürlich klar, in dem ERM fehlen die Entitäten für das Handling der User-Rechte ... aber das ist eh Standard und daher lässt man es anfänglich weg, das fügt man erst gaaaaanz am Schluß dazu).

Hier ist jetzt die Frage die es zu klären gilt wo das Flag zu setzen ist ... bei Artikel oder bei Buchungen/Vorgängen? Ein neuer Artikel wird ja nur angelegt wenn er bestellt wird, also würde es reichen dort ein Flag zu setzen damit ein Besteller die Artikeldaten prüft. Aber der Besteller muss ja eh die Bestellung "bearbeiten" damit es überhaupt eine Bestellung wird und daher ist die Frage braucht es überhaupt ein separates Flag oder erledigt sich das eh automatisch mit wenn der Besteller die Bestellung mit dem neuen Artikel zur Bearbeitung auf dem Tisch hat?

Egal wie ... ist so oder so ein Attribut-Handling und sollte daher eh erst im nächsten Schritt - der folgt wenn auch HerrFrie mit dem ERM einverstanden ist - beleuchtet werden.

Muss ein Artikel nicht besonders gekennzeichnet sein, solange noch garnicht feststeht, obs ihn in dieser Form gibt, und ob er ühaupt bestellt werden wird?
Oder reicht vlt. als Kennzeichnung, dasser noch niemals je geliefert worden ist?

Absolut richtig.

Die Logik dahinter ist ja eindeutig und ohne Zweifel: Es gab für den Artikel noch kein Zugang und auch noch keinen Abgang, sondern nur eine oder mehrere Bestellungen = das kann nur ein neuer Artikel sein. Gibt es auch nur einen Zugang oder einen Abgang, ist es kein neuer Artikel mehr sondern ein Artikel der schon im Lager existiert.

Für solche Informationen die sich so eindeutig aus den anderen erfassten Daten ergeben, legt man auf gar keinen Fall eigene Attribute an, da es reine "berechnete" Informationen sind. Genauso wie man in einer DB niemals das Alter einer Person erfasst sondern nur das Geburtsdatum und an Hand der Differenz Geburtsdatum zu Heute dann das Alter aktuell ermittelt.

Und solche Informationen "berechnet" man lieber just in time und stellt sie standardmäßig in einer View zur Abfrage zur Verfügung. Vor allem - und viiiel wichtiger - vermeidet man dadurch Informationsfehler weil bei irgendeinem Vorgang vergessen wurde das Field zu ändern. Sachen an die man nicht denken muss, kann man auch nicht vergessen.

Genau dafür sind Views gedacht: Einfacher Zugriff auf Informationen die sich aus "Berechnungen" von gespeicherten Informationen ergeben. Z.B. würde man um es den Programmiereren einfacher zu machen für das Alter eine View erstellen die für alle Kunden das korrekte Alter zum heutigen Tag beinhaltet. So kann der Programmierer dann aus dem View das Alter zum Kunden abfragen in dem er eine Beziehung in der Abfrage herstellt:

[MYSQL]
SELECT t1.Nachname, t1.Name, t2.Alter FROM tblPersonen As t1 INNER JOIN vwAlter As t2 ON t1.PersID = t2.PersID[/MySQL]

Und genauso geht es mit neuen Artikeln:

[MySQL]
SELECT * FROM tblArtikel As t1 INNER JOIN vwNeueArtikel As t2 ON t1.ArtID = t2.ArtID[/MySQL]

Bzw. ergibt sich das eigentlich aus der Negativ-Abfrage der View für Artikelbestände. Ist die richtig erstellt, werden dort nur Artikel gelistet zu denen es Zu- und/oder Abgänge gegeben hat. Und alle Artikel die nicht in dieser View aufgelistet sind aber im Table Artikel existieren sind dann eben neue Artikel.

[MySQL]
SELECT * FROM tblArtikel WHERE NOT ArtID IN (SELECT ArtID FROM vwLagerBestaende)[/MySQL]

Kommt beides auf's selbe raus, wenn die Views mit den richtigen SQL-Statements erstellt wurden.

Gruß

Rainer

Ja, mein Vorschlag war ja, Buchung umzubenennen in "Vorgang". Und ein Vorgang kann vom Typ Lieferung sein, Bestellung, Entnahme, Zurücklegung - was du wolle.
Und was da geliefert, bestellt, entnommen wird, sind mehrere Artikelmengen, zb hier 2 Artikelmengen:
Schraube m4 - 2 Stk
Wattestäbchen - 1000 stk

must du wissen, wie dus benennen willst.

zu das mit die Bestell-Anforderung neuer Artikel:
Mein Vorschlag ist, dass Arbeiter einen Artikel einfach anlegen dürfen, so gut sie können.
Danach erstellen sie einen Vorgang vom Typ "BestellAnforderung".
Der Besteller kriegt das auffn Schirm, korrigiert ggfs. den Artikel, und bestellt ihn dann (Vorgang-Typ "Bestellung").
Evtl. müssteman auch einen VorgangTyp "AnforderungsAblehnung" erfinden.

Oder besser noch: Der arbeiter legt den Artikel an - der fällt dann ja eh ins ToDo des Bestellers, weil der Artikel ja mit 0 seine Mindestbestand unterschreitet.
Statt eines Vorgangs vom Typ "BestellAnforderung" sollte der Arbeiter einen Vorgang vom Typ "SagMirBescheidWennsDaIst" anlegen können - das braucherja auch für annere Artikel, die u.U. grad mal aus sind.

HerrFrie schrieb:

Im Grunde beinhaltet die jetzige Buchung ein oder mehrere Artikel, wobei die ArtBewegung immer nur einen Artikel beinhaltet. Soweit sollte ich richtig liegen.

Juup, da liegst Du richtig.

Vielleicht sollte man die Buchung in der Art wie GesamtBuchung und Art Bewegung sowas wie EinzelBuchung nennen. Wäre zumindest ein Vorschlag, der mir momentan als besser selbsterklärend erscheint.

Die Benamsung kannst Du ja problemlos ändern wenn es Dir so besser gefällt. Mir gefällt bloss die Aufteilung in Buchungen und EinzelBuchungen nicht da das impliziert man könnte auch direkt Einzelbuchungen eingeben und dabei das Table Buchungen übergehen. Daher die von mir gewählte Benamsung die diesen Rückschluß erst gar nicht aufkommen lässt. Glaub mir wenn Du die DB entwickelst und jemand anders proggt das GUI dann kann das enorm wichtig sein solche Gedankengänge beim Progger zu unterbinden durch die Benamsung.

Hier könnte der Artikel erst angelegt werden, wenn man die fehlenden Daten wie z.B. Artikelnummer und Preis hat.

Nein! NIE NIE NIE mit einer 2ten Liste/Table arbeiten das die gleiche DS beinhaltet (ausser bei Archivierungen).

Leg solche Artikel die noch nicht existieren und bei denen zum Zeitpunkt der Anlage weder Artikelnummer noch Preis bekannt sind, trotzdem als Artikel an. Geht ja eh problemlos (denk daran: Artikelnummer kann NIE NIE NIE der Primary Key von Artikel sein! Der läuft separat los gelöst. Artikelnummer ist nur ein Attribut des Tables Artikel und hat rein gar nichts mit der referentiellen Integrität zu tun) und Preis ist ja eh kein Attribut der Entität Artikel sondern ein Attribut der Entität ArtikelBewegungen/Einzelbuchungen.

Würde mir bloss für solche Artikel wie Wattestäbchen überlegen ob die wirklich eine Artikelnummer brauchen? Denen würde ich eher die Artikelnummer "Allgemein" verbraten und Feierabend ist. Sonst hast Du von drölfmillionen Lieferungen Wattestäbchen 136989 und ein paar geklemmte neue Artikel angelegt und das kann es nicht sein.

Bei Wattestäbchen reicht es doch völlig aus wenn irgendeine Lieferung ankommt das über das Table ArtikelBewegungen/EinzelBuchungen der Lieferant und der Preis erfasst wird ... und Feierabend.

@ ErfinderDesRades

Ich denke eine Art Vorgangs-/Buchungsstatus insbesondere in Hinblick auf Bestellungen einzuführen könnte nicht verkehrt sein.

Aber um nun in diese Richtung weiter zu überlegen, müssten wir nun von HerrFrie genau wissen wie der Ablauf bei einer Bestellanforderung ist und wie der Ablauf bei einer Bestellung auf Grund Unterschreitung Mindestbestand ist. Also kurz: Wer sagt wem in welcher Form Bescheid.

Gruß

Rainer

HerrFrie schrieb:

1. ein Arbeiter trägt in diese Liste einen Artikel ein, den er benötigt und der noch nicht vorhanden ist. Hier gucken die Besteller auch täglich.
2. In der Liste, wo die Artikel verwaltet werden gibt es ein Makro, dass alle Artikel die den Mindestbestand unterschritten haben in ein gesondertes Tabellenblatt raus schreibt. Die Besteller erstellen daraus ihre Bestellanforderungen für das interne Firmenprogramm. Dies machen die Besteller täglich.

Okay.

Dann gucken wir mal wie das Vorgehen in das obige ERM passen würde:

Mitarbeiter will Artikel bestellen:

Er erfasst einen BuchungsTyp Bestellung über das Table Buchungen (oder wie man es auch immer nennen mag ^^), über Artikelbewegungen erfasst er die Stückzahl des einzelnen Artikels den er braucht (können natürlich auch mehrere Artikel pro Buchung sein). Gibt es dabei einen Artikel nicht, dann legt er ihn neu an im Table Artikel. Soweit passt das ERM.

Frage: Wie weiss nun der Besteller das er genau diese Bestellungs-Buchung zu bearbeiten hat? Eindeutige Auswertungen rein aus den DB-Informationen sind mMn nicht möglich. Man kann sich derzeit zwar alle Bestellungen zu denen es noch keinen Wareneingang gab als offene Bestellungen anzeigen lassen, aber das gibt noch nicht eindeutig zurück ob für die Bestellungs-Buchung schon ein Besteller eine Bestellung aufgegeben hat.

Obwohl ... eine Buchung von Typ Bestellung bekommt ja erst eine Bestellanforderungsnummer wenn der Besteller die Bestellung beim Lieferant durchgeführt hat. Also wäre die Logik: Alle Bestellung die noch keine Bestellanforderungsnummer bekommen haben muss der Besteller noch bearbeiten.

Das führt uns aber gleich zu einem weiteren Problem: Z.B. Arbeiter X braucht 3 Artikel von 3 unterschiedlichen Lieferanten. Wird die Bestellanforderungsnummer nun für die gesamte Bestellung vergeben ober bekommt jeder Artikel eine eigene Bestellanforderungsnummer? Weil wenn ja, dann muss zumindest bei der Bestellung per GUI darauf geachtet werden das pro Buchung vom Typ Bestellung immer nur ein Eintrag aus dem Table Artikelbewegungen möglich ist.

Aber egal wie ... ich würde ja fast lieber mit einem Flag arbeiten das bei Bestellungen verschiedene Statusse erfassbar macht: Bestellung neu, Bestellung (vom Besteller) bearbeitet, Bestellung offen (für den Zeitraum zwischen Bestellung beim Lieferanten und dem Wareneingang) und Bestellung erledigt. Für erledigt wären vllt noch mehrere Unterteilungen denkbar Bestellung erledigt w/Stornierung Auftrag, Bestellung erledigt w/Auslieferung, Bestellung erledigt w/Ablehnung Lieferant.

Müsstest Du mal genau nachdenken was als Bestellungsstatus wirklich gebraucht wird. Aber wenn Du das mit dem Flag lösen willst, dann müssten wir das ERM ergänzen um ein LookUp-Table das die möglichen Flags aufnimmt.

Gruß

Rainer