Ja, korrekt. Allerdings dachte ich, daß das nur zwischen Unternehmen gilt, nicht für B2C. Ich versuche, demnächst wieder etwas aktiver an Fakturama zu arbeiten...

Hallo Ralf,

richtig B2C Geschäfte sind davon ausgenommen. Aber sobald man nur ein Unternehmen im Kundenstamm hat, wird es ja schon relevant. Es gilt also in den Kundendaten ein Flag zur entsprechenden Unterscheidung zu haben. Insbesondere falls das künftig zu verwendende Datensatz nicht direkt lesbar seien sollte.

Genauso bei Kommunalverwaltungen und Behörden, da muss man Rechnungen ja evtl. sogar über ein Portal (künftig ggf. sogar über eine API) einreichen. Hier sollten entsprechende Zugangsadten/Schnittstellen ebenfalls in den Kundendaten hinterlegt werden können.

Da man bei den Zulieferern wohl fast ausnahmslos im B2B unterwegs ist, ist jedes Unternehmen von der Verpflichtung zu elektronischen Rechnungsannahme betroffen. Es wäre daher schön wenn man dies mit Fakturama abbilden könnte um nicht wieder eine extra Software dafür bemühen zu müssen... Die Grundlegende Voraussetzung ist mit den Kreditoren ja bereits gegeben. Von der am Ende des verlinkten Artikel erwähnten alternativen staatlichen eRechnungs-Plattform halte ich hingegen garnichts.

Schön zu hören das Du da bereits so zu sagen am Ball bist. Schade nur das hinsichtlich des Programmieraufwand (die Liste im Bugtracker +1 ist ja noch ziemlich Umfangreich) keine rechte Unterstützung da ist... Ich werde mir diesen Skill wohl leider nicht mehr drauf schaffen und kann daher nur meinen Senf dazu geben. 🧐 

Gruß
Matthew

Am 30.08.2023 wurde der Gesetzesentwurf im Bundeskabinett beschlosssen und durchläuft nun das weitere parlamentarische Verfahren: Aktuelles zur E-Rechnung

Update: Der Zeitplan für die Einführung der verpflichtenden E-Rechnung ist ungewiss...

Da es nun ja gar nicht mehr so ungewiss ist- wie macht, bzw. wie habt Ihr vor den E-Rechnungsempfang für 2025 zu lösen? Oder besteht die Möglichkeit das Fakturama das (zeitlich) schafft?

Ich bin auf Linux und möchte auch ungerne von OpenSource & Co. weg., allerdings wäre ich dennoch bereit für eine solche Lösung auch "was springen" zu lassen 🙂

Moin, der Empfang von Rechnungen ist momentan in Fakturama erst mal nur in Vorbereitung. Derzeit wird das Programm ja eigentlich nur zur *Erstellung* von Rechnungen verwendet. Das Einlesen von Rechnungen war nicht vorgesehen. Wir werden uns demnächst Gedanken machen, allerdings ist das sehr zeitintensiv und ich kann nicht sagen, ob das bis Januar durch ist...

@rheydenr 

Hallo Ralf,

ja, das es nicht mal "eben so" zu realisieren sein wird oder kann ist mir durchaus bewusst, macht das Problem aber leider auch nicht besser, ich sehe mich schon ab Januar mit einer "Windows Kauflösung" auf einer VM am rumdümpeln, Cloud kommt mir in dem Bereich wohl eher nich so in die Tüte...

Danke aber für die schnelle Antwort und die gute Unterstützung hier 🙂

Hallo,

wenn ich die Ausführungen zur e-Rechnung richtig verstanden habe, ist es ab 01/25 im B2B Bereich nur zwingend erforderlich e-Rechnung austellen und empfangen zu können.

D.h. dass der Versand und Empfang via e-Mail, downlod aus Kundenkonto oder ähnlichem möglich sein muss.

Die empfangene e-Rechnung muss dann nur dauerhaft gesichert und für die Finanzbehörden einlesbar/auswerbar gespeichert werden.

Bisher habe ich nichts gelesen, dass eingehende e-Rechnungen in eine Warenwirtschaft eigelesen werden müssen.

Bei einer hausinternen Buchhaltung sieht das dann wohl anders aus.

Bei Buchhaltung bei Dienstleister/Steuerberater wird es wohl eine Schnittstelle zur Übermittlung der erhaltenen e-Rechnungen geben.

e-Rechnungen kann Fakturama meines Wissens im Zug...-Format schon.

Grüße strobelix

Hallo Strobelix!

