(@rheydenr @OBM-JueM) Hallo zusammen,

wegen ähnlicher Anforderungen hier (u.a. mehr Flexibilität bei e-Rechnungen) habe ich in eine angepassten Fakturama Version erstellt. Siehe auch: https://www.fakturama.info/community/fehler-verbesserungsvorschlaege/verwendung-von-rechnungs-und-lieferadresse/#post-17799
Mein (vorläufiger) Lösungansatz (im tägl. Einsatz bewährt) ist wie folgt (Auszug aus einer Mail Ralf):

"EmbeddedProperties" - so heißt bei mir nun der in fkt_contact.note gespeicherte Java Properties Block.
Diesen variablen, strukturierten Speicherplatz in das Note Feld zu "mergen", kommt daher, dass ich keine DB-Strukturänderung ohne Abstimmung machen möchte. Ich könnte mir aber vorstellen, dass es ggfs. Sinn macht das als eigenes Feld beim Kontakt zu hinterlegen. Größter Vorteil ist m.M. die Variabilität ohne DB-Änderung. Gerade mit dem Thema E-Rechnung könnte ich mir vorstellen, dass in näherer Zukunft da Bedarf ist.
So sieht das dann in der DB aus (siehe -> 20210305_DB_Contact_Note.png)

Der Anwender bekommt davon nichts (mehr) im Notizfeld mit, da beim Öffnen des Kontakteditors dieser Block "rausgeschnitten wird" und komfortabel in einem eigenen Tab "Extras" (Vorschlag) bearbeitet werden kann
(siehe -> 20210305_Contact_TabExtras.png):

beim Speichern wird der <[EmbeddedProperties[ ... ]]> Block (sofern benutzt) dann automatisch dem Note Feld hinzugefügt.

Neu ist (wie schon erwähnt), dass nun je Kontakt hinterlegt werden muss, ob und welches E-Rechnungsformat für den jeweiligen Kontakt erstellt werden soll.
Die bisherigen Einstellungen bzgl. E-Rechnung (de)aktivieren die E-Rechnungserstellung generell. Um mit dem bisherigen Verhalten kompatibel zu sein könnte dort eine Option "Kundenindividuelle Einstellung verwenden" eingefügt werden. Allerdings nehme ich an, dass bei den F.-Anwendern so wie hier der Standard bei den Kunden ist: (noch) keine E-Rechnung.
Für die (Ziel)Felder BT-10/11/12/13 kann wahlweise eingestellt werden:
- statischer Wert (z.B. für Leitweg ID)
- dynamisch, Feld "Kundenreferenz" aus Rechnung
- wie vor, jedoch nur was links von der Zeichenfolge " - " (Leerzeichen Minus Leerzeichen) steht
- bei BT-13 auch Nummer der Bestellung (wenn Dokument vorhanden)

