[gelöst] E-Rechnungen Pflicht ab 2025

25. April 2024 08:54

Hallo zusammen,

ab 2025 ist man verpflichtet in der Lage zu sein E-Rechnungen empfangen und verarbeiten zu können.
AB 2028 dann auch in Lage sein E-Rechnungen zu erstellen.

Also Format würde grundsätzlich XRechnung oder ZugFeRD gehen.

Ist dies mit NAV 5.0 möglich? XML-Port hat NAV 5.0 ja bereits.
Nur haben wir bisher mit XML-Port noch nichts gemacht.

Viele Grüße
Zuletzt geändert von dai am 10. August 2024 10:55, insgesamt 1-mal geändert.

Re: E-Rechnungen Pflicht ab 2025

25. April 2024 09:07

Hallo,

also den XML-Port würde ich an dieser Stelle mal vergessen, insbesondere in NAV5.
Da wirst du dich mit native MSXML als COM- Objekten herumschlagen müssen (was NAV an der Stelle meistens auch tut), wenn du es denn in NAV5 machen möchtest/musst.

Denn das Problem wir weniger das Verarbeiten der Daten sein, sondern der Transfer/Empfang.

Gruß Fiddi

Re: E-Rechnungen Pflicht ab 2025

25. April 2024 09:12

Hallo,

also wir müssen leider mit NAV 5.0 machen.
Herumsclagen heiss aber nicht das es nicht geht oder?:-)

Oder gibt es da eine andere Möglichkeit XRechnung oder ZugFerd in Navisuin zu verarbeiten?

Gruß

Re: E-Rechnungen Pflicht ab 2025

25. April 2024 09:25

Hallo,

ob es geht oder nicht kann ich nicht sagen. Ich weiß nicht wie weit MSXML in NAV5 unterstützt wird, und wie weit XRechnung oder ZugFerd die letzten XML- Features benötigen.
Grundsätzlich möglich ist es sicherlich, denn XML ist NUR eine Text-Datei, die kannst du im Zweifelsfall auch "von Hand" in C/AL zerpflücken. Die Frage ist nur, wie hoch der Aufwand ist.

Gruß Fiddi

Re: E-Rechnungen Pflicht ab 2025

25. April 2024 09:30

Es gibt zumindest Anbieter ab NAV 2009 Classic Client. Eventuell reicht denen ja auch ein technisches Update, damit u.a. .NET und Webservices in der alten Mühle laufen. Einfach nachfragen, siehe Liste hier.
.NET Interoperability in NAV 2009 R2

Re: E-Rechnungen Pflicht ab 2025

25. April 2024 11:18

Kowa hat geschrieben:Eventuell reicht denen ja auch ein technisches Update

Mein heutiger Arbeitgeber war damals auch auf NAV 5.0 gestartet und hatte zu einem späteren Zeitpunkt dann einfach nur ein technisches Update auf NAV 2009 R2 durchgeführt, um die "neuen Technologien" in unserer "alten" Datenbank nutzen zu können.

Der Umgang mit XML-Dateien ist technisch auch mit noch älteren Versionen möglich, denn mein damaliger Arbeitgeber konnte schon in Navision 4.x (oder evtl. schon unter 3.x) Datenaustausch im XML-Format unterstützen.

Es ist also keine Frage nach der technischen Machbarkeit, sondern nur nach dem zeitlichen Aufwand, welcher entsprechend hohe Entwicklungskosten verursachen kann.

Ich hinterfrage jetzt nicht, warum man im Jahr 2024 noch NAV5.0 (aus den Jahren 2007/2008) einsetzt, denn dafür könnte es unter Umständen gute Gründe geben.
Wenn ihr bis 2025 euer NAV5.0-System E-Rechnungs-kompatibel haben müsst, dann wird das zum gegenwärtigen Zeitpunkt (04/2024) schon sportlich. (Konzeptionierung, technische Spezifizierung, Programmierung, Tests, Korrekturen, ..., Dokumentation, Schulungen, ...)

