Rechungserstellung

Deutsch
, ,
#1

Hallo *,

ich habe in einem anderen Thread bereits angedeutet, dass ich mich etwas mit dem Thema XRechnung auseinander setze, weil das für Firmen untereinander ab 2025 Pflicht werden wird.

Jetzt habe ich den Weg über Writer direkt und über Calc direkt zur Rechnungserstellung getestet und stoße überall an Grenzen, die das Ganze entweder nicht vernünftig gestaltbar oder nicht vernünftig bedienbar machen.

Writer: Tabellen erstellen ist kein Problem. Formeln runter ziehen geht aber schon nicht. Beim Erweitern von Tabellen müssen also Formeln neu erstellt werden. Summenformel für die Rechnungssummierung wird auch nicht mit hinzugefügten Tabellenzeilen erweitert auf den neuen Bereich, zeigt also nur die Summe des vorher bestehenden Bereichs an.
Bisher sieht es so aus, dass ich das Dokument so weit wie möglich schützen würde (Zellschutz) und die Erweiterung von Rechnungsposten über Makros regeln würde.

Calc: Mit den Formeln sieht es bei Calc natürlich besser aus: Erweitern geht und die Summierung läuft mit, wenn ich dazwischen Zeilen für zusätzliche Artikel eingebe. Nur fehlt mir für eine ordentliche Rechnungsgestaltung die Fußzeile, in der ich für die weitere Verarbeitung auslesbare Variablen (Kontonummer, Firmenname, UmsatsteuerID usw.) speichern kann.

Base: Hier bekomme ich all das geregelt, weil ich die Eingabe von der Druckausgabe komplett trenne. Da lasse ich dann über eine Writer-Vorlage eine Rechnung in lesbarer Form erstellen, die immer sauber formatiert ist und zusätzlich auch noch so etwas wie den Übertrag beim Gang von einer zur nächsten Seite beherrscht.

Wie regelt ihr das mit der Erstellung von Rechnungen, die entsprechend professionell aussehen sollen und einfach mit Daten zu befüllen sind?

Gruß

Robert

#2

Mit einer dafür gemachten Software, die der Verwaltung einer Arztpraxis dient.
Für Base habe ich eine kleine Makro-Suite, die Serienbriefe (Rechnungsdaten) mit Tabellen (Rechnungspositionen). verknüpen kann.
So etwas profanes wie Rechnungserstellung ist anscheinend nie im Open/LibreOffice-Projekt mitgedacht worden. Man will das ja nicht wie zu Schreibmaschinenzeiten jede Rechnung in ein Dokument eintippen, sondern vielleicht auch mal einen ganzen Stapel von Datensätzen versandfertig machen.

EDIT: Ich habe mein Mail Merge Projekt vom Sommer 22 nochmal angeschaut. Ich habe es irgendwann aufgegeben, eine GUI dafür zusammenzufrickeln, aber es müsste auch ohne funktionieren. Die folgende Datei fasst den Stand der Dinge ohne GUI auf Englisch zusammen.
Die MailMerge-Eigenschaften werden in den Dokumenten-Eigenschaften festgelegt. Das Recordset dafür ist ein Formular mit dem Namen "MailMerge_Master.
Die abhängigen Tabellen werden als Text-Tabellen angelegt, analog zu den alten Datenbankberichten, mit einer Kopfzeile und einer Dummy-Zeile als Formatvorlage für die Datenzeilen, jedoch ohne Gruppierung.
Die abhängigen Text-Tabellen werden mittels Parameterabfragen gefüllt, welche in einem “Hidden Control” des Formulars “MailMerge_Master” definiert sind.
Ich hatte das damals mit einer HSQLDB getestet und auch mit einer Calc-Datenquelle. Letzteres funktionierte leider nicht, obwohl es eigentlich keinen Unterschied machen sollte.
README.odt (139.8 KB)
Die Code-Basis und Test-Dokumente muss ich mir nochmal genauer ansehen.

Undi hier noch der Code in einem Modul:
MailMerge_Tables.py.odt (46.7 KB) (2.Upload Sa,2023-11-11 14:00)