Um den Anwender bedarfsgerecht (v.a. weil's derzeit ja noch eher selten ist) auf die erstellte E-Rechnung hinzuweisen gibt es diesen Hinweis, wenn mindestens eines der Felder "Hinweis", "per E-Mail an" oder "Portal/URL" befüllt ist
(siehe -> 20210305_Document_EInvoiceInfoDialog.png)

Derzeit sind es hier nicht-editierbare Felder, aus denen mit Copy-Paste die Daten übertragen werden können.
Angedacht ist, auch hier E-Mail und URL als Link mit entsprechender Funktionalität anzubieten.

@gschrick @rheydenr Hervorragend! Das ist viel weiter gedacht. Vor allem wegen der Möglichkeit, Informationen zur e-Rechnung zu hinterlegen.
Natürlich ist es schön, wenn vorhandene Nutzer nichts von den Änderungen mitbekommen, ich persönlich würde aber eine neue Version der Datenbank bevorzugen, weil dann die volle Flexibilität für weitere Änderungen bleibt. Die Bemerkungsfelder sind nämlich schnell aufgebraucht. Ich muss mal nachfragen, wo mein Kunde eigentlich gern das Rechnungsleitkennzeichen hätte. Meine Befürchtung ist, dass die darüber noch gar nicht nachgedacht haben. Aktuell lesen die nämlich PDF ein und verlangen, dass Leitweg und Rechnungsleitkennzeichen Teil der Adresse ist. Morgen weiß ich dazu vielleicht schon mehr.
Zum Konverter: Meine Vermutung ist, dass die Feldzuordnung je nach Rechnungstyp sich auch noch ändern könnte. Mit der Information über das Format lässt sich das dann aus einer Konvertierungstabelle entnehmen.

@OBM-JueM @gschrick @rheydenr

Hallo zusammen,

ich muss jetzt mal da kurz zwischenfragen:
Gibt es eigentlich einen EU-weiten Standard für E-Rechnungen oder kocht sich da jedes Land tatsächlich sein eigenes Süppchen?

Was ist mit EDI/EDIFACT?
Offensichtlich gibt es in Deutschland die "X-Rechnung" und hier bei uns in Österreich "ebInterface".

In Österreich müssen bereits seit 2014 Rechnungen an den Bund bzw. die öffentliche Verwaltung, sowie einige staatsnahe Betriebe (ÖBB, ASFINAG etc.) über das "Unternehmensserviceportal" (USP) oder das "E-Rechnungsportal" als XML-Strukturierte E-Rechnung (ebInterface) eingebracht werden.
Zusätzlich kommt noch dazu, dass diese elekronisch signiert sein müssen.

Ich selbst habe im Jahr nur 3 bis 4 Mal die Anforderung für eine E-Rechnung an die öffentliche Verwaltung, und habe das bisher immer über das entsprechende Formular im USP 'händisch' gelöst; aber ich nehme an, dass dies relativ bald auch mehr werden wird.

Theoretisch würde das wohl bedeuten, dass in Fakturama mehrere "Schnittstellen" für E-Rechnung geschaffen werden müssten.

LG
Jürgen

@microangelo @OBM-JueM @rheydenr

Hallo zusammen,

mit einem Background von etwa 15 Jahren intensiver Tätigkeit mit XML und XSLT kam mir folgende Idee, die uns in Fakturama viel Aufwand ersparen müsste.
Achtung genial! 😉

(betrifft nur den Prozess der E-Rechnungserstellung)

1. Fakturama erzeugt ein "Fakturama-Dokument/Rechnungs-XML" (to be defined; einfach aber flexibel und hat noch nix mit irgendeinem Standard (außer XML) zu tun)
   hierin sind alle für die Rechnungserstellung relevanten Daten enthalten incl. der berechneten Summen etc. pp.
2. in einer anschließenden XSLT Transformation wird mit einem für das gewünschte E-Rechnungs-Format spezifischem XSLT-Stylesheet daraus das eigentliche E-Rechnungsdokument erzeugt (X-Rechnung CII, Zugferd, Weiß-Der-Geier-Was-Noch-Kommt, ...)
3. "Weiterverarbeitung" des in 2. erzeugten Dokuments, z.B. Speichern der XML Datei, Einbettung in PDF (zugferd), ...

Der Clou an der Sache:
im Programm ist nur mehr 1. und 3. "fest verdrahtet" und voraussichtlich relativ stabil was Änderungen an E-Rechnungsformaten betrifft.
Die eigentliche Arbeit/Logik steckt in den XSLT-Stylesheets. Diese (beliebig viele) liegen einfach in einem Verzeichnis wie auch die Vorlagendokumente und können jederzeit angepasst und/oder durch neue ergänzt werden; d.h.: um ein neues/angepasstes E-Rechnungsformat bereitzustellen muss lediglich ein passendes XSLT-Stylesheet in das Verzeichnis. An Fakturama muss dazu NICHTS geändert werden, KEINE neue Version ö.ä.

Die Formatauswahl, d.h. welches XSLT genutzt wird stelle ich mir z.B. so vor:
Die XSLTs folgen einem Namensschema, z.B: Format_customVariant.xsl
beim Kontakt (ähnlich meiner bisherigen Variante) wird das Zielformat durch Auswahl des XSLTs bestimmt (keine Angabe = keine E-Rechnung für diesen Kunden).
Per Wildcards können mehrere infrage kommenden Formate (also XSLTs) spezifiziert werden, welche wie Vorlagen beim Drucken dann zur Auswahl erscheinen. Mögliches Anwendungsszenario: Abbilden von kundenspezifischen Anforderungen (z.B. spezielle/zusätzliche Felder/Feldwerte).

zu 1.: hier würde ich alle Spalten der einbezogenen Datensätze (z.B. Notizfeld der Kontakte Rechn.-/Lieferadresse) gleich mit aufnehmen, d.h. alles was in Fakturama verfügbar ist. Man weiß nicht, wann/wofür man's braucht und dann steht fürs XSLT schon alles zu Verfügung.

zu 2.: hier soll Fakturama in der Lage sein (Fehler)Meldungen, die in der Transformation ausgegeben werden können entsprechend auszugeben. Damit kann sogar (wiederum vom XSLT gesteuert) eine gewisse Validierung realisiert werden.

FAZIT:
sämtliche Formatspezifika, -anpassungen, Fixes, neue Varianten/Versionen, Länderspezifika etc. erfordern keine Programmänderung, solange das Ausgabeformat ein Textbasiertes ist (XML, csv, JSON, ...), also per XSLT erzeugt werden kann und die für die Rechnung erforderlichen Daten in Fakturama abgebildet werden können (ggfs. auch über Workarounds à la Marker in Textfeldern)

Abschließend noch ein Gedanke zu den "EmbeddedProperties":
Ja, die sollen nicht im Notizfeld bleiben, sondern einen eigenen Platz bekommen (wollte wg. Kompatibilität erstmal nix an der DB ändern).
Evlt. einfach ein Textfeld (wie Notiz) in welchem im Java Properties Format Schlüssel-Wertepaare abgelegt werden können. Eine "user friendly" UI ist sicher kein Problem.
Diese Werte sollen dann einzeln strukturiert im Fakturama-Dokument/Rechnungs-XML zur Verfügung stehen.

Klingt jetzt vielleicht sehr technisch und komplex, doch der "Standard User" wird davon nix mitbekommen und der "Advanced User" (z.B. der/die Fragesteller hier) werden die Flexibilität zu schätzen wissen.

So, jetzt lass' ich's mal gut sein 😉
Liebe Grüße
Gerd

@gschrick 

Hallo Gerd,

also für mich - als programmiertechnischer Laie - hört sich das soweit mal sehr gut an.
Ich könnte mir das gut vorstellen, dass dann eben die "Dokumente" auch als XML-File etc erstellt werden, und vor allem die "Steuerung" über Vorlagen-Dateien finde ich wirklich gut.

Ich glaube diesen Ansatz sollte man weiterverfolgen.

LG
Jürgen

PS: @gschrick - Du hast demnächst eine PM von mir 😉

@microangelo Ich schließe mich der Meinung an. Die Idee mit den Stylesheets ist gut und macht dann auch keine Probleme bei späteren neuen Anforderungen.
Mein Kunde hat sich inzwischen wie erwartet nicht wirklich entschlossen gezeigt. Argument: Die Firmen machen sowieso, was sie wollen. Einigkeit herrschte beim Leitweg für BT10, das Rechnungsleitkennzeichen würde der Kunde in BT11 (Projekt) oder BT13 (Bestellnummer) sehen, es ist ihm egal. Wenn ich entscheiden dürfte, würde ich BT11 bevorzugen, weil da ja durchaus noch mehrere Bestellungen gemacht werden können. So eine strukturierte Denkweise ist aber meinem Gesprächspartner eher fremd (was für einen promovierten Physiker ungewöhnlich ist 😉 ).
Für die Zuordnung der Felder aus Fakturama zu denen in XRechnung wäre also das (neue) Feld für Leitweg ID -> BT10, Kundenreferenz -> BT13, für BT11 habe ich nichts Sinnvolles im Bestand (Handbuch) gefunden. So wie ich es sehe, muss die Datenbank von Fakturama tatsächlich etwas aufgebohrt werden, um die Felder in XRechnung abdecken zu können. Die Frage ist, was davon sinnvoll ist ...
Die zwei Schritte in der Erstellung von eRechnungen hatten wir früher schon bei Zugferd, das wäre also nicht neu. Allerdings wurde der manuelle Eingriff ja schon erfolgreich beseitigt.
Wenn ich könnte, würde ich beim Programmieren helfen. Aber in dieser Hinsicht habe ich zwei linke Hände mit lauter Daumen. Wenn es ums Testen geht, bin ich gern dabei.
Grüße
Jürgen (in meinem Jahrgang ein Sammelbegriff)

Update:

Ich habe mit einem Proof-of-concept begonnen und kann schonmal bestätigen, dass der Ansatz funktioniert! Im wesentlichen ging's mir um die Integration der XSLT-Transformationsfunktionalität in Fakturama (für die Techies: XSLT Prozessor Saxon-HE 10.6, XSLT 1, 2 und 3!).

(Hinweis: wie genau die Integration/Benutzerinteraktion dann mal aussieht ist noch komplett offen; zusätzliche Schritte bei der E-Rechnungserstellung sind grundsätzlich mal nicht zwingend erforderlich.)

Also (kurz) wie mein Prototyp funktioniert:

1. XSLTs liegen im Vorlagenverzeichnis im Order "XSLT"
2. die exportierten Dateien landen im "Export" Ordner im Dokumentverzeichnis
3. Im Menü Extras gibt's jetzt "Export document", ist (wie Drucken) nutzbar, wenn ein Dokument im Editor aktiv ist. Bei Auswahl ...
4. werden die Dateinamen aller ".xsl" Dateien aus 1. und "-none- (nur XML raw)" als Auswahl für den Exportprozess angezeigt (wie Vorlagenauswahl beim Drucken)
5. wird ein XSLT gewählt, wird dieses geladen/compiliert(=geprüft) ggfs. mit Fehlerausgabe (-> Abbruch -> Fehler korrigieren -> 3.)
6. Erstellen der "Fakturama-Dokument-XML" Datei und speichern im Exportordner
7. (wenn ausgewählt) XSLT Transformation darauf anwenden und speichern des Ergebnisdokuments im Exportordner

Die Funktionalität steht für JEDEN Dokumenttyp zur Verfügung, nicht nur für Rechnungen.
Und das per XSLT mögliche Ausgabeformat ist nicht auf pures XML beschränkt. Inwieweit das jetzt außer für E-Rechnungen "sinnvoll" ist, sei dahingestellt - die Technologie bringt diese Freiheit halt mit 😉

Testweise habe ich mal folgende Beispieldateien erzeugt und als "Stimmungsbild" eingefangen (20211117_DocumentExportPrototype.png):
- Fakturama-Dokument-XML (links mitte)
- plain Text (links unten)
- XRechnung (rechts oben)
- HTML(rechts unten im Browser)

Alle diese Dateien basieren auf dem gleichen Dokument in Fakturama (hier Rechnung) und wurden ganz real mit der Prototyp-Funktionalität und "echten" (aber noch nicht vollumfänglichen, v.a. XRechnung) XSLTs erstellt.

LG
Gerd

@OBM-JueM 

Hallo Jürgen,

ich habe ein ähnliches Problem, mit einem einzigen Kunden, der (aufgrund einer Beteiligung eines Staatsbetriebs an seinem Unternehmen) eigentlich verpflichtet ist e-Rechnung einzusetzen. Da kommt die Rückmeldung "machen's was wollen, wir müssen des eh händisch bearbeiten"

Ich glaube, dass das Problem einfach darin liegt, dass sich

1. die Entscheidungsträger in Unternehmen, sich mit der Materie nicht auseinandersetzen (wollen).
2. diejenigen die damit arbeiten (müssen) keine 'echten' Entscheidungsträger sind.
3. es keinen einheitlichen Standard gibt.
   Ich muss vermutlich für Empfänger in AT ein anderes Format einsetzen als für solche in DE oder HU.

Aber ich kenne das aus den Bereichen Datenschutz und digitale Signatur.

Es ist tatsächlich Interessant, dass die EU-Gremien alles mögliche in Regelungen gießen, aber solch essentielle Dinge einfach vernachlässigen.

LG
Jürgen

@gschrick 

Servus Gerd,

wow das hört sich ja schon vielversprechend an.

Das heisst für mich es ist unerheblich mit welcher Vorlage das Ausgabe-Dokument erstellt wird, am Ende kommt jedes gewünschte (durch Vorlage definierte) Dokument heraus. Habe ich das so richtig kapiert?

Was aus meiner (österreichischen) Sicht noch wichtig wäre, sind einige extra Daten, die das Dokument zwingend enthalten muss, da ist dann wahrscheinlich Ralf (@rheydenr) gefragt, weil man die Datenbank etc damit ein wenig "aufbohren" muss. Grundsätzlich liesse sich das wohl in einer Dokumentvorlage einbauen, aber ich finde es als Datensatz aus Fakturama heraus 'eleganter', vor allem kann man es dann überall verwenden.

LG
Jürgen

@microangelo

Hallo Jürgen,

mit den bisherigen Vorlagen hat das alles garnix zu tun. Diese beziehen sich ja nur auf die Druckausgabe (.odt/.pdf Erstellung) und haben hier keine Bedeutung.

"Mein" Dokument-(XML-)Export greift ausschließlich auf die Daten "in Fakturama" (DB) zu, also die, welche auch die Datenbasis der Druckausgabe sind.
Daraus wird erstmal eine pure (=ohne Bezug zu irgendeinem Standard) "Fakturama-Dokument-XML" (einfach mal meine Bezeichnung dafür) XML-Datei erstellt, welche den aktuellen Datenstand des Dokuments und der referenzierten Datensätze (z.B. Empfänger->Kontakt) beinhaltet.
Dieses "Fakturama-Dokument-XML" ist widerum die einheitliche Rohdatenbasis für die optional anschließende XSLT-Tansformation, wodurch das eigentiche Zielformat erzeugt wird (z.B. eine X-Rechnung nach Standard xyz).

Zu den zusätzlichen Daten:
hier ist die geeignetste Strategie noch zu prüfen.
Mein derzeit bereits ja schon produktiv genutzer Ansatz mit den "EbeddedProperties" im Notizfeld der Kontakte ist (exemplarisch) eine Möglichkeit vorläufig ohne DB-Anpassung auszukommen (OK, hierfür habe ich natürlich die Oberfläche erweitert und eine eigene Version im Betrieb). Aber ...
basierend auf der Flexibilität mit XLST könnte man auch (vorläufig bzw. für Sonderfälle)
a) eigene "Vorlage(n)" (hier: XSLTs) haben/erstellen, welche diese Besonderheiten/Werte fix abbilden oder
b) diese variabel aus "irgendeinem" (freien) Feld beziehe/extrahieren (z.B. per 'Marker' identifizierbar im Notizfeld).