Nuja... "Empfangen" ist da genau der Knackpunkt- das sind XML Informationen, keine klassische Rechnung. Klar kann man die auch mit nem Editor öffnen und den Inhalt lesen, aber handlich oder übersichtlich ist das nicht und das ist damit sicher auch nicht gemeint.

Haken an der Sache aber ist ja das man damit auch ja irgendwie Arbeiten können muss und diese Informationen auch ggfls. verwalten muss- und wenn man das auch mit Fakturama machen könnte hätte man alles in einem, u.U. könnte man dann vielleicht sogar irgendwann Artikel, Seriennummern usw. aus einer Eingangsrechnung übernehmen, EK/VK gegenüberstellen und und 🙂

Alternativ wird auch an einem LibreOffice importer gearbeitet wie ich gelesen habe, aber dessen Stand ist mir noch unbekannt- aber selbst dann ist es immernoch viel "Handarbeit".

@Jochen hat da völlig recht! Es ist ja nicht damit getan, eingegangene eRechnungen an den Steuerberater weiterzuleiten (insofern man als Kleinunternehmen zur Erstellung einer EÜR überhaupt einen hat). Eingangsrechnungen müssen ja auch geprüft (Artikel, Mengen, Beträge etc.) und eine Zahlung veranlasst werden! Dafür müsste man sich also zwingend eine zusätzliche Anwendung besorgen, welche dann natürlich wieder eigenständig vor sich hin werkelt und naturgemäß keinerlei Datenaustausch mit Fakturama bietet. Es wäre also wesentlich besser wenn dies in Fakturama direkt integriert wäre. Neben den von Jochen bereits aufgezeigten Vorteilen könnte man dann beispielsweise auch Zahlungen veranlassen bzw. abgleichen (siehe Feature: #679) 🤗 

Übrigens mit dem Versand von eRechnungen könnte man sich noch etwas Zeit lassen (auch wenn dies Fakturama natürlich bereits seit längerem beherrscht). Zum Empfang derartiger Rechnungen ist man als Unternehmen aber bereits ab 1. Januar kommenden Jahres verpflichtet. Hier dazu nochmal die Fakten im Detail.

P.S. Wäre ebenfalls Bereit für eine solch umfangreiche Umsetzung von Feature-Wünschen etwas zu Spenden! 🖐️ 

@lastboyscout @jochen @strobelix @rheydenr

(( Posting, 2. Versuch ))

und jetzt ich mal wieder zu (m)einem Lieblingsthema 😉

erneut bezugnehmend auf diese, meine bisherigen Beiträge zu diesem Thema (eRechnungs Handling):

1. https://www.fakturama.info/community/postid/17906/
2. https://www.fakturama.info/community/postid/17924/
3. https://www.fakturama.info/community/postid/21143/
4. https://www.fakturama.info/community/postid/21147/

wage ich die Behauptung, dass dort bereits die Basis für eine zukunftsorientierte, flexible und v.a. praktisch machbare (z.T. durch Prototyp geprüfte) Lösung für Fakturama beschrieben ist.

(vorläufige) Ausnahme: Import der detaillierten Eingangsrechnungsdaten (Artikelpositionen etc.), da dies einen ganz erheblichen Komplexitätsgrad hat.

Lösungsansatz kurz skizziert (Details bitte in obig verlinkten Posts (v.a. 2.) nachschlagen):
(Anmerkung: die hier beschriebenen Aspekte/Schritte beziehen sich NICHT auf die Bedienung)

A) "Fakturama Dokument Objekt"
programminternes Java Objekt, welches alle zur Dokumenterstellung benötigten bzw. verfügbaren Daten bereitstellt. (Empfängerdaten, Positions-/Artikeldaten, Dokumentinfos (u.a. Rechn.Nr, Datum, Bemerkung, ...) etc.)
Dies existiert im Wesentlichen ja bereits und muss ggfs. für diesen Anwendungsfall nur ergänzt/angepasst werden.

B) "Fakturama Dokument XML" - eine Repräsentation von A) als XML-Dokument, welches ALLE Daten von A) beinhaltet, jedoch ohne jeglichen Bezug zu einem spezifischen Format wie z.B. "XRechnung".
Dieses "XML-Dokument" bezieht sich erstmal nur auf eine Datenstruktur innerhalb des Programmablaufes - also (noch) nicht zwingend als Datei im System.
Wenn bei A) berücksichtigt, kann die Erstellung dieser Datenstruktur generisch per "Java Reflection" erfolgen, wodurch zukünftige Änderungen an A) hier bereits "automatisch mitkommen".

Dokumenterstellung (z.B. e-Ausgangsrechnung)

