Felder werden erst nach Aktualisierung berechnet

[DF6GL]

Hallo,

mhmm, fast richtig...  


Die "Bestellungen" bestehen aus zwei Tabellen:   tblBestellkopf und tblBestellpostionen.     In tblBestellkopf kommen alle diejenigen Daten/Werte hinein, die NICHT einer Bestellposition angehören, also Kundenadresse, Absender-Daten, Bestelldatum, Bestellkonditionen, usw.  In tblBestellpositionen kommen NUR die Daten, die zu einer Position gehören, also MaterialNr, Menge, Einzelpreis(wenn der sich aktuell von dem hinterlegten EinzelpreistblMaterial unterscheiden kann) . Es werden in den Tabellen KEINE berechenbaren Werte gespeichert,also in tblBestellpositionen KEIN Positonspreis , in tblBestellkopf KEIN (Bestell-)Gesamtpreis.

In jeder Bestellposition wird (in einem Formular!) über ein Kombifeld, das seine Listendaten aus Tabelle tblMaterial bezieht, die Material_ID ausgewählt und als Fremdschlüsselwert im Datensatz gespeichert.  Dabei können dann die evtl. aktuell veränderbaren Daten (siehe oben zu Einzelpreis) in die entspr. Felder übernommen (kopiert) werden.



tblBestellkopf und tblBestellpositionen stehen als  1:n-Beziehung mit ref. Integrität in Zusammenhang miteinander.

[MarkusR]

Hallo,

@MzKlMu:
Bisher werden alle Produkte in einer Tabelle gelistet, allerdings wird ein Produkt immer nur von einem Kunden bestellt (der Kunde schickt uns eine Zeichnung zu einem Produkt, wir erstellen das Angebot, jeder Kunde hat andere Produkte).
Was du mit auslagern meinst, habe ich glaube ich verstanden. Aber was bringt es mir, eine Tabelle zu erstellen mit ID, Arbeitsschritt und Preis, wenn ich dann in der Zuordnungstabelle zum Produkt wieder den Arbeitsschritt (diesmal als ID) und den Preis angebe? Klingt irgendwie doppelt. Aber davon mal abgesehen, versteh ich noch nicht, wie das mit der Zuordnung funktionieren soll. Mal ein Beispiel:

Produkt A: Bearbeiten 100 €, Richten 20 €, Rüsten 50 €
Produkt B: Bearbeiten 150 €, Richten 40 €, Rüsten 100 €

tblProdukte:
ID 1  Produkt A
ID 2  Produkt B

tblArbeitsschritte:
ID 1  Bearbeiten  100
ID 2  Richten          20
ID 3  Rüsten          50
ID 4  Bearbeiten  150
ID 5  Richten         40
ID 6  Rüsten        100

tblZuordnungProdukArbeitsschritt:
ID 1  ID 1  100
ID 1  ID 2    20
ID 1  ID 3    50
ID 2  ID 4  150
ID 2  ID 5    40
ID 2  ID 6  100

Ist das bis dahin so richtig dargestellt? Wenn ja, WIE mache ich das?! 
Ich meine, wie verknüpfe ich die Tabellen miteinander und wie wird ein Formular aufgebaut, dass ich die Daten da eingeben kann, ohne hunter Tabellen öffnen zu müssen?

In einer Bestellung wird immer nur ein Produkt bestellt, allerdings kann es vorkommen, dass die Bestellung gesplittet wird, da es mehrere Liefertermine gibt. Somit kann dann eine Bestellnummer öfters vorkommen.

Ich seh schon, das wird noch sehr viel Arbeit...und leider versteh ich scheinbar nichtmal die Grundstruktur
Habt Ihr sowas beruflich gelernt oder ist das nur "Freizeit" mäßig? Ich bin ja eigentlich nur n popeliger Kaufmann!


@DF6GL:

Sowas wie ein Bestellkopf ist eigentlich nicht nötig. Ein Produkt gibt es immer nur für einen Kunden und viele Kunden haben wir nicht gerade. Also kann man sowas wie Zahlungsbedingungen, Kundendaten usw. ja eigentlich in einer tblKunden speichern, oder?

Ach, was du da mit dem Kombifeld erklärst...ist das das mit dem Auslagern und der Zuordnung? Das würde aber bedeuten, dass zum Beispiel bei Materiallänge zehntausende von Werten in das Kombifeld müssten. Quasi alles zwischen 1mm und 14000mm länge.

