Hallo in einer Tabelle ist das Feld (Preis) 0,00 DM Nun soll dieses Feld gefüllt werden, und zwar in Abhängigkeit des Inhaltes der Felder (ARTIKELNUMMER und GRÖSSE). Dies soll in einem nonprinting Report passieren. Es sollte ein Dialogfenster erscheinen, das mir die Artikelnummer und Groesse anzeigt, dann möchte ich den Preis eingeben für diese Kombination. Ich habe bereits ein Fenster erstellt, aber da diese Kombination (Artikelnummer und Groesse) mehrmals vorkommt, muss ich jedesmal den Preis eingeben. Wie kann ich erreichen, daß die Anwendung kapiert, daß diese Kombination bereits bearbeitet wurde. Vielen Dank im voraus. lothar knichel
quote:
Originally posted by lothar knichel: Nun soll dieses Feld gefüllt werden, und zwar in Abhängigkeit des Inhaltes der Felder (ARTIKELNUMMER und GRÖSSE). […] aber da diese Kombination (Artikelnummer und Groesse) mehrmals vorkommt, muss ich jedesmal den Preis eingeben.
Überdenke mal die Struktur der Tabelle denn irgend etwas stimmt da nicht: Wenn Die Kombinaktion Artikel/Grösse den Preis bestimmt, dann können und dürfen nicht verschiedene Preise für dieselbe Artikel/Grösse-Kombination vorkommen. Und wenn noch weitere Felder Massgebend sind (Qualität, Material, Datum) dann Stimmt der erste Teil der Frage nicht. Wie lautet der Primary Key der Tabelle? With best regards from Switzerland Marcus Fabian
Hallo Marcus, die Kombination Artikel/Grösse kommt in der Tabelle mehrmals vor, diese Kombination soll auch immer den gleichen Preis bekommen. Das Dialogfenster das ich erstellt habe, stellt mir nur leider diese Kombination immer wieder vor bis der letzte Datensatz mit der Kombination erreicht ist. Dieses Dialogfenster sollte erkennen, das der Preis eingegeben wurde und dann alle gleichen Kombinationen ändern, anschliessend sollte die nächste Kombination vorgestellt werden usw… Gruß Lothar Knichel
Hallo Herr Knichel, schön das man sich in diesem Forum “wiederfindet”. Ich könnte mir folgendes Lösungskonzept vorstellen (Braucht leider eine zusätzliche Tabelle): Als erstes durchläuft der Report Ihre Tabelle und schreibt die Möglichen Kombinationen aus Artikelnummer und Grösse in eine Neue Tabelle (Bestehend aus den Feldern Artikelnummer, Grösse, und Preis. Primärschlüssel sind Artikelnummer und Grösse). Nachdem alle Kombinationen weggeschrieben sind, fragt der Report die Preise der Kombinationen ab und trägt sie in die Tabelle ein. Im letzten Schritt filtert man in der Ursprungstabelle die Datensätze über Artikelnummer und Grösse, und ändert in diesen den Preis. Das alles ist natürlich zum selberprogrammieren nicht ganz so leicht, aber vieleicht kann da ein Systemhaus aus Krefeld, bei dem ich auch mal war, aushelfen. Viele Grüsse, Oliver Schmitz
Hallo Ralph, Artikelnummer und Groesse bilden nicht den Primärschlüssel. Die Tabelle hat nichts mit der Artikeltabelle zu tun, es ist eine von mir erstellte Tabelle um die es sich handelt. (Primärschlüssel:Lfd,PerNr,Datum) Lfd PerNr Artikelnr Beschreibung Groesse Anzahl Preis AnzahlPreis summe/PerNr 1 10102 LTZ1 Latzhose(blau) 50 1 0 0 0 1 10103 LTZ2 Jeans 52 1 0 0 0 1 10501 JK1 Jacke (blau) 54 1 0 0 0 1 10601 LTZ1 Latzhose(blau) 52 1 0 0 0 2 10102 SH1 Schuhe 8 1 0 0 0 2 10103 SH1 Schuhe 8 1 0 0 0 2 10501 LTZ2 Jeans 50 1 0 0 0 3 10501 SH1 Schuhe 9 1 0 0 0 Ich möchte ein Dialogfenster öffnen, das folgendes tut: 1. Filter Preis=0 2. Zeige mir Artikelnummer und Groesse 3. Benutzer soll den neuen Preis eingeben 4. Ändere diese Preise in der Tabelle 5. Aktualisiere Felder (“Preis”)("AnzahlPreis") (“summe/PerNr”) 6. Finde den nächsten Artikel usw… Ich hoffe das Problem wird nun etwas klarer. Vielen Dank auch an alle die sich gemeldet haben. Gruß Lothar Knichel
Hey Lothar, vielleicht wäre das eine Lösung :? Tab1.SETRANGE(Preis, 0); Tab1.FIND(’-’); REPEAT __IF Tab1.Preis = 0 THEN BEGIN ____Tab2.RESET; ____Tab2.SETRANGE(Artikel, Tab1.Artikel); ____Tab2.SETRANGE(Groesse, Tab1.Groesse); ____IF Tab2.FIND(’-’) THEN BEGIN ______<hier eine Routine für die Eingabe des neuen Preises einfügen>; ______REPEAT ________Tab2.Preis := neuerPreis; //<- ‘neuerPreis’ stammt aus der PreisEingabe-Routine ________Tab2.MODIFY; ______UNTIL Tab2.NEXT = 0; ____END; __END; UNTIL Tab1.NEXT = 0; Tab1 und Tab2 verweisen auf den gleichen Table. Die Abfrage nach dem Preis = 0 in der 4. Zeile wird notwendig (obwohl ja anfangs nur nach dem Preis 0 gefiltert wird), da in der Zwischenzeit der gefilterte Satz einen Preis enthalten kann. Ist es das, was Du versuchst ? Stefan Weinreich Billing Analyst
quote:
Originally posted by lothar knichel: Artikelnummer und Groesse bilden nicht den Primärschlüssel. […] (Primärschlüssel:Lfd,PerNr,Datum)
Ich stehe nach wie vor zu meiner Vermutung, dass die Tabelle falsch strukturiert ist. Wir sollten uns deshalb zunächst einmal darum bemühen, die Tabelle vernünftig zu strukturieren. Die entsprechenden Forms ergeben sich dann wie von selbst. Zunächst scheint es sich hier um das klassische Artikel-Zusatz-Problem zu handeln, wie es bei Kleidern häufig vorkommt: Dieselbe Latzhose kostet gleich viel, egal ob sie in Grösse 48 oder 56, in blau oder rot angeboten wird. Nun zur Frage, wie das strukturiert werden soll: 1. Die Bedeutung des Feldes “Lfd” (immerhin erster Sortierschlüssel des PK) ist mir nicht klar. Ich vermute mal, dass es sich hier - wie der Feldname impliziert - um eine Laufnummer handelt. Wenn das stimmt, läge schon mal der erste Tabellen-Murks vor. Ohne das Problem zu kennen, behaupte ich mal ganz frech, dass bei jeder Tabelle, die einen Artikel näher beschreibt, die Artikelnummer das erste Feld des Primary Key sein muss. 2. Da es offenbar keinen direkten Zusammenhang zwischen Preis und Grösse/Farbe des Produktes gibt, müssen diese Angaben in verschiedenen Tabellen abgelegt sein. Insofern würde es genügen, den Preis über Tabelle 28 zu erfassen. Hat die Grösse dennoch eine Bedeutung für den Preis, müsste Tabelle 28 um die Grösse erweitert und die Grösse Teil des Primärschlüssels werden. Dies gilt für alle Felder, die Preisrelevant sind. 3.) Felder, die nichts mit dem Preis zu tun haben, werden in einer eigenen Tabelle abgelegt. Und dort darf dann - bittschön - auch kein Preis erscheinen. Anders ausgedrückt: Der Preis darf, soll und muss in einer Tabelle abgelegt sein, bei der alle den Preis bestimmenden Felder den Primärschlüssel bilden. — Hier noch einige Beispiele aus meiner Praxis: a) Frucht und Gemüse-Handel: Dieselben Karotten (= Artikelnummer) haben höhere Preise, wenn die Karotten gewaschen und abgepackt werden müssen. In diesem Fall wurden Leistungsarten definiert (z.B. Verpackung, Waschen, Schälen) etc, die den Preis verändern. Dabei können mehrere preisrelevante Leistungsarten zutreffen: Waschen+Schälen+Verpacken b) Kontaktlinsen: Eine Linse vom Typ x wird in 5 verschiedenen Farben und 3 verschiedenen Materialien angeboten. Jegliche Kombination aus Material und Farbe hat denselben Preis. Weiterhin müssen pro Linse individuelle Parameter erfasst werden wie Späre, Innenradius, Abflachung etc. Hier wurde das Problem so gelöst, dass es eine mit der Seriennummer verknüpfte Tabelle gibt, die diese Parameter enthält. Aber, (um den Faden wieder zu finden): Diese Zusatztabelle enthält nicht den Preis der Linse. Lothar, vielleicht erklärst Du uns mal die Bedeutung der Felder Lfd,PerNr und schilderst mal Dein Problem ganz allgemein, damit wir uns ein besseres Bild machen und Dir konkretere Tips geben können. Tschüss Marcus Fabian
Hallo Marcus, vielen Dank für Deine Antwort. Zu Punkt “klassiches Artikel Zusatz Problem”. Es ist nicht dieses Artikel Zusatz Problem, denn Artikel 4711, Groesse 50 kostet 100 DM. Der Artikel 4711 Groesse 54 kostet 120 DM. Zu Punkt 1) Deine Vermutung stimmt, Lfd heisst Laufende Nummer. Allerdings hat meine Tabelle fast nichts mit der Artikel Tabelle zu tun. Es wird zwar eine Verknüpfung auf diese Tabelle gemacht, jedoch wird nur die Artikelbezeichnung in meine neue Tabelle einbezogen(kein Preis,keine Groesse). Der Preis und die Groesse sollen in meiner neuen Tabelle gepflegt werden. Meine neue Tabelle hat folgende Felder: Laufende Nummer, Personal Nummer, Artikelnummer, Beschreibung, Groesse, Anzahl,Preis, “AnzahlPreis", Summe/Personalnummer. Der primär Schlüssel ist Laufende Nummer, Personalnummer, Datum. Über diese Tabelle soll für unsere Mitarbeiter 2x im Jahr Bekleidung bestellt werden. Die Bekleidungsanforderung pro Mitarbeiter wird in diese Tabelle eingetragen (Anzahl,Artikel und Grösse). Deswegen auch der primärschlüssel(Laufende Nummer, Personalnummer, Datum). Anschliessend werden diese Artikel bestellt, erst jetzt ist der Preis für die Artikel bekannt. Diese Preise sollen nun in die Tabelle eingepflegt werden und zwar wie folgt beschrieben. In einem processing only Report möchte ich ein Dialogfenster öffnen, das folgendes tut: 1. Filter Preis=0 2. Zeige mir Artikelnummer und Groesse 3. Benutzer soll den neuen Preis eingeben 4. Ändere für diesen Artikel mit dieser Groesse die Preise in der Tabelle 5. Aktualisiere Felder (“Preis”)("AnzahlPreis”) 6. Finde den nächsten Artikel usw… Es ist natürlich so das verschiedene Mitarbeiter den gleichen Artikel in der gleichen Grosse bestellen, trotzdem soll mein Dialogfenster mir diese kombination nur einmal anzeigen. Mittlerweile habe ich eine Lösung hingefummelt, mit Hilfe der Antworten von Euch allen. Danke nochmal. Es klappt tatsächlich nur weiß ich nicht ganz warum. Die Lösung: bekleidung.SETRANGE(Preis,0); fenster1.OPEN (‘Artikelnummer #1##########’ +‘Groesse #2##########’ +‘Neuer Peis 3 #3##########’,Artikelnummer,Groesse); IF FIND(’-’) THEN REPEAT fenster1.INPUT(3,neuerpreis); SETRANGE(Artikelnummer,Artikelnummer); SETRANGE(Groesse,Groesse); REPEAT Preis:=neuerpreis; bekleidung.MODIFY; VALIDATE(Preis); VALIDATE(Anzahl); VALIDATE(“AnzahlPreis"); bekleidung.MODIFY; bekleidung.MODIFYALL("AnzahlPreis”,Anzahl*Preis); UNTIL NEXT=0; SETRANGE(Artikelnummer); SETRANGE(Groesse); UNTIL NEXT=0; END; Gruß lothar
Hallo Lothar, Deine Lösung scheint mir - jetzt wo das Problem bekannt ist - gar nicht so “hingefummelt” wie Du es bescheidener Massen ausdrückst. Was ich persönlich anders gemacht hätte ist folgendes: 1.) In der Tabelle hätte ich auf die nichtssagende Laufnummer verzichtet und als Primärschlüssel verwendet: “Personalnummer, Artikelnummer, Grösse, Datum”. In der Annahme, dass derselbe Mitarbeiter nicht dasselbe Kleidungsstück zweimal am selben Tag bestellt. Doch ok, diese Annahme kann falsch sein. Ich versuche aus meiner Erfahrung heraus grundsätzlich, Laufnummern zu vermeiden. 2.) Der Eingabeprozess ist mir zuwenig Anwenderfreundlich. Der Anwender ist nämlich gezwungen, die vom System vorgegebene Reihenfolge bei der Eingabe einzuhalten. Ich würde folgendes machen: Die Records mit Preis=0 in eine temporäre Tabelle übertragen (jeweils natürlich eine Zeile pro Artikel/Grösse). In dieser Tabelle kann der Anwender die Preise in beliebiger Reihenfolge eingeben. Ein Button startet dann den Prozess, der die Preise in die Ausgangstabelle überträgt. Tschüss Marcus With best regards from Switzerland Marcus Fabian