Ja Danke für den Verweis, aber den kenne ich ja. Bei Xycons steht in der Liste der vorgefertigten Abfragen nur eine in Bezug auf Rechnungen: "Liste geschriebener Rechnungen (invoices_by_date)" Meine Frage war, ob das schon mal jemand ausprobiert hat. Weil es vom Wortlaut nicht unbedingt nach dem klingt was ich suche. Und nur zum testen sind mir 89,- netto etwas viel. Kennt es irgendjemand genauer? Edit: Ich hab' jetzt auch mal bei Xycons nachgefragt.
Ich zitiere von der Xcons Seite: Test-Versionen Test-Versionen der Module und des Frameworks sind auf der jeweiligen Modulseite erhältlich. Test-Versionen sind einmalig 14 Tage lang funktionsfähig und ggf. in Ihrer Nutzungszahl limitiert. Die Test-Versionen sind zum Testen und nicht für den produktiven Einsatz gedacht und deaktivieren sich daher in zufälligen Intervallen oder deuten ihre Funktion nur an. Aus (selbst) installierten Testversionen können wir jederzeit nach Erwerb der Nutzungslizenz eine vollwertige Vollversion schalten.
Ahhh. Übersehen. Das schau ich mir mal an. Wenn trotzdem irgendjemand konkrete eigene Erfahrung damit hat, bitte posten. Danke!
Man muss abwägen, was es kostet, wenn man das immer per Hand macht. Wenn die eigene Arbeitszeit nichts Wert ist, dann sind 89 EUR natürlich teuer. Auch mal nachgefragt, ob die ggf. dabei behilflich sind, die gewünschte SQL Abfrage zu erstellen?
?? Hast du falsch verstanden. Mir ist es nur zu teuer, wenn ich vorher nicht weiß ob das Modul denn das gewünschte überhaupt kann... Ja, ich hab da mal nachgefragt. Ich bekam unter anderem folgenden Screenshot, den ich auch weiterposten darf: Das war genau das was ich wissen wollte. Ist bestimmt auch für andere interessant. Nach den Spalten zu urteilen, wird es wohl das enthalten was ich brauche! Insbesondere auch die Auftrennung der Mehrwertsteuersätze. Werde dann also Xycons Modul demnächst mal installieren. Ich berichte dann auch mal ob es wirklich alle nötigen Daten für die Fibu enthält, usw.
ps. im Zusammenhang mit Auswertungen vor dem Steuerberater ist auch das (Link nur für registrierte Nutzer sichtbar.)i zu empfehlen. Damit bekommst Auswertungen und Statistiken die weit umfangreicher und genauer sind als die vom Shop internen. Dann hast schon eine Übersicht bevor der Stb. dir die Bilanz macht
So. Ich hatte ja versprochen hier noch Rückmeldung zu geben. Habe den Xycons SQL-Reporter eben mal ausprobiert. Also es gibt wie o.a. eine vorbereitete SQL Abfrage im Modul. Diese ist auch ein wenig mehr als nur der hinterlegte SQL Befehl, denn ein wesentlicher Punkt der Verarbeitung der Daten ist ein PreProcessing durch eine Xycons-interne Funktion "{GenerateInvoiceData}". Hier werden in einer Zwischentabelle Dinge wie die Anzahl der Positionen auf der Rechnung und Summen der Mehrwertsteuern usw. vorbereitet. Leider gibt es für meinen Zweck ungefähr 2,5 Probleme hiermit. 1. Das ist erst seit der neuen Gambio Rechnungsverwaltung (ab irgendwo V3.x, table "Invoices") nutzbar. Da wir erst im Mai 2018 auf >V3 geupgradet haben (Von 2.2.xy), sind alle vorherigen Rechnungen in dieser Auswertung hier NICHT dabei! 2. Die Umsatzsteuersätze werden nur in Beträge für "Voller Satz" und "reduzierter Satz" kumuliert. Es gibt aber keine nähere Angabe dazu, insbesondere nicht pro Ergebniszeile die Angabe der angewendeten Sätze! Solange es nur um DE geht, und man nur 19% und 7% hat, ist das ja noch zuzuordnen. Wenn es aber um andere europäische Sätze geht, EU-Lieferungen an Händler, oder man auch Rechnungen innerhalb DE mit 19/7 UND 0% hat, ist das nicht sehr hübsch. (Eventuelle eigene Anpassungen dieses Teils des Moduls gehen übrigens nicht wg. IonCube.) 2,5. Selbst wenn Punkt 2 aufwendiger gelöst würde, u.a. unter besserer Einbeziehung von orders_tax_sum_items beim PreProcessing, käme ja noch der ungefixte Gambio-Bug 57636 für Shops mit manuellen Bestelländerungen/Anlagen hinzu. https://www.gambio.de/forum/threads/wie-rechnungsexport-fuer-steuerberater.27306/page-6#post-300592 (Wobei ich (da ich ja nicht in das Modul reinschauen kann), nicht mal weiß wie relevant dieser Bug noch ist. Ob die Table überhaupt genutzt wird...) Zur Klarstellung: Das Xycons-Modul an sich ist voll OK und die beschriebenen "Probleme" sind kein Problem von Xycons. Es ist halt für meinen Rechnungsexport-Zweck nur leider nicht so richtig nutzbar.
Tja, das ist ja so Schade. So ein Overkill. Denn ich brauche ja gar keine WaWi/FiBu. Der Gambio-Shop reicht uns völlig. Es hängt nur an diesem jährlichen Export... Ich hab sogar mal in die API-Doku von Gambio geschaut. Da finde ich ja auch NIX zu Rechnungsexport, es ist alles auf Basis von ORDERS und somit auch nicht direkt nutzbar.
Das heißt, es werden auch keine im Shop hinterlegte Steuersätze anderer EU Länder (Österreich hat zB 20%, Ungarn ganze 27% MwSt.) dargestellt?
Tja wenn ich dir das sagen könnte... Nein, ganz ehrlich denke ich, dass es mit einer SQL Abfrage allein nicht getan ist, sondern da schon etwas Programmcode drumherum muss. So wie Gambio das ja auch nicht nur mit einer reinen SQL Abfrage gelöst hat, und auch Xycons ja schon Programmmäßig erstmal Zwischendaten vorbereitet. Ich werden nun die Lösung von Michael W. kaufen und probieren. Und dann hier berichten!
So. Nochmal zu den Export-Lösungen allgemein, und um die Infos hier im Thread zu sammeln. Ein Mega Problem besteht darin, dass einfach der Shop gar nicht alle nötigen Daten speichert! Wenn man Storno-Rechnungen hat, dann bleiben in der orders_total wohl immer nur die letzten Werte (von Storno- oder von neuer Rechnung). d.h. bei Rechnung, Stornorechnung und neuer Rechnung stehen in der Tabelle INVOICES nur die Summen der jeweiligen 3 Rechnungen. Einzelpositionen hat man aber nicht mehr! Und in der Orders_Total stehen nur die Werte der letzten, neuen Rechnung. Die Spezialabfrage im Xycons SQL-Reporter versucht anscheinend zwar das irgendwie zu beachten, mixt dabei aber die Summen der 3 Rechnungen mit den (für 2 der Rechnungen nicht mehr passenden) Werten aus Orders_Total, und kalkuliert dann auch noch komplett falsche Nettobeträge hinzu... -> Es kommen keine brauchbaren/verlässlichen Zahlen raus. Dies gilt ähnlich auch für die Lösung hier von Michael W. Die habe ich zwar jetzt soweit, dass Rechnungen mit gemischten Mehrwertsteuersätzen sinnvoll exportiert werden, und man auch generell mit reduziertem Satz korrekt exportiert, aber das o.a. Grundproblem bleibt auch hier natürlich offen. Korrekt und vollständig KANN das anscheinend aktuell gar nicht aus Gambio exportiert werden. Es würden Daten fehlen, die letztlich nur noch in den PDFs der stornierten Sachen stehen. Gambio müsste hier offensichtlich mal grundsätzlich an die Datenstruktur ran. (Ob's dazu schon ein GX-Bug oder GX-Feature Eintrag gibt?? Konnte nix finden, also wohl noch nicht mal geplant... :-( ) Kein Wunder jedenfalls, dass der alte Rechnungsexport von Gambio entfernt wurde. (Faktisch bekommt die ältere Art des Exports (gm_invoicing), die nur die Orders_Total und noch nicht die Tabelle Invoices verwendete, aber trotzdem erstmal bessere Zahlen raus als die neuen Lösungen die auf der Invoices Tabelle basieren...) Sollte ich was übersehen, und die Daten noch sonstwo in der Datenbank versteckt existieren, bitte Hinweis! Grundsätzlich kann man mit Michael W.s Lösung aber gut arbeiten. Ein kompaktes, einfach geschriebenes Script, das auch PHP-Amateure wie ich anpassen können. Kann ich also empfehlen. Nur muss man folgende manuelle Nachbearbeitung leider jedes Mal machen: - Tabelle nach "order_id" sortieren - Wenn eine order_id mehrfach vorkommt (suchen nach "STORNO" in der Rechnungsnummer), dann alle Zeilen löschen die sich eigentlich gegenseitig aufheben sollten. Also zB Rechnung und die folgende Stornorechnung. Nur falls es danach noch eine letzte neue Rechnung gab, diese Zeile als einzige belassen. Alternativ, und wenn man für den Steuerprüfer wirklich lückenlose Listen/Buchungen mit allen fortlaufenden Rechnungsnummern präsentieren können will: Die Zeilen händisch mit den korrekten Werten aus den alten PDFs befüllen. Wer zuletzt mit einer der beiden Lösungen Daten exportiert und weiterverwendet hat, sollte also auf die Mehrwertsteuersache und auf die Stornos mal ein waches Auge haben, und bei Bedarf händisch nacharbeiten. (Das ist wichtig, denn bevor ich das bemerkt habe, hatte ich einen zu hohen Umsatz herausbekommen, der durch die mehrfache (3 bis 5-fache) Einrechnung von Rechnungen kam, die vorher 1-2 Stornorechnungen im Verlauf hatten!) Beide Lösungen sind aber übrigens nicht geeignet wenn man zusätzlich zu 0/7/19% Sätzen noch weitere EU Sätze abrechnen muss. Was wegen dem immer noch nicht behobenen Bug 57636 bezüglich der Tabelle orders_tax_sum_items auch eh nicht korrekt implementierbar wäre... @Gambio: Es wäre schön, wenn Gambio das ganze Thema doch endlich mal umfassend auf die Roadmap setzen würde. Dass da mal Ordnung reinkommt, und es dann auch noch über die API verfügbar wird. Als mögliche sinnvolle erste Maßnahme: In der Tabelle "invoices" wird ja teils jeder Kram nochmal gespeichert, alle Details zu Liefer- und Rechnungsadresse. Aber zu den für eine Rechnung ja nicht ganz unwichtigen fiskalischen Daten nur ein einziges "total_sum". Also warum nicht die Summenzeilen der Rechnung hier mit reinpacken?
das würden sie nur zu gerne. Das der Grund warum immer mehr die API als zugriffspunkt von aussen genutzt werden soll. Solange aber tausende Shops ihre WaWis mittels eigenem DB Zugriff betreiben würde das knallen an allen ecken und enden. Der Shop soll ja auch eigentlich nicht die Buchhaltung machen. Die Storno Rechungen sind ja noch nicht so extrem alt. Vielleicht mal die Entwickler darauf Hinweisen. Vielleicht können die das ja anpassen.
Ja, gerne auch API. Ich bin mir aber sicher, dass Gambio die Datenstruktur auch nur "erweitern" könnte, um das alles abzubilden. Ohne dass die Drittprogramme nicht mehr laufen. Und es dann zur API packen. Wilken hat ja in 2017 mal geschrieben dass die das vorhaben. Seitdem aber nix mehr davon gelesen, und leider auch nicht in der Roadmap zu finden... :-( Mal schauen, vielleicht gibt Gambio ja mal ein Status-Update zur Planung diesbezüglich.
das sollte alles rein mit mysql gehen, ohne plugins. ich hab da mal für einen kunden was entwickelt. der zwete join ist nötig da kunden ohne mwst (b2b, ch, usa) keine werte in der tabelle orders_tax_sum_items haben. ihr könnt gerne verbessern! aktuell fehlt mir noch hier auch stornorechnungen reinzubekommen. PHP: SELECT o.orders_id,o.billing_firstname,o.billing_lastname, o.date_purchased,o.gm_orders_code,o.payment_method, o.billing_country,o.customers_vat_id, otsi.gross, otsi.net, otsi.tax, otsi.tax_rate, GROUP_CONCAT(ot.value separator '|')FROM orders AS oLEFT JOIN orders_tax_sum_items AS otsiON otsi.order_id = o.orders_idLEFT JOIN orders_total AS otON ot.orders_id = o.orders_idWHERE o.date_purchased >= '2023-02-01' AND o.date_purchased < '2023-03-01'GROUP BY o.orders_idORDER BY o.orders_id; das ganze führt man in phpmyadmin aus. danach ergebnis als csv exportieren, wegen group concat oben mit | als trennzeichen.