[DF6GL]

Hallo,

lt. der Beschreibung nach "bearbeitest" Du gar keine Bestellungen, sondern Arbeitsaufträge.  In diesem Fall (jeder Auftrag "produziert "ein anderes Produkt) ist auch keine Produkt-Tabelle nötig.  Die Bestellnummer kann als "Auftragsnummer" angesehen werden, und die Liste der zugeordneten Arbeitsgänge (aus einer Stammtabelle entnommen) entspricht dem Fertigungsablauf.  Diese Konstellation erfordert das Gleiche in Grün, also 3 Tabellen:

tblArbeitsgänge  (wäre analog zu tblProdukte)

tblAufträge   (wäre analog zu tblBestellkopf)

tblAuftragArbeitsgänge  wäre analog zu tblBestellpositionen)


Wenn bei den einzelnen Arbeitsgängen Rohmaterial verarbeitet wird, das registriert werden soll, dann spielen da weitere Tabellen mit:

tblMaterial (1:n-Beziehung zu tblArbeitsgangMaterial)

tblArbeitsgangMaterial  (in n: 1-Beziehung zu tblAuftragArbeitsgänge)



Das Gleiche gilt, wenn zusätzlich zum Material Arbeitszeiten von verschiedenen MAs beim gleichen Arbeitsgang erfasst werden müssen.



(Teil)-Lieferungen sind in einer "Bewegungstabelle" zu erfassen die als n-Tabelle an der "tblAufträge" hängt.

[MzKlMu]

Hallo,
ich habe mir mal die Mühe gemacht und habe das mal an Hand des Beispiel aus Deinem letzten Beitrag umgesetzt.
Zunächst ist mal anzumerken, dass hier noch eine weitere Normalisierungstabelle fehlt. Die Bearebietungsschritte hast Du ja mehrfach in der Tabelle. Daher sind dazu 2 Tabellen notwendig. 1x für die Schritte und 1x für den Preis. In letzterer Tabelle ist dann ein Fremdschlüssel zum Schritt erforderlich.

Schaue Dir erst die Beziehungen an, dann das Formular. Du kannst im Ufo einen Arbeitsschritt zum Produkt auswählen im Kombi für den Preis wird ein Preis vorgeschlagen der zum Arb.Schritt passt. Der Preis wird in das Preisfeld übertragen und kann bei Bedarf geändert werden.

Das Beispiel beinhaltet jetzt nur die Beschreibung aus Deinem letzten Beitrag. Die Anmerkungen von Franz sind noch einzuarbeiten.

Aber was bringt es mir, eine Tabelle zu erstellen mit ID, Arbeitsschritt und Preis, wenn ich dann in der Zuordnungstabelle zum Produkt wieder den Arbeitsschritt (diesmal als ID) und den Preis angebe?

In Deinem jetztigen Aufbau muss in der Grundtabelle für jeden Schritt eine Feld vorhanden sein, auch wenn der Schritt bei diesem Produkt gar nicht vorhanden ist. Bei korrekten Aufbau gibt es einen Schritt nur wenn dieser auch vorhanden ist.
Weiterhin, stelle Dir mal vor, Du musst irgendwann einen neuen Arbeitsschritt einführen?
Was dann? Jede Objekt (Formulare, Abfragen, Berichte) muss geändert werden, ausnahmslos.
Bei korrektem Aufbau ist das nur eine neuer Datensatz bei den Schritten und die Erfassung der Grundpreise, fertig, alles passt immer noch.

Habt Ihr sowas beruflich gelernt oder ist das nur "Freizeit" mäßig?

Ich bin schon 8 Jahre Rentner (Sorry  ) und betreibe die Mitarbeit im Forum für Access als Gehirnjogging. Hatte früher im Beruf viel mit PC und EDV zu tun.

[Anhang gelöscht durch Administrator]

[MarkusR]

Guten Morgen!

Ersteinmal vielen Dank für Deine Mühe! Das macht mir das ganze doch schon um einiges verständlicher...

tblKunden trage ich einfach alle Kunden ein, die wir haben. Soweit klar.
tblProdukte kann ich durch die drei anderen Tabellen alle Produkte mit frmErfassung eintragen und hieraus die Angebote für meine Kunden erstellen.
ABER: Wie kommen die Preise in die tblArbSchrPreis? Wir haben ja für jeden Arbeitsschritt viele hunderte mögliche Preise. Trage ich da alle vorher von Hand ein? Oder werden die da irgendwie gespeichert, wenn ich ein neues Produkt anlege?