Re: E-Rechnungen Pflicht ab 2025

26. April 2024 08:54

Timo Lässer hat geschrieben:Es ist also keine Frage nach der technischen Machbarkeit [...]

Je nach externem Modul ist es das schon, wenn die Dateien manipulationssicher weiterverarbeitet werden sollen. Da können denn Komponenten notwendig sein, die man in den alten Versionen nicht findet.
XML-Dateien kann man auch schon unter DOS mit Navision "blau" erzeugen und verarbeiten, das geht mit reinem C/AL wunderbar :wink: (siehe SEPA-Verarbeitung OPplus in den alten Versionen, die boten wir seinerzeit auch ab NAV 2.6 an als "SEPA Sorglos" :-) )

Re: E-Rechnungen Pflicht ab 2025

26. April 2024 10:35

Hallo,

ich denke schon das man das such im NAV5 hinbekommt. Ich habe vor einiger Zeit einem NAV5 System JSON und die Nutzung von Webservices beigebracht. Das ging mit Hilfe des SQL-Servers ganz gut.

Gruß Fiddi

Re: [gelöst] E-Rechnungen Pflicht ab 2025

12. September 2024 19:37

Kowa hat geschrieben:XML-Dateien kann man auch schon unter DOS mit Navision "blau" erzeugen und verarbeiten, das geht mit reinem C/AL wunderbar


Geht das auch mit NAV2.01?
Ich muss auf Windows XP eine Lösung für XRechnung mit NAV2.01 finden. :-?
Wie ungefähr wäre die Vorgehensweise?

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 08:00

Hallo,

welche technische Umgebung benutzt ihr denn. Wirklich noch NAV2.01?

Gruß Fiddi

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 09:21

MF hat geschrieben:Geht das auch mit NAV2.01?

Sicher, NAV 2.01 kam nach den DOS-Versionen.
Falls Automations (COM) zur Verfügung stehen, geht es so aber komfortabler mit XML DOM.
How to create/read xml file from Microsoft Dynamics NAV without using xmlports bzw. Thema hier.
Die Methode, es nur mit C/AL zu machen, wurde damals gewählt, weil das unabhängig von der Umgebung und externen Komponenten immer und überall lauffähig sein sollte.

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 09:29

Hallo Fiddi,

ja, stark individualisiertes NAV 2.01 auf virtuellem Windows XP unter Linux.
Rechnungen verschicken wir bisher mit PDFmailer von gotomaxx.
Ich hätte gerne die Lösung von gotomaxx für XRechnung verwendet. Geht aber erst ab Windows 11.

Eine weitere Idee ist, mit Dataport die nötigen Daten exportieren und damit außerhalb Navision die XML-Datei erzeugen.
Besser wäre aber aus meiner Sicht, eine XML direkt aus NAV zu erstellen. Die könnte ich dann einfach mit PDFmailer an die E-Mail mit der PDF-Rechnung anhängen.
Ich wusste nicht, dass das mit Navision blau geht, bis ich den Beitrag von Kowa gelesen habe.
Geht das über OCX, Automation? Sind dazu C#-Kenntnise notwendig?

Grüße Marcus

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 10:28

Hallo,

Besser wäre aber aus meiner Sicht, eine XML direkt aus NAV zu erstellen. Die könnte ich dann einfach mit PDFmailer an die E-Mail mit der PDF-Rechnung anhängen.


Kleines Problem:
Bei der XRechnung kann die XML eine PDF enthalten, muss aber nicht. Hier kannst du tatsächlich beide Dateien separat verschicken.

Bei ZUGFeRD ist die XML-Bestandteil der PDF, die das Format PDF/A3 haben muss. Dort kann man die XML als Anhang hinterlegen.
Hier muss der PDF-Mailer/Drucker also in Lage sein das passende PDF-Format zu erzeugen, und deine XML- Datei in die PDF einzubetten.

