LibreOffice-Forum

Hallo ihr Lieben,
seit einiger Zeit beschäftige ich mich (beruflich) mit LO Base und habe mir mit Hilfe dieses und all der anderen wunderbaren Foren vieles selbst beigebracht. Nun bin ich aber an einem Punkt, wo ich echt nicht mehr weiter komme:

Ich habe eine Tabelle "Einkauf", in der unsere Rohstoffe mit Lieferdatum, Preis und Menge aufgelistet sind. Ich soll jetzt eine Abfrage schreiben aus der hervorgeht, welchen Preis pro Stück die letzten 250 gelieferten Artikel durchschnittlich haben.

Eine Abfrage, die eine laufende Summe erzeugt, habe ich bereits hinbekommen, aber die fängt natürlich ab dem zuerst gelieferten Artikel an zu zählen und nicht ab dem zuletzt gelieferten. Mir fehlt gerade jeglicher Ansatz, wie ich das umdrehen kann:
Zudem ist es eher unwahrscheinlich, dass die laufende Summe tatsächlich einmal exakt 250 ergibt. D.h. es müsste ein Datensatz nur teilweise berücksichtigt werden. Geht das überhaupt? Beispielsweise wurde "Artikel 2" am 25.02. 12-mal geliefert, die laufende Summe wäre somit 261. 1-mal "Artikel 2" müsste also in den Durchschnittspreis mit eingerechnet werden, 11 Stück aber nicht...

Ich hoffe, mein Problem ist deutlich geworden. (Ich bin ganz schlecht im Erklären von Dingen. )

Die Tabelle hänge ich mal als .ods an:

Hallo JuRo,

nur zum Verständnis:
Die Spalte "Grundpreis" ist der Preis pro Stück, oder?
Die Definition 250 Stück rückwärts von jetzt an trifft in dem angehängten Beispiel nirgendwo zu. Schließloch wurde ja von keinem Artikel diese Stückzahl verkauft, richtig?

Hallo RobertG,

der Grundpreis ist unser EK-Preis pro Stück, auf den dann je nach Größe noch ein Aufpreis draufkommt, ja.

Der Verkauf wird in dieser Tabelle gar nicht berücksichtigt, es wird nur eingetragen, wenn eine neue Lieferung kommt. Wir bestellen halt teilweise, weil es gerade günstig ist und nicht weil alles verbraucht ist.

... jetzt müsste man nur noch wissen welche Liefermengen pro Lieferung kamen/kommen - evtl. reicht der Code oben aber schon um eine ungefähre Größenordnung abzuschätzen.
Wenn's genau 250 Stk sein sollen, wird's schwierig, dann ist es vermutlich am besten den Preis pro Einkauf zu kategorisieren und dann die Tabelle zu iterieren - ist dann aber kein SQL mehr

Hallo gogo,

Danke erstmal für deine Hilfe.
Wenn ich die Daten wie von Dir vorgeschlagen sortiere, bekomme ich zwar den zuletzt gelieferten Artikel als ersten Datensatz angezeigt, aber die laufende Summe wird trotzdem noch vom ersten Artikel (also dem mit der niedrigsten ID) aus gebildet. Ich möchte ja aber gern, dass diese eben vom letzten Artikel an (also dem mit der derzeit höchsten ID) gebildet wird.

limitiert die Gesamt-Datenmenge

Ich hab das jetzt mal so eingebaut:
bekomme dann aber die Fehlermeldung:

Cannot be in ORDER BY clause in statement [SELECT COUNT( * ) AS "ID", "A"."Lieferdatum", "A"."Artikel 1", "A"."Artikel 2", "A"."Stück", SUM( "B"."Stück" ) AS "Laufende Summe" FROM ( SELECT * FROM "Einkauf" ORDER BY "Lieferdatum" DESC LIMIT 250 ) AS "A" INNER JOIN ( SELECT * FROM "Einkauf" ORDER BY "Lieferdatum" DESC LIMIT 250 ) AS "B" ON "B"."ID" <= "A"."ID" GROUP BY "Lieferdatum", "Artikel 1", "Artikel 2", "Stück"]

da gibt's wohl eher ein Problem mit der Limit-Anweisung, die sieht in Firebird wohl eher so aus: Nachdem first im Editor aber grün dargestellt wird nehme ich an, dass der Treiber das wohl nicht implementiert hat.

Bei komplexen Abfragen gilt: zuerst die Datenbasis so darstellen wie man's haben will (Also genau die DS suchen die man braucht, in der richtigen Reihenfolge darstellen und dann erst auf Basis dieser Tabelle die Berechnungen machen).

Ich nehme an, dass die Limit-Anweisung passt. Wenn die Abfrage funktioniert, dann wäre die sicherste Lösung, diese Abfrage als Ansicht zu erstellen und dann auf die Ansicht zuzugreifen. Die Kombination von Sortierung und Gruppierung macht der HSQLDB Probleme.

Aber: Ist die Abfrage überhaupt das, was gewünscht war? Das sind doch jetzt die letzten 250 Datensätze aus dem Einkauf, nicht die letzten 250 Stück eines Artikels, oder?

Gruß

Robert

So sehe ich das auch und ich frage mich, welcher Sinn steckt hinter der Zahl 250? Macht es nicht viel mehr Sinn einen gleitenden Durchschnittswert mitzuführen, wie es in jedem ERP-System gemacht wird? Dann stünde der aktuelle Wert immer im neuesten Datensatz zur Verfügung und es müßten keine aufwendigen Rechenoperationen durchgeführt werden.

Gruß
Ray