Und könntest Du mir vielleicht auch noch erklären, wie ich jetzt eine Tabelle mit meinen Aufträgen dazu verknüpfe? Da müsste ich doch jetzt eigentlich eine Tabelle tblAuftraege anlegen und die über eine Zuordnungstabelle, sagen wir tblZuordnungAuftragProdukt, mit der Tabelle tblProdukte verknüpfen, oder?

Ich glaube, ich komme der Sache so langsam näher...dank Euch!...aber da hab ich wohl noch eine ganze Menge Arbeit vor mir.


@Franz
Ich denke schon, dass eine Produkttabelle nötig ist. Da wir nicht jedes Produkt nur einmal produzieren, sondern ein Produkt immer wieder bestellt werden kann. Oder meintest Du das anders?

[MarkusR]

Ich habe jetzt mal eine Tabelle tblAuftraege mit den Felder "AuftragsID", "Auftragsnummer" und "ProduktID_F" erstellt und diese mit der Tabelle tblProdukte verknüpft.

Dann habe ich eine Formular frmAuftraege mit den Feldern "Auftragsnummer" und "ProduktID_F" erstellt, das Formular tblErfassung als Unterformular eingefügt und vom Unterformular zum Hauptformular verknüpft mit den Feldern "ProduktID" und "ProduktID_F". Ist das so richtig?

Hab die Datei mal mit hochgeladen.

[Anhang gelöscht durch Administrator]

[DF6GL]

Hallo,

es nutzt absolut nichts, Formulare zu erstellen,  wenn die Tabellenstruktur noch nicht KOMPLETT klar und vollständig ist..

Ich denke schon, dass eine Produkttabelle nötig ist. Da wir nicht jedes Produkt nur einmal produzieren, sondern ein Produkt immer wieder bestellt werden kann.

Wenn, wie ich es jetzt (noch) sehe, ein "Produkt"  identisch einhergeht mit einer fertigungs-/projektbezogenen Auftragsabwicklung, dann ist ein Produkt (Produktnummer) lediglich ein Attribut eines "Auftrages" wie vorher schon erwähnt und braucht nicht als eigene Tabelle geführt zu werden, weil der reale Fertigungsablauf mit allen seinen Eigenheiten (Rohmaterial, Arbeitsgänge, evtl. auch Vorgabe-Arbeitszeiten)  genau dieses "Produkt" spezifiziert.

[MarkusR]

Hallo Franz,

dass ich jetzt noch keine Formulare ausarbeite ist auch klar. Sollte nur zur Veranschaulichung dienen. Man kann natürlich auch nur die Tabellenstruktur betrachten.

Wenn ich Dich richtig verstehe müsste ich also statt einer tblProdukte eine tblAuftraege machen, in der ich dann das Produkt spezifiziere. Aber hat man dann auch die Möglichkeit, auf ein bereits bestehendes Produkt zurück zu greifen?

[DF6GL]

Hallo,

Man kann natürlich auch nur die Tabellenstruktur betrachten.

NUR das sollte man in dieser Phase..

Ich hatte das Ganze doch letzthin beschrieben..?

Letztendlich musst Du entscheiden/erkennen, ob solche Datenkonstellation für Euch zutrifft.  Wenn nicht, dann muss das halt noch verändert/angepasst werden.  Ich (wir) selber kann (können) die Sachlage nur aus Deinen Schilderungen ablesen..

auf ein bereits bestehendes Produkt zurück zu greifen

Hier derselbe Hinweis: wenn "Produkt"  == "Projektauftrag"  dann besteht diese Möglichkeit .

[MarkusR]

Guten Morgen zusammen,

Betriebsferien sind vorbei, der Stapel auf meinem Schreibtisch ist abgearbeitet...jetzt habe ich wieder Zeit, mich hiermit auseinander zu setzen.

Ich habe jetzt mal dein Zuordnungsbeispiel um zwei Tabellen erweitert: tblAuftraege und tblZuordnungProduktAuftrag
Die Tabellen habe ich dann in den Beziehungen verknüpft. Ist das richtig, wie ich das gemacht habe?

