ZM ab 2013

Unser Mitglied Tim hat zusammen gefasst, wie vorgegangen werden muss (Link):

Für alle, die sich Fragen was zu tun ist. Erstmal ist wichtig zu wissen, ob man schon einen Zugang zum BZStOnline-Portal hat (nicht zu verwechseln mit dem ElsterOnline-Portal). Zusätzlich muss der Zugang per ELSTERBasis erfolgen (das heißt mit Software-Zertifikat). Und aufpassen: das ElsterOnline-Zertifikat funktioniert auch für das BZStOnline-Portal, aber damit ist die Anmeldung zum ELMA5-Verfahren nicht möglich.

Registrierung am BZStOnline-Portal noch nicht erfolgt

1. Registrierungsantrag auf Zulassung zum BZStOnline-Portal ausfüllen, ausdrucken, unterschreiben und absenden
2. Es folgt relativ schnell eine Bestätigungsmail und etwas später eine Mail und ein Brief mit den Registrierungsdaten
3. Registrierung nach dieser Anleitung durchführen

Registrierung am BZStOnline-Portal ist erfolgt

1. Anmelden an BZStOnline-Portal und Menüpunkt Dienste auswählen
2. Nutzung der ELMA5-Schnittstelle des BZSt anklicken
3. Antrag auf Freischaltung zur Teilnahme am ELMA5-Verfahren des BZSt anklicken
4. Im sich öffnenden Formular alle Daten angeben (Angaben zum Unternehmen & Angaben zum Ansprechpartner); es ist ein "Verfahrensspezifisches Geheimnis" erforderlich - dieses sollte durch das BZSt mit den Zugangsdaten bereitgestellt worden sein

Alles weitere wissen wir dann, wenn MS sich genauer dazu äußert, wie die Daten aus NAV übermittelt werden. Aber die grundsätzlichen Vorbereitungen für die zukünftige Übermittlung per ELMA5-Verfahren sind damit abgeschlossen.

Weitere Informationen sind hier zu finden:
Informationsseite zum BZStOnline-Portal mit weiterführenden Links
PDF mit Übersicht zu den elektronischen Verfahren zur Abgabe der ZM

Da ich mir das alles mühsam erarbeiten musste, hoffe ich hiermit anderen helfen zu können, schneller den Überblick zu gewinnen.

Alles weitere wissen wir dann, wenn MS sich genauer dazu äußert, wie die Daten aus NAV übermittelt werden.

Soweit ich weiß, wird Dynamics NAV die ELMA5-Datei exportieren. Die Übertragung erfolgt dann (manuell) per gesicherter FTP-Verbindung, wie im ELMA5-Dokument bzw. einem der Dokumente dazu beschrieben.

Wie bereits mehrfach angekündigt steht seit dem 01.01.2013 der Formularserver zur Übertragung der ZM Daten im XML Format nicht mehr zur Verfügung.

Mit dem von Microsoft zur Verfügung gestellten Update kann man mit Hilfe eines Reports die notwendigen Daten im ELMA5 exportieren.
Bitte zu beachten, dass die Lizenz entsprechend aktualisiert werden muss!

Hier die Links:
NAV 2009SP1
https://mbs.microsoft.com/partnersource/support/selfsupport/taxupdates/MSDYN_EUGermanySalesListNAV2009SP1
NAV 2013
https://mbs.microsoft.com/partnersource/support/selfsupport/taxupdates/MSDYN_EUGermanySalesListNAV2013

Frühere Versionen müssen wohl von hand aktualisiert werden. für weiterführende Informationen und Erfahrungsberichte wäre ich dankbar.

Beste Grüße,

Stefan

Hallo Stefan,

wir hexen gerade auch mit der ZM rum...

Beim Test in NAV2009 haben wir bis jetzt schon einige Fehler festgestellt: Menu-Eintrag für die Einrichtung, Rundung, 0-Salden je Beleg werden angezeigt, zweistellige Jahresangaben werden nicht korrekt umgesetzt, UST-ID kommt nur noch aus MWSt-Posten und nicht mehr aus Debitor...

Wir sind diesbezüglich in Kontakt mit MBS und sollen eigentlich heute noch Infos kriegen...

Viele Grüße
Mike

Hallo Zusammen,

ich habe den neuen Report 88 und die davon erstellte csv-Datei getestet (für Unternehmen mit < 1000 Meldezeilen). Das Ergebnis eines Probeimports bei ELSTERonline:

