Deutsche Sprache...XMLPort mit englischem Datumsformat?

Hallo,

ich möchte einem XML-Port das Format eines bestimmten auszuwählenden Landes mitgeben und nicht das der NavisionApplikation.

Also in Nav2013 steht "12. Dez. 2014"
und dann soll der XML-Port abhängig von der übergebenen Sprache die entsprechende Formatierung machen..."12. Dec. 2014"

Gibt es da etwas "kurzes" im Formatbefehl, oder muss man das ausprogrammieren, wenn man beim Client die Windowssprache nicht umstellt?

Weiss da jemand etwas?

Sprachwechsel zur Laufzeit innerhalb des Codes sind über GLOBALLANGUAGE möglich, z.B. wie hier bei einem gleichartigen Problem:
http://www.mibuso.com/forum/viewtopic.php?f=23&t=33305

Falls dieser XMLport dazu dient, Daten zwischen verschiedenen NAV-Datenbanken auszutauschen, kannst du es dir noch einfacher machen, und die Daten in einem globalen XML-Format ex- und importieren. Dann ist das Format immer fix, und wird durch die individuellen Ländereinstellungen auch NICHT negativ beeinflusst bzw. "falsch verstanden".
Setze hierzu im XMLport (in Quell- und Zieldatenbank) die Eigenschaft Format/Evaluate auf XML Format/Evaluate

Falls dieser XMLport dazu dient, Daten zwischen verschiedenen NAV-Datenbanken auszutauschen, kannst du es dir noch einfacher machen, und die Daten in einem globalen XML-Format ex- und importieren. Dann ist das Format immer fix, und wird durch die individuellen Ländereinstellungen auch NICHT negativ beeinflusst bzw. "falsch verstanden".
Setze hierzu im XMLport (ein Quell- und Zieldatenbank) die Eigenschaft Format/Evaluate auf XML Format/Evaluate

Ich hab da mal ein Wort eingefügt

Ich hab da mal ein Wort eingefügt

Danke ... Frau sollte in geistiger Umnachtung keine Beiträge schreiben *g*

Falls dieser XMLport dazu dient, Daten zwischen verschiedenen NAV-Datenbanken auszutauschen, kannst du es dir noch einfacher machen, und die Daten in einem globalen XML-Format ex- und importieren. Dann ist das Format immer fix, und wird durch die individuellen Ländereinstellungen auch NICHT negativ beeinflusst bzw. "falsch verstanden".
Setze hierzu im XMLport (ein Quell- und Zieldatenbank) die Eigenschaft Format/Evaluate auf XML Format/Evaluate

Genau das wollte ich, als ich das Thema am Montag gesehen habe, auch sagen (Datentypen sind im XML doch eigentlich international standardisiert). Aber ich möchte hier nicht schon wieder der Buh-Mann sein, nur weil ich meine, dass man im technischen Umfeld eigentlich von landes- oder sprachspezifischen Lösungen Abstand nehmen sollte.

Datentypen sind im XML doch eigentlich international standardisiert.

Ein XMLport in NAV 2013 schreibt nicht nur XML-Dateien, sondern auch ganz normale Textdateien, was vormals die Dataports taten.
The dataport is dead, long live the xmlport!
Das XML-Datumsformat kann man auch so jederzeit direkt in NAV erzeugen:
http://msdn.microsoft.com/en-us/library/dd301059.aspx
war aber nicht die Frage im ersten Beitrag.

Äh... ja! Soweit alles bekannt. Aber warum exportiert man denn Daten? Damit sich das ein Mensch im Texteditor angucken kann? Eher nicht, oder?

war aber nicht die Frage im ersten Beitrag.

Schon klar. Fragen kann man oft auf vielfältige Arten beantworten. Du hast ihm halt die Quick&Dirty-Lösung geboten, ich habe eher daran gedacht (und Natalie ja anscheinend auch), wie man das Problem allgemein lösen kann, damit man gleich auch einen Ansatz für zukünftige Fragestellungen in ähnlicher Richtung hat. Beides ist, glaube ich, legitim und kann hier im Forum hilfreich sein. Oder?

Du hast ihm halt die Quick&Dirty-Lösung geboten

Das war eine Anwort auf die Frage, wie man die Sprache wechselt. Welche nicht "Quick&Dirty"-Lösung gibt es sonst dafür?

Wie wäre es damit, dem Fragenden zu empfehlen nicht die Sprache zu wechseln, sondern über den Aufbau seines Exports nachzudenken?

Kai, du bist einer der erfahrensten Experten hier und wie ich dir schon mal sagte, schätze ich deine Antworten immer sehr. Du willst mir doch nicht ernsthaft erzählen, du hast nicht verstanden, worauf diese Hinweise abzielen!? Von daher weiß ich jetzt nicht, was diese Fragerei soll...

Du willst mir doch nicht ernsthaft erzählen, du hast nicht verstanden, worauf diese Hinweise abzielen!

Ein NAV-System auf den Gegenseite ist keine allgemeine Lösung, sondern ein Ausnahmefall. Das wäre natürlich eine schöne Lösung, aber auch nur die halbe Miete, weil es nur Felder im Datumsformat betrifft, aber eben nicht…

