Neu Rechnungen verändern - JTL-Wawi 1.6 - (Video)

[Verkäuferlein]

Die Frage ist interessant...

Wir haben auch die Lieferadresse mit auf der Rechnung, haben es derzeit aber so gelöst, dass alle Rechnungen nur zu einem fixen Zeitpunkt am Tag nach erfolgter Auslieferung erstellt werden.

 

[Manuel Pietzsch]

Die Frage ist interessant...

Wir haben auch die Lieferadresse mit auf der Rechnung, haben es derzeit aber so gelöst, dass alle Rechnungen nur zu einem fixen Zeitpunkt am Tag nach erfolgter Auslieferung erstellt werden.

Hi,

wir werden bei Adressänderung im Nachdruck die Rechnung per Rechnungskorrektur ausbuchen und mit der geänderten Adresse neu erzeugen.
Bei anderem Lieferland werden wir die MwSt und UstId entsprechend aktualisieren, den Brutto Betrag aber nicht verändern.

Gruß

Manuel

 

[trummerjo]

wir werden bei Adressänderung im Nachdruck die Rechnung per Rechnungskorrektur ausbuchen und mit der geänderten Adresse neu erzeugen.

Ja Moin, dass wird die steuerliche Verarbeitung der Rechnungen, Gutschriften und Zahlungen richtig geil zerstören ... es sei denn JTL2DATEV bekommt das hin, dass zu einer Bestellung(=Zahlung) plötzlich 10 Rechnungen und 9 Gutschriften existieren

 

[ruth]

• Super Funktionen, genau das Richtige!
• Wann erscheint 1.6, Herbst 2020 oder Frühjar 2023?
• Ja - bitte einen eigenen Performarechnungsnummerbereich! Verstehe gar nicht auf die Idee zu kommen, es ohne machen zu wollen.
• Eine Rechnung, die das Haus verlassen hat, darf nicht mehr geändert werden, sondern muss durch Korrektur aufgehoben werden. Fertig! / Also die Aussage weiter oben, dass man minimale Änderungen vornehmen darf, ist schlicht falsch.
• Ich nehme an, und hoffe, es sind PDF/A
• Wird man die PDFs nach Jahren exportieren können? Wir werden ja in der Regel in zwei Jahreszeiträumen geprüft. Kann ich nun die PDFs 2017 und 2018 exportieren?
• Kann ich PDFs automatisch löschen lassen. Zum Beispiel am 1. Januar 2030 geht ein Fenster auf: Hallo 10 Jahre sind rum, willst du 2020 löschen oder erst nächstes Jahr?
• Werden die PDS in die DB abgelegt, oder verschlüsselt im Filesystem?
• Lasst Ihr Euch das GoBD-Verfahren zertifizieren?

 

[ruth]

Nachfrage: Wird weiterhin das Passwort der Datenbank bekannt geben werden, oder wird ab der Version 1.6 die Datenbank nicht mehr für uns zugänglich sein? Denn wenn ich weiterhin an die DB dikret dran kann, so kann ich doch auch dort noch nachträglich Änderungen vornehmen, oder irre ich mich da?

 

[t.oster]

Hallo, das mit dem Speicherort der PDFs würde mich auch dringend interessieren. Ein Kunde von uns macht ca 1000 Aufträge pro Tag. Da würde die Datenbank extrem explodieren, wenn jedes PDF in der Datenbank gespeichert würde!

 

[ruth]

Hallo, das mit dem Speicherort der PDFs würde mich auch dringend interessieren. Ein Kunde von uns macht ca 1000 Aufträge pro Tag. Da würde die Datenbank extrem explodieren, wenn jedes PDF in der Datenbank gespeichert würde!

Das wären im 120Mb pro Tag. Wer 1000 Rechnungen am Tag raushaut hat sicher auch die notwendige Hardware. Die Begrenzung der SQL-Datenbank liegt bei 524 Petabyte, https://docs.microsoft.com/en-us/sq...016?redirectedfrom=MSDN&view=sql-server-ver15.

Vielleicht könnte die Rechnung nur in graustufen max. 300 dpi abgelegt werden, daß sind glaube ich, die üblichen Größen auch im DMS-Bereich. Dann wäres es bei 1000 Rechnungen ca. 60 MB pro Tag.

 

[SebiW]

Und nach 10 Jahre hast Du, kein Wachstum vorausgesetzt, 400 GB allein an PDFs in der DB hängen. Zusätzlich zu Artikelbildern, den normalen Daten, Servicedesk etc. Geht natürlich, macht aber nur bedingt Spaß.
Ich bin mir aber sicher JTL hat da bereits einen Plan in der Pipeline, das Thema kam ja auch beim Servicedesk schon auf.
Ist halt ein grundsätzliches Problem, je mehr Funktionen die Wawi bekommt desto voluminöser wird die DB.

 

[t.oster]