Der Import der csv-Datei auf ELSTERonline setzt den Wert des 1. Importfeldes (Länderkürzel) und den Wert des 2. Importfeldes in das Online-Feld "Umsatzsteueridentifikationsnummer".

In NAV muss man den 2-stelligen-ISO-Ländercode im Feld USt-ID-Nr. zwingend mit eintragen. Wenn man aber dann die csv-Datei bei ELSTERonline im dem ZM-Forumlar importiert, sind alle USt-ID-Nummern falsch, da der Länder/Regionscode beim Import ja zusätzlich als Präfix in das Online-Formular- Feld "Umsatzsteueridentifikationsnummer" importiert wird.
Folge: der User muss dann jede Zeile bei ELSTERonline manuell ändern.

Ergo: die csv-Datei vom neuen Report 88 ist in sowiet fehlerhaft, da das 2. Importfeld lt. csv-Formatbeschreibung bei ELSTER maximal 12 Stellen haben darf - also ohne den 2-stelligen- Länderpräfix, den man in NAV in dem Feld UST-Id-Nr. ja mit eingeben muss (Beispiel: Schweden hat SE + 1 Block von 12 Ziffern).

Änderungswunsch: Der Inhalt des Feldes USt-Id.Nr muss beim csv-Export erst ab der 3. Stelle berücksichtigt werden. Nur, wer macht das?

VG,
Anke
(das Schicksal der Freiberufler: Microsoft hört uns nicht...)

Hallo Zusammen,

muss jetzt schon die Dezembermeldung am 25.01 über das neue Verfahren gemeldet werden oder haben wir noch Zeit bis zum 25.02?

Hallo Patrick,

nein, leider muss schon die Dezember-Meldung im neuen Format erfolgen...

Viele Grüße
Mike

Änderungswunsch: Der Inhalt des Feldes USt-Id.Nr muss beim csv-Export erst ab der 3. Stelle berücksichtigt werden. Nur, wer macht das?]

Scheint nicht notwendig zu sein: Microsoft schreibt in einem Rundbrief, dass bekannt ist, dass "diese Lösung derzeit nicht fehlerfrei" sei. Die Objekte würden aktuell korrigiert werden.
Sobald die Korrekturen fertig sind, werden sie in der PartnerSource und hier veröffentlicht werden:
http://blogs.msdn.com/b/german_nav_deve ... x#10383412

Den gesamen Inhalt des Schreibens und das angehängte ZMEinrichtungundFunktionsweise2009SP11.pdf findet ihr in der PartnerSource:
https://mbs.microsoft.com/partnersource ... av2013.htm
https://mbs.microsoft.com/partnersource ... 009sp1.htm

Hallo,

es gibt jetzt doch eine Übergangsfrist bis zum 31.08.13!!!
Siehe http://www.bzst.de/DE/Home/NEWS/20130110_ZM_Uebergang_Artikel.html;jsessionid=EDDC23820345A43D970A9079388F38D9
Ich denke, das erspart uns allen einige Hektik....

VG
Mike

Microsoft schreibt in einem Rundbrief ...

Nachdem ich das gerade mit Microsoft abgeklärt habe, vorsorglich eine Bitte:

Leider dürfen wir Neuigkeiten aus diesem Partner-Newsletter, der sich auf die Objektkorrektren und andere Microsoft-Interna bezieht, nicht veröffentlichen.
Auch wenn ich das sehr bedaure, bitte ich euch (andere Partner), diese Informationen hier niemals zu veröffentlichen.

Juhuuu! Anfang Mai 2013 kamen die korrigierten Objekte von Microsoft heraus.

Die Links weiter oben sind noch gültig im Partnersource und auch im Developer Blog findet man das Update gelistet.

Cheers,
Anke

Mit dem von Microsoft zur Verfügung gestellten Update kann man mit Hilfe eines Reports die notwendigen Daten im ELMA5 exportieren.
Bitte zu beachten, dass die Lizenz entsprechend aktualisiert werden muss!

In welchem Granule ist die ZM enthalten?

Grüße
Manfred

Auf dem German NAV Developers Blog gibt es neue Infos bzgl. ZM:

Die Objekte für die Zusammenfassende Meldung im sog. ELMA5-Verfahren für die Version Dynamics NAV 2009 SP1/R2 wurden überarbeitet und am 05. September ausgetauscht.

Das aktuellste Paket ist das mit der Bezeichnung „TFS352870_EUSalesList_DE_NAV2009SP1“.

Es sind nur kleiner Anpassungen. Ich hatte die alte Version schon auf 4.0 downgegraded, die Änderungen zu implementieren hat insgesamt keine 10 Minuten gedauert.

Ich habe nur gerade ein Link zu Customersource. Die Seite für NAV 2013 scheint noch nicht aktualisiert worden zu sein. Oder es wird ausschließlich über das Rollup-Update zur Verfügung gestellt.

Germany - EU Sales List - New Method for Submission as of 01.01.2013 - Microsoft Dynamics NAV 2009 SP1

Jetzt hat sich doch noch ein mittleres Problem ergeben. In unserer Datenbank ist der Ländercode für Griechenland "GR", der EU-Ländercode ist aber "EL".

In der alten ZM wurde der Ländercode durch Abschneiden des Länderkennzeichens der UStID-Nr. ermittelt. In der neuen ZM wird der Ländercode aus dem MwSt.-Posten verwendet. Dieser wird letztendlich aus dem Feld "VAT Country/Region Code" des Verkaufsbelegs gefüllt und dieses wiederum wird immer mit dem "Country/Region Code" des Debitoren (je nach FiBu-Einrichtung aus "Verk. an" bzw. "Rech. an") gefüllt. Soll heißen: das Feld "EU Country/Region Code" aus der Ländertabelle kommt hier nie zum tragen.

Ist das jemandem schon aufgefallen? Natürlich könnte ich jetzt den Ländercode direkt ändern, aber dann wäre das Feld "EU Country/Region Code" ja noch nutzloser. Ich denke ich ändere jetzt einfach die Routine beim Sammeln der ZM-Daten, um möglichst wenig Auswirkungen auf die sonstige Anwendung zu haben, oder gibt es bessere Ideen?

In unserer Datenbank ist der Ländercode für Griechenland "GR", der EU-Ländercode ist aber "EL".

"EL" ist eigentlich der UPU-Code vom Weltpostverein (Universal Postal Union) für ELTA, genauso wie D für Deutschland und B für Belgien. Ungeeignet, als Ländercodes in NAV: ISO 3166.
Leider ist das eine von zwei Ausnahmen (die andere UK), die vom Schema abweichen:
http://publications.europa.eu/code/en/en-370100.htm

In unserer Datenbank ist der Ländercode für Griechenland "GR", der EU-Ländercode ist aber "EL".

"EL" ist eigentlich der UPU-Code vom Weltpostverein (Universal Postal Union) für ELTA, genauso wie D für Deutschland und B für Belgien. Ungeeignet, als Ländercodes in NAV: ISO 3166.

Und jetzt soll ich der EU schreiben, dass sie gefälligst den Ländercode von EL auf GR ändern sollen? Oder inwiefern hilft mir der Hinweis? In der ZM-Meldung muss EL als Ländercode verwendet werden. Wir haben eine Beanstandung unserer ZM-Meldung vom Bundeszentralamt für Steuern bekommen.

EDIT: Ok, hast du inzwischen selbst gemerkt und deinen Beitrag geändert.

EDIT: Ok, hast du inzwischen selbst gemerkt und deinen Beitrag geändert.

Das hat sich mit deinem überschnitten.
Da ja beide Codes möglich sind ("recommended" ist nicht "compulsory") , "EL" aber nur bei steuerlichen Angaben zwingend verwendet werden muss, wäre die sauberste Lösung, dafür ein extra Feld in der Ländertabelle oder Tabelle 381 VAT Registration No. Format USt-IdNr.-Format einzubauen (VAT ID Prefix) und das dann auszuwerten.

Und mal wieder ein Problem: inzwischen haben wir ein Update auf NAV 2009 R2 vorgenommen. Dort wird ja jetzt in der CU12 der Ländercode in den MwSt.-Posten nicht mehr aus der Buch.-Blattzeile übernommen, sondern immer im Debitoren nachgesehen und von dort die USt.-IdNr., sowie der Ländercode übernommen. Das ist meiner Meinung nach totaler Quatsch, da man ja nun mal extra in jedem Verkaufsbeleg den MwSt.-Ländercode und die USt.-IdNr. ändern kann, diese dann aber wiederum nie wieder irgendwo zu tragen kommen (außer auf dem Rechnungsbeleg, was wiederum große Schwierigkeiten bringen kann, wenn Beleg und Buchung nicht zusammen passen).

Ein konkreter Fall: ein Schweizer Kunde kauft mit niederländischer USt.-IdNr. bei uns ein. Jetzt steht in den MwSt.-Posten Schweiz als Ländercode, obwohl der MwSt.-Ländercode logischerweise Niederlande sein soll. In der ZM wird der Umsatz deswegen nicht herangezogen, weil die Schweiz nun mal kein EU-Land ist. Nun kann ja jedes Unternehmen in der EU theoretisch eine USt.-IdNr. in jedem EU-Land beantragen (also z.B. drei USt.-IdNr. haben, einmal DE, einmal NL, einmal FR) und bei jedem Einkauf eine andere USt.-IdNr. angeben. D

Habe ich jetzt einen Denkfehler oder ist das komisch umgesetzt von MS? Was soll denn der MwSt.-Ländercode im Verkaufskopf überhaupt bringen? Ok, er wird in die Artikelposten geschrieben, aber warum nun ausgerechnet den MwSt.-Ländercode in die Artikelposten und in den MwSt.-Posten wird der Ländercode des Debitoren übernommen?

[Natalie]

Jetzt hab ich eine Frage, betrifft NAV 2009 R2 ...
Wenn in einer Kundendatenbank ein früheres ZM-Update vorhanden ist ([PS53045,PS56018,PS59460] Monatliche zusammenfassende Meldung für Microsoft Dynamics NAV 2009 SP1 – Deutschland - enthält nur Report 11007),
und nun soll das aktuellste ([EUSALESLIST, 352870] Germany - EU Sales List - New Method for Submission as of 01.01.2013 - Microsoft Dynamics NAV 2009 SP1) eingespielt werden. Dort ist der besagte Report 11007 ebenfalls enthalten, allerdings mit starken Änderungen. Ich nehme an, dass die alten Änderungen ignoriert werden können, da das neue Objekt maßgeblich ist ...?

Außerdem habe ich noch folgende Nummern in der Version List der Kundendatenbank gefunden, die vermutlich ebenso rauskönnten/müssten: PS56643 (nur Report 594), 59132 (nur Report 11007) ... kann jemand diese Nummern einer Quelle zuordnen? Die PartnerSoruce gibt nichts her.

Zuletzt geändert von Natalie am 7. Juli 2014 14:18, insgesamt 2-mal geändert.
Grund: Ergänzungen ...

Kurze Antwort: Überschreiben!

Lange Antwort: Ursprünglich war die ZM nur der Report. Nun ist der Bereich etwas umfangreicher, weswegen auch viel mehr Objekte betroffen sind. Du brauchst also nichts mergen, sondern nur ersetzen.

Zu den weiteren Korrekturen (PS xxxxx): Wenn du diese in der Datenbank hast und diese nicht von neuen Korrekturen überschrieben werden, dann lass sie einfach so drin.

Wir haben diesen Monat die ZM übermittelt und bekommen nun zum ersten Mal die folgende Rückmeldung per Mail:

Sehr geehrte Dame, sehr geehrter Herr,

wir haben Ihre im Betreff genannte Datei erhalten.
Die Signaturprüfung ist leider fehlgeschlagen.
Die Datei wurde abgewiesen.

Nun steht im Dokument "Dokumentation ELMA5-ZIVIT" folgendes:

3.2 Ablauf der Datenübertragung mit ELMA5
Der Benutzer erstellt mit seinen Backend-Systemen entsprechend der technischen Beschreibung des jeweiligen Fachverfahrens eine Datei mit den zu übertragenden Daten. Diese Datei ist vor der Übertragung mit dem privaten Schlüssel des Senders zu signieren. Dateien ohne Signatur werden im Rahmen der Signaturprüfung vom ELMA5Kommunikationsserver für die Verarbeitung im jeweiligen Fachfachverfahren abgewiesen.

Meiner Meinung nach ist das irreführend. Denn im Beispiel der ZM, wird ja eine "einfache Textdatei" erstellt und das Signieren geschieht dann bei der Übermittlung im Elster-Portal selbst, oder?

Hat jemand eine Idee oder einen Ansatz, wie ich dem Problem auf die Schliche kommen kann? Ansonsten rufe ich morgen mal beim Elster-Support an. Interessant ist nur, dass das Elster-Portal am 29.07.14 ein Update bekommen hat und das die erste Meldung nach dem Update ist. Aber wenn das der Grund ist, müsste ja hier im Forum oder auch im ElsterOnline-Portal-Forum schon längst etwas dazu zu finden sein.

Hallo Tim,

einer meiner Kunden hatte das gleiche Problem und hat vom Elster-Support die Antwort bekommen, dass es an den Servern beim Finanzamt liegen könne - es lägen mehrere Fälle dieser Art vor...
Er hat die ZM dann per Hand erfasst.

Viele Grüße
Mike