Mir stellt sich jetzt die Frage, wie man damit arbeitet? Ich meine, unsere Mitarbeiter wissen ja nicht, welches Produkt welche Produkt ID hat. Kann man nicht statt einer Produkt ID als Schlüssel die Zeichnungsnummer kombiniert mit dem Angebotsdatum nehmen?

Ich werde jetzt erstmal versuchen, die Tabellen zu normalisieren...das wird wohl was dauern 

Danke und Gruß,
Markus

[Anhang gelöscht durch Administrator]

[MzKlMu]

Hallo,

Kann man nicht statt einer Produkt ID als Schlüssel die Zeichnungsnummer kombiniert mit dem Angebotsdatum nehmen?

Nein, das wäre ein fataler Fehler.
Die ID bekommt auch niemand zu Gesicht. Die Auswahl erfolgt mit einem Kombi in dem die ID ausgeblendet wird und die Klartextfelder angezeigt werden.

[DF6GL]

Hallo,

die Tabellen sind doch schon normalisert... wenngleich bei tblArbSchrPreis noch irgendein Unterscheidungsmerkmal für die verschiedenen Preise eines Arbeitsschrittes fehlt (z. B. ein Gültigkeitsdatum und/oder auch eine Mengenstaffelung). Weiterhin ist ein bestimmtes "Produkt" (würde eher sagen: "Herstellungsablauf") an lediglich nur einen Kunden gebunden.  Falls das nicht zutrifft, muss tblKunden an tblAuftraege angebunden werden.


Wenn "Produkt" eigentlich eine "Liste von definierten Arbeitsschritten" ,( bzw. "Herstellungsablauf") bedeutet und eindeutig von der Zeichnungsnummer abhängt, dann reicht es, dass bei der Erstellung eines Auftrages die Zeichnungsnummer vom User ausgewählt wird, die er ja in diesem Moment kennen muss.   Die ProduktID bleibt aber so wie sie ist...

[MarkusR]

Hallo,

Die ID bekommt auch niemand zu Gesicht. Die Auswahl erfolgt mit einem Kombi in dem die ID ausgeblendet wird und die Klartextfelder angezeigt werden.

Ah, okay...dann wird mir das schon klarer. Wenn ich einen neuen Auftrag anlege, könnte ich quasi über ein Kombifeld eine Artikelnummer wählen, zu der mir dann die verschiedenen Zeichnungsnummer und das jeweilige Angebotsdatum zu der Zeichnung angezeigt werden.

die Tabellen sind doch schon normalisert...

Ich meinte auch nicht die in dem Beispiel, sondern meine eigene (oben beschriebene) Tabelle. Hab mir dazu deinen Link 1a nochmal angeschaut, den find ich halbwegs verständlich  . Im ersten Schritt schaue ich, dass in keinem Feld mehr als 1 Wert ist. Im zweiten Schritt muss ich dann schauen, dass ich Tabellen erstelle, in den die Attribute nur vom Schlüssel abhängig sind. Den dritten Schritt habe ich noch nicht verstanden...aber so weit muss ich erstmal kommen!

[MarkusR]

So, ich hab das Beispiel jetzt mal um ein gutes Stück erweitert. Könnte bitte da mal jemand von euch drüber schauen, ob ich jetzt endlich auf dem richtigen Weg bin?

Dankeeee  

[Anhang gelöscht durch Administrator]

[MarkusR]

Hallo zusammen,

anbei hab ich nochmal die aktuelle DB hochgeladen. Habe jetzt neben den Tabellen, die ich zur Produkterfassung benötige, auch noch ein Formular mit Unterformular angefangen.

Ersteinmal: Ist die Tabellenstruktur jetzt so richtig? Wäre ja Quatsch mit weiteren Tabellen anzufangen, wenn ich das immer noch nicht richtig verstanden habe.
Dann ist mir aber beim Erstellen des Formulars etwas aufgefallen: Bisher arbeiten wir mit einem geteilten Formular. Da sieht man dann zum Formular auch alle Produkte im Datenblatt, die bisher angelegt wurden. Das ist auch wichtig für unsere Arbeit. Wenn ich jetzt aber ein Unterformular in das Hauptformular einfüge, sieht man die Spalten vom Ufo ja nicht im Datenblatt des Hauptformulars. Gibts da irgendeine Möglichkeit?

Im Voraus tausend Dank für Eure Hilfe!

Gruß, Markus

[Anhang gelöscht durch Administrator]