Moin, stehen in ~/.fakturama2/.metadata/.log (bei Linux / Mac OS) bzw. %USERPROFILE%\.fakturama2\.metadata\.log
irgendwelche Hinweise? Man kommt da auch über Hilfe -> Über Fakturama -> Installation Details -> Configuration -> View Error Log ran.

Wird generell überhaupt ein PDF erzeugt? Oder ist da gar nichts da?

@rheydenr :

Im in den Einstellungen definierten Exportverzeichnis für die ZUGFeRD/X-Rechnungen wird nichts erzeugt.

"Spaßeshalber" habe ich aber mal die PDF-Rechnung aus dem regulären Dokumentenverzeichnis in den Validator der ZUGFeRD-Community hochgeladen und prüfen lassen.

Interessanterweise scheint im Dokumentenpfad die Rechnung im gewählten ZUGFeRD Format erzeugt zu werden, hier die Ergebnisse des Validators:

Das ZUGFeRD-PDF ist valide.
Profile: PDF/A-3B validation profile
Statement: PDF file is compliant with Validation Profile requirements.
Signature: unknown
Passed checks: 7893
Passed rules: 124
Failed checks: 0
Failed rules: 0

ABER:
Das ZUGFeRD-xml ist nicht valide.
Profile: urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.1
[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ?EL?. (From /xslt/cii16931schematron/EN16931-CII-validation.xslt)

Ich bin Kleinunternehmer nach § 19 UStG. Und ich habe keine Umsatzsteuer-ID.
Das ist wahrscheinlich die Ursache.
Gibt es hier schon eine Lösung bzw. einen Workaround?

Das Logfile sagt diesbezüglich gar nichts.
Aber dort findet sich ein anderer Eintrag, ich lade den Auszug aus dem Logfile als Textdatei hoch.
Es beinhaltet alle Meldungen seit dem letzten Start, inkl. Rechnungserzeugung.

Veröffentlicht von: @marka

↑

Ich bin Kleinunternehmer nach § 19 UStG. Und ich habe keine Umsatzsteuer-ID.
Das ist wahrscheinlich die Ursache.
Gibt es hier schon eine Lösung bzw. einen Workaround?

Kann stattdessen nicht die Steuernummer verwendet werden?

Ich kenne mich als Österreicher mit ZUGFeRD nicht so gut aus. Bei der e-Rechnung in Österreich kann man entweder Steuernummer oder UID verwenden.

@microangelo :
Hierzu gibt es schon im Unterforum "Fehler und Verbesserungsvorschläge" einen Beitrag:
https://www.fakturama.info/community/postid/18624/

Ist wohl ein bekannter Bug, aber daran wird bereits gearbeitet.

Es handelte sich um einen Irrtum meinerseits!
Das am regulär definierten Speicherort abgelegte PDF-Dokument IST bereits im ZUGFeRD Format vor.
Ich bin davon ausgegangen, dass es wie in den Vorversionen in einem separaten Verzeichnis abgelegt wird.

Ok, damit ist praktisch nur noch der Validierungsfehler. Irgendwas muß noch mit der Umsatzsteuer-ID gemacht werden. Ich seh mal zu, daß ich da was rausbekomme.

Hallo,

ich habe gerade das gleiche Problem. Allerdings wird bei mir gar keine PDF (mehr) erzeugt.

Habe in LibreOffice auf PDF/A-3b gestellt. Bei den Zugpferd Einstellungen kann ich gar kein Haken eintragen,

sieht für mich aber nur nach Darstellungsfehler aus. Wie kann ich vorgehen?

Nachtrag: .xml wird jetzt erzeugt. Es lag daran, dass ich Leerzeichen in der IBAN hatte.

Kurzfristig ging das erzeugen von PDFs, jetzt allerdings wieder nicht mehr.

Spielt aber auch keine Rolle, weil ich die ODT eh nachbearbeite und dann als PDF ausgebe.

Moin Markus,

das Problem könnte an einer fehlerhaften Konfiguration oder einem Bug in der Fakturama-Version liegen. Du könntest prüfen, ob alle nötigen Bibliotheken für den ZUGFeRD-Export vorhanden sind. Eventuell hilft es auch, Fakturama auf die neueste stabile Version zu aktualisieren, da SNAPSHOT-Versionen manchmal noch nicht vollständig getestet sind. Falls das nicht hilft, schau mal, ob die LibreOffice-Einstellungen richtig mit Fakturama kommunizieren und der richtige Exportordner festgelegt ist.

Beste Grüße!

@schmidts1981 :
Danke, das Thema war bereits erledigt.

Zum Thema Validität:

In der zitierten Ausgabe des Validators steht "The Seller VAT identifier ... shall have a prefix ...".
Normalerweise wird in Standards das Wort "shall" verwendet, wenn der Wert etwas (sein) "soll".
Für "müssen" stünde da ein "must" oder "has to be".

Insofern müsste das XML eigentlich valide und der "Fehler" eigentlich nur eine Warnung sein...

@york Asche auf mein Haupt, das hatte ich offenbar nicht mehr korrekt im Kopf.

Habe gerade nochmal das RFC zur Sprachdefinition in RFCs gelesen, da steht es tatsächlich so drin.

Grüßigkeiten
                Olaf

Und damit wir alle es mal wieder frisch in Erinnerung haben:

. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.





Bradner                  Best Current Practice                  [Page 1]

RFC 2119                     RFC Key Words                    March 1997


. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)