Rechnung - Kundenkommentar und Anmerkung nicht änderbar

[MichaelH]

Rechnung - Kundenkommentar und Anmerkung nicht änderbar​

Diese 2 Felder werden vom Auftrag übernommen.
Es gibt jedoch keine Möglichkeit diese 2 Textfelder in der erstellen Rechnung zu ändern.

Übersehe ich hier eine Möglichkeit oder ist das tatsächlich so ?
Warum sollte man keine Anmerkung zu einer Rechnung ändern können, denn dafür ist das Feld Anmerkung doch da ?!?

Ändere ich das / die Felder testweise im entsprechenden Auftrag, dann wird dies dort gespeichert, jedoch nicht in der Rechnung dazu, also diese Variante fällt schon mal weg.

Und anders gefragt:
Wenn ihr eine (interne) Anmerkung zu einer Rechnung machen wollt wo oder wie hinterlegt ihr diese ?

 

[John]

Du kannst Die Felder editieren, solange die Rechnung noch nicht festgeschrieben ist.
Vermutlich wurde das gemacht, um die Rechnung als Gesamtwerk unveränderlich zu haben, weil beide Felder auf der Rechnung ausgegeben werden können.

Ich finde das auch doof.

 

[MichaelH]

Hi John,

"Du kannst Die Felder editieren, solange die Rechnung noch nicht festgeschrieben ist."
Wir sind wieder mal am testen, daher die Frage an dich - wie kann ich eine Rechnung festschreiben bzw. wie "nicht" festschreiben ?
Wenn ich diese einzeln erstelle habe ich die Wahl, bei "Ausliefern" jedoch nicht.

"Vermutlich wurde das gemacht, um die Rechnung als Gesamtwerk unveränderlich zu haben, weil beide Felder auf der Rechnung ausgegeben werden können."
Dies würde theoretisch bedeuten, dass JTL sämtliche Stammdaten und Stammdaten-Texte direkt in der Rechnung speichern muss, damit auch Änderungen an den Stammdaten die Rechnung nicht verändern können.
Hast du diese Erfahrung schon gemacht ?
Werden die Texte aus den Stammdaten die in der Rechnung gedruckt werden können bzw. könnten ebenfalls in der Rechnung festgeschrieben ?
Ansonsten wäre diese Einschränkung für die Texte Nonsens, denn wenn ich 2 Jahre später, trotz Änderungen der Stammdaten eine Rechnung nachdrucken will, genau DANN muss diese gleich aussehen.

SG

 

[frankell]

Hallo @MichaelH,

wie kann ich eine Rechnung festschreiben bzw. wie "nicht" festschreiben ?

Ich bin mir nicht ganz sicher, ob das auch schon in der von Dir genutzten Version möglich war, aber zumindest aktuell kannst Du eine Rechnung "mit Vorschau" erstellen und diese dann nur "Als Entwurf speichern". Dann ist das quasi eine Proforma-Rechnung, die gerade nicht festgeschrieben ist.

Ergänzend noch: Es gibt neben dem Kundenkommentar und der Anmerkung bei der Rechnung auch noch den "Rechnungstext".

Dies würde theoretisch bedeuten, dass JTL sämtliche Stammdaten und Stammdaten-Texte direkt in der Rechnung speichern muss, damit auch Änderungen an den Stammdaten die Rechnung nicht verändern können.

Meinst Du damit die Kunden-Stammdaten? Denn da passiert genau das.

 

[MichaelH]

Hi Frankell !

Ergänzend noch: Es gibt neben dem Kundenkommentar und der Anmerkung bei der Rechnung auch noch den "Rechnungstext".

Den finde ich nirgends, kann man diesen einblenden oder im Auftrag / Rechnung bearbeiten ?
Oder anders gesagt: Wo und wie kann ich Zusatzinfo für einen Auftrag/Rechnung erfassen bzw. speichern ?

Meinst Du damit die Kunden-Stammdaten? Denn da passiert genau das.

Kundenstammdaten sind (nur) ein Teil davon, damit eine Rechnung zu 100% reproduziert werden kann mit ALLEN Daten/Felder die im Rechnungsdruck verwendet werden könn(t)en müssten alle änderbaren Stammdaten komplett in jeder Rechnung enthalten sein.
Nur so macht es Sinn sogar belegspezifische (nur für diesen Auftrag/Rechnung geltende) interne Angaben/Information zu sperren.