Selbst wenn die Hardware das hergibt ist das für Backups usw nicht schön. Und wenn die PDF noch ein paar mehr Bildchen etc enthält, könnte sie auch schnell größer werden. Abgesehen davon schiessen dann kleine Unternehmen sehr schnell über die 10GB Grenze von SQL Server Express. Man kann sagen wer Geld verdient kann sich die dickere DB leisten, aber eigentlich sind PDFs ja keine Relationalen Daten, gehören also nicht unbedingt in die DB meiner Meinung nach.

 

[Manuel Pietzsch]

Hi Freunde,

das Thema Speicher von Binärdaten (hier PDFs) diskutieren wir tatsächlich schon im Rahmen vom Servicedesk. Dort werden ja auch viele Mails gespeichert.
Großes Problem sehen wir aktuell tatsächlich bei den Backups, die dauern länger und die Diskussion um das Thema wird auch immer größer.
Wir haben dazu intern eine kleine Taskforce aufgestellt und werden uns ein paar Lösungen überlegen. Unabhängig davon freue ich mich natürlich über Vorschläge von euch zu dem Thema, aber lasst uns die Diskussion am passenden Ort bündeln:

https://forum.jtl-software.de/threads/speicherung-in-sql-db.128733/page-3#post-706676

Gruß und Danke für die anregenden Gespräche

Manuel

 

[forumjtlolshopag]

@ManuelP
Glaub als "Dateilinks" wäre es wohl am besten. Wir müssen die Rechnungen eh als PDF für den Datevabgleich abspeichern. Dann würde diese Extra Sicherung wegfallen, die wir als Workflow angelegt haben. Klar liegt dann die Verwantwortung beim Nutzer, das dieser dann nicht die Dateien einfach so entfernt. Wichtig wäre nur, das diese Sicherung über den Worker läuft, der ja soweiso auch die Uploads ins Amazon IDU macht. Weiß nur nicht,. wie dann einzlene Nutzer ohne Freigabezugriff dann an die PDF kommen. Ggf. muss der Worker die "durchreichen".

 

[jensfalk]

Die Möglichkeit, dass die Rechnung, wenn es nur um die GoBD-konforme Ablage geht, in max. 300 dpi und in graustufen abgespeichert wird, halte ich auch für den richtigen Ansatz. Die schöne Rechnung für den Kunden kann ja im Shop abgelegt werden, wo sich der Kunde diese dann holen kann.

 

[Schotti]

Wann erscheint 1.6, Herbst 2020 oder Frühjar 2023?

JA, wann erscheint 1.6? 😁
LG

 

[NewBuy]

Dann wenn Sie da ist lieber warten und eine möglichst Stabile Version als jeden Tag ein Update zu installieren

 

[wawi-dl]

Hi,

Technische Fehler auch?!

Wie dem auch sei, wie sollte eine solche Funktion denn implementiert sein? Woher soll die Wawi wissen, was eine kleine, erlaubte Änderung ist und was nicht? Was soll sie erlauben und was nicht? Wo sind wir dann noch GodB konform und wo nicht?

Persönlich sehe ich diesen Usecase als eher selten an und der Nutzen steht nicht in Relation zum Aufwand und den möglichen Gefahren, die man sich ins Haus holt.


Lohnt sich denn dieser Aufwand? Du musst mit dem Kunden diskutieren, dass er dir das schickt. Du musst das Dokument dann zusätzlich zur Rechnung 10 Jahre aufbewahren, nehme ich an. Ich denke eine ReKo + neue Rechnung ist hier der stressfreie Weg mit weniger Aufwand und Fehlerpotential.

Danke Thomas!
Ich habe bestimmt 5 Tickets gezogen, dutzende Datensätze euch geliefert, bei denen einmal Firmendaten von eBay übermittelt werden, einmal nicht.
Es ist KEINERLEI Regel dafür erkennbar, ich hab mit Support hier dutzende Stunden schon Runden gedreht, bis heute bringt man das leidige Thema nicht in den Griff.

Ein Entwickler (der ebenfalls Schnittstelle zu eBay mittels API entwickelte) sagte mir, dass es Daten für Firma über API gibt,
andere Systeme Afterbuy etc. haben diese Probleme scheinbar auch nicht?! Also wo es klemmt wissen wir nicht.

Das Problem vieler eA-Nutzer wird seit Jahren nicht gelöst, Themen dazu gibt es zu genüge auf Facebook, Foren etc. ... täglich haben wir auch hier bestimmt 10% Bestellungen, die wir selbst mittels einem Tool gerade biegen,
um nervige Kundenemails zu vermeiden.

Ein Kunde hat das Recht auf Korrektur seiner Rechnung, dazu muss ich keine stornieren und neu erstellen.
Auf Anraten von Steuerberater und Finanzamt, sollen wir uns schriftlich Änderungen quittieren lassen, machen wir daher auch (von FA zu FA wohl unterschiedlich).


WENN ihr eine Rechnungskorrektur als Prozess interegrieren wollt, dann bitte RICHTIG!
Die ganze Umbucherei kann man sich doch sparen, ich will keinen neuen Versand, keine neue Rechnung etc.

