Wahrscheinlich ist es nur ein Bedienungsfehler aber die Anzeige verwirrt mich a´bisserl - siehe Bild. Bei nur einer Bestellung in dem gewählten Zeitbereich derart viel Umsatzsteuer? Sollte die Anzeige der Steuern etwa nicht den eingestellten Zeitbereich berücksichtigen?
Du kaufst ja auch nix! Ist aber auch egal - das Problem ist auch bei mehr Umsatz/Tag: Die Anzeige der Steuern beziehen sich nicht auf den Datumsbereich! Weshalb dann "startDate" und "endDate" an "TaxSumManagerReader.inc.php" übergeben werden .... ??
Irgendwie finde ich diese Anzeige besser - siehe Bild! Das "WHERE `insert_date` >= '%s' AND `insert_date` <= '%s'" in "TaxSumManagerReader.inc.php" kann m.E. kein sinnvolles Ergebnis bringen, da die Tabelle "orders_tax_sum_items" vom System angelegt und aktualisiert wird. Wenn 1400 Datensätze das gleiche Datum haben, wie soll dann eine Selektion für einen Bereich dabei rauskommen? Habe die ganze Select in eigenes Script eingebaut und mit "WHERE o.date_purchased <meine Datumbereiche> zeigt es an, was es soll.
@Manfred habe genauso ein Phänomän wie in deinem Beispiel. Habe eine Testbestellung im Duplikat Shop getätigt mit folgender Auswertung. stellt sich im allgemeinen die Frage, wie errechnet er diese Bestellung???
Gute Frage! Meines Erachten kann die Anzeige der Steuern gar nicht den eingestellten Zeitbereich berücksichtigen - siehe Beitrag #6. PS: Nur gut dass es für richtige Zahlen eine preiswerte Alternative gibt - siehe "Tipp"!
Die Module sind mir alle bekannt...Danke Manfred ;-) ...Ist aber nicht Sinn der Übung, da der Shop ja in diesen Format Arbeitet und dieses so auch zur Verfügung stellt. Woran hapert es also. Nicht ausgereift ...noch in Überarbeitung....schwerwiegender Bug? Wird die Umsatzstatistik erweitert auf eine funtionierende Version?
Das Ding stammt aus grauer Vorzeit, erfreut sich wenig Beachtung durch GM und liefert seitdem Zahlen, die den Wahrheitsgehalt einer 6-Wochen-Wettervorhersage haben. Im Prinzip "Ja" ...