Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
nochmal Backzettel - neuer Ansatz?
Gehe zu Seite Zurück  1, 2, 3
zurück: Prüfung ob Combobox Wert hat vor Datensatzschließen/-wechsel weiter: bei eingabe prüfen ob datensatz vorhanden und anzeigen Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
MissPh!
Office-VBA-Programmiererin


Verfasst am:
22. Sep 2010, 12:26
Rufname:
Wohnort: NRW

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

Und vorher sollte die neu eingetragene Tour besser noch gespeichert werden.
Der Code dazu könnte dann so aussehen:
Code:
Private Sub btnOK_Click()
    Dim db As Database
    Dim qd As DAO.QueryDef
   
    Me.Dirty = False       'DoCmd.RunCommand acCmdSaveRecord
    Set db = CurrentDb
    Set qd = db.QueryDefs("qryAnf1")
    qd.Parameters(0) = Me!lbltour_id
    qd.Execute
    Set qd = Nothing
    Set qd = db.QueryDefs("qryAnf2")
    qd.Parameters(0) = Me!lblprodsort_id
    qd.Parameters(1) = Me!lbltour_id
    qd.Execute
    Set qd = Nothing
    Set db = Nothing
End Sub

_________________
Gruß MissPh!
tar
neugiersch


Verfasst am:
22. Sep 2010, 12:33
Rufname:


Re: AW: nochmal Backzettel - neuer Ansatz? - Re: AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

Hallo DieterB,
DieterB - 22. Sep 2010, 12:13 hat folgendes geschrieben:
was brauchst du jetzt?
Beides.

In der Praxis schaut es so aus: Da sitzt 1 Person, die überlegt sich am Vorabend, wieviel Produkte in welche Filiale ungefähr geliefert werden müssen (Eingabe der Mengen pro Filiale = Bestellzeilen für die Bestellung pro Filiale). Daraus ergibt sich dann die Summe = Backzettel, der nachts von den Bäckern spontan korrigiert wird (bspw. um Blech komplett zu füllen oder weil Teig alle ist, etc.). Am Folgetag wird die korrigierte Menge in der Tour eingegeben, deswegen habe ich in tblBestellzeile auch 2 Spalten:

- bestzeile_menge_geschaetzt
- bestzeile_menge_realisiert

Das Problem ist, dass die korrigierte Menge vor dem Eintragen am PC ausgeliefert wird (morgens), d.h. es müsste der geschätzte Lieferschein gedruckt werden - mit ein wenig freiem Platz zum schriftlichen Eintragen der Korrekturangaben des Auslieferers. Dieser korrigierte Lieferschein dient dann dazu, abends die Korrekturen am PC einzutragen.

Die hierigen Daten beziehen sich letztlich immer alle auf den Folgetag (gebacken wird nachts) der geschätzten Eingabe. Hast du einen besseren Vorschlag, außer den Bäckern unten einen PC samt Drucker hinzustellen (Probleme: zusätzliche Kosten, kaum Platz, dreckige Finger, PC-Kenntnisse, Hektik und Falscheingaben)?

Es gibt natürlich noch zusätzliche Einzelbestellungen (bspw. Hochzeitstorte usw.), die aber separat abgehandelt werden - in eigenen Tabellen, die in diesem Datenbank-Ausschnitt nicht dargestellt werden.

Gruß!
DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
22. Sep 2010, 12:40
Rufname:

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

@tar:

ich weiss wie es in der Praxis läuft.

Bin Bäckermeister.
btw: ich habe was ähnliches mal für AS/400 umgesetzt.

Auch die Hochzeitstorte kann in der Tabelle abgehandelt werden.
Es gibt dann zwei Abteilungen: Bäckerei, Konditorei.
Druckst du den Backzettel aus, Gruppenwechsel nach der Bäckerei.

Wobei schon im Ansatz ein fehler ist.
Nicht eine Person überlegt, sondern die Filialen haben zu bestellen.

Ist der Teig alle, kann der Bäcker nicht rechnen Smile

Nebenbei, ist der Backzettel nur ein Anhaltspunkt.
Sicher würde ich den Bäcker das Teil (PC) auch nicht in die Backstube stellen.
Aber die Korrekturen sind zu vernachlässigen, in der Produktion.
Wichtig hierbei ist, dass das Büro darüber in Kenntnis gesetzt wird, für die Rechnung.