Wenn man seine eigene Rechnungsdatenbank mit einer Serienbriefabfrage und einer Parameterabfrage ergänzt (parameter = Rechnungs-ID), im Writer-Brief die Serienbrief-Felder + Leertabelle erstellt und ein Formular “MailMerge_Master” mit der Serienbriefabfrage sowie einem “hidden control” für die Parameterabfrage hinzufügt, dann könnte es wirklich funktionieren.
Name des “hidden control” = Name der Text-Tabelle
Wert: Name der Parameterabfrage
Zusatzinfo: Name des Serienbrief-Feldes, das den Parameter ausfüllen soll (oder auch mehrere durch Semikolon getrennt in Reihenfolge der Parameter)
Ohne jede weitere Konfiguration in den Dokumenteneigenschaften sollte ein neues Writer-Dokument mit allen Rechnungen erscheinen.

#3

Bislang habe ich auch so gehandhabt: den Rechnungs-Brief in WRiTER manuell erstellt und die Rechnungs-Tabelle in CALC, eingebettet im WRiTER-Brief. Das Organisatorische geschah bislang im Kopf: Anfrage des Kunden durchdenken, Angebot ausarbeiten, Kunden-Daten recherchieren, Kunden-Auftrag festhalten, Rechnungs-Daten anhand der Kunden-Daten festlegen, Lieferung(en)/Rechnung(en) schreiben und dokumentieren, Zahlungs-Vorgang in der Kunden-Datei festhalten, jede Änderung in der Kunden-Datei festhalten.
Aktuell arbeite ich eine komplexe CALC-Dokument-Struktur aus in fortlaufend nummerierten odt.Dateien, wobei die höchste odt.-Nummer die aktuellste ist, worauf der nächste Auftrag basiert:
a) nicht druckbare Blätter mit allen aktuellen Kunden-Daten, die stets zu pflegen sind: TAB-1, Stammkunden und TAB-2 sporadische und neue Kunden;
b) nicht druckbare Blätter mit Auftrags-Vorgang: Anfrage, Kalkulation, Aufwand, Termine, Art des Auftrags, usw.;
c) druckbares Blatt: wahlweise Angebot, Lieferschein, Änderung, Rechnung(en). Da ich den ersten Vorgang, meist Angebot, als odt.Dokument gespeichert habe, lässt sich in der Zelle mit Liste der Auswahl das nächste Formular (Lieferschein, Änderung, Rechnung 1, Rechnung 2, …) wählen und als ods.Blatt ausdrucken; dabei werden alle Blätter (TAB-1, TAB-2, TAB-calc, TAB-termin, TAB-auftrag, …) mit gespeichert, sodass ich mit jedem Vorgang nicht nur alle aktuellen Daten vorfinde (zB.: Liquiditäts-Status, Datum des letzten Auftrags jedes Kunden, Einsatzort, Umfang und Art des Auftrags, …) sondern anhand der mit fortlaufender Datei-Nummerierung auf sodann veraltete ods.Dokumente mit damals aktuellen Daten zugreifen kann.
Die reine Rechnungs-Erstellung geschieht nüchtern formell quasi halb-automatisch, wozu ich LO-CALC „missbrauche“ im Schreib- und im Datenbank-Modus. Der größte Aufwand besteht ohnehin in der Aktualisierung und der Pflege der Kunden-Daten mitsamt den bereits gelieferten Aufträgen.
Das Brief-Layout ist sachlich ohne früher übliches Design: Kopf-Bereich auf jeder Druckseite gleich, Fuß-Zeile nur Seiten-Nr. und -Anzahl, Fuß-Bereich auf separater Seite mit dem Status des Auftrag-Vorgangs, iD-Nummern, etc.
Da jeder Auftrag ohnehin individuell ist, erübrigt sich eine Massen-Formulierung wie zB. die Änderung meiner Konto-Nummer.
Das Ganze ist erst einmal Versuch-und-Test-und-Irrtum, wobei jeder Vorgang mit neuen oder veralteten Variablen auf den vorherigen Vorgang aufbaut und geändert und angepasst wird

#4

Dann probier mal folgendes:
Speicher die folgenden Dokumente in einem Verzeichnis, wo Makros ausgeführt werden dürfen.
MailMergeTables_Calc.odb (2.7 KB)
MailMergeTables_Calc.ods (43.7 KB)
test_MMT_Calc.odt (20.1 KB)

