[Gelöst] [CC] GDPDU Export ...

Alle paar Jahre wieder ... GDPDU Export ... will nicht klappen ...

Dabei habe ich mir beim letzten mal extra ne Anleitung geschrieben ... Klick hier, klick da... aber funktioniert nicht ...

Also, GDPDU Performance Kit ist installiert. (PS60102)

Es scheitert bei der Komponenteneinrichtung.
Datenbankservername gebe ich ein , Testverbindung schlägt fehl.

C:\Program Files (x86)\Common Files\Microsoft Dynamics NAV\Microsoft Dynamics Nav 2009 R2 GDPdU Export\Microsoft.Dynamics.NAV.GDPdUExportProcess.exe:Couldn't connect or open the database, verified that database exist, servername is correct and connection and database is closed before connecting. If multiple Dynamics NAV versions are installed, then remember to set the NavisionPath to the correct client files. Error thrown is : Eine externe Komponente hat eine Ausnahme ausgelöst.

Trage ich den SerevrName unseres Test Datenbankserver ein kommt:
Error thrown is : Error Code: 6146849 - Error Message: Die Datenbank LIVEDB auf dem Server WIN-*****\SQL2 ist nicht vorhanden.

Andersherum, ich bin mit dem Client auf der testDatenbank verbunden, und gebe als Servername den Live Servrename, erhalte ich den Fehler:

Error Code: 6146849 - Error Message: Die Datenbank TESTDB auf dem Server LIVESQL ist nicht vorhanden.

Mehr als Datenbankservername kann man ja nicht angeben, alle Protokolle durchprobiert, auch IP als Servername

Habe schwach in Erinnerung dass da irgendwas mal war mit Client von anderer Maschine einloggen? Kann mich auch täuschen...

Hat jemand eine Idee?

PS: Für den Export gilt der Report 11020 ? Der R11015 ist der alte (vor dem Performance Package?)

Danke

Zuletzt geändert von elTorito am 17. April 2015 16:22, insgesamt 1-mal geändert.

Hmm, hatte damals auch mal ein Problem.
Kann dir jetzt aber nicht sagen ob das deinem Fehler entspricht.

Mit einer Lizenzdatei im Clientverzeichnis klappt es jedenfalls nicht.

Zudem stand für das Form 11025 und die Table 11020 ein falscher OptionString für den "Net Type" drin (siehe Hotfix).
http://support.microsoft.com/kb/2708481/en-us

Report 11020 ist schon korrekt.

mfg,
winfy

Ohne Lizenzdatei im Client Ordner bekomme ich den Client nicht gestartet, lösche ich die Cronis.flf nach dem Starten, und führe die GDPDU Testverbindung aus, kommt die Meldung Cronus.flf nicht gefunden ;)

Den Hotfix habe ich mal angewendet...

(Ich bin am TESTSQL angemeldet, und versuche connect auf dem LIVESQL)
Wähle ich: SqlMultiprotocol bekomme ich nun:
Error Code: 6146858 - Error Message: Der gelieferte Net Type Wert von Multiprotocol ist ungültig. Die verfügbaren Net Types sind: Default,Named Pipes,TCP/IP Sockets.

Wähle ich SqlDefault:
Error Code: 6146849 - Error Message: Die Datenbank DB_TEST auf dem Server LIVESQL ist nicht vorhanden.

(Ich bin am TESTSQL angemeldet und versuche Connect auf die TESTDB)
Mit SqlDefault: Error thrown is : Eine externe Komponente hat eine Ausnahme ausgelöst.
Mit SqlMultiProtocol: Error Code: 6146858 - Error Message: Der gelieferte Net Type Wert von Multiprotocol ist ungültig. Die verfügbaren Net Types sind: Default,Named Pipes,TCP/IP Sockets.


Füge ich in der Table11020 den OptionString "Default" hinzu

Bekomme ich : 6146858 - Error Message: Der gelieferte Net Type Wert von TCPS ist ungültig. Die verfügbaren Net Types sind: Default,Named Pipes,TCP/IP Sockets.

......

Ich Versuch nunmal auf dem TESTSQL den gleichen Datenbankname wie auf dem SQLLIve, vielleicht komme ich dann mit
Error Code: 6146849 - Error Message: Die Datenbank DB_TEST auf dem Server LIVESQL ist nicht vorhanden.weiter ...

Man man man... wie war das nur? Ist erst 2 Jahre her und konnten den Steuerprüfer mit den Exportierten Dateien zufriedenstellen, muss also irgendwie gehen ...

Ohne Lizenzdatei im Client Ordner bekomme ich den Client nicht gestartet, lösche ich die Cronis.flf nach dem Starten, und führe die GDPDU Testverbindung aus, kommt die Meldung Cronus.flf nicht gefunden ;)

Ich meinte damit die fin.flf

mfg,
winfy

Entsprechen die cfront DLLs auch dem Build-Stand der anderen Komponenten? Siehe auch http://blogs.msdn.com/b/german_nav_deve ... 0-sp1.aspx unten.

Auszug:

Kopieren Sie dann noch von der Installations-DVD bzw. dem Installationspfad die folgenden Dateien in das GDPdU-Installationsverzeichnis unter „C:\Program Files (x86)\Common Files\Microsoft Dynamics NAV\Microsoft Dynamics Nav 2009 R2 GDPdU Export“:
•cfront.dll
•cfrontsql.dll
•Microsoft.Dynamics.NAV.CFront.CFrontDotNet.dll

Entsprechen die cfront DLLs auch dem Build-Stand der anderen Komponenten? Siehe auch http://blogs.msdn.com/b/german_nav_deve ... 0-sp1.aspx unten.

Auszug:

Kopieren Sie dann noch von der Installations-DVD bzw. dem Installationspfad die folgenden Dateien in das GDPdU-Installationsverzeichnis unter „C:\Program Files (x86)\Common Files\Microsoft Dynamics NAV\Microsoft Dynamics Nav 2009 R2 GDPdU Export“:
•cfront.dll
•cfrontsql.dll
•Microsoft.Dynamics.NAV.CFront.CFrontDotNet.dll

Habe die Dll's kopiert. Nun ist der Verbindungstest erfolgreich...

Auf meiner Lokalen Maschine okay, kann sein dass ich die in den letzten 2 Jahren mal neu gemacht habe,
aber kann mir nicht erklären warum in der VM wo ich damals GDPDU exportierte, nun die falschen DLL's drin hatte ...

Das war dann wohl ein Persönliches Problem, wie dem auch Sei,jetzt gehts ...

vielen Dank für eure Antworten.

Hi,

ich hab vom Prüfer 2 Dokumente bekommen:

1. GDPDU Export aus Navision nach Vorgaben der Finanzverwaltung (Stand 15.07.2011)
2. Exportanleitung Navision GDPDU (Stand 21.09.2012)

Gelten für Dynamics NAV ab 3.70 bis 5.0 SP1 Classic Client.

In 2. Sind Hauptsächlich Angaben zu den Tabellen und Felder die Exportiert werden sollen, während 1. auch die Einrichtung beschreibt.

Weiß nicht ob ich die hier Posten darf, Copyright oder ähnliches steht nicht drauf, wenn es also jemand gebrauchen kann, kann er mir gerne eine PN oder E-Mail schicken.

Bahhhh... ich verzweifle noch dran ...
Der Prüfer bekommt die exportierten GDPDU Dateien nicht eingelesen...

Das Fehlerprotokoll welches mir vorgelegt wurde sagt eigentlich nur "Import geht nicht", "Entspricht nicht der aktuellen Exportdefinition", und "Tabelle Fehlt"
Das war im ersten Anlauf, dann war mir aufgefallen dass in NAV bei den Datensatzdefinitionen einige GDPDU TabellenName und Feldnamen Leer waren, diese Händisch reingeschrieben, gab es zumindest schonmal ein paar "geht nicht" weniger...

Aktuell wieder Fehlerprotokoll, wie oben 3 Tabellen fehlen, ich nachgeschaut, Anlageposten.txt wurde beim Export nicht erstellt (steht aber in der index.xml drin) , wurde nicht erstellt (vermute ich) weil die Tabelle in NAV Leer ist.

Tabelle MWSTBuchungsmatrix fehlt, dort steht als Exportname: "MwstBuchungsMatrixEinr..txt" zwei punkte im Dateiname (vermute ich es liegt daran)

Und tabelle Debitorenpostenfehlt, Dateiname ist "Debitorenposten.txt", aber GDPDU Tabellenname ist "Debitorposten", meine Vermutung darin das hier der Fehler sein könnte.

Index.xml also Händisch mit meinen Vermutungen korrigiert (Anlageposten ganz raus, Dateiname und Tabellenname der anderen korrigiert) , dem Prüfer die neue Datei rübergegeben, er kommt anschließend mit dem gleichen Fehlerprotokoll...

Kann ich mir nicht vorstellen dass es die gleichen Fehler gibt wenn man händisch die index.xml ändert, vor allem wenn man Sachen rausslöscht oder ändert muss doch andere Fehler kommen, und wie schnell vergisst man ein < oder > Tag ...

Abgesehen davon gibt es noch eine List vom Import mit "Fehlerhaften Daten", wo aber auch nur steht: Debitorenposten fehlerhafte Daten 21499, Krreditorenposten 5211, steht nicht bei welche Daten, welche Zeile, nichts, nada,...

Da frage ich mich vorher kommen die Fehlerhaften Debitorenposten Daten wenn doch weiter oben steht Debitorenposten tabelle fehlt...

Habe mich nun in Kontakt mit AUDICON gesetzt, unsere Exporte übermittelt, deren Consulting meldet: "Index.xml enthält Fehler" , Angebot zur Fehlerbehebung folgt , ca. 1/2 Tag, ca 650 EUR... Toll ey, das die index.xml fehlerhaft ist ist mir bekannt...

Bei der letzten Prüfung hatte ich schon angemeckert warum denn keine Software bereitgestellt wird womit man die exportierten Daten auf Plausibilität überprüfen kann, um nicht dieses Try/Error mit dem Prüfer zu haben , Plausibilitätsprüfung bietet Audicon Gebührenpflichtig an...

Nun beim Vorgesetzen angefragt ob ich die Prüfung in Auftrag geben kann kam als Antwort: Wer hat die Schnittstelle gebaut? NSC oder ob ich die gebastelt hätte... Tolle Wurst ...

Und warum spuckt diese Prüfer Software keine vernünftigen Fehlermeldungen aus ? Ist doch zum Mäusemelken...

Statt "Tabelle fehlt" könnte der Fehler doch "In der Index.xml wird auf eine nicht vorhandene Anlagenposten.txt verwiesen" lauten... Oder "Der Dateiname enthält ungültige Zeichen" ...

man man man ...

Hat noch jemand ne Idee wie ich die index.xml prüfen könnte? Weder Angebot von Audicon noch Vorgesetzter zum Ok einholen sind da, und wenn der Prüfer gleich wieder bei mir in der Tür steht und fragt ob ich was für ihm hätte komme ich mir wieder total doof vor wenn ich mit den Schultern zuckenmuss

Ja, leere Tabellen sollte man nicht exportieren, da legt er keine Datei an.

Ansonsten hatte ich bisher nie in der Index.xml rumgefummelt.

Bei der IDEA Software kommt sowieso immer eine Warnung/Fehler.
Hatte das damals schon einmal hier thematisiert: (Link)

Ferner werden die Verknüpfungen zwischen zwei Tabellenin der INDEX.XML nicht
beschreibungsstandardkonform dargestellt. Der Prüfer hat allerdings Informationen um die
Verknüpfungen manuell herstellen zu können. Bislang ist vorgesehen, dass das verknüpfende
Element (z.B. „Nr.“) in beiden Tabellen (z.B. Sachkonto und Sachposten) gleich heißt. Das ist in
Navision nicht der Fall. In den Sachposten heißt das verknüpfende Feld „Sachkontonr.“.
Folgte man dem Beschreibungsstandard und stellte sich ein Szenario vor, in dem Debitor /
Verkaufskopf / Verkaufszeile / Artikel / Artikelposten als Struktur ausgelesen werden sollten,
dann würde in der INDEX.XML für jede Tabelle ggf. das verknüpfende Element „Nr.“ verwendet
werden. So ein Szenario wäre schwerlich anhand der INDEX.XML nachzuvollziehen.
Audicon und das BMF haben hierin eine Schwäche am Beschreibungsstandard erkannt und
arbeiten derzeit an einer neuen Version des Beschreibungsstandards. Demnach wird es in der
Index.xml ein neues Element namens ’Alias’ geben, das wir, wie auch zahlreiche andere
Hersteller, verwenden können um beim bestehenden Datenmodell die Verknüpfungen abbilden
zu können.
Die aus Navision exportierten Daten können dennoch schon jetzt auf jeden Fall in IDEA
verarbeitet werden!
„Lediglich“ die Überprüfung der INDEX.XML weist momentan daraufhin, dass die INDEX.XML nicht
dem Beschreibungsstandard entspricht.

Ich habe immer die "gdpdu-01-09-2004.dtd" genommen, da ist das 'Alias' Element enthalten.
In der gdpdu-01-08-2002.dtd war das noch nicht der Fall.

mfg,
winfy

Bei der IDEA Software kommt sowieso immer eine Warnung/Fehler.

Ja, hatten wir bei der letzten prüfung auch noch Fehler beim Import, da hat der Prüfer sich aber (scheinbar) damit auseinander gesetzt, beim FA IT Support angerufen und da paar Sachen durchgegangen, und ich konnte (durfte) ihm beim Import zu sehen und direkt sehen wo es happert...

Ist diesmal anders... Mache USB Stick fertig, bringe rüber, kommt zurück: Fehler... erst nach dem 3ten Versuch bekam ich mal ein ausgedrucktes Fehlerprotokoll ...

Gaaaanz komisch halt das nach Manueller Änderung der Index.xml die gleichen Fehler beim Import kamen ... sorry, aber ... ... ... ... ...

Ja, leere Tabellen sollte man nicht exportieren, da legt er keine Datei an.

Ja, ok, wenn man es dann weiß, ist mir ja dann auch aufgefallen, ... steht ja in keiner Doku ? Anleitung drin: "Leere Tabellen nicht exportieren"
Müsste die Schnittstelle doch eigentlich behandeln? Wenn Tabelle leer , kein Eintrag in die index.xml ?

Ferner werden die Verknüpfungen zwischen zwei Tabellenin der INDEX.XML nicht
beschreibungsstandardkonform dargestellt. Der Prüfer hat allerdings Informationen um die
Verknüpfungen manuell herstellen zu können.

Ja, auch bekannt, deswegen Export ohne Verknüpfungen zwischen Tabellen, war beim letzten mal auch so, Ordnete der sich dann selber zu ...

Wollte die Sache nun schnell erledigen, und von Audicon prüfen lassen, kostet aber, sieht mein Vorgesetzter nicht ein, ist ja dann wohl Sache des NAV Partner, weil die Schnittstelle falsch wäre, soll ich das nun also vom NAV Partner prüfen lassen , ich hoffe die können das simulieren...

Ich würds ja selber hindengeln, aber ich kann den IDEA Import nicht simulieren, bei den einen Fehler weiß ich nun die Leere Tabelle nicht mit exportieren, okay, nehme ich raus, exportiere die Daten neu, kann aber nicht testen obs nun okay ist, der Prüfer nun außer Haus und kommt dann wieder wenn die Daten da sind... Daten sind ja da... aber ob die nun okay sind oder nicht zeigt wohl erst wieder der nächste IDEA Import ... was nen hin und her ...

Morgen noch ... ... dann Wochenende ...

Ja, ok, wenn man es dann weiß, ist mir ja dann auch aufgefallen, ... steht ja in keiner Doku ? Anleitung drin: "Leere Tabellen nicht exportieren"
Müsste die Schnittstelle doch eigentlich behandeln? Wenn Tabelle leer , kein Eintrag in die index.xml ?

Das mit dem GDPdU Performance-Update erst so: (Link)

Lies dir hier auch einmal den Workaround bezüglich der Sonderzeichen durch, evtl. war hier ein Problem?

Mit dem GDPdU-Performance Update wurden neue Felder eingeführt, in denen Tabellen- bzw. Feldnamen nunmehr, wie es der GDPdU-Beschreibungsstandard ursprünglich vorgesehen hat, ohne Sonderzeichen und ohne Leerzeichen abgebildet werden.

Workaround:
Der Anwender kann den von NAV vorgeschlagenen „GDPdU-Tabellennamen“ und auch den „GDPdU-Feldnamen“ einfach mit dem Original-Tabellen- bzw. Feldnamen überschreiben und die Daten dann erneut exportieren.

Ferner werden seit GDPdU-Performance Update keine „leeren“ Tabellen mehr exportiert. Auch das könnte dazu führen, dass die Importroutine der Prüfungssoftware abbricht. Dafür gibt es derzeit keinem empfohlenen Workaround.

mfg,
winfy

Hi,

so, endlich, Freitag mit dem NAV Partern noch mal die "Definitionsgruppen" durchgegangen, die Einträge entfernt wo die NAV Tabellen Leer waren, dann die Datei welche 2 Punkte enthielt geändert, einige GDPDU Tabellennamen mit den NAV Tabellennamen gleichgeschrieben.

Der Prüfer kam heute den USB Stick abholen (Digitale Übermittlung ans FA geht irgendwie nicht) und trotz einiger weiterer Fehler konnte der Prüfer die Daten einlesen so dass er nun weiter arbeiten kann...

*erleichtert*