Und wenn ein Kunde 100 Brötchen mehr bestellt? Da brauch ich nicht mal rechnen.
nehme ich 3 Kg Mehl mehr, 60g Salz, ca 1650 g Wasser (TA 155), 60 g Backhilfsmittel, 120g Hefe mehr, und fertig sind die drei Pressen. Wo ist das Problem? Faustregel: 1 Presse Brötchen = 1 Kg Mehl.

Wichtig ist doch in diesem Falle, dass dem Kunden nicht zu wenig in Rechnung gestellt wird.

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
tar
neugiersch


Verfasst am:
22. Sep 2010, 12:50
Rufname:

Re: AW: nochmal Backzettel - neuer Ansatz? - Re: AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

DieterB - 22. Sep 2010, 12:40 hat folgendes geschrieben:
ich weiss wie es in der Praxis läuft.

Bin Bäckermeister.
btw: ich habe was ähnliches mal für AS/400 umgesetzt.
Ein Bäckermeister, der soviel Zeit hat? Mein Schwiegervater würde dich sicher beneiden ;)

Zitat:
Auch die Hochzeitstorte kann in der Tabelle abgehandelt werden.
Es gibt dann zwei Abteilungen: Bäckerei, Konditorei.
Druckst du den Backzettel aus, Gruppenwechsel nach der Bäckerei.
Ja, aber wie kopple ich dann das mit dem Lieferschein und den korrigierten Mengen?

Zitat:
Wobei schon im Ansatz ein fehler ist.
Nicht eine Person überlegt, sondern die Filialen haben zu bestellen.
Ja, die Faxe der Filialen, die abends eintreffen, werden abends bei den Bestell-Eingaben für den Backzettel berücksichtigt. Diese Eingaben macht aber allein die Frau vom Chef.

Zitat:
Ist der Teig alle, kann der Bäcker nicht rechnen Smile
Oder der Lieferant hat Mist gebaut ;)

Gruß!
DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
22. Sep 2010, 15:09
Rufname:


AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

dazu müsste ich sie mir ganz genau angucken.

Im Moment muss ich für ein Neu-Geschäft eine Spedi-DB entwickeln.

Ich versuche es am WE, ist aber Wetterabhängig.

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
tar
neugiersch


Verfasst am:
22. Sep 2010, 17:12
Rufname:

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

Hallo nochmal,

ich habe es mir nochmal durch den Kopf gehen lassen und ja - es ist wirklich Schwachsinn, gleich die kompletten Verknüpfungen zur Tour zu erstellen.

Sinnvoller wäre es, erstmal ein Sortiment auszuwählen, daraufhin die Produkte, die jenem Sortiment zugeordnet sind, aufzulisten und schlussendlich dort dann die Mengen der Bestellungen samt Datum für die Filialen einzugeben, aus denen sich dann der Backzettel zusammensetzt.

Dabei stelle ich mir grundlegend 2 Formulare vor:

In Bestellformular 1 werden die Backwaren eingegeben, die alle zum selben Datum geliefert werden müssen (bspw. Brötchen, Brote, Kuchen usw.) - in der Regel am Folgetag.

In Bestellformular 2 werden einzelne Produkte ausgewählt, die zu einem anderen Liefertermin angefordert werden und damit zu jeweils zu einer separaten Bestellung mit eigenem Datum gehören.

Dies alles wäre filialweise zu integrieren. Könnte man dies über eine spaltenartige Darstellung umsetzen, d.h. so, dass man alle Filialmengen auf einmal eingeben kann, diese aber zu den expliziten Bestellungen (eben zu der jeweiligen Filiale) eingefügt/verknüpft werden?

Die Tour wäre dann ja separat anhand des Datums der vorhandenen Bestellungen zu erstellen?

Was haltet ihr davon?

Gruß!
DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
22. Sep 2010, 18:44
Rufname:

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

AH!!!!!!!!!!!!!

sehr schön, so soll es sein.

Denn die Korrekturen, wenn z.B. ein Fax vom Kunden kommt, und der Bäcker muss 500 Brötchen mehr backen, sind für Backzettel und Tourenplanung nicht wirklich entscheidend.

Denn wenn die in die DB eingepflegt werden, sind die Brötchen schon gefrühstückt.
Die sind nur für die Rechnung wichtig.

Aber, mit zwei Forms kommst du nicht aus.