Oder anders gesagt:
Wird eine Rechnung erstellt müssten sämtliche für die Rechnung nötigen Stammdaten mit Code und Text in der Rechnung mitgespeichert werden, da diese ja beim Druck verwendet werden könn(t)en und nicht nur die Daten die eingetippt wurden.
-> Der Formulardruck dürfte somit nicht auf Stammdaten der WAWI referenzieren, für nichts und gar nichts, denn Stammdaten können geändert werden womit sich auch der Inhalt der Rechnung ändern würde.

 

[frankell]

Den finde ich nirgends, kann man diesen einblenden oder im Auftrag / Rechnung bearbeiten ?

Immer unter dem Vorbehalt, dass das auch in Deiner Wawi-Version schon so umgesetzt ist, hier ein Screenshot der Verortung. Oder testest Du vll sogar mal eine neue Version?

Oder anders gesagt:
Wird eine Rechnung erstellt müssten sämtliche für die Rechnung nötigen Stammdaten mit Code und Text in der Rechnung mitgespeichert werden, da diese ja beim Druck verwendet werden könn(t)en und nicht nur die Daten die eingetippt wurden.

Adressdaten werden auch eigenständig für die Rechnung gespeichert, ebenso ein Teil der Positionsdaten.

-> Der Formulardruck dürfte somit nicht auf Stammdaten der WAWI referenzieren, für nichts und gar nichts, denn Stammdaten können geändert werden womit sich auch der Inhalt der Rechnung ändern würde.

Das tut er auch vom Prinzip her nicht in den Standardvorlagen, zumindest meistens.

Aber in den Vorlagen kannst Du ehrlicherweise ohnehin machen, was Du willst (was auch gut so ist). Du kannst auch einfach nur ein Bild von Mickey Mouse als Rechnung ausgeben. Das ist aber auch nicht anders als vor der digitalen Umsetzung. Ob der Inhalt einer geschriebenen Rechnung mit dem tatsächlichen Sachverhalt deckungsgleich ist, war schon immer nur eine Frage der Entscheidung, ob man sich an geltendes Recht hält oder nicht.

 

[MichaelH]

Immer unter dem Vorbehalt, dass das auch in Deiner Wawi-Version schon so umgesetzt ist, hier ein Screenshot der Verortung. Oder testest Du vll sogar mal eine neue Version?

Ich teste immer die neueste Version, denn ich hätte keine Info darüber dass eine vorige Version besser wäre ...
Ich bin auch im Beta-Programm obwohl ich die 1.5 noch nutze und sehe den allgemeinen Nutzen darin, dass ich die Datenkonvertierung von 1.5 mache und Fehler melde.

Den Anhang 120727 betrachten

OK, das Feld gibt es unter Rechnung, aber nicht unter Auftrag.
Wo oder wie kann ich dort was reinschreiben, denn auch unter Rechnung ist dieses Feld gesperrt ???
Und in der Rechnungsübersicht ist es nicht einblendbar.

Adressdaten werden auch eigenständig für die Rechnung gespeichert, ebenso ein Teil der Positionsdaten.
Das tut er auch vom Prinzip her nicht in den Standardvorlagen, zumindest meistens.
Aber in den Vorlagen kannst Du ehrlicherweise ohnehin machen, was Du willst (was auch gut so ist). Du kannst auch einfach nur ein Bild von Mickey Mouse als Rechnung ausgeben. Das ist aber auch nicht anders als vor der digitalen Umsetzung. Ob der Inhalt einer geschriebenen Rechnung mit dem tatsächlichen Sachverhalt deckungsgleich ist, war schon immer nur eine Frage der Entscheidung, ob man sich an geltendes Recht hält oder nicht.

Jein, das wäre nicht kosequent.

Wenn ich ein Textfeld, das wahlfreien Inhalt haben kann, sperre, weil es "rechtlich" nötig ist, dann muss ein Softwarehersteller aber auch sämtliche Stammdaten die änderbar sind in den Rechnungsdatensatz übernehmen damit diese nicht änderbar sind. Und mit sämtliche meine ich sämtliche.
Warum sollte ein Textfeld gesperrt sein, aber Stammdatentexte nicht ?
So meinte ich das.

... ein Mickey-Mouse Foto betrifft dies natürlich nicht.

 

[frankell]

OK, das Feld gibt es unter Rechnung, aber nicht unter Auftrag.

Ergibt sich aber irgendwie auch schon aus der Bezeichnung.