Registriere die Datenbank unter dem Namen MailMergeTables_Calc
Die Tabellenkalkulation enthält Rechnungsdaten auf dem ersten Blatt und Rechnungspositionen auf dem zweiten in Datenbankbereichen “Import1” und “Import2”.
Das Datenbankdokument ist mit der Tabellenkalkulation verknüpft. DIe Tabellenkalkulation wird so präsentiert als wäre sie eine Datenbank. Außerdem enthält die Datenbank 2 Abfragen.

Die Textdatei enthält das oben verlinkte Python-Modul in eingebetteter Form und ein wenig Konfigurations-Voodoo wie oben beschrieben.
Sichtbar ist ein Serienbrief, der die Daten von der registrierten Datenquelle “MailMergeTables_Calc”, Tabelle “Import1”, also der Datenbankberiech vom ersten Blatt.
Darunter ist eine Dummy-Tabelle mit einer Kopzeile und einer Datenzeile mit Währungsformatierung.
Drücke die Schaltfläche und warte ein paar Sekunden bis ein weiteres Textdokument erscheint, mit den ausgefüllten Rechnungen samt zugehöriger Rechnungspositionen in der Tabelle.

#5

Wenn ich das bisher lese, dann habe ich wohl nicht den falschen Eindruck, was die Fähigkeiten von Writer und Calc angeht. Das eine ist zum schön Machen und das andere zum sauber Rechnen. Ich mache das ja seit geraumer Zeit mit Base und einem Ausdruck über den Writer (Platzhalter und Tabellen). Da nutze ich das Schönmachen vom Writer und die nicht gerade großen Rechenansprüche an Base sowie die klare Formularstruktur von Base-Formularen.

@Villeroy : Die verschiedenen Ansätze von Dir werde ich mir natürlich noch zu Gemüte führen. Und wenn ich dann mit dem XRechnungsansatz fertig bin kommt dazu auch wieder eine kurze Beschreibung raus.

#6

Die Routine “start_MailMerge” macht folgendes mit dem Textdokument:

  1. Suche nach dem erstbesten Serienbrieffeld und nimm daraus die Datenbankverbindung.
  2. Erste ein neues c.s.s.text.MailMerge mit der Verbindung des Serienbrieffeldes.
  3. Lies alle weiteren MailMerge-Eigenschaften aus den benutzerdefinierten Dokumenteneigenschaften.
  4. Finde das Formular “MailMergeTables”
  5. Für jedes “hidden field” darin
    5.1 suche die gleichnamige Text-Tabelle.
    5.2 suche die genannte Parameterabfrage aus dem Wert des hidden control.
    5.3 lies den oder die Feldnamen aus der Extrainfo des hidden controls. Die beziehen sich auf die Master-Felder aus dem MailMerge-Recordset, mit denen die Parameter ausgefüllt werden sollen.
    5.3 Füge einen XNotifyLIstener zum MailMerge-Objekt hinzu. Jeder Listener wird mit einer Referenz auf das jeweiligen preparedStatement und den jeweiligen Parameter-Infos versehen.
  6. Bei jedem Datensatzwechsel des MailMerge-Objekts wird für jede abhängige Texttabelle der Listener getriggert, der die Parameter ausfüllt und aus dem resultierende Recordset ein DataArray erzeugt. Die entsprechende Texttabelle wird um die entsprechende Zeilenanzahl vergrößert und der DataArray hineingekippt.

Wenn man in den benutzerdefinierten Eigenschaften des Textdokument nichts festlegt (wie im obigen Beispiel), dann wird MailMergeType.SHELL gesetzt, was den Serienbrief in ein neues, ungespeichertes Dokument lädt. Man kann in den benutzerdefinierten Eigenschaften alles definieren, was mit dem MailMerge-Dialog möglich ist, also Ausgabe in eine Datei oder mehrere Dateien, an Drucker oder Email via SMTP.

