Naja, es ist bereits jetzt eine E-Rechnungs-Implementation im Programm vorhanden. Wir zum Beispiel nutzen die seit Anfang des Jahres. Seitdem habe ich keine Rückmeldungen von irgendjemandem bekommen, der nicht mit unseren E-Rechnungen zufrieden gewesen wäre. Ich speise die zum Beispiel auch ins Portal zur Zusammenarbeit mit dem Steuerberater ein, und sie werden dort hübsch automatisch ausgelesen und weiterverarbeitet.

Es mag immer Leute mit erweiterten Anforderungen geben, aber für einfach gelagerte Unternehmen ist Fakturama hinsichtlich E-Rechnung auch jetzt schon definitiv brauchbar.

Die E-Rechnung funktioniert eigentlich super, nur die aktuelle Beta ist für diesen Zweck nicht nutzbar, da muss noch ein wenig was gefixt werden. Hoffe das der nächste Snapshot bald kommt, solange habe ich erst mal umgestellt und nutze erst mal nur die PDF Rechnung. 

Moin,

bei der allerersten Installation von Fakturama konnte ich ganz problemlos E-Rechnungen erstellen, dann habe ich Java und Libre-Office aktualisiert und seitdem geht es nicht mehr... Da kommt immer folgende Fehlermeldung:

Error starting OpenOffice with Rechnung.ott in: com.sebulli.fakturama.office.OfficeDocument#postProcess (354)
Document couldn't be created. Reason: Error starting OpenOffice with Rechnung.ott in: com.sebulli.fakturama.office.OfficeDocument#createDocum...
Exception occured: in: com.sebulli.fakturama.office.OfficeDocument#postProcess (354)

Wobei der Fehlercode 354 auch mal anders sein kann, 351 oder so. Office-Einstellungen und ZUGFeRD-Einstellungen sollten soweit korrekt sein. Ich hatte zwischenzeitlich auch die Beta 2.2 ausprobiert, aber auch dort dasselbe Problem.

Gibt es dazu schon eine Lösung oder einen Zeitplan? Danke vorab!

Zunächst kann ich mir ja noch mit der normalen PDF-Rechnung behelfen, aber perspektivisch wird es ohne E-Rechnung ja nicht mehr gehen.

Moin, ich bin gerade dabei, eine neue Beta zusammenzubauen. Das genannte Problem hier könnte auch daran liegen, daß was mit dem XRechnung-Export nicht stimmt. Da ist leider die Fehlermeldung wenig hilfreich. Das wurde aber in der aktuellen Version verbessert. Ich schreib das wieder in die News, wenn die neue Version da ist.

Veröffentlicht von: @rheydenr

↑

Moin, ich bin gerade dabei, eine neue Beta zusammenzubauen. 

Gibt es schon einen ungefähren Termin, wann die neue Beta online zur Verfügung steht? 

Nachtrag: Ich habe es eben mit der neuen Beta ausprobiert und es wurde eine ZUGFeRD-Rechnung mit meinem selbstgebauten Layout erzeugt, die auch Ultramarin-/Quba-lesbar ist! Ich werde das morgen noch weiter testen, aber wenn das jetzt wirklich so funktioniert wäre das wirklich super! Allen Entwicklern einen ganz herzlichen Dank!

😊

So, heute mal ein wenig weiter ausprobiert, es sind mir auf jeden Fall noch 2 Problemkomplexe aufgefallen, zumindest der eine wurde auch schon im Forum diskutiert:

- BT-73 wird um einen Tag zurückversetzt

- USt wird zwar, wie auch Rabatte, korrekt berechnet und in der XML dargestellt, nicht jedoch in der ODT-Datei (unabhängig von der Formularversion), siehe Anhang

Außerdem spucken unterschiedliche Validatoren unterschiedliche Meldungen aus, aber das beunruhigt mich jetzt noch nicht groß (und dass die Ländercodes nicht leer bleiben sollen wurde ja auch schon irgendwo im Forum angesprochen).