Wo oder wie kann ich dort was reinschreiben, denn auch unter Rechnung ist dieses Feld gesperrt ???

Gesperrt sein sollte es maximal dann, wenn die Rechnung festgeschrieben ist.

Und in der Rechnungsübersicht ist es nicht einblendbar.

Korrekt. Ist inkonsequent.

So meinte ich das.

Hab ich auch so verstanden. Ich verteidige die Vorgehensweise auch nicht, rechtlich unbedeutende Informationen nicht ändern zu können, während man andere Dinge weiterhin ändern könnte, wie bspw. so relevante Dinge wie TARIC oder CoO.

Die Möglichkeit, in der Ausgabe machen zu können, was man will, ist sicher in diversen speziellen Einzelfällen notwendig. Für JTL war wohl schlicht der Ansatz, eine Form der "Festschreibung" zu gewährleisten, so dass die Software als GoBD-konform gelten kann.

Und wenn wir ehrlich sind: Wollte man wirklich alles alles festschreiben, dann würde man eine Flut an redundanten Datensätzen erzeugen. Und hier muss man sich halt für einen Mittelweg entscheiden, was ich auch durchaus nachvollziehen kann.

Wie gesagt, das ändert nichts an der Tatsache, dass es einfach over the top ist, rechtlich irrelevante Informationen nicht ändern zu können.

 

[MichaelH]

Ergibt sich aber irgendwie auch schon aus der Bezeichnung.

Na ja, ich kann doch auch Info im Auftrag für eine Rechnung angeben ...

Gesperrt sein sollte es maximal dann, wenn die Rechnung festgeschrieben ist.

Gut, wenn die Rechnung nicht festgeschrieben ist, ist (fast) alles änderbar, da nützt dann ein Rechnungstextfeld wenig.
Dann wäre das so zu verstehen: Es gibt ein Rechnungstextfeld, das nur im Rechnungs-Entwurf verwenbar ist und nur an 1 Ort angezeigt wird.
Welchen Sinn der Erfinder des Feldes dahinter sah würde mich interessieren.
Text im Rechnungstext: "Diese Rechnung ist nur ein Entwurf und dafür darf man die anderen 2 Textfelder nicht verwenden."
🤣

Korrekt. Ist inkonsequent.
Hab ich auch so verstanden. Ich verteidige die Vorgehensweise auch nicht, rechtlich unbedeutende Informationen nicht ändern zu können, während man andere Dinge weiterhin ändern könnte, wie bspw. so relevante Dinge wie TARIC oder CoO. Die Möglichkeit, in der Ausgabe machen zu können, was man will, ist sicher in diversen speziellen Einzelfällen notwendig. Für JTL war wohl schlicht der Ansatz, eine Form der "Festschreibung" zu gewährleisten, so dass die Software als GoBD-konform gelten kann.
Und wenn wir ehrlich sind: Wollte man wirklich alles alles festschreiben, dann würde man eine Flut an redundanten Datensätzen erzeugen. Und hier muss man sich halt für einen Mittelweg entscheiden, was ich auch durchaus nachvollziehen kann.
Wie gesagt, das ändert nichts an der Tatsache, dass es einfach over the top ist, rechtlich irrelevante Informationen nicht ändern zu können.

Ja, ist schwer nachvollziehbar wer sich das so ausgedacht hat und das bis Version 1.10.9 so akzeptiert wird.
Da wird es auch keinen Sinn machen sich hier eine Änderung zu wünschen die nie kommen wird.


Zusammenfassung:
Diese zwei Textmöglichkeiten wurden somit unbrauchbar gemacht und bleiben auf alle Zeiten auf der Rechnung festgeschrieben.

 

[John]

Das ganze Thema Festschreiben ist sowieso nur GUI Shitshow.
Man kann alles in der Rechnung im Nachhinein in der Datenbank ändern, inkl. Amerkungen, Preisen etc.

 

[wawi-dl]

@MichaelH
Ich muss hier dem einen oder anderen mal ganz klar widersprechen!
Mal abgesehen von Anmerkungen / Kundenkommentare, können diese Bestandteil von einer Rechnung sein, wenn z.B. hier vertragliche Details fixiert werden.
JTL hat das konsequent richtig gemacht und mit Festschreibung gesperrt!