Frage, sind auf dem Backzettel auch gleich die Rezepturen drauf?
Wenn ja, muss du das komplette Rezept für das Produkt eingeben.
Wobei du z.B. ein Standardrezept erstellen kannst, dann das Produkt, und dann ordenst du dem Produkt das Rezept zu.
So musst du nicht für
Kaiserbrötchen, Schrippen, Knüppel, Rundstücke (wie wir in Hamburg sagen) jedesmal ein neues Rezept anlegen.
Dann müsste jedes Produkt einer warengruppe zugeordnet werden (z.B. Weizenkleingebäck, Weißbrote, Mischbrote usw), diese dann einer Abteilung (Bäckerei, kalte Konditorei, warme Konditorei)

Daraus resultiert dann ein Bericht mit Gruppenwechsel, so dass auf dem Backzettel für den Teigmacher keine Sahnetorte draufsteht.

Im Bestellformular legst du dann einen neuen DS an, diesem DS weist du den Kunden zu, das Lieferdatum (evtl das Bestelldatum), und das Produkt.

In einer Abfrage wird dann (ausgehend vom Bestellformular) nur die DS erfasst,
für ein bestimmtes Lieferdatum.

Bedenke, der Kunde kann am Freitag auch schon die Bestellung für in zwei Wochen aufgeben, wenn es sich z.B. um eine Hochzeitstorte handelt.
Denn die macht der Sahnepanscher auch nicht mal eben in 5 min Smile

Alles klar, soweit? Backrezepte-Online Smile
Nachtrag: DieterB am 22. Sep 2010 um 18:51 hat folgendes geschrieben:
Tar, schick mir mal eine Office2000-Version.

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
tar
neugiersch


Verfasst am:
23. Sep 2010, 00:19
Rufname:

Re: AW: nochmal Backzettel - neuer Ansatz? - Re: AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

DieterB - 22. Sep 2010, 18:44 hat folgendes geschrieben:
Denn die Korrekturen, wenn z.B. ein Fax vom Kunden kommt, und der Bäcker muss 500 Brötchen mehr backen, sind für Backzettel und Tourenplanung nicht wirklich entscheidend.
Nachts um 2 Uhr wird sicher keiner urplötzlich 80 Brötchen bestellen Laughing

Aber es gibt andere Probleme, wie bspw. Mehlqualität (kenne mich da nicht aus), irgendwelche fehlenden Materialien, weil irgendwas schief geht oder man disponiert um, um Bleche voll aufzufüllen - backt also mehr, als bestellt worden sind.

Zitat:
Denn wenn die in die DB eingepflegt werden, sind die Brötchen schon gefrühstückt. Die sind nur für die Rechnung wichtig.
Auch für die Bestandserfassung der benötigten Materialien und im Verbund mit den Retouren zur Kontrolle der Filialerlöse. Wäre ja alles zur späteren statistischen Auswertung nützlich.

Zitat:
Frage, sind auf dem Backzettel auch gleich die Rezepturen drauf?
Meinst du die Teigart? Die wollte ich über Rezepte -> Zutaten -> Teigkategorie & Teigteiler herausfinden lassen (soweit bin ich noch lange nicht), um letztlich gleich die Summe des benötigten Teiges auf den Backzettel ausgeben zu lassen.

Zitat:
Wenn ja, muss du das komplette Rezept für das Produkt eingeben.
Ja, wenn man das will, kommt man da wohl nicht drumherum.

Zitat:
Wobei du z.B. ein Standardrezept erstellen kannst, dann das Produkt, und dann ordenst du dem Produkt das Rezept zu. So musst du nicht für Kaiserbrötchen, Schrippen, Knüppel, Rundstücke (wie wir in Hamburg sagen) jedesmal ein neues Rezept anlegen.
Das klingt gut. Gänge das mit folgender Datenstruktur (siehe Bild unten)?

Zitat:
Dann müsste jedes Produkt einer warengruppe zugeordnet werden (z.B. Weizenkleingebäck, Weißbrote, Mischbrote usw), diese dann einer Abteilung (Bäckerei, kalte Konditorei, warme Konditorei)
Reichen dazu nicht Produktkategorien aus? Die Abteilung brauche ich doch nur auf dem Backzettel (also dem Bericht) und lasse da eben nur bestimmte Produktkategorien ausgeben, oder nicht?

Zitat:
Daraus resultiert dann ein Bericht mit Gruppenwechsel, so dass auf dem Backzettel für den Teigmacher keine Sahnetorte draufsteht.
Basieren diese Gruppenwechsel auf vorhandenen Tabellen oder kann man das in dem Bericht manuell machen?

