Office: (Office 2007) Daten abfragen, Seriennummer hoch zählen, in Formular schreiben

...noch etwas, jetzt ist aber noch sicherzustellen, dass du über
den Button nicht wieder 3 oder je nach dem, Seriennummern einfügen kannst!
Das ist natürlich ein "Muss" *Smilie und nicht sehr schwierig.

 

...ist aber noch nicht optimal...
Füge in dein Formular noch ein nicht sichtbares Feld IDAuftrag ein und verwende den unten stehenden Code.
Code:

PS: sorry, hatte in der Früh zu wenig Zeit *wink.gif*

Ich würde auch noch zielseriennummer auf Seriennummer ändern, natürlich auch in der Tabelle.

 

#gelöscht

 

Code:

 

Oh, aus versehen nur den Code verschickt *grins

Jetzt merke ich, dass es jede einzelne Artikelnummer anfügt und die Serial dazu, aber die Artikelnummern kommen immer mal wieder vor und benötigen dann auch andere Seriennummern. D.h. die Verknüpfung mit der ID ist (glaube ich) nicht optimal. Theoretisch müsste ja in die Tabelle Auftragsdaten eine Zeile sein mit den Auftragsdaten und in der Seriennummerntabelle n Zeile (abhängig Anzahl) *Smilie
dann verknüpfen Artikelnummer = Artikelnummer = *mrcool *grins

 

Dann musst eben einen neuen Auftrag eingeben, darum gibt es ja diese IDAuftrag!
Es wäre auch gut, wenn du diese Artikel in eine Tabelle tblArtikeln einfügst
und immer bei einem Auftrag verwenden würdest...sinnvoll denke ich!

 

...hatte kurz Zeit und habe die BDB nochmals überarbeitet, denke so passt es.
Artikel, Auftrag, Seriennummern...Formular, Bericht.

PS: habe es eben mit einer Tabelle T999 (eine Tabelle mit einer Spalte ID und Inhalt von 1-999
wie es Eberhard empfohlen hat) und der Abfrage getestet...
Code:

 

Hey, ich war leider sehr beschäftigt gestern und heute und habe jetzt erst wieder zeit... *wink.gif*

Kyron ich finde dein Hilfe wirklich bemerkenswert super!
Ich bin mit der V1 aber noch etwas näher an meinem "Soll" dran. Ich habe nur das Problem, dass die ID von Auftrag nicht mit ansteigt in der Tabelle Seriennummern. D.h. bei ID-Auftrag steht immer 1 obwohl ich dann ja schon Auftrag 2,3,4, etc habe...
Wenn die Zahl noch gleich mit hochzählt, dann habe ich ja immer meine Verknüpfung vom Auftrag -> Seriennummer -> volle Rückverfolgbarkeit *wink.gif*


Code:

 

Hallo,

im Formular gibt es unten so kleine Button, da wechselst auf den nächsten DS und gibst den Artikel deiner Wahl ein und alles andere auch.
Dann Start klicken... es werden in der Tabelle die Seriennummern und die neue ID eingefügt!
Ich hätte sonst keine Idee was du vor hast. Hätte auch noch eine weitere BDB V3 *grins

PS: das iAnz usw. benötigst ja auch nicht, bist ja im Formular und kannst diese Felder einfach abfragen!!
Me.Anzahl/Me.Seriennummer

 

danke... ich muss immer beschäftigt sein, mir wird so schnell langweilig.
Programmieren ist für mich wie für eine andere Person ev. Kreuzworträtseln *grins.
Zu deinem Problem, wie ich schon geschrieben habe, verstehe ich dein Konzept noch nicht wirklich.
Wie soll eine ID einfach ansteigend sein, das geht schon mal nicht. Sie muss mit einem anderen DS in Beziehung stehen.
Du gibst einen Auftrag mit allen wichtigen Daten ein, fügst die Anzahl/Seriennummern dazu und fertig.
Der nächste Auftrag, bekommt wieder eine neue ID und so geht das weiter.

PS:eine DBD ist noch dabei

 

Guten Morgen,
ich mal wieder *wink.gif*

Zu meinem Problem: Man stelle sich vor, ein Mitarbeiter möchte dieses Formular ausdrucken. Der Mitarbeiter ist gfs. nicht der Hellste und möchte eigentlich nur einen Knopf drücken. Er drückt diesen Knopf(Button) und alles passiert von selbst. Keine Datensätze auswählen, kein weiter klicken, etc.