Hier E-Rechnungs-Checker:

Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}CountryID': [facet 'enumeration'] The value '' is not an element of the set {'AD', 'AE', 'AF', 'AG', 'AI', 'AL', 'AM', 'AO', 'AQ', 'AR', 'AS', 'AT', 'AU', 'AW', 'AX', 'AZ', 'BA', 'BB', 'BD', 'BE', 'BF', 'BG', 'BH', 'BI', 'BJ', 'BL', 'BM', 'BN', 'BO', 'BQ', 'BR', 'BS', 'BT', 'BV', 'BW', 'BY', 'BZ', 'CA', 'CC', 'CD', 'CF', 'CG', 'CH', 'CI', 'CK', 'CL', 'CM', 'CN', 'CO', 'CR', 'CU', 'CV', 'CW', 'CX', 'CY', 'CZ', 'DE', 'DJ', 'DK', 'DM', 'DO', 'DZ', 'EC', 'EE', 'EG', 'EH', 'ER', 'ES', 'ET', 'FI', 'FJ', 'FK', 'FM', 'FO', 'FR', 'GA', 'GB', 'GD', 'GE', 'GF', 'GG', 'GH', 'GI', 'GL', 'GM', 'GN', 'GP', 'GQ', 'GR', 'GS', 'GT', 'GU', 'GW', 'GY', 'HK', 'HM', 'HN', 'HR', 'HT', 'HU', 'ID', 'IE', 'IL', 'IM', 'IN', 'IO', 'IQ', 'IR', 'IS', 'IT', 'JE', 'JM', 'JO', 'JP', 'KE', 'KG', 'KH', 'KI', 'KM', 'KN', 'KP', 'KR', 'KW', 'KY', 'KZ', 'LA', 'LB', 'LC', 'LI', 'LK', 'LR', 'LS', 'LT', 'LU', 'LV', 'LY', 'MA', 'MC', 'MD', 'ME', 'MF', 'MG', 'MH', 'MK', 'ML', 'MM', 'MN', 'MO', 'MP', 'MQ', 'MR', 'MS', 'MT', 'MU', 'MV', 'MW', 'MX', 'MY', 'MZ', 'NA', 'NC', 'NE', 'NF', 'NG', 'NI', 'NL', 'NO', 'NP', 'NR', 'NU', 'NZ', 'OM', 'PA', 'PE', 'PF', 'PG', 'PH', 'PK', 'PL', 'PM', 'PN', 'PR', 'PS', 'PT', 'PW', 'PY', 'QA', 'RE', 'RO', 'RS', 'RU', 'RW', 'SA', 'SB', 'SC', 'SD', 'SE', 'SG', 'SH', 'SI', 'SJ', 'SK', 'SL', 'SM', 'SN', 'SO', 'SR', 'SS', 'ST', 'SV', 'SX', 'SY', 'SZ', 'TC', 'TD', 'TF', 'TG', 'TH', 'TJ', 'TK', 'TL', 'TM', 'TN', 'TO', 'TR', 'TT', 'TV', 'TW', 'TZ', 'UA', 'UG', 'UM', 'US', 'UY', 'UZ', 'VA', 'VC', 'VE', 'VG', 'VI', 'VN', 'VU', 'WF', 'WS', 'YE', 'YT', 'ZA', 'ZM', 'ZW'}.

Hier Valitool:

Das XML ist nicht valide.

Profil: urn:cen.eu:en16931:2017
Korrekte XML Struktur: Nein
Korrektes XML Schema: OK
Korrekte XML Namespaces: OK
Korrekte XML Kodierung: OK
Korrekte Code Listen: Nein
Gibt es Warnungen? Ja

Details

[BR-CL-14]-Ländercodes müssen aus der ISO Codeliste 3166-1 stammen.
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID

---

[BR-09]-Eine postalische Anschrift des Verkäufers "SELLER POSTAL ADDRESS" (BG-5) muss einen Verkäufer-Ländercode "Seller country code" (BT-40) enthalten.
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID

---

[VD-Valitool-126]-Hinweis: Es wurde ein leeres Element übergeben z.B. . Dies kann bei einigen Zielsystemen zu Problemen führen. Sie sind leere Elemente z.B. bei der Übermittlung der Rechnung über das Peppol-Netzwerk nicht zulässig.
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID

---

[VD-Valitool-17b]-Das Element oder Attribut (E-Mail-Adresse der Kontaktstelle des Käufers, BT-58) soll im Format urn:cen.eu:en16931:2017 nicht verwendet werden.
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:DefinedTradeContact/ram:EmailURIUniversalCommunication/ram:URIID/@schemeID

---

[BR-CO-26]-Damit der Erwerber den Lieferanten automatisch identifizieren kann, soll der "Seller identifier" (BT-29), der "Seller legal registration identifier" (BT-30) oder der "Seller VAT identifier" (BT-31) vorhanden sein.

---

Hier Mustang:

Das XML ist nicht valide.

Profil: urn:cen.eu:en16931:2017
Bestandene Regeln: 158
Gescheiterte Regeln: 2

Details