Zitat:
Im Bestellformular legst du dann einen neuen DS an, diesem DS weist du den Kunden zu, das Lieferdatum (evtl das Bestelldatum), und das Produkt.
Ja, das wäre sicher für eine Einzelbestellung sinnvoll, aber nicht für den laufenden alltäglich sich fast nie ändernden Backbetrieb. Da braucht man am besten das aktuelle Sortiment (Produkte vorher zugewiesen) und eine Gesamtübersicht pro Filiale (noch besser gleich alle) mit gleichzeitiger Eingabe für alle Produkte und eben nicht jeden Datensatz einzeln.

Zusätzlich dazu dann noch die Einzelbestellungen.

Zitat:
In einer Abfrage wird dann (ausgehend vom Bestellformular) nur die DS erfasst, für ein bestimmtes Lieferdatum.
D.h. Backzetteldatum (Ausdruck des Backzettels) = Lieferdatum minus 1 Tag?

Zitat:
Backrezepte-Online Smile
Danke, aber ich selbst bin kein Bäcker ;)

Gruß!



bz_dm.png
 Beschreibung:
aktuelles Datenmodell (der Übersicht halber Mitarbeiter-Tabellen usw. nicht mit angezeigt; Bestandszellen und -tabellen werden vorr. noch entfernt, weil überflüssig)
 Dateigröße:  134.43 KB
 Angeschaut:  819 mal

bz_dm.png



bz_dm.zip
 Beschreibung:
Volle Aufloesung

Download
 Dateiname:  bz_dm.zip
 Dateigröße:  105.6 KB
 Heruntergeladen:  25 mal

DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
23. Sep 2010, 09:22
Rufname:

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

also:

doch es kann vorkommen, dass Nachts um 2 bestellt wird.
Vielleicht nicht bei euch, aber Beispiel:
eine Kneipe, Bistro was auch immer
gibt mehr raus als kalkuliert, die rufen kurz vor Feierabend an, wwenn sie morgens um 2 den laden schliessen.

Ja auch die Mehlqualität spielt eine Rolle.
Aber das passiert ein oder zweimal, immer wenn Anfnag des Jahres die neue Ernte auf dem Markt ist,
oder die Mühle schlechte Qualität liefert.

Um den benötigten Teig mit auszudrucken, musst du die Rezepte erfassen.
In Abhängigkeit der bestellten Mengen berechnet Access das automatisch.

Produkt - und Warenkategorien sind hier das selbe.

Die Gruppenwechsel basieren auf erstellte Abfragen.
Diese diene als Datenbasis für die Berichte.
Im Bericht selber kann mna die Gruppenwechsel dann definieren.

Was das Bestellformular angeht: du MUSST einen neuen DS anlegen,
nämlich die Bestellung.

Unabhängig ob du den Kunden mehrfach bedienst, oder nur einmal.
Brauchst du sowieso für die Backzettel / Tourenplanung.

Auch dazu habe ich eine Idee ausgebrütet.

Wieviele Fahrzeuge habt ihr, wie oft fahren die vom Hof?

nein, der Backzettel ist NICHT Lieferdatum -1 tag.
Es sei denn, die Brötchen, die der Kunde bestellt hat für Dienstag, werden am Montag schon gebacken.

ich glaube den belieferst du dann zwei mal.
das erste und das letzte mal Smile

und grade weil du kein Bäcker bist, slltest du mal ins Forum schauen.
Bringt dich weiter Smile

Und was deine Beziehungsstruktur angeht, vergiss sie.
Viel zu komplex.

Für die Filialerlöse würde ich persönlich Excel nehmen.
Kann man verknüpfen.

btw: wenn du eine Menge X an Brötchen haben willst, und du legst die Produkte in der DB an,
kannst du auch hinterlegen, wieviel auf einen Gärgutträger kommen.

Bestellt (benötigte Menge : Anzahl auf Gärgutträger = Anzahl der Gärgutträger)
Beispiel:

2500 Brötchen : 32 per Gärgutträger = 78,125
Der Bäcker würde dann 78 Bleche voll machen, und den Filialen 4 Brötchen weniger geben. Besser als 28 wegzuschmeissen. Smile

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
tar
neugiersch


Verfasst am:
23. Sep 2010, 10:44
Rufname:

Re: AW: nochmal Backzettel - neuer Ansatz? - Re: AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

Zitat:
doch es kann vorkommen, dass Nachts um 2 bestellt wird.
Vielleicht nicht bei euch, aber Beispiel:
eine Kneipe, Bistro was auch immer
gibt mehr raus als kalkuliert, die rufen kurz vor Feierabend an, wwenn sie morgens um 2 den laden schliessen.
Ich frage mal nach, ob auch nachts Bestellungen eingehen. Hochzeitstorten werden i.d.R. aber wohl seltens mitternachts bestellt ;)

Zitat:
Was das Bestellformular angeht: du MUSST einen neuen DS anlegen,
nämlich die Bestellung.
Unabhängig ob du den Kunden mehrfach bedienst, oder nur einmal.
Brauchst du sowieso für die Backzettel / Tourenplanung.
Natürlich kannst du alles einzeln eingeben und täglich hundert neue Bestellungen pro Filiale anlegen. Aber genau das wäre sinnfrei. In der Praxis bündelt man zusammenhängende Bestellungen (Bestellzeilen) in einer Bestellung. Darum geht es mir. Zusätzlich zu diesen laufenden zusammenhängenden Bestellzeilen kommen Einzelbestellungen hinzu (Hochzeitstorte an Kunde X).

Zitat:
Auch dazu habe ich eine Idee ausgebrütet.
Wieviele Fahrzeuge habt ihr, wie oft fahren die vom Hof?
Ein Fahrzeug - geht, soweit ich weiß, einmal früh (Auslieferung), einmal mittags (je nach Verkaufslage in den Filialen) von der Hauptfiliale weg und holt (nicht immer) abends die Retouren.

Zitat:
nein, der Backzettel ist NICHT Lieferdatum -1 tag.
Es sei denn, die Brötchen, die der Kunde bestellt hat für Dienstag, werden am Montag schon gebacken.
Es wird doch Montag nachts (Datum X) gebacken - und Dienstag (Datum X+1) ausgeliefert? Oder willst du die erst Dienstag backen und der Kunde (die Filiale) hat halt Dienstag früh keine Brötchen?

Zitat:
und grade weil du kein Bäcker bist, slltest du mal ins Forum schauen.
Bringt dich weiter Smile
Ich muss sicher nicht erst Bäcker lernen (Rezepte wälzen), wenn ich Bestellungen etc. in Access integrieren will? Rolling Eyes

Zitat:
Und was deine Beziehungsstruktur angeht, vergiss sie.
Viel zu komplex.
Das kommt wohl darauf an, was man damit bezweckt - schließlich möchte ich so flexibel wie möglich bleiben und dabei so wenig Redundanzen wie möglich erzeugen. Meine alte Struktur war auch "einfacher (Beziehungsabbildung)" - nur eben für meine Zwecke nicht ausreichend.

Zitat:
Für die Filialerlöse würde ich persönlich Excel nehmen.
Kann man verknüpfen.
Bitte?! Da braucht man auch gar kein Access verwenden, denn der Backzettel wird bereits im Excel gemacht - und es ist einfach umständlich. Wenn ich aber einmal alle Daten bereits im Access habe, kann er die Rechnungen, Erlöse usw. da auch wunderbar ausrechnen und als Bericht ausgeben - wo ist da nun wieder das Problem?

Zitat:
btw: wenn du eine Menge X an Brötchen haben willst, und du legst die Produkte in der DB an,
kannst du auch hinterlegen, wieviel auf einen Gärgutträger kommen.
Ja, diese Information müsste im Rezept hinterlegt und beim Backzettel abgefragt werden.

Gruß!
DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
23. Sep 2010, 11:09
Rufname:

AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

wenn der Bäcker morgens um 2 anfängt, und um 7 ausliefert, ist in beiden Fällen der gleiche tag.

Unabhängig davon, ist der Backzettel für Dienstag, egal ob der Bäcker Montag Abend um 10, oder Dienstag morgens um 2 anfängt.

Und gebündelt wird auch in der Praxis nichts, denn du kannst nicht Brote, Sahnestücke und Brötchen in eine Bestellung packen.

Letzendlich legst du pro Kunde / Filiale nur eine Bestellung an, und weist der die Menge / Artikel zu.

Wir telefonieren am WE.
Am besten am Samstag Abend. Wenn das Wetter gut ist, bin ich nämlich nicht zu Hause.

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
tar
neugiersch


