Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Abfrage

Begonnen von kovald, Dezember 17, 2010, 10:53:49

⏪ vorheriges - nächstes ⏩

kovald

Hallo,

ich habe folgende Ausgangssituation:

Tabellen: tbl_Auftrag, tbl_Auftragdetails,  tbl_Lieferschein, tbl_Lieferscheindetails, und tbl_Lieferung.

Sobald ein neues Lieferschein (tbl_Lieferschein, tbl_Lieferscheindetails) erstellt wird, wird dieser einer Lieferung (tbl_Lieferung) zugeordnet. Die "LieferungNr" wird in die Tabelle tbl_Lieferschein eingetragen.  Die Tabelle tbl_Lieferung besitzt ein Feld mit Gesamtkosten dieser Lieferung. Zur einer Lieferung können mehrere Aufträge gehören.

Ich möchte gerne in einer Abfrage die Kosten der Lieferung auf einzelne Aufträge verteilen. Die Verteilung soll prozentual, in Abhändigkeit vom Auftragswert (Auftragmenge*Positionspreis (tbl_Auftragdetails)), erfolgen.   (z.B. Kosten der Lieferung =100€, Auftrag1= 100€, Auftrag 2 = 300 €, Auftrag 3 = 600 €, Die Kosten müssen dann entsprechend, 10 € für Auftrag1, 30€ für 2 und 60€ für 3 umgelegt werden.

Meine Access Kenntnisse sind ´nicht wirklich gut und diese Aufgabe würde ich nur über mehrere Abfragen (mehr als 5) lösen können und damit habe ich schlechte Erfarungen in der Vergangenheit gemacht. Danach wird alles ziemlich unübersichtilich.

Kann bitte jemand eine elegante Lösung vorschlagen?

Gruß

Kovald

database

Hallo,

so wie du das darstellst müßtest du einen fixen Satz von 10% festgelegt haben.
Die Aufteilung wie du sie hier angerissen hast funktioniert aber auch dann nur fehlerfrei, wenn IMMER ganze Eurobeträge zum Tragen kommen sonst kommst du irgendwann ins Schleudern, wenn sich die Einzelbeträge nicht RESTLOS aufteilen lassen.

Ich will mich nicht in deine Logistik mischen aber ich würde das eher umgekehrt bewerkstelligen - die Gesamtkosten einer Lieferung aus den Teilbeträgen der einzelnen Aufträge zusammenzählen.

Und wenn es sich dabei tatsächlich um einen EINMALIG fixierten %-Satz handelt kann das dann in einer einzigen Abfrage ermittelt werden in dem du die einzelnen Auftragswerte mit 0,1 (im Fall von 10%) multiplizierst, die Summe daraus bildest dann diesen Betrag dann in das Feld Gesamtkosten - wobei das eigentlich nicht benötigt wird und m.E. auch unterlassen werden sollte - einträgst.

Andererseits würde sich sicher auch eine VBA-Function erstellen lassen, die nach Bekanntgabe einer LieferungNr diese Kosten berechnet und für die Weiterverarbeitung bereitstellt.
Alles in Abhängigkeit davon wie die Abläufe fixiert sind und die Ausgaben erfolgen sollen, kann diese Funktion dann auch in eine Abfrage eingebaut werden.



kovald

#2
Hallo Database,

tut mir leid, ich glaube ich habe mich nicht gut genug ausgedruckt! Das ist keine feste Verteilung!!! Ich habe lediglich ein einfaches Beispiel ausgesucht. A1 = 100, A2 = 300, A3= 600. Das sind die gesamtsummen pro Auftrag (Auftragswert). Die Kosten sollen etsprechend, je nach Auftragwert, prozentual verteilt werden. Die Kosten für die Lieferung sind immer unterschiedlich, je nach Entfernung oder Gewicht und ich muss die Kosten auf die Aufträge umlegen.  Gerechntet wird so: Gesammtsumme der Aufträge für Lieferung =1.000 €, etspricht 10% A1. 30 % A2, 60 % A3.  Kosten 100€!  Verteilt werden dann 10% für A1 30% für A2 und 60% für A3 von 100€  für jeden Auftrag.

P.S. Die Kosten muss ich nicht ermitteln, die werden immer eingetragen pro Lieferug, ich muss die nur auf Aufträge verteilen!

database

Hmmm,

berichtige mich dann bitte nochmals, wenn ich auch jetzt falsch liegen sollte.

Für mich bedeutet das dann , dass du in 2 Schritten rechnen musst.

1. Berechnung der Prozentsätze an Gesamtkosten der Lieferung für anteiligen Auftrag
   ProzAnteil = Auftragswert / Gesamtwert * 100

2. Berechnung der Prozentanteile an den Lieferkosten für jeden beteiligten Auftrag entsprechend der vorher ermittelten Prozentsätze.
   AnteilLieferkosten = Gesamtlieferkosten/100 * ProzAnteil

Wenn das so ist, würde ich das in eine Function verpacken und diese dann in einer Abfrage verwenden...

kovald

Hallo Database!
Genau richtig! Und eine VBA Funktion stelle ich mir als "elegante" Lösung vor!
Meine VBA Kenntnisse sind leider sehr begrenzt! Könntest du mir bitte ein einfaches Beispiel darstellen?
Vielen Dank im Voraus!

database

Hallo,

Also:

Ich habe dir ein einfaches Beispiel erstellt, ich hoffe das entspricht in Etwa deinem Tabellenaufbau ...

Versuch mal die Daten in den Tabellen zu analysieren und dann die Abfrage auszuführen.
Im Abfrageentwurf kannst du die LieferungID ändern.
Die Function befindet sich im Modul basBerechnung.

Ist halt nicht ganz einfach, da ich die tatsächliche Zusammnstellung deiner Tabellenfelder und Daten nicht kenne

HTH
Peter

[Anhang gelöscht durch Administrator]

kovald

Hallo,

sage ich nur wow!!! Hast du dir Mühe gemacht!
Sieht sehr gut aus!!!
Die Tabellenstruktur hast du sehr gut nachgebildet. Die Lösung ist genau das was ich gesucht habe!
Ich habe versucht ganz schnell alles an meine Tabellenfelder anzupassen, leider bisher ohne Erfolg. Die Abfrage wird ausgeführt, aber die Berechnung funktioniert nicht, "FEHLER" kriege im Feld "PAnteil" angezeigt. Habe auch nicht viel Zeit gehabt und werde erst am Montag weiter versuchen. Bin mir sicher, es wird schon funktionieren. Die Richtung stimmt auf jeden Fall. Setzte noch kein "Gelöst" zeichen!

Herzlichen Dank und ein schönes Wochenedne!

Kovald

database

Hallo,

du musst natürlich auch im Code nachsehen - hier gibt es ein SQL-Statement und eine DLookup-Funktion - auch hier müssen die Feldnamen UNBEDINGT angepasst werden!

kovald

Hallo Database,

ich konnte erst heute weitermachen. Irgend was mache ich obv. falsch und komme deshalb nicht weiter! Im Anhang meine Version. Was habe ich übersehen?

MfG
Kovlad

[Anhang gelöscht durch Administrator]

DF6GL

Hallo Dimitry,


TransportNr ist Datentyp String, deshalb in der Funktion auch so deklarieren. Weiterhin auf korrekte Schreibweise der Tabellenfeldnamen achten...


Inwieweit die geforderte Funktionalität so abgebildet werden kann, hab ich nicht getestet..

Single am Besten ganz vermeiden, besser wäre Double , bzw. bei monetären Feldern Währung (Currency)

database

#10
Hallo,

@kovald
wobei mit ...
ZitatSingle am Besten ganz vermeiden, besser wäre Double , bzw. bei monetären Feldern Währung (Currency)
die Deklarationen in der Function gemeint sind, in den Tabellen meines Beispiels sind sie 'richtig'.
Bei derartigen "Beispiel-Spiereien" verwende ich immer wieder die kleinen Datentypen in Erwartung eher kleiner Zahlen - eine Angewohnheit von mir...  ;) ;D