Error
[BR-CO-26]-In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present. [ID FX-SCH-A-000001] from /xslt/ZF_233/FACTUR-X_EN16931.xslt)
/*:CrossIndustryInvoice[namespace-uri()='urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100'][1]/*:SupplyChainTradeTransaction[namespace-uri()='urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100'][1]/*:ApplicableHeaderTradeAgreement[namespace-uri()='urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100'][1]/*:SellerTradeParty[namespace-uri()='urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100'][1]

---

Error
[BR-09]-The Seller postal address (BG-5) shall contain a Seller country code (BT-40). [ID FX-SCH-A-000018] from /xslt/ZF_233/FACTUR-X_EN16931.xslt)

/*:CrossIndustryInvoice[namespace-uri()='urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100'][1]

Ich hoffe, das hilft ein wenig weiter. Wie gesagt, die Validierung spielt für mich noch ne total untergeordnete Rolle. Das mit der USt im Rechnungsformular werde ich einfach vorerst über Info-Texte lösen ("Ihre Rechnung enthält x€ n% und y€ m% USt.") und der Leistungszeitraum ist jetzt auch nicht so dramatisch, den lasse ich einfach erstmal aus dem Formular raus. So kann ich nämlich schonmal produktiv mit Fakturama starten, das freut mich sehr!

Wichtig wären hier immer die Beispiele. Das, was wir da bekommen, ist gut, aber es ist im Fakturama fast alles freiwillig. Die Pflichtsachen für die ERechnung werden noch eingebaut. Probier doch mal, ein Land im Programm zu hinterlegen (Einstellungen -> eigene Firmendaten). Dann sollte der Fehler weg sein. Die Datumssachen hab ich korrigiert. 

Für das ODT Template ist (NOCH) jeder selber verantwortlich. Da haben wir nix mit zu tun. 

Grüße

Boarschti

Diese Platzhalter werden nicht ausgefüllt (gelb markiert aus der mitgelieferten Standard-Vorlage für Rechnungen: VATLIST.DESCRIPTIONS und VATLIST.VALUES), siehe Anhang. Land habe ich eingetragen, aber das ändert nichts. Will allerdings auch nicht ausschließen, dass der Fehler vielleicht gar nicht reproduzierbar ist...

da müssen wir die Vorlage nochmal anpassen. Änder die mal bitte so, das das eine eigene kleine tabelle ist, dann gehts auch 🙂 ... ich check das nachher nochmal

@boarschti Das hat tatsächlich funktioniert, vielen Dank! 🤗

Nachtrag: Ich hatte das Problem mit der Umsatzsteuer bei mehreren USt-Sätzen in einer Rechnung, dass weitere Zeilen dann einen Rahmen bekommen. Hier ist ein Workaround beschrieben, der funktioniert:

https://www.fakturama.info/community/postid/18673/

Nachtrag 2: Ich habe mal einen Screenshot angehängt, wie ich es jetzt hingebastelt habe. Dazu noch einen Screenshot mit den entspr. Platzhaltern, die Tabelle für USt, Netto- und Bruttosumme besteht aus 3 verschiedenen Tabellen.

So, ich habe mir das jetzt alles schön so konfiguriert, dass es mir die Arbeit wirklich leicht macht:

- zweiten Mandanten angelegt

- für beide Mandanten jeweils die Vorlagen erstellt

- die start.html mit jeweiligen Logos und Links zu wichtigen Ordnern versehen (PDF's, Vorlagen, Excel-Tabellen, sonst. Daten - auch das Handbuch ist hier verlinkt und wird im Editorfenster geöffnet)

- Kundenstämme angelegt und exportiert/importiert

- Artikel angelegt

Ich nutze Fakturama jetzt schon produktiv. Die Arbeit geht wirklich wahnsinnig leicht und intuitiv von der Hand! Das Hin- und Herwechseln zwischen den Mandanten ist kein Problem, es erscheint zwar ab und an eine Fehlermeldung, aber die ist sofort wieder weg (daher kein Screenshot). Verschiedene Dinge wie Textfeld 3 für die Mahnkosten funktionieren sehr gut, wenn man die Vorlagen selbst gebaut hat natürlich erst recht. Hier fehlt höchstens eine Funktion für eine Mahn-Fristsetzung, die kann man aber natürlich über Makros oder Formeln in versteckten Tabellen lösen, hab ich erstmal aufgeschoben, da nicht drängend. Wahrscheinlich mache ich es einfach eh dauerhaft über Textfeld 2.

Allerdings ist mir aufgefallen, dass die Storno-Rechnungen keine E-Rechnungen sind. Das nur noch als kleiner Hinweis, für mich aktuell nicht wichtig, ich drucke dann notfalls Storno-Rechnungen einfach über den normalen Rechnungsdialog mit eigener Storno-Rechnung-Vorlage und der Eingabe der Bezugsrechnungsnummer von Hand.

Als nächstes werde ich mal die eMail-Funktionalität ausprobieren. 🙂 

E-Mail-Versand funktioniert auch alles, allerdings wird der Text aus der TXT-Datei doppelt eingefügt, einmal mit Umbrüchen und einmal ohne. Stört aber ja nicht weiter.

@arne_ps Hast du die Start.html auch veröffentlicht?