Übrigens benötigst du zur Erstellung der XML-Datei nicht unbedingt das MSXML- COM Objekt, das geht schlimmstenfalls auch ohne. Ist nur etwas aufwändiger.

Ein paar Themen musst du evtl./ ganz bestimmt noch angehen:
1. UTF8- Zeichensatz: Die XML-Datei muss Texte im UTF8- Zeichensatz enthalten.
2. In der XML-Datei sind einige Informationen enthalten, die es Standardmäßig in NAV nicht gibt. Da sind evtl. noch einige Felder oder Funktionen nötig.


Gruß Fiddi

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 10:57

MF hat geschrieben:Geht das über OCX, Automation?

Automation, siehe obige Links, das hat sich wohl zeitlich überschnitten.

Die erzeugte Datei nach UTF-8 konvertieren kann man z.B. mit PowerShell wie hier: Inhalt der Datei austauschen

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 13:12

Vielen Dank für die hilfreichen Antworten.

Grüße Marcus

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 13:19

Hier sind die Basisfunktionen, um in reinem C/AL XML-Dateien zu schreiben. Urheber war seinerzeit der Bruder von meinem damaligen Chef, letzterer hat zugestimmt, das hier zu veröffentlichen :wink: . Nachtrag: Lesefunktionen hier.

IX : Integer;
CRLF : Text[2];
Stack : ARRAY [30] OF Text[40];

Code:
   CRLF[1] := 13;
   CRLF[2] := 10;

Code:
    PROCEDURE cont@1234522(Stream@1234504 : OutStream;Tag@1234502 : Text[30];Text@1234503 : Text[1024]);
    BEGIN
      IF Indent THEN
        Stream.WRITETEXT(PADSTR('',2*(IX+1)));
      Stream.WRITETEXT('<' + Tag + '>' + Text + '</' + Tag + '>');
      Stream.WRITETEXT(CRLF);
    END;

    PROCEDURE contAttrib@1234521(Stream@1234506 : OutStream;Tag@1234502 : Text[30];Text@1234503 : Text[1024];AttribTag@1234504 : Text[30];AttribValue@1234505 : Text[30]);
    BEGIN
      IF Indent THEN
        Stream.WRITETEXT(PADSTR('',2*(IX+1)));
      Stream.WRITETEXT('<' + Tag + ' ' + AttribTag + '="' + AttribValue +'">' + Text + '</' + Tag + '>');
      Stream.WRITETEXT(CRLF);
    END;

    PROCEDURE push@1234519(Stream@1234503 : OutStream;Tag@1234502 : Text[30]);
    BEGIN
      IX += 1;
      Stack[IX] := Tag;
      IF Indent THEN
        Stream.WRITETEXT(PADSTR('',2*IX));
      Stream.WRITETEXT('<' + Tag + '>');
      Stream.WRITETEXT(CRLF);
    END;

    PROCEDURE pop@1234518(Stream@1234502 : OutStream);
    BEGIN
      IF Indent THEN
        Stream.WRITETEXT(PADSTR('',2*IX));
      Stream.WRITETEXT('</' + Stack[IX] + '>') ;
      IX -= 1;
      Stream.WRITETEXT(CRLF);
    END;