database

Hallo,

um dir zu zeigen wie es leichter und verständlicher und funktioneller gehen kann, habe ich deine Datei nochmals geändert.

Allerdings hat mich verwundert, dass plötzlich eine Tabelle auftaucht, die in deiner Anfrage nicht beinhaltet war.  :-\

Nun ich habe in sämtlichen Tabellen den Primärschlüssel auf Autowerte gelegt, die Detailtabellen dahingehend angepasst und die Beziehungen nach dem neuen Datenmodell frisch angelegt.
Datentypen soweit notwendig habe ich im Code geändert, die Feldnamen im SQL-String berichtigt und die Abfrage erneuert.
Ich habe die Beschränkung auf eine bestimmte TransportID (vorher LieferungID) weggelassen.

Es ist zwar nicht unbedingt falsch Textfelder als Primäschlüssel zu verwenden, allerdings ist das eine Fehlerquelle, die höchst unangenehme Nebeneffekte hervorrufen KANN.
Du solltest Primärschlüssel wo es möglich ist als Autowert deklarieren und so Access die Verwaltung der RICHTIGEN Einträge überlassen - das Ding kann das, hat schon lange Übung damit  ;) :D

Ich denke, die Änderungen sollten auch in einer bestehenden Datenbank keine allzugroße Sache sein - die Fremdschlüssel würden sich auch mittels VBA-Routine oder Aktualisierungsabfrage befüllen lassen.

Versuch das mal an einer Kopie deiner Original-DB - passe die an mein Beispiel im Anhang an.

HTH

[Anhang gelöscht durch Administrator]

DF6GL

Hallo Peter,


nur kurz zur Info:

An dieser DB ist dafür gesorgt, dass die PK-Werte streng per Code gerechnet werden (weil ich da selber mitgemischt habe... ;-) )

Diese PKs waren Teil der Konzeptionierung und hatten ihren Grund, so dass
"die Änderungen sollten auch in einer bestehenden Datenbank keine allzugroße Sache sein "
nicht durchzuführen ist.    :)

kovald

Hallo Franz, Hallo Peter,

habe ich eine Diskusion hier ausgelöst! Tut mir leid! Das wollte ich nicht.  :)
Eigentlich muss  ich das ganze in der DB nicht umsetzten, die Werte bekomme ich auch anderes, durch mehrere Abfragen und die Datenbank läuft in dieser Form schon seit ein par Jahren. 
Vor Weihnachten habe ich etwas Zeit gehabt und wollte was neues und nützliches lernen. Durch eure Hilfe ist es mir gelungen. Die Vorgehensweise habe ich verstanden und das war mein Ziel! 

Herzlichen Dank für eure Hilfe!

MfG
Dimitiriy

database

Hallo Franz,

ZitatAn dieser DB ist dafür gesorgt....

Das ging leider aus dem gesamten Thread nirgends hervor...  ;)

LG