ABER!
Kundenkommentar --> meistens Hinweise vom Kunden aus Verkaufsplattformen, somit Bestandteil "theoretisch" von der Rechnung
Anmerkungen --> eigentlich "nur" für interne Zwecke gedacht, können aber ebenfalls angezogen werden, daher wird es gesperrt


Es gibt aber die Möglichkeit über "eigene Felder" zu gehen, so machen wir es, wenn tatsächlich noch für uns oder den Kunden Infos erfasst werden müssen.
JTL kann die "eigenen Felder" nicht sperren, diese werden also immer offen bleiben, gehe also über diesen Umweg, so groß ist dieser nicht.

P.S. wir verwenden eigene Felder, wenn Käufer eine Rechnungskorrektur wünscht, denn wir stornieren Rechnungen NICHT, er bekommst nur ein Berichtigungsdokument, damit er nicht 2 absetzen kann.

 

[frankell]

wenn z.B. hier vertragliche Details fixiert werden

Das ist nicht die Aufgabe von JTL und sollte auch nicht Sinn und Zweck des Ganzen gewesen sein.

Aber es hakt halt schon. Ein Beispiel habe ich mit TARIC und CoO ja genannt. Das sind keine "festgeschriebenen" Werte, können also geändert werden, obwohl sie rechtlich relevant sind.

JTL kann die "eigenen Felder" nicht sperren, diese werden also immer offen bleiben, gehe also über diesen Umweg, so groß ist dieser nicht.

Das widerspricht dann aber eben der Argumentation mit der Richtigkeit des Sperrens. Denn so gesehen kannst Du ja auch vertragliche Details in Eigene Felder packen, die nach Deiner Argumentation dann gesperrt gehören würden.

P.S. wir verwenden eigene Felder, wenn Käufer eine Rechnungskorrektur wünscht, denn wir stornieren Rechnungen NICHT, er bekommst nur ein Berichtigungsdokument, damit er nicht 2 absetzen kann.

Verstehe ich nicht so ganz. Wenn Du der Rechnungsausgabe für den Fall der Stornierung ein "STORNO" hinzufügst, muss man schon mutig sein und im Falle einer Außenprüfung auf Schlampigkeit der Prüfer hoffen, wenn man so ein Dokument angesetzt hat.

Ansonsten bin ich aber ganz bei Dir, dass Stornos keinen Berichtscontainer benötigen, sondern einfach nur den kurzen Hinweis, dass die Rechnung oder die Rechnungskorrektur (oder der Auftrag) storniert wurde.

Ich würde hier aber schon noch distinguieren zwischen Stornos (vollständig) und Korrekturen (punktuell).

 

[frankell]

Das ganze Thema Festschreiben ist sowieso nur GUI Shitshow.
Man kann alles in der Rechnung im Nachhinein in der Datenbank ändern, inkl. Amerkungen, Preisen etc.

True. Wobei das nur für Nicht-Otto-Normal-User gilt.

 

[wawi-dl]

Das ist nicht die Aufgabe von JTL und sollte auch nicht Sinn und Zweck des Ganzen gewesen sein.

Aber es hakt halt schon. Ein Beispiel habe ich mit TARIC und CoO ja genannt. Das sind keine "festgeschriebenen" Werte, können also geändert werden, obwohl sie rechtlich relevant sind.

Muss ich leider erneut wiederpsrechen, das eine hat mit dem anderen nichts zu tun.
Nur weil JTL den einen oder anderen Punkt vergessen/übersehen/noch nicht in den Tabellen erweitert hat, muss das noch lange nicht richtig sein.
Ein Ticket dazu machen, dann wird das schnell gefixt, weil es gesetzliche Vorgaben sind für "unveränderliche Rechnungen".

Das widerspricht dann aber eben der Argumentation mit der Richtigkeit des Sperrens. Denn so gesehen kannst Du ja auch vertragliche Details in Eigene Felder packen, die nach Deiner Argumentation dann gesperrt gehören würden.

Warum? Ich habe nicht geschrieben, dass ich das gut und richtig finde, ich habe nur eine Möglichkeit aufgezeigt die es gibt, die ich besser löschen sollte.

Verstehe ich nicht so ganz. Wenn Du der Rechnungsausgabe für den Fall der Stornierung ein "STORNO" hinzufügst, muss man schon mutig sein und im Falle einer Außenprüfung auf Schlampigkeit der Prüfer hoffen, wenn man so ein Dokument angesetzt hat.