D.h. die Schwierigkeit für mich (uns): Ein Tool, bei dem der Mitarbeiter bestmöglich nur die Auftragsdaten (Belegjahr, Belegnummer, Position eingibt und dann öffnet sich das Formular mit allen wichtigen Infos. *Smilie

Leider kann man nicht davon ausgehen, dass jeder Mitarbeiter versteht wie und was da passiert, dementsprechend muss es nach dem Poka Joke Prinzip sein (oder vereinfacht idiotensicher).

 

Guten Morgen,

normaler Weise bin ich ja nicht begriffsstutzig, aber ich weiß, trotz deiner Erklärung, die Arbeitsweise nicht richtig zu deuten.

1. du suchst einen schon bestehenden Auftrag, wozu aber dann diese Seriennummern?
2. von wo kommen diese Auftragsdaten, aus einer AC-Tabelle oder aus Excel?
3. dann brauchst eigentlich nichts speichern sondern nur ungebundene Felder verwenden!?
4. es sollte in diesem Fall gar kein Auftrag erstellt, sondern nur ein schon bestehender, mit allen dazugehörigen Date, angezeigt werden!
5. falls das so nicht richtig ist, man könnte auch diese Belegnummer anstatt der ID speichern. Die wäre dann fortlaufend.
6. komm auch mit deinen "Ursprungstabellen" nicht zurecht, da ergibt sich für mich kein Sinn.

...das wäre jetzt meine Idee dazu. Aber, das mit den Seriennummern ist mir in jedem Fall ein Rätsel *Smilie.

 

zu 1.: Die Seriennummern benötigt man für die Rückverfolgbarkeit des Produkts

zu 2. die Auftragsdaten kommen alle aus einer Tabelle, die ich in der Testversion nicht mit verknüpft habe, da diese Kundendaten enthält und die nicht jeder bekommen darf. In dieser Tabelle (richtigerweise besteht die Abfrage aus 2 Tabellen) stehen die Daten in tblAuftragsdaten. D.h. für das Tool kann ich die "Grundabfrage" nach den Kundendaten weglassen, da mir die Daten aus der tblAuftragsdaten genügt.

zu 3.: theoretisch brauch ich keine IDs speichern und theoretisch muss ich nicht mal die Belegnummer, Jahr, Pos. speichern

zu 4.: genau, wir brauchen keinen neuen Auftrag sondern nehmen einen bestehenden Auftrag, fügen die Seriennummern hinzu und drucken das in einen Formular/Bericht aus. D.h. optimaler weiße habe ich eine "finale" Tabelle in der alle Datensätze des jeweilig abgefragt Auftrags drin stehen und ich nur ein Formular öffne, sage bitte verknüpft mit tbl_xyz, bisschen hin und her ziehen, fertig

zu 5.: Jap *wink.gif*

zu 6.: der erste Schritt (wie oben beschrieben) ich füge die Auftragsdaten an die tblAuftragsdaten an. Dann habe ich Belegnummer, Jahr, Position, Stückzahl, Artikelnummer, Artikeltext, etc. pp.
Dann bräuchte ich einen Startknopf, bei dem ich die 6 stellige Seriennummer einfüge und zack habe ich eine Tabelle mit X Datensätzen und einer aufsteigenden Seriennummer abhängig der Stückzahl.

Hoffe das ist jetzt etwas verständlicher... ein großes SORRY für all die Verwirrung...

Grüße Christian

 

ja genau und das ohne eine ID oder Belegnmmer zu speichern nur die Seriennummer
und diese dann ev. noch jedesmal löschen wie schon gehabt...
wo ist da eine Rückverfolgbarkeit, das ist mir unklar und wird es auch bleiben.
Du musst diese Seriennummern ja einem Artikel und einem Auftrag zuordnen.
Wenn einem Auftrag ein Artikel zugeordnet wird, dann genügt diese ID des Auftrages und ist somit auch gleich die Seriennummer des Artikels.

Bei einem "nur" Suchformular benötigst alleine die Belegnummer,
über ein Kombi eingeben im Ufo werden alle Daten angezeigt.

Nicht mal das, es genügt im Formular, in dem du die Aufträge eingibst, ein
Kombi in dem du die Belegnummer suchst und anklickst...
dann erscheint dieser Auftrag, wenn du noch die Seriennummer
wie schon gezeigt einfügst, hast die auch beisammen.
Einfacher geht es ja gar nicht mehr. Das versteht doch jeder und wenn nicht, leider Zeit dem Arbeitnehmer etwas zu erklären *Smilie
Hast dir den Bericht angesehen? Der ist so auf diese Basis.

Bei deiner Idee muss man ja alles wissen und dann kannst das erst eingeben, bei meiner Idee musst nur die Belegnummer wissen.

Du hast ja schon alles beisammen, was fehlt jetzt noch (so quasi... woran hapert es noch),
ich weiß es ehrlich gesagt nicht!?

 

Servus,
möglicherweise wird hier um den heissen Brei herumgeredet?
Was ist denn unter Seriennummer zu verstehen?
Bei einem Auto ist es die "eingebrannte" Motorblocknummer.
Der Artikel Motorblock wird also physikalisch dadurch einmalig gemacht.
Er wird definitiv NICHT !!! nur aus Zahlen bestehen, sondern aus einer Kombination aus Text und Zahlen, was bedeutet, dass ein Primärschlüssel in einer DB dafür ausscheidet.
Die Motorblöcke werden in Motorblockgruppen zusammengefasst.
Auch diese haben ganz sicher wieder Text-Zahlenkombinationen als Motorgruppen-Namen.
Aus diesem Grunde finde ich, dass es das einfachste Prinzip ist, keine
realen Daten für die Schlüsselfelder zu verwenden und auch umgekehrt nicht. Schlüsselfelder sollten immer vom Typ Zahl sein.

Dadurch bleiben die Schlüsselfelder reine accessinterne Organisationsfelder
und tangieren niemals irgendwelche realen Datenwerte.

Aber jeder nach seinem Geschmack.