Beispiele für die Anwendung bei SEPA-Datei, XS ist ein OutStream.
Code:
      XS.WRITETEXT('<?xml version="1.0" encoding="UTF-8"?>' + CRLF);

      IF Location <> '' THEN
        XS.WRITETEXT(
          '<Document xmlns=' + XMLNS +
          ' xmlns:xsi=' + XSI +
          ' xsi:schemaLocation=' + Location + '>')
      ELSE
        XS.WRITETEXT(
          '<Document xmlns=' + XMLNS +
          ' xmlns:xsi=' + XSI + '>');

      XS.WRITETEXT(CRLF);
      IF painVersion > 2 THEN
        push(XS,'CstmrCdtTrfInitn')
      ELSE
        push(XS,'pain.001.001.02');

      // Header
      push(XS,'GrpHdr');
        cont(XS,'MsgId',COPYSTR(PmtType + '/' + Tools.SEPA_String(PmtHead."Gen. Journal Batch"),1,SEPA_SHORTSTRING));
        cont(XS,'CreDtTm',MakeISODateTime(TODAY));

        cont(XS,'NbOfTxs',FORMAT(TransactionCounter));
        IF painVersion < 3 THEN BEGIN
          cont(XS,'CtrlSum',CONVERTSTR(FORMAT(TotalAmount,0,'<Integer><Decimals,3>'),',','.'));
          IF SepaOld THEN
            cont(XS,'Grpg','GRPD')
          ELSE IF OPplusPmtSetup.SepaGrouping > 0 THEN
            cont(XS,'Grpg',FORMAT(OPplusPmtSetup.SepaGrouping))
          ELSE
            cont(XS,'Grpg','MIXD');
        END;

        push(XS,'InitgPty');
          IF (painVersion = 2) AND (BankCountryCode = 'AT') THEN BEGIN // END ELSE BEGIN
            push(XS,'Id');
              push(XS,'OrgId');
                cont(XS,'BkPtyId',OtherOrdererID);
              pop(XS);
            pop(XS);
          END ELSE BEGIN
            cont(XS,'Nm',SenderName);
            IF SepaOld THEN
              SepaPstlAdr(XS,TRUE,CompanyInfo,FALSE); // kein erw. Zn.Satz vor Version 3
          END;
        pop(XS);
      pop(XS);  // </GrpHdr>


Code:
            push(XS,'Amt');
              contAttrib(XS,'InstdAmt', CONVERTSTR(FORMAT(Amount,0,'<Integer><Decimals,3>'),',','.'), 'Ccy','EUR');
            pop(XS);

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 13:45

Kleiner Tipp noch zu den Routinen von Kowa's Kollegen.

IX sollte am Ende der XML = 0 sein. Damit kann man recht einfach prüfen, ob man alle Open- Tages auch wieder geschlossen hat.

Gruß Fiddi

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 14:04

Kowa hat geschrieben:Die erzeugte Datei nach UTF-8 konvertieren kann man z.B. mit PowerShell wie hier: viewtopic.php?f=17&t=25726&#p138532

PowerShell-Skripte direkt aus NAV -> PowerShell: Skripte aus NAV erzeugen und ausführen

Re: [gelöst] E-Rechnungen Pflicht ab 2025

13. September 2024 14:55

ok, vielen Dank. Das werde ich jetzt mal versuchen zu verarbeiten. :wink:

Grüße Marcus

Re: [gelöst] E-Rechnungen Pflicht ab 2025

15. September 2024 00:38