C) Ziel-Dokumentgenerierung:
per "XSLT-Transformation" wird aus B) mithilfe eines "XSLT-Stylesheets" durch einen "XSLT-Prozessor/-Transformer" (Saxon HE im Prototyp) das gewünschte Zieldokument (z.B. X-Rechnung) erzeugt.

D) XSLT-Stylesheets (in XSLT-Transformation):
sind XML Dokumente im Dateisystem (Vorlagenordner) mit den Regeln (Anweisungen) für die Dokumenterstellung und sind zentraler Teil des Prozesses.
Einfach gesagt kann damit aus einem beliebigen XML-Dokument direkt ein beliebiges Textbasiertes Dokument (XML, HTML, JSON, PlainText, ...) erstellt werden.
(sehr vereinfacht) vom Prozess vergleichbar der "Dokumentvorlagen", welche die LibreOffice-/PDF-Dokumenterzeugung steuern.
Ebenso können jederzeit beliebig weitere Stylesheetdateien bereitgestellt/angelegt/kopiert/angepasst werden (z.B. kundenspezifische Anpassung oder neues/weiteres eRechnungsformat) OHNE das Programm zu ändern!

E) Erzeugen des physischen Dokuments:
je nach Bedarf, kann das in C) erzeugte Dokument weiterverarbeitet werden, z.B. als Datei gespeichert oder zur Erstellung des PDF (Zugferd) genutzt werden.

XML-Eingangsdokument Verarbeitung (v.a. "Lesbarmachung")

F) per XSLT-Stylesheet wird das (standardisierte) Eingangsdokument zum "Fakturama Dokument XML" transformiert ...

G) ... und kann nun mit denselben Prozessen von D) + E) in ein "menschenlesbares Format" überführt werden - z.B. HTML und im (fakturamainternen) Browser angezeigt werden (siehe dazu oben Link 2.: im Prototyp-Beispiel Scrennshot unten rechts).
Somit liegt nun zum XML-Eingangsdokument auch eine menschlesbare Datei vor.
Die Weiterverarbeitung des Eingangsdokuments (z.B. Rechnung) erfolgt nun (erstmal) wie bisher manuell.

Anmerkung zu F): falls Eingangsdokumente nicht datenkompatibel zum "Fakturama Dokument XML" sind (also relevante Daten enthalten, welche nicht in Fakturama abgebildet werden können/sollen), kann dieser Schritt entfallen und in G) muss direkt das Eingangsformat verarbeitet werden.

Fun-Fact: Seiteneffekt ist, dass F) und G) praktisch eine Konverterfunktion darstellen, wodurch eine (externe) eRechnung sogar in ein anderes eRechnungsformat konvertiert werden könnte. 😉

XML-Eingangsdokument Verarbeitung (zukünftige Erweiterung "Importieren")

H) aus dem aus F) resultierenden "Fakturama Dokument XML" wird ein "Fakturama Dokument Objekt" generiert (müsste generisch machbar sein - (noch) nicht getestet / nicht Teil des Prototyps)

I) programminterne Verarbeitung des Objekt und ggfs. faktischer (Teil)Import der Daten.

Fazit und Vorteile

durch die Verlagerung der eigentlichen (XML-)Dokumenterzeugung/-Verarbeitung aus dem statischen Programmcode in den generischen Transformationsprozess wird OHNE Programmupdate (wie bei den Dokumentvorlagen) erreicht:
- Nutzung offener und bewährter Standards
- unabhängig von spezifischen Programmbibliotheken zur eRechnungsgenerierung (was, wenn z.B. gesetzlich geforderte Änderungen nicht zeitnah implementiert werden?)
- neue eRechnungsformate/-versionen bereitstellbar
- anpassbare eRechnungsformate (z.B. kundenspezifische Ergänzung von Daten die nicht in Fakturama sind; z.B. Referenznummern o.ä.)
- flexible/individuelle Validierung durch entsprechende XSLT-Stylesheet Regeln (ggfs. kundenspezifisch)
- pragmatische "ad-hoc" Fixes wie z.B. "Rundungsfehler" (1Cent Differenz) welche zu Rechnungsabweisung führen (jaja, sollte irgendwann im Programm gefixt sein)
- andere textbasierte Formate möglich (z.B. HTML)
- länderspezifische Formate nach Bedarf
- generische XML-Verarbeitung von Eingangsdokumenten (Lesbarmachung, Konvertierung und zukünftiger Weiterverarbeitung)

Der Implementierungsaufwand sollte "überschaubar" sein (Basisfunktionen bereits im Prototyp verfügbar)

Aber (m.M. einziger "Nachteil")