Ansonsten bin ich aber ganz bei Dir, dass Stornos keinen Berichtscontainer benötigen, sondern einfach nur den kurzen Hinweis, dass die Rechnung oder die Rechnungskorrektur (oder der Auftrag) storniert wurde.

Ich würde hier aber schon noch distinguieren zwischen Stornos (vollständig) und Korrekturen (punktuell).

Nein, darum geht es hier nicht, es geht um die Käufer, die Privat bestellen um sich das Widerrufsrecht zu erschleichen, um dann im Nachgang die Rechnung auf die Firma zu ändern, wenn der Artikel passt.
Andere widerum wollen keine neue Rechnung, weil diese bereits im System freigegeben ist, aber wollen eine Korrektur.
Nur als Beispiele ... daher werden eigene Felder ausgefüllt, um zur RECHNUNG ein ZUSATZdokument "Berichtigungsdokument" auszustellen, die RECHNUNG selbst wird aber NICHT geändert.

WIR hatten schon Prüfer, das Berichtigungsdokument wurde daher auch mit dem FA abgestimmt und WIR wissen was wir tun.

https://www.wawi-dl.de/JTL-Wawi-Druckvorlage-Design-01-Berichtigungsdokument-fuer-Rechnung

 

[John]

@wawi-dl inwiefern ist Dein Ansatz mit dem Berichtigungsdokument geeignet, Privatkäufer, die sich später zu gewerblichen nachdeklarieren lassen einzudämmen?

 

[MichaelH]

Die Diskussion gleitet ab.

Zusammenfassung:
Es gibt nun 3 Textfelder, keines davon ist änderbar.
Sogar das Textfeld für die Rechnung nicht.
Mit der neuen Auftragsbearbeitung hätte man wenigstens 1 des beiden Felder welche nicht für "Portale" verwendet wird änderbar belassen können.

Weiters habe ich nun einen kleinen Test gemacht bezüglich Stammdaten:
Wenn ich den Text der Zahlungsart in den Stammdaten ändere, dann wird dieser geänderte Text auf einer existierenden Rechnung verwendet, wenn ich diese aufrufe.
So hat der Kunde also nicht auf Bank X sondern auf Bank Y überwiesen.
Toll !!!

• JTL schreibt also auch ganz normale Stammdaten wie eine Zahlungsart nicht fest, verhindert jedoch, dass wir Textfelder die als Anmerkung bzw. intern verwendet werden für Rechnungen ändern können.
  Darüber solltet ihr euch aufregen ...

Und hier einen Änderungswunsch anzubringen wird wohl kaum erfolgreich sein, da es diese groteske Denkensweise bis in die Version 1.9 geschafft hat.

 

[wawi-dl]

@wawi-dl inwiefern ist Dein Ansatz mit dem Berichtigungsdokument geeignet, Privatkäufer, die sich später zu gewerblichen nachdeklarieren lassen einzudämmen?

Warum eindämmen? Wie willst du das eindämmen? Darum geht es uns nicht.
Wir ändern/stornieren keine Rechnungen, basta, es gibt nur ein Zusatzdokument, mit dem Sie alleine nichts anfangen können.

@MichaelH
wie schon gesagt, JTL ist hier noch nicht gänzlich durch, das wird sicher alles noch kommen ... für mich ist auch viel zu wenig gesperrt, da gibt es noch viel mehr Felder.

 

[MichaelH]

@MichaelH
wie schon gesagt, JTL ist hier noch nicht gänzlich durch, das wird sicher alles noch kommen ... für mich ist auch viel zu wenig gesperrt, da gibt es noch viel mehr Felder.

Das ist eine wesentliche Frage und Anforderung, das Datendesign der neuen Auftragsbearbeitung ist schon lange fertig.
Wenn JTL nun tatsächlich noch Stammdatenfelder nachträglich mitziehen würde, dann wäre das wohl irgendwie lächerlich.

 

[frankell]

Ein Ticket dazu machen, dann wird das schnell gefixt

Realitätsferne Aussage, und das weißt Du auch.

Unabhängig davon: Was es bis heute nicht in die Festschreibung geschafft hat, wird es auch selbst in nur halbwegs absehbarer Zeit nicht dorthin schaffen. Inhaltlich entspricht das dem letzten Post von @MichaelH.

 

[wawi-dl]

Das ist eine wesentliche Frage und Anforderung, das Datendesign der neuen Auftragsbearbeitung ist schon lange fertig.

sagt wer? wäre mir neu ...