Verfasst am:
23. Sep 2010, 11:52
Rufname:

Re: AW: nochmal Backzettel - neuer Ansatz? - Re: AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

Zitat:
Und gebündelt wird auch in der Praxis nichts, denn du kannst nicht Brote, Sahnestücke und Brötchen in eine Bestellung packen.

Letzendlich legst du pro Kunde / Filiale nur eine Bestellung an, und weist der die Menge / Artikel zu.
Entweder meinen wir dasselbe und reden aneinander vorbei oder ich verstehe dich nicht.

Wenn ich als Kunde/Filiale 30 Brötchen und zwei Torten bestelle, ist das doch 1 Bestellung?

Gruß!
DieterB
Office-Anwender mit Programmierkenntnissen


Verfasst am:
23. Sep 2010, 12:38
Rufname:


AW: nochmal Backzettel - neuer Ansatz? - AW: nochmal Backzettel - neuer Ansatz?

Nach oben
       Version: Office 2010

ja, ist eine Bestellung für den Lieferschein,
aber 2 für den Backzettel.

D.h. du erstellst einen neuen DS "Bestellung", und dem weist du zwei Artikel zu.

Wir kriegen das hin

_________________
Gruß

DieterB

Auch der längste Weg
beginnt mit dem ersten Schritt
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Gehe zu Seite Zurück  1, 2, 3
Diese Seite Freunden empfehlen

Seite 3 von 3
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: mehrere Variablen aus einer Tabelle zu neuer Variabeln 6 StNeu 110 06. Feb 2014, 15:21
StNeu mehrere Variablen aus einer Tabelle zu neuer Variabeln
Keine neuen Beiträge Access Tabellen & Abfragen: neuer Datensatz bei Änderung 16 toto1964 437 18. Jan 2014, 21:21
toto1964 neuer Datensatz bei Änderung
Keine neuen Beiträge Access Tabellen & Abfragen: Zelleninhalt teilen und Werte in neuer Zeile einfügen 5 Gast 2223 06. Jun 2013, 10:44
Gast Zelleninhalt teilen und Werte in neuer Zeile einfügen
Keine neuen Beiträge Access Tabellen & Abfragen: Neuer Preis einfügen 21 moebiusband 402 19. Apr 2013, 15:40
moebiusband Neuer Preis einfügen
Keine neuen Beiträge Access Tabellen & Abfragen: Neuer Index mit variablem Inkrement 4 cocco 509 08. Jan 2012, 17:25
Nouba Neuer Index mit variablem Inkrement
Keine neuen Beiträge Access Tabellen & Abfragen: Zwei Attribute in neuer Tabelle verbinden - Beziehungen 12 Tig3r 402 13. Sep 2011, 10:57
Gast Zwei Attribute in neuer Tabelle verbinden - Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Anfügeabfrage /Neuer datenschlüssel aus Formular übernehmen 0 Kla-Sur 290 16. Aug 2011, 12:04
Kla-Sur Anfügeabfrage /Neuer datenschlüssel aus Formular übernehmen
Keine neuen Beiträge Access Tabellen & Abfragen: "Liegezeiten" berechnen. Ansatz gesucht. 2 nakoda 508 01. Jun 2011, 10:38
nakoda "Liegezeiten" berechnen. Ansatz gesucht.
Keine neuen Beiträge Access Tabellen & Abfragen: Aufbau neuer Datenbank mit Zeiterfassung 14 Lothar123 3803 09. Dez 2009, 14:08
tk6 Aufbau neuer Datenbank mit Zeiterfassung
Keine neuen Beiträge Access Tabellen & Abfragen: Nochmal Aufbauen einer Gültigkeitsregel mit Datumsformat 1 Maedel 388 14. Jan 2009, 00:13
Nouba Nochmal Aufbauen einer Gültigkeitsregel mit Datumsformat
Keine neuen Beiträge Access Tabellen & Abfragen: Problem mit Ansatz zu kumulierender Summe 1 crossweb 504 22. Okt 2008, 12:46
crossweb Problem mit Ansatz zu kumulierender Summe
Keine neuen Beiträge Access Tabellen & Abfragen: neuer Datensatz im Formular immer oben an erster Stelle 9 speedy0308 2024 11. Apr 2008, 14:45
Willi Wipp neuer Datensatz im Formular immer oben an erster Stelle
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Expression Web Forum