Anbei ein Beispiel, es wird hier z.B. die Rechnungsnummer mit Version versehen, so dass KEINE neue Rechnungsnummer erzeugt wird, sondern nur eine Version und hat somit Bezug zur alten:
Rechnung fehlterhaft: RE1001
Rechnung korrigiert: RE1001-1 (inkl. Vermerkt mit "Rechnungskorrektur zur Rechnung RE1001")
https://sevdesk.de/lexikon/rechnungskorrektur/

 

[wawi-dl]

....
Anbei ein Beispiel, es wird hier z.B. die Rechnungsnummer mit Version versehen, so dass KEINE neue Rechnungsnummer erzeugt wird, sondern nur eine Version und hat somit Bezug zur alten:
Rechnung fehlterhaft: RE1001
Rechnung korrigiert: RE1001-1 (inkl. Vermerkt mit "Rechnungskorrektur zur Rechnung RE1001")
https://sevdesk.de/lexikon/rechnungskorrektur/

Möchte nochmals nachfragen @Manuel Pietzsch , ob ihr das Thema intern nochmals diskutiert.

Man sollte sich wirklich überlegen, ob man die Auswahl anbietet, ob eine neue Rechnungsnummer erzeugt wird, oder die bestehende Rechnungsnummer mit "Version" erweitert wird.
Man hätte dann eben einen Verweis und Zusammenhang auf die neue Rechnung, man hat dadurch viel weniger Verwechslungsgefahr.

Mir persönlich wäre viel wichtiger, die alte Rechnungsnummer zu übernehmen und eine Version anzuhängen die hochgezählt wird.

Angenommen ich muss 3x ändern, dann hab ich 4 unabhängige Rechnungsnummer 😭

 

[NewBuy]

Mir persönlich wäre viel wichtiger, die alte Rechnungsnummer zu übernehmen und eine Version anzuhängen die hochgezählt wird.

Angenommen ich muss 3x ändern, dann hab ich 4 unabhängige Rechnungsnummer 😭

SO sehen Wir es bei uns auch... Besser die Version Hochzählen ist übersichtlicher als wenn es vollkommen unterschiedliche Nummer sind.

 

[Night]

Ich finde das Feature gut und wichtig, denn die reine PDF Abspeicherung reicht ja nicht aus, um gobd-konform zu sein, die Sache mit dem gleichen Druck ist super, denn das fehlt derzeit ja.
Der Nummernkreis der Proformarechnung wäre super wichtig, kann man evtl. auch eine Einstellung machen, dass die Nummer = Rechnungsnummer mit nem Suffix davor wäre? Denn es ist richtig mies, das bei Vorkassen zuzuordnen, das machen schon unsere Lieferanten dauernd "falsch" und ich möchte es meinen Kunden leicht machen, die Belege zuordnen zu können.
Aber ja, Nummerierung der Proformarechnung ist wichtig, sonst findet man evtl. Zahlungen niemals.

Das mit den Tippfehlern ist schade, weil einfach so fern der Praxis, aber gut, geht ja nicht anders. Nur wenn ich das ändere, muss ich dem Kunden das ja mitteilen, kriegt der dann automatisch die Korrektur zugeschickt, sonst hat der Kunde ja am Ende zwei Rechnungen und ist verwirrt, grade wenn es nur ein Tippfehler ist und versteht den Sinn nicht.

EDIT: Wo ich das grade sehe, ja Versionsnummern der Rechnung als "neue" Nummerierung wäre echt besser, denn angenommen der Kunde zahlt die falsche Rechnung schon, bekommt dann aber die Korrektur und im System findet man nur die neue, weil man die korrigierten ausblendet bzw. wie wird das dann an z.B. JTL2Datev übertragen.

 

[Manuel Pietzsch]

Hi Freunde,

ich finde den Vorschlag absolut super und hab das für die 1.6 noch aufgenommen: https://issues.jtl-software.de/issues/WAWI-50290
Nummernkreis für Proforma-Rechnungen sehe ich als separate Baustelle die wir nicht für das Release der 1.6 benötigen: https://issues.jtl-software.de/issues/WAWI-46177

Geht ihr da mit? Sind die Tickets inhaltlich für euch korrekt, bzw. spiegeln sie eure Wünsche wieder?

Danke und Gruß

Manuel

 

[forumjtlolshopag]

EDIT: Wo ich das grade sehe, ja Versionsnummern der Rechnung als "neue" Nummerierung wäre echt besser, denn angenommen der Kunde zahlt die falsche Rechnung schon, bekommt dann aber die Korrektur und im System findet man nur die neue, weil man die korrigierten ausblendet bzw. wie wird das dann an z.B. JTL2Datev übertragen.

Das Frag ich mich auch, wie das mit JTL2Datev funktioniert und speziell auch in Datev selbst. Wahrscheinlich muss da nachgebessert werden, weil bei einer Korrektur auf einen bestehenden Buchungssatz eine neue Rechnung mit eingefügt wird.