Mein Vorschlag wäre bezogen auf kontaktspezifische Daten: beim Kontakt ein zusätzliches "Notizfeld" in der DB zu haben, welches in der Oberfläche als variable Liste beliebiger Schlüssel-Wertepaare editiert werden kann (im DB-Feld abgebildet im Java Properties Format). Den Vorteil gegenüber einer eigenen Tabelle mit einzelnen Datensätzen sehe ich im Handling (keine zusätzlichen Abfragen/Updates in der DB-Schicht, sondern nur ein Feld mehr).
Diese Wertepaare werden strukturiert im "Fakturama-Dokument-XML" ausgegeben und können dann wozu-auch-immer in der XSLT-Transformation genutz werden.

Dokumentspezifische Zusatzdaten ließen sich ebenso abbilden - ob und inwieweit das Sinn macht, oder einfach nur ein/zwei zusätzliche Felder (z.B. "(Kunden)Referenz 2/3" für freie Nutzung als Projektnummer, Kostenstelle, ...) praktikabler sind ist zu klären.
Für alle möglichen Zusatzdaten eigene Felder anzubieten ist m.M. sicher nicht der Weg.
Evtl. auch einfach 1/2/3/4/... zusätzliche Freitextfelder, deren Label in den Einstellungen angepasst werden kann.

LG
Gerd

@gschrick

Hallo Gerd,

mit den bisherigen Vorlagen hat das alles garnix zu tun. Diese beziehen sich ja nur auf die Druckausgabe (.odt/.pdf Erstellung) und haben hier keine Bedeutung.

Ja soweit war mir das schon klar, ich habe mit "Vorlagen" eigentlich eine (Vorlagen)Datei gemeint in der die Struktur der notwendigen XML-Datei mit allen Datensätzen und Platzhaltern abgebildet ist. Also kurz und vereinfacht gesagt eine "XML-Vorlage"

Betreffend der zusätzlichen Daten muss man halt sehen, was sich einfacher Handeln lässt.

LG
Jürgen

@microangelo

Hallo Jürgen,

dann war mir nicht klar, dass es Dir klar war ... aber jetzt ist alles klar. (aufgrund beengter Platzverhältnisse am Rechner steht wohl öfter mal ne Rolle meines Bürostuhls auf meiner Leitung) 🤪 

LG, Gerd

@gschrick 

Du glaubst gar nicht wie oft MIR das im Büro passiert 😜 

Und dann liegt da noch der Hund vor/hinter/neben dem Bürostuhl .... 🤪