Ich bilde mir ein, dass ganz ähnlicher Code genauso gut XRechnung als Nebenprodukt erzeugen könnte. Man legt MailMergeType.FILE fest, das Ausgabeverzeichnis, ein Prefix und den Primärschlüssel, der die Dateinamen unique macht.
Der Serienbrief triggert den Listener für jeden einzelnen Datensatz, dieser liest sowohl den Rechnungsdatensatz wie auch die Rechnungspositionen, und erzeugt das passende XML zusätzlich zur Text-Tabelle mit den Positionen. Oder man bettet xrechnung.xml in das ODF-Dokument ein. Dann hätte man ein Hybridformat.

#7

Ich sehe hier, ich habe das falsche Fähr-Ticket gelöst und einen nicht gewollten Ziel-Hafen gewählt:
a) Macros sind auf meinen PCs gesperrt. So bleiben deine odb.- und ods.Dateien reine Daten-Inhalte.
b) Die Funktionen in Pythron-Prog. verstehe ich nicht; mit BASE (anstelle von MS-ACCESS) habe ich mich noch nicht rumgeschlagen (starrköpfige Verweigerungshaltung).
c) Das reine „schön-geschriebene“ Rechnungs-Blatt im DiN-Design ist kein zentraler Prozess in meinem Büro-Alltag, sondern nur ein vorletzter Schritt im Ablauf eines Auftrags.
d) Serienbriefe kommen bei mir nicht vor.

Dein gut beschriebes System ist sehr speziell, passt nicht ansatzweise in mein spezielles System, auch blicke ich nicht durch, besonders deine letzte Beschreibung: „böhmische Dörfer“, die ich zu studieren hätte.

#8

Schade, ich hätte gerne gewusst, ob es anderswo auch läuft. Das halbgare Projekt war ein Jahr im Tiefschlaf, und heute konnte ich doch noch zwei Fehler finden und beseitigen. Mit Tabellenkalkulation befasse ich mich nicht mehr, wollte aber demonstrieren, dass man sogar eine Tabellenkalkulation als Datenquelle für meinen Rechnungsgenerator benutzen könnte.

#9

@Villeroy
Wieso schade? Meine bisherigen Versuche scheiterten eher schneller als erwartet, die völlig unterschiedlichen Modi von Text-Typografie mit Design (WORD) mit Tabellenkalkulation (CALC bzw. EXCEL) mit Datenbanken (ACCESS) irgendwie zusammen zu bringen. Daher durchaus mein Respekt vor deiner Macro-Programmierung! Ohne die der „Komplott“ wohl nicht gelingen kann. Nicht umsonst sind Büro-Softwares teuer und exzentrisch komplex strukturiert in mehreren Modulen, die man einzeln zusammengestellt erwerben muss.

Ich erinnere mich an 2 Bruchlandungen: die Serienbrief-Funktion wurde „ über den Haufen geschmissen“, als Microsoft ein Update anbot. Und eine private komplexe Kalkulation fürs Finanzamt von Umsätzen, als meine verstrickten Berechnungen keine aufwändigen Änderungen, die das Finanzamt forderte, zuließen.

#10

Schade halt, dass du deine Erfahrungen mit MSO auf LibreOffice überträgst.

#11

Nur eine kurze Anmerkung zu Makros:
Extras → Optionen → LibreOffice → Sicherheit → Makrosicherheit. Das habe ich bei mir auf “Mittel” stehen und bei den vertrauenswürdigen Quellen einen entsprechenden Speicherort angegeben. Dann funktionieren Makros nur in diesem Speicherort ohne Sicherheitsabfrage.
Würde ich ganz ohne Makros arbeiten, so käme bei mir neben Serienbriefen der Report-Builder in Frage. Aber beides ist von der Bedienung und vom Resultat her eher eine Krücke als Walkingstick.

1 Like
#12

