Sorry für die späte Antwort, ich muß mich da erst mal schlau machen. Möglicherweise gibt es da eine Lücke.

So, hab mich schlau gemacht. Das ist tatsächlich ein Fehler im Programm. Das schreibt nämlich ein falsches Kennzeichen in die VAT-Liste ("Zero"). Dort muß was andres drinstehen ("E"). Das muß ich umgehend reparieren.

Das Problem tritt in Fakturama 2.1.3 leider unverändert auf.

Leider muss ich dies bestätigen. Sobald in den Firmendaten das Feld USt-IdNr. leer ist und stattdessen das Feld Steuernummer verwendet wird, wird keine valide XRechnung XML generiert. Die Steuernummer taucht nicht auf. Vermutlich wird dies nur deshalb nicht in der Masse auffällig, da nur wenige Kleinstunternehmer zwingend solche Rechnungen erstellen müssen. Diejenigen jedoch, wären alle sicher äußerst dankbar für einen Fix des Problems.

Herzlichen Dank!

Version: 2.1.3-SNAPSHOT
Build-ID: 20221216-0937
Java-Version: 17.0.1

Hallo,

ich bin auch Kleinunternehmer und ebenfalls auf dieses Problem gestossen. Gibt es einen Zeitraum, wann das Problem gefixt wird? Leider finde ich dazu auch nichts im Bugtracker.

Vielen Dank!

Version: 2.1.3-SNAPSHOT
Build-ID: 20221125-2128
Java-Version: 17.0.1

und bei mir erscheint diese Fehlermeldung... was kann das für eine Ursache haben?

Hey, 

ich werd mich diesem spätestens in der nächsten hauptversion annehmen (XRechnung 3.0), die Steuernummer bekomm ich aber bestimmt noch in die 2.2.0 rein 🙂

Hallo @boarschti

zum Kontext "zukünftige Fakturama-Erweiterung/-Entwicklung bzgl. eRechnungen" (XRechnung, ZUGFeRD, ...) hier der Verweis auf folgenden Beitrag, insbesondere ab diesem Post: https://www.fakturama.info/community/postid/17906/

Dort beschreibe ich eine hochflexible Lösung via XML/XSLT, wodurch dann jedes beliebige (eRechnungs)Format erzeugt werden kann, OHNE Fakturama Programm-Update (solange sich das Datenmodell nicht relevant ändert). Kunden-, Länder- sowie Versionsspezifika sind dadurch auch individuell und kurzfristig realisierbar, ebenso zuküftige Formatanpassungen/-anforderungen.

Dies nurmal erwähnt, bevor hier umfangreichere Erweiterungen (neue eRechnungsversionen) "fest verdrahtet" werden.

Bei Fragen einfach melden 🙂

Grüße, Gerd

Hay, ich hab sowas außerhalb von Fakturama schon live im Einsatz. Das hat alles seine Vor- und Nachteile. Das ganze im Fakturama wird in der nächsten Version eingebaut, wie? tbd! . 

Ich mach genau das gleiche auch Hauptberuflich. Sollte nicht sooo wild sein das umzusetzen 🙂

@boarschti

ob und wann das in die "offizielle" Fakturama Version kommt, obliegt nicht mir 😉

Wie im bereits verlinkten Thread in diesem Post: https://www.fakturama.info/community/postid/17924/ beschrieben, liegt ein funktionierender Proof-of-concept in "meiner Version"* ( https://bitbucket.org/fakturamadev/fakturama-2/branch/develop-GS21x ) bereits vor.
* diese ist hier täglich produktiv im intensiven Einsatz.

somit: der dazu benötigte Anteil in Fakturama ist m.M. "überschaubar" und relativ einfach/schnell machbar (Detailabstimmung erforderlich).
Der Anteil außerhalb Fakturama, also Erstellen der XSLT Stylesheets für die benötigten Formate ist der m.M. aufwändige Aspekt dabei.
ABER (und das ist der Hauptvorteil): dazu ist dann kein Programmupdate mehr erforderlich (Voraussetzung: die Daten sind in Fakturama verfügbar/abbildbar; läuft ja im Prinzip wie mit den Dokumentvorlagen). Und wenn die ersten Stylesheets mal für die XRechnung stehen, sind Anpassungen (z.B. für neue Versionen) eher "Kleinkram".

Angemerkt sei noch, dass dies auf ein paar anderen Features "meiner Version" basiert (welche dann auch zu intergrieren sind)
z.B.: auf Kundenebene ob eRechnung erstellt werden soll und wenn ja, welches Format und "Custom Fields" (benutzerdefinierte Felder)

Nachteile? vielleicht, dass das ein "Killer-Feature" werden könnte (v.a. wenn die Gesetzgeber die Erstellung vermehrt zur Verpflichtung machen) 🤣  ... verschiedene Formate ... individuell (wenn nötig je Kunde) anpassbar ... Formatabweichungen für andere Länder möglich ... evtl. sollten wir daraus ein Bezahl-Feature machen? 🤡