Zum Importieren sind das die Basisfunktionen zum Lesen von XML-Dateien mit C/AL.
Code:
    PROCEDURE xttSegmentCopy@1234528(VAR offSet@1234502 : Integer;document@1234503 : BigText;tag@1234504 : Text[30];VAR segment@1234505 : BigText);
    VAR
      maxInt@1234507 : Integer;
      myPos@1234506 : Integer;
      needle@1234508 : Text[30];
    BEGIN
      // komplettes Segment <tag> ... </tag> ab Position "offSet" aus einem Text(fragment) kopieren
      // und den Zeiger aktualisieren

      maxInt := document.LENGTH;
      document.GETSUBTEXT(document,offSet,maxInt);
      myPos := document.TEXTPOS('<' + tag + '>');

      IF myPos > 0 THEN BEGIN
        offSet += myPos;
        document.GETSUBTEXT(segment,myPos,maxInt);
        needle := '</' + tag + '>';
        myPos := segment.TEXTPOS(needle);
        IF myPos > 0 THEN BEGIN
          segment.GETSUBTEXT(segment,1,myPos+STRLEN(needle)-1);
          offSet += myPos;
        END ELSE BEGIN // eigentlich Error
          CLEAR(segment);
          offSet := 0;
        END;
      END ELSE BEGIN
        CLEAR(segment);
        offSet := 0;
      END;
    END;

    PROCEDURE xttSegmentCut@1234532(VAR document@1234503 : BigText;tag@1234504 : Text[30];VAR segment@1234505 : BigText);
    VAR
      maxInt@1234507 : BigInteger;
      myPos@1234506 : Integer;
      myPos2@1234502 : Integer;
      needle@1234508 : Text[30];
      part1@1234510 : BigText;
      part2@1234509 : BigText;
    BEGIN
      // komplettes Segment <tag> ... </tag> aus einem Text(fragment) ausschneiden
      // aus einem Text(fragment) ausschneiden

      needle := '<' + tag + '>';
      myPos := document.TEXTPOS(needle);
      needle := '</' + tag + '>';
      myPos2 := document.TEXTPOS(needle);

      IF (myPos > 0) AND (myPos2 > 0) THEN BEGIN

        myPos2 += STRLEN(needle);

        document.GETSUBTEXT(segment,myPos,myPos2-myPos);

        document.GETSUBTEXT(part1,1,myPos-1);
        document.GETSUBTEXT(part2,myPos2,maxInt);
        CLEAR(document);
        document.ADDTEXT(part1);
        document.ADDTEXT(part2);
      END ELSE
        CLEAR(segment);
    END;

    PROCEDURE xttFirstField@1234537(Haystack@1234502 : BigText;Fieldname@1234503 : Text[30]) result : Text[1024];
    VAR
      maxInt@1234506 : BigInteger;
      needle@1234504 : Text[30];
      myPos@1234505 : Integer;
    BEGIN
      // Den Text des ersten <Fieldname></Fieldname> in Haystack extrahieren:
      // ohne Attribute; "Haystack" kann ein beliebiges Fragment sein.

      needle := '<' + Fieldname + '>';
      myPos := Haystack.TEXTPOS(needle);

      IF myPos > 0 THEN BEGIN
        maxInt := Haystack.LENGTH;
        Haystack.GETSUBTEXT(Haystack,myPos+STRLEN(needle),maxInt);
        needle := '</' + Fieldname + '>';
        myPos := Haystack.TEXTPOS(needle);
        IF myPos > 0 THEN BEGIN
          Haystack.GETSUBTEXT(result,1,myPos-1);
          result := DELCHR(result,'<>',' ');
        END ELSE
          result := ''; // eigentlich Error
      END ELSE
        result := '';
    END;

    PROCEDURE xttFirstFieldAttr@1234530(Haystack@1234505 : BigText;FieldName@1234506 : Text[30];VAR Attrib@1234507 : Text[30]) result : Text[1024];
    VAR
      maxInt@1234502 : Integer;
      myPos@1234503 : Integer;
      needle@1234504 : Text[30];
    BEGIN
      // Den Text des ersten <Fieldname></Fieldname> in Haystack extrahieren:
      // ggf. mit dem _ersten_ Attribut; "Haystack" kann ein beliebiges Fragment sein.

      needle := '</' + FieldName + '>';
      myPos := Haystack.TEXTPOS(needle);
      IF myPos > 0 THEN BEGIN
        Haystack.GETSUBTEXT(Haystack,1,myPos-1);
        needle := '<' + FieldName;
        myPos := Haystack.TEXTPOS(needle);
        IF myPos > 0 THEN BEGIN
          maxInt := Haystack.LENGTH;
          Haystack.GETSUBTEXT(result,myPos,maxInt);
          IF AttribSeparator = '' THEN
            IF STRPOS(result,'"') <> 0 THEN
              AttribSeparator := '"'
            ELSE IF STRPOS(result,'''') <> 0 THEN
              AttribSeparator := ''''
            ELSE AttribSeparator := '"';
          Attrib := COPYSTR(result, STRPOS(result,AttribSeparator) + 1, maxInt);
          Attrib := COPYSTR(Attrib, 1, STRPOS(Attrib,AttribSeparator) -1);
          result := COPYSTR(result, STRPOS(result,'>') + 1, maxInt);
          result := DELCHR(result,'<>',' ');
        END ELSE
          result := ''; // eigentlich Error
      END ELSE
        result := '';
    END;

    PROCEDURE xttSubFieldXP@1234531(Haystack@1234502 : BigText;xPath@1234503 : Text[255]) result : Text[1024];
    VAR
      maxInt@1234504 : Integer;
      myPos@1234505 : Integer;
      myPos2@1234507 : Integer;
      needle@1234506 : Text[30];
    BEGIN
      // ein Feld per Pfad aus einem Abschnitt extrahieren

      // Pfad durchlaufen
      maxInt := Haystack.LENGTH;
      REPEAT
        myPos := STRPOS(xPath,'/');
        IF myPos > 0 THEN BEGIN
          needle := '<' + COPYSTR(xPath,1,myPos-1) + '>';
          xPath := COPYSTR(xPath,myPos+1,MAXSTRLEN(xPath));
        END ELSE
          needle := '<' + xPath + '>';

        myPos2 := Haystack.TEXTPOS(needle);
        IF myPos2 > 0 THEN BEGIN
          Haystack.GETSUBTEXT(Haystack,myPos2 + STRLEN(needle),maxInt);
        END ELSE EXIT(result);
      UNTIL myPos < 1;

      // Feld holen, wenn nicht leer
      needle := '</' + xPath + '>';
      myPos := Haystack.TEXTPOS(needle);
      IF myPos > 0 THEN BEGIN
        Haystack.GETSUBTEXT(result,1,myPos-1);
        result := DELCHR(result,'<>',' '+ TAB + CRLF);
      END ELSE
        result := '';
    END;


Snippets dazu
Code:
          IF StatementNo = '' THEN
            StatementNo := xttFirstField(Segment,'LglSeqNb');
          IF StatementNo = '' THEN
            StatementNo := xttFirstField(Segment,'ElctrncSeqNb');     

     PortCodeOption::"CAMT.054":
            BEGIN
              PosEntry := 1;
              xttSegmentCopy(PosEntry,EntryDtl,'TxAmt',segment);
              field := xttFirstFieldAttr(segment,'Amt',Attrib);
              pathNtry := '';
            END




        // SDD betreffende Felder
        path := pathNtry + 'TxDtls/Refs/';
        field := xttSubFieldXP(EntryDtl, path + 'PmtInfId');
        IF field <> '' THEN
          "Reason Row 10" := COPYSTR('PmtInfId: ' + field,1,MAXSTRLEN("Reason Row 10"));

        field := xttSubFieldXP(EntryDtl, path + 'EndToEndId');
   
        // Verwendungszweck (unstrukturiert)
        offset := 1;
        counter := 0;
        xttSegmentCopy(offset,EntryDtl,'Ustrd',segment);
        WHILE offset > 0 DO BEGIN
          counter += 1;
          ProcessUstrd(segment,counter);
          xttSegmentCopy(offset,EntryDtl,'Ustrd',segment);
        END;

Re: [gelöst] E-Rechnungen Pflicht ab 2025

19. September 2024 12:06

Hallo zusammen. Ich schlage mich ebenfalls gerade mit dem Thema rum.

Ich bekomme bereits eine konforme xRechnung / Facture-X aus NAV heraus erzeugt. Nun wollte ich eigentlich versuchen unsere aktuelle PDF Rechnung in eine PDF/A3 zu konvertieren um dann daraus eine ZUGFeRD Rechnung zu erzeugen.
Nun lese ich aber hier dass es wohl gar nicht so unüblich ist eine normale PDF und eine xRechnung.xml getrennt zu versenden?

Dieser Ansatz ist ebenfalls interessant, aber ich würde es schon gerne alles mit DotNet lösen wollen: viewtopic.php?f=66&t=29778&p=144706&hilit=zugferd#p144706

Um das ganze mittels DotNet zu lösen hatte ich iText oder Pdfsharp ins Auge gefasst.
Würde mich mal interessieren wie ihr mit dem Thema umgeht?

Re: [gelöst] E-Rechnungen Pflicht ab 2025

19. September 2024 12:30

Hallo,

um nochmal eins klar zu stellen es gibt eigentlich 3 Formate (X-Rechnung(cii,ubl) und ZUGFeRD,bzw. Factur-X, wie es neuerdings heißt).

Diese Formate unterscheiden sich von der Struktur grundlegend, enthalten aber die gleichen Inhalte.
X-Rechnung arbeitet mit einer XML-Datei, die als Anhang auch eine PDF enthalten kann, während Factur-X mit einer PDF arbeitet, die eine der X-Rechnung im cii- Format ähnlichen XML- Datei als Anhang enthält.

Deshalb meine Frage:

Welches Format bekommst du tatsächlich aus NAV heraus?
XRechnung kannst du mit Bordmitteln erstellen, sofern deine NAV- Version XML kann (eine PDF muss da nicht drin sein).
Für die Factur-X- Rechnung benötigst du ein externes Tool und eine andere XML-Datei, um aus einer PDF-Rechnung (würde je nach Version aus NAV gehen) und deinem XML-Teil eine PDF-A/3- Datei zu machen. Das könntest du, wie in deinem Link beschrieben mit GhostScript machen.

Arbeitest du mit BC als SaaS, wird Microsoft zumindest am Anfang nur die XRechnung unterstützen, weil BC (noch) kein PDF-A/3 kann.

Gruß Fiddi

Re: [gelöst] E-Rechnungen Pflicht ab 2025

19. September 2024 13:06

fiddi hat geschrieben:Deshalb meine Frage:

Welches Format bekommst du tatsächlich aus NAV heraus?
XRechnung kannst du mit Bordmitteln erstellen, sofern deine NAV- Version XML kann (eine PDF muss da nicht drin sein).
Für die Factur-X- Rechnung benötigst du ein externes Tool und eine andere XML-Datei, um aus einer PDF-Rechnung (würde je nach Version aus NAV gehen) und deinem XML-Teil eine PDF-A/3- Datei zu machen. Das könntest du, wie in deinem Link beschrieben mit GhostScript machen.

Arbeitest du mit BC als SaaS, wird Microsoft zumindest am Anfang nur die XRechnung unterstützen, weil BC (noch) kein PDF-A/3 kann.

Gruß Fiddi


Hi Fiddi, wird sind auf NAV 2018 und ich habe eine Factur-X XML nach ZUGFeRD 2.2 im EN16931 Format erstellt, da mein eigentliches Ziel ja war eine ZUGFeRD/Factur-X PDF inkl. XML zu erzeugen um damit hoffentlich gesetzeskonform Rechnungen an B2B, B2G und B2C Kunden versenden zu können.
Ich bin aber zugegeben völlig verwirrt welches Format nun letztendlich benötigt wird.

Dazu kommt noch dass manche Kunden die Rechnung via PEPPOL verlangen. Dafür werden wir aber vermutlich mit einem ext. Dienstleister zusammen arbeiten

Re: [gelöst] E-Rechnungen Pflicht ab 2025

19. September 2024 15:13

Habe gerade gesehen dass es von Mustang nun auch eine .net Bibliothek gibt: https://www.mustangproject.org/net/?lang=de

Zudem unterstützt sowohl das Java Kommandozeilen Tool als auch die .net Version eine Konvertierung von PDF zu PDF/3-A :shock:
Den zusätzlichen Schritt über Ghostscript kann man sich also ggf. sparen. Ich werde mich mal daran versuchen...

Re: [gelöst] E-Rechnungen Pflicht ab 2025

19. September 2024 15:14

Für NAV 2018 gibt es auch Add-ons für den Versand von E-Rechnungen...