Ohne diese Erfahrungen hätte ich anfangs das neue OO (OpenOffice) nicht parallel zum alten MSO („MicroSchrottOffice“) laufen lassen, um schließlich und ausschließlich bei LO (LibreOffice) zu landen. Nur leider ließ und lässt sich eine komplex strukturierte ACCESS-Datenbank nicht nach BASE transferieren :face_vomiting:. Die beiden Text- (WORD ÷ WRiTER) und Kalkulations-Programme (EXCEL ÷ CALC) gleichen sich bis auf wenige Details und/oder Spezialitäten.
Der einzige und nicht zu unterschätzende Vorteil von OO u LO lag und liegt darin, dass selbst alte Dateien, die mit einer frühen Version erstellt, mit der aktuellen Version sowohl lesbar als auch veränderbar/bearbeitbar sind, was bei MSO und auch CorelDraw nicht voraussehbar war und neue Software-Funktionen wurden/werden von einer veralteten Version ignoriert, mit der man zwar bewährt arbeiten konnte, was allerdings nicht akzeptabel war, wenn der Nachbearbeiter mit einer neueren Version arbeitete.

Deswegen – um zum Thema „eRechnung“ zurück zu schwenken – akzeptiert der finanz-rechtliche Angestellte digitale Rechnungen und Auftrags-Dokumente nur in lesbarer und nicht fälschbarer Form, üblicherweise handschriftlich oder zusätzlich zur digitalen Datei ausgedruckt. Denn Dokus müssen mindestens 7 Jahre lesbar aufbewahrt werden, wenn ein Finanzprüfer überhaupt so lange rückwirkend prüfen soll/muss, da das durchaus 7 Wochen Außendienst für den Büro-Hengst bedeuten kann :laughing::thinking::cowboy_hat_face::money_mouth_face:, während dessen seine Innendienst-Tätigkeit ja ruht.

Einblicke in den eRechnung-Hyperbürokratismus, deren Form aktuell nur für Rechnungen an öffentliche Auftraggeber des Bundes gestaltet werden müssen:
https://www.ferd-net.de/standards/zugferd-2.2/zugferd-2.2.html.

Meine zaghaften Recherchen haben bislang ergeben: Erst in vielen Jahren wahrscheinlich, dass jede eRechnung, nicht nur B2B – Firma÷Firma – sondern auch B2C – Firma÷Konsument –, im PDF-Format erstellt und gelesen werden müsse (!?) mit den Variablen (Daten) im eingebetteten und separat auslesbaren XML-Format. Soviel verstehe ich nicht vom Programmieren, ich nehme an, die XML-Datei ist als Macro der PDF-Datei angekettet?! Bis dahin werden wohl alle Rentner u Pensionäre, die keine B2C-eRechnung mangels El-Equipment erhalten/lesen, ausgestorben sein, um das oberst-ministerielle Diktat konsequent durchzudrücken („Stichwort:Diggitahlisierunk“ :face_with_head_bandage::lying_face::sunglasses:).
Gefordert ist eine PDF/A-3b-Datei, die LO lässig exportiert. Ohne Kundenstamm-Dateikarten und ohne Datenbanken und ohne Auftrags-Dokumentation.

Soweit sehe ich da keinen Aufwand, irgendetwas in PYTHRON, ACCESS, CALC, C++ aufwändig und speziell zu erarbeiten. Oder? Jede Anregung, Einwändung, Conta, Unterstützung hoch-willkommen!

Dennoch, oder gerade deshalb: Als fremd-benannter „Excel-Kaiser“ bastle ich weiter die CALC-Auftrags-Prozedur/Datei perfektionierend im Trial-Error-Modus, nur um zu lernen …

#13

Kein Macro. Die xml-Version ist - ähnlich einem Attachment zur eMail - in der Datei enthalten.

Und gansu das ändert sich gerade, auch weil es inzwischen reichlich Geschäftsvorfälle gibt, die schon rein online passieren und kein Papier brauchen. Bei unserer kürzlichen Prüfung fanden sich auf den vorbereitenden Formularen auch direkt die Fragen in welchen Formaten das Rechnungswesen speichert. Du kannst davon ausgehen, dass das Finanzamt für Körperschaften durchaus mit SAP-Daten umgehen kann.
.
Diverse Bereiche sind längst “online”-pflichtig und auch wen ich kein Fan von xml/xslt bin, es ist esser als der bisher Verbreitete Murks mit csv-Dateien…

1 Like
#14

@Wanderer
Wie kann ich die eingebetteten XML-Daten aus der ACROBAT-Datei extrahieren bzw. die Variablen geändert einbetten? Und zwar im U+00000000-Format-Code.

#15

