Nein, Dennis, die liegen in admin/includes/gm/classes/. Die andere Datei liegt direkt in /admin. In der Datenbank zu gm_invoicing sieht das so aus, wie im Screenshot.
@bully connection Was macht ihr denn alle so ewig rum!? Die Dateien sind alle vorhanden, nur der Eintrag in der Datenbank muss verändert werden. Wurde bereits am 12. Oktober 2016 in Post #21 geschrieben.
@Devil bei mir ist eine 1 und den Befehl habe ich gestern nacht auch ausgeführt. Wie ich oben geschrieben habe, habe ich davon absolut keinen Plan von dem Driss und suche hier also entsprechend Hilfe. Dein "was macht ihr denn alle so ewig rum" ist keine Hilfe und sowas von überflüssig.
Ich habe gestern einen neuen Testshop installiert und den SQL Befehl aus #21 ausgeführt und zack, "Rechnungsexport" ist vorhanden und kann konfiguriert werden. Und ich habe davon erst Recht keine Ahnung. Möglicherweise könnt es am nicht geleertn Cache liegen oder an den temporären Dateien im Browser.
Cache hatte ich geleert, aber das Problem nun gefunden....das wie immer vor dem PC sitzt (ich sagte ja, ich habe davon so nuill komma null Ahnung).
Möglicherweise würde auch andere Nutzer interessieren, wo das Problem nun lag - nicht, dass die dann auch einen "Denkfehler" haben und verzweifelt auf den Bildschirm gucken
haha, du willst doch nur wissen, wie blöde ich doch tatsächlich war! gönn ich dir! ich habe den SQL Befehl nicht im Admin Bereich eingegeben, sondern in der Datenbank.
Da saß der "Fehler" also doch vorm Bildschirm :-D Gut, so eindeutig hat Kai Schoelzke das nicht geschrieben. Für die Nachfolgenden. Um die Funktion "Rechnungsexport" zu erhalten, reicht es (eigentlich) aus, wenn man im Admin unter "Toolbox > SQL" den Befehl Code: UPDATE `admin_access` SET `gm_invoicing`='1' WHERE `customers_id`='1' eingibt und ausführt. Dateien brauchte ich jedenfalls nicht hin- und her zu kopieren, war alles da. Und auch hier gilt: Alles auf eigene Gefahr. Vorher Sicherung machen.
jahaaa, hab ich ja oben zugegeben Danke, dass du es für die anderen nochmal ausführlicher geschrieben hast. Für Leute, die WIRKLICH keine Ahnung von SQL, PHP und was weiß ich haben, sind so Feinheiten in der Erklärung äußerst hilfreich.
Hallo Ihr Mitleser, anbei möchte ich Euch eine Variante vorstellen, wie man auch unproblematisch direkt aus dem Shop mit richtiger Kontierung, die Rechnungen an seinen Steuerberater übergeben kann. Wenn man viele Buchungen hat und das Ganze automatisiert geschehen soll, dann rechnet sich die Schnittstelle auf jeden Fall. Habe mal in diesem Beitrag was zusammengeschrieben: http://www.gambio.de/forum/threads/...-heraus-ohne-drittanbieter.27823/#post-238594
Wie aus der Roadmap zu entnehmen ist, wird die gm_invoicing in einem zukünftigen Update entfernt, weil sie ab 3.3 nicht mehr zuverlässig arbeitet. - großes SCHADE Ich habe ca. 300 Bestellungen/Rechnungen im Monat und benötige keinerlei Warenwirtschaftsprogramme oder teure Module. Der GX erfüllt alle Wünsche, was ich täglichen Arbeiten brauche. Und die gm_invoicing brachte mir genau die Summen, die ich dann manuell in das Programm vom Steuerberater eintragen muss. Dabei handelt es sich um die drei Posten: .) Verkauf mit MwSt. .) Verkauf B2B innerhalb EU .) Verkauf ohne MwSt. ausserhalb EU Die Rechung.csv hab ich in Excel importiert, sortiert, und mir die Summen errechnet und diese ins Steuerberaterprogramm eingetragen. So waren 3 Monate in wenigen Minuten abgearbeitet. Unterm Strich heißt das jetzt, dass ich mich nicht mehr auf den Export verlassen kann (hab 3.4 laufen) und das ist ja nicht gerade beruhigend, wenn es um das Finanzamtsgschichtl geht Jetzt gibt es das gm_invoicing, was sicherlich sehr vielen "Kleinen" unter uns ausreicht, und keiner bringt es auf den jetzigen Stand - ein Jammer - und der noch größere Jammer sind die unnötigen Stunden um die Rechnungen wieder manuell zusammenzurechnen.
Mich trifft das auch. Ich habe gerade mal ein bisschen in der Datenbank geschaut. Früher wurde die Rechnungsnummer in der Tabelle "orders" in der Spalte "gm_orders_code". Wenn man mehrere Rechnungen erzeugt wird die Spalte leider immer mit der gleichen Rechnungsnummer vollgeschrieben. Die richtige Rechnungsnummer steht jetzt in der Tabelle "invoices". Ich frage jetzt mal ganz laienhaft. Könnte man den Export nicht so umbiegen, dass die Rechnungsnummer aus der Tabelle invoices kommt und der Rest aus der Tabelle orders? Edit: Das Problem mit der gleichen Rechnungsnummer bei der Stapelverarbeitung taucht bei mir nur auf, wenn man auf "e-mail Rechnung" klickt. Bei "Rechnung herunterladen" wird die Spalte fortlaufen beschrieben. Also gehe ich eher von einem BUG aus.
Wir haben nach dem Update auf die 3.4. nach ein paar Tagen einen Test. Herr Hiller v. Gambio hatte auf unseren Hinweis Anpassungen vorgenommen. Der Test ware erfolgreich und die Datei der Debitoren für Datev konnte erfolgreich erstellt werden.
Hallo Michael, das weiss ich nicht. Ich hatte Herr Hiller/Gambio gebeten, hier eine entsprechende Info reinzuschreiben, vielleicht hatte er keine Zeit.
Kollege Hiller hat diese Woche Urlaub, darum kann ich ihn gerade nicht direkt dazu interviewen, ist aber nächste Woche wieder da. ich werde ihn dann mal dazu befragen. Sicher ist: Wenn Kollege Hiller mir bestätigt, dass das erstmal weiter zu gebrauchen ist, finden wir einen Weg euch den Erhalt möglich zu machen. Wir sprechen aber immernoch darüber den Status Quo mit dem alten Export dann eine kleine Weile länger am Leben zu erhalten, nicht dauerhaft. Diese alten Exportcodepfade werden sterben, die sind nicht zukunftsfähig. Wenn eine solche Funktion gebraucht wird, müsste dann trotzdem eine neue Alternative entwickelt werden, mit dem alten ist es irgendwann zappenduster.
@Wilken (Gambio) ich bin dann für eine neue Alternative. Ich denke es werden sich dem Wunsch noch mehr anschließen. Bleibt abzuwarten was Herr Hiller sagt. In diesem Sinne frohe Ostern
Leider ist in den Beitrag Stille eingekehrt Stimmt mich traurig: mach gerade den Rechnungsexport und hab einige Posten kontrolliert. Mit dem Ergebnis, dass ich dem Modul nicht mehr trauen kann und jetzt jede Rechnung manuell eintippen muss. Das kanns ja nicht wirklich im PC-Zeitalter sein........
Ich hatte es Anfang April, nach dem 3.4er Update probiert und es hat funktioniert. Wo hakt es denn bei Dir Heinz? Vielleicht wurde die Änderungen auch nur für uns angepasst. Herr Wilken hatten Sie schon Gelegenheit mit Herrn Hiller zu sprechen?