E-Rechnungen Pflicht ab 2025

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

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

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ß

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

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

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, ...)

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 (siehe SEPA-Verarbeitung OPplus in den alten Versionen, die boten wir seinerzeit auch ab NAV 2.6 an als "SEPA Sorglos" )

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