Mir ist zwar schon einiges begegnet, aber dies Format ist mir nicht bekannt.
.
Ansonsten gibt es diverse Tools zur PDF-Bearbeitung. Normalerweise wird man einen Anhang aber genau so speichern, wie er eingebettet wurde. Bei xml muss man dann in der DTD nachsehen, was man da bekommt…

#16

Nur weider eine Kurzinfo:
XRechnung bzw. ZUGFeRD wird ab 2025 für den Firmenkontakt untereinander Pflicht. Nur der Kontakt zu Privatkunden läuft weiterhin in analoger Form.

XRechnung ist eine reine *.xml-Datei. Die ist mit jedem Texteditor lesbar. Das Format darf nicht irgendwo eingebettet werden - also auch nicht in eine *.pdf-Datei.

ZUGFeRD wird in einem zweiten zulässigen xml-Format herausgegeben. Diese Datei darf auch in eine *.pdf-Datei eingebettet werden. Jedes Betrachtungsprogramm kann zum Auslesen genutzt werden, bei mir z.B. unter Linux Okular.

An der Rechnungserstellung (im Moment Schwerpunkt XRechnung) mit LibreOffice bin ich dran. Was nicht so einfach lösbar ist, ist das Auslesen dieser Dateien, da eine Firma eben gleich beide Formate mit allen Einstellungsmöglichkeiten lesen können muss.

#17

Zum Importieren braucht man in der Tat eine möglichst vollständige Implementierung damit man jede Rechnung von jeder Firma darstellen kann. ABER: Warum sollte man eine eingehende Rechnung in eine Office-Suite importieren? Zum Lesen mit den eigenen Augen bekommt man doch ein PDF (oder docx :face_vomiting: ).
Man will sie mit Bestellungen und Lieferscheinen abgleichen. OK, wer macht das mit der Office Suite?
Man will sie bezahlen. Die Banken werden das schon hinbekommen, das Format in Transaktionen umzusetzen, sobald der Kunde sie dazu autorisiert.
Und überhaupt, welches Modul sollte die Daten aufnehmen? Eine mit Base verbundene Datenbank natürlich, aber wer zum Teufel benutzt schon Base außer uns beiden? Writer? Ganz bestimmt nicht. Wozu sollte man ein Dokument einer Fremdfirma in eine eigene Vorlage einlesen? “Alle” wollen das in Calc haben. Calc ist aber zunächst einmal nur ein Gitter von leeren Zellen. Was wird mit welcher Formatierung genau wohin geschrieben – und warum überhaupt? Um die Rechnung nachzurechnen?

#18

Nur kann es sein, dass sich einige Firmen auf die XRechnung versteifen. Und der Inhalt dieser Rechnung ist schließlich maßgebend, nicht was in dem lesbaren Teil einer *.pdf-Rechnung steht.

Das Auslesen würde ich sowieso mit so etwas wir xrview machen. Nur: Die Installation davon ist für Unbedarfte nicht zu machen und auch das Öffnen eines Dokumentes geht standardmäßig über die Konsole.

Ich habe mehrere Firmen, für die ich eine Rechnugsdatenbank auf Grundlage von Base erstellt habe. Und eine dieser Firmen verdient eben seine Brötchen hauptsächlich mit Firmenkunden… Also: Wir sind zumindest nicht ganz allein mit der Nutzung von Base auch für diesen Bereich.

#19

Aber dabei geht es doch eher um ausgehende Rechnungen. Wie und wozu würdest du eingehende Rechnungen mit LibreOffice berarbeiten? Wenn xview solche Rechnungen menschenfreundlich darstellen kann, dann ist das doch nur ein 5-zeiliges Makro, das xview mit der richtigen Datei aufruft.

#20

Eingehende XRechnungen würde ich nicht mit LibreOffice bearbeiten. Da können die Leute besser die Einkaufpreise in die entsprechende Tabelle eintippen. Aber die Ansicht von eingegangenen Rechnungen muss eben nicht gegeben sein.

Wenn ich dann als Quelle für den Viewer xrview etwas angebe, das nur mit Mühe von mir selbst installiert werden kann, dann frage ich mich, wie das Windows-User hin bekommen sollen.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.