Hat noch jemand das Problem, dass er/sie z. B. keine Umsatzstatistik seit dem 01.01. diesen Jahres oder noch früher abfragen kann? Das Datum wird immer wieder auf den 21.02.2012 zurückgesetzt. Darüber hinaus stimmen die Zahlen nicht wirklich. Da werden z.B. 91 Stück angegeben (Artikel nach dem 21.02.2012 hinzugekommen) und dann verteilt der Report diese Menge auf 2 Attribute: Variante 1: 6 Stück Variante 2: 4 Stück Äh? 6+4 = 91 ???? Kennt Ihr die Probleme bei der Umsatzstatistik? VG Holger
Nein, aber ich denke die Zahlen sollten dennoch korrekt sein - oder ? ;-) Ein Rechnungserzeugendes System sollte schon in der Lage sein 3 Zahlen zu addieren...
Ich habe mir das jetzt auch mal angesehen. Wenn ich das richtig verstehe steht da wie oft ein Artikel bestellt wurde, aber nicht wie viel Stück bei der Bestellung genommen wurden. Ich habe zum Beispiel einen Artikel, der ist erst 1x Verkauft worden, aber der Kunde hat 30 Stück genommen. in der Statistik steht: Bestellung .............. #Artikel............. Umsatz Artikel xy: 1x .............30....................xx,xx€
Hast Testbestellungen usw. gemacht? Die sind da auch mit drinnen vermut ich mal. es sei den hast die damals richtig zurückgesetzt/stoniert.
Hallo, ja, alles ordnungsgemäss storniert, was Testbestellungen angeht. Das mit dem "wie oft" bestellt wär eine Möglichkeit, aber das wär eine Zahl für einen Bestellhäufigkeitsreport, nicht für eine Umsatzstatistik mit Details und Betrag . Ich möchte ja gern wissen, wie oft ein Artikel und seine Variante "versendet" wurden, um mal den Bestand gegen Artikel-Abgang zu prüfen. Sowas sollte ja auch ohne eine WaWi möglich sein, dass ein System, welches Buchungen durchführt, Rechnungen/Lieferscheine schreibt und Bestände verwaltet auch sagen kann, wo die Sachen hin sind. Sinnfrei wären ja dann im Vergleich auch die Zeilen ohne Varianten, da steht NICHT wie oft sie bestellt wurden, nur die "angebliche" Menge. Ich mein, wen interessiert es in einer Umsatzstatistik wie oft eine Artikelvariante bestellt wurde? Man will wissen welchen Mengenanteil die Variante hat. Habs gerade nochmal stichprobenartig kontrolliert. Das mit Anzahl Bestellvorgänge kommt bei etlichen auch nicht hin.
Also wenn ich nicht ganz daneben liege sollte folgendes SQL alle Artikel aufsummieren, die ungleich Status 99 (STORNIERT) sind. Ersatzweise kann man auch (siehe Tabelle ORDER_STATUS) den order_status_id = 3 (Versendet) nehmen. Wobei "<> 99" sollte ja passen, da der Bestand auf jeden Fall eingelastet sein und im Restbestand berücksichtigt sein sollte. Code: SELECT orders_products.products_model, orders_products.products_name, sum( orders_products.products_quantity ) AS Qty, sum( orders_products.final_price ) AS Sales, Count( orders_products.orders_id ) AS OrderCounter FROM orders_products, orders WHERE orders_products.orders_id = orders.orders_id AND orders.orders_status <>99 GROUP BY products_model ORDER BY `orders_products`.`products_name` ASC Vergleiche ich nun die so ermittelten Werte mit dem Report hab ich Abweichungen ohne Ende. Mal abgesehen davon, dass der Report nicht in der Lage ist korrekt nach Artikel-Nummer zu sortieren. Sieht jemand einen Denkfehler? Holger
So, der Gambio-Support hat sich gemeldet. Die Fehler sind weitestgehend bekannt und werden in einer der nächsten Updates gefixed.