Hauptaufwand ist die (initiale, produktionsreife) Implementierung der benötigten XSLT-Stylesheets.
Nachdem dies aber systembedingt von der Fakturama-Programmierung (Versionsupdates) entkoppelt ist, könnte das auch von Nicht-(Java-)Programmierern gemacht werden und (wie bei den Dokumentvorlagen) stückweise ergänzt / finalisiert und per Download "verteilt" werden.

So, war nun viel Text, aber ich hoffe, dass die Idee / das Konzept damit nachvollziehbar ist.

Cheers, Gerd

Ich muss zugeben das es mir ein wenig Mühe bereitet den Inhalt zu verstehen, da ich weder mit Java noch mit XSLT Stylesheets jemals gearbeitet habe, aber ich denke die Idee dahinter ist mir klar.

Kurz: klingt für mich sehr plausiblel und flexibel 🙂

Allerdings stellt sich mir dann die Frage was denn dagegen spräche, oder sind die Hauptentwickler da einfach noch nicht wirklich "drin" in der Sache?

Mal am Rande- (wie) ist die Ablage der Daten denn dann auch GoBD konform? Ich weiß, anderes Thema, aber bei dem ganzen Gesetzwirrwarr bekomme ich langsam Kopfschmerzen.

Der von @gschrick aufgezeigte Lösungsansatz scheint mir sehr vielversprechend... zumal es die Fakturama zugrundeliegende Idee der Dokumentvorlagen aufgreift und die Ausgabe von eRechnungen damit flexibel angepasst werden kann, ohne auf Änderungen am Programm selbst angewiesen zu sein. Evtl. sollten wir an dieser Stelle besser von "eBelegen" sprechen, schließlich ließen sich damit auch andere Dokumente in ein elektronisch verarbeitbares Pendant konvertieren.

Gerd hat da ja offenbar bereits eine selbst angepasste Version im Produktiven Betrieb laufen. Vielleicht könnte @rheydenr mal mitteilen ob dies auch aus seiner Sicht ein gangbarer Weg wäre, um das innerhalb der vom Gesetzgeber vorgegebenen Frist umsetzten zu könne!?

Bei der Umsetzung sollten Anforderungen an das zukünftig geplante Umsatzsteuer-Meldesystem gleich mit gedacht werden. OFF-Topic: Eigentlich vergeht mir da langsam die Lust an der Selbstständigkeit, bedeutet all das für Unternehmer doch immer mehr Aufwand und nicht weniger 🤢 

@jochen Die Aufbewahrungspflichten gem. GoBD sind ja auch so eine leidige Sache. Fakturama selbst dahingehend Fit zu machen, wird m.E. unverhältnismäßigen Aufwand bedeuten. Nichts desto trotz ist es ja aber in der Lage erstelle Belege an ein entsprechendes Dokumentenmanagementsystem zu übergeben. In Bezug auf den Empfang von eRechnungen sind diese übrigens unveränderbar im Ursprungsformat für 10 Jahre zu Archivieren.

Analog zur Ausgangsbelegen sollte man in Fakturama dann auch einen Pfad für importierte Eingangsbelege angaben können, welcher im DMS wiederum als Inbox definiert werden kann. Sofern der Import von eBelegen in Fakturam integriert ist, wäre es überdies wünschenswert auch die Zugangsdaten für ein gesondertes Mailpostfach zum Abruf der Eingangsbelege hinterlegen zu können.

Moin zusammen, das ist ja hier schon eine ziemlich rege Diskussion 🙂 Also, ich bin in dem Thema schon mit drin. Allerdings mache ich das nach wie vor nur in meiner Freizeit, deswegen helfen da Spenden auch nur begrenzt etwas (obwohl sie immerhin für die Deckung der Kosten für Server und Mac-Lizenz sehr hilfreich sind). Inzwischen arbeiten sowohl @gschrick als auch @boarschti an dem Thema. Es wird also definitiv noch was fertig, aber ich werde hier keine Zeitleiste veröffentlichen (können). Aktuell bin ich selber noch am Testen der neuen Version. Die funktioniert in weiten Teilen schon ziemlich zuverlässig, aber ich bin trotzdem noch nicht ganz durch damit.

Die Ausführungen von @gschrick sind tatsächlich nur was für Entwickler ==> hier sollten wir allerdings nochmal abseits dieses Threads im Entwicklerforum diskutieren. Mit Reflection stehe ich auf Kriegsfuß, das möchte ich nicht im Code haben. Ansonsten entspricht das so ungefähr dem, was sich auch @boarschti ausgedacht hat. Damit kann ich im großen und ganzen mitgehen. Oberstes Ziel ist aber jetzt tatsächlich erst mal das Release der aktuellen Version.