Damit sich das ein Mensch im Texteditor angucken kann?

…Daten, die als Text direkt durchgereicht werden und auch so angezeigt werden, die man in Schnittstellten immer unterscheiden muss von denen, die dann noch weiterverarbeitet werden. Ob das eine XML, CSV, feste Feldlängen-Datei usw. ist, ist dabei völlig unerheblich.
Zur Weiterverarbeitung ist ein solche Datumsformatierung natürlich eher ungeeignet, da würde man andere Datumsformate wählen, bei XML dann das dortige Standardformat YYYY-MM-TT.

Wie wäre es damit, dem Fragenden zu empfehlen nicht die Sprache zu wechseln, sondern über den Aufbau seines Exports nachzudenken

Dazu besteht kein Anlass, denn der Normalfall ist: Die Gegenstelle gibt Anforderungen vor, denen man entsprechen muss. "Wir machen uns die Welt, wie sie uns gefällt" funktioniert bei Schnittstellen eher selten.
Dass die Gegenstelle die dortige Schnittstelle erweitert, weil man den Anforderungen nicht nachkommen kann, kommt in der Praxis auch eher selten vor und ist meist mit größeren Kosten verbunden, als wenn man die eigene anpasst.
Dass diese das Datum aber genau so haben möchte, ist durchaus verständlich und nicht ungewöhnlich. Nur mit einem ausgeschriebenen Monat ist weltweit immer eindeutig zu erkennen, welches Datum wirklich gemeint ist, egal wie, wann und wo die Daten dann noch weiterverarbeitet werden. Selbst wenn das nur als Kontrollinstanz dient, hilfreich ist das immer und oft auch bitter notwendig.
Bei der Mibuso Conference 2009 gab es einen schönen Vortrag, was weltweit alles schiefgehen kann, ein fehlinterpretiertes Datum ist da nur einer von vielen Punkten.
http://www.mibuso.com/dlinfo.asp?FileID=1106

Keiner hat behauptet, dass auf der Gegenseite auch ein NAV-System steht. Im Gegenteil, genau deswegen gibt es ja internationalisierte Standards.

Dass Daten einfach eins zu eins so dargestellt werden wie sie im Textformat an eine Schnittstelle übergeben werden, ist doch heutezutage der Ausnahmefall. Natürlich kann man das auch manchmal vorfinden, besonders bei alten Systemen, aber der Normalfall ist heute eigentlich ein anderer. Meist lassen sich die Schnittstellen sogar bis zu einem gewissen Grad konfigurieren.

Außerdem kann man die Sache auch mal andersherum aufziehen. Wenn es wirklich nicht anders geht, als eine der Schnittstellen anzupassen, warum muss denn immer das NAV-System das System sein, welches das Format seiner ausgegebenen Daten anpassen muss? Nach meiner Erfahrung hängt das maßgeblich davon ab, wer welche Marktposition inne hat. Ist das Unternehmen mit NAV der Verkäufer, dann wird man sich in der Regel an die Wünsche des Kunden anpassen, weil man ja mit diesem Geschäfte machen möchte. Ist es der Einkäufer, kann es andersherum sein. Sicherlich hängt das Ganze auch noch von der Größe der Unternehmen ab. Die kleineren passen sich meist eher den Anforderungen der großen an. Die vielen weiteren Einflussfaktoren nenne ich gar nicht erst. Ich denke, es ist klar, was gemeint ist.

Mal abgesehen davon, welche Schnittstelle gibt es denn, in der nur das Datumsformat ein anderes ist? Was ist mit Dezimalzahlen, Währungen, Tagesanzeigen, usw.? Da wir aber nicht wissen, was der User mit den exportierten Daten genau vor hat und welche Konstellation bzgl. möglicher Anpassungen an den In- und Output-Schnittstellen gegeben ist, gibt es hier mehrere Möglichkeiten für eine richtige Antwort, je nachdem welche Annahmen man vorher über den (unbekannten) Prozess macht.

Ich finde, selbst wenn keine andere als die Quick&Dirty-Lösung möglich sein sollte (warum auch immer), sollte man trotzdem darüber bescheid wissen, wie man es eigentlich machen sollte. Wenn sich jeder immer nur auf seine Individuallösung konzentriert, dann braucht man sich auch auf keine Standards zu einigen. Das macht es nicht gerade einfacher für die Zukunft.

sollte man trotzdem darüber bescheid wissen, wie man es eigentlich machen sollte.

Natürlich, diese Standards auch zu verwenden, und im Datenaustausch ausschließlich das ISO-Datumsformat einzusetzen, habe ich schon vor 9 Jahren hier empfohlen.
Das ist aber nur die eine Seite, die der maschinellen Verarbeitung. Das heutige Datum als "16 Oct 2014" geschrieben wird überall verstanden, unabhängig davon, welche Datumsschreibweise in dem jeweiligen Land wirklich gebräuchlich ist. Deswegen ist das so auch im Belegdruck am besten geeignet. Es ist die sicherste Art, ein Datum anzuzeigen, eben weil es nicht umformatiert zu werden braucht.