Was habt Ihr genau über die "tAdressExportFelder" laufen lassen?
Ich habe, seit ich letztes WE auf die Openbeta umgestiegen bin, vor ein paar Tagen erstmalig wieder eine "Live-Übertragung" an Intraship gemacht.
Dabei habe ich festgestellt, das sich da so ein paar Dinge geändert haben.
Ich kann nur nicht sagen, ab welcher Version, da ich mit der 099817 angefangen habe, und den Export jetzt in der 099819 das erste Mal genutzt habe.
Dass Ihr die "$#Lieferschein_Nummer#$" bei "Sendungsreferenz" in allen Vorlagen (sogar in allen von uns selbsterstellten) eingebracht habt, ist ja schön.
Ich hatte vorher in diesem Feld die $#Rechnung_Nummer#$ genutzt, da ich selten zwei Pakete aus einer Rechnung versende.
In den einzelnen Ausnahmefällen hatte ich das Paket bei Intraship händisch dupliziert und die weiteren Sendungsnummer händisch in die Rechnungsanmerkung kopiert.
Nur habt ihr noch irgendetwas geändert, was ich nicht komplett nachvollziehen kann. Ich hatte auch bei Ordnungsnummer die $#Rechnung_Nummer#$ genutzt.
Jetzt ist dort $#Rechnung_InterneNummer#$. Als ich $#Rechnung_Nummer#$ benutzt hatte, war alles prima und er hat als Ordnungsnummer die "letzten" 10 Ziffern exportiert.
Folgende Fehler passieren:
Es erscheint im Exportfile dann bei der ersten Ordnungsnummer "dd2626MMyy" und bei den weiteren "dd2626MM".
Wenn ich $#Rechnung_Nummer#$ nutze kommen die "ersten" 10 Ziffern (bzw 8 Ziffern) und nicht die "letzten", wie vorher.
Bei $#Lieferschein_Nummer#$ das Gleiche.
Woher ddmmyy kommen ist mir ein Rätsel. Bei anderen getesteten Variablen wie z.B. $#Firma_HausNr#$ o.ä. erscheinen die Datumsvariablen nicht.
Die $#Rechnung_InterneNummer#$ gibt übrigens auch bei allen anderen Feldern und Vorlagen, wo man sie testet, ddmmyyyy mit aus.
Kann es sein, dass ihr für die Variable $#Rechnung_InterneNummer#$ aus Versehen ein Datumsformat festgelegt habt?
Die verkürzten Stellen kann ich mir evtl. erklären.
Da ich der erste war, der einen mehrzeiligen Intrashipexport realisiert hatte, bevor Ihr den "Zeilenumbruch" hinzugefügt hattet, mußte ich ein Umbruchsteuerzeichen im Prefix der zweiten bis vierten Ordnungsnummer mittles Toad und Excel direkt in die Datenbank injizieren. Händisch ging es ja nicht und Eure Variable für "Zeilenumbruch" gab es damals auch nocht nicht.
Die Feldzeichenangabe maxleng von 10 Zeichen funktionierte immer prima. Jetzt scheint jedoch das Prefix mitgezählt zu werden.
LfCr müssten als unsichtbare Steuerzeichen imho ja genau zwei sein. Beim Umstellen auf 12 Zeichen für die zweite bis vierte Ordnungsnummer ist die 10er Länge dann logischerweise auch wieder da.
Diese kleine Anpassung ist bei mir ja nicht das große Problem, aber es kann ja sein, dass diese neue Art der Zählung der Feldgöße von Euch nicht beabsichtigt war.
Falls Ihr irgendwo einen Excel-Export eines Intraship-Satzes aus der Datenbank inkl. des "neuen Zeilenumbruch" habt, wäre toll.
Dann könnte ich ihn Importieren und meine paar Spezalitäten hinzufügen. Ganz neu von Hand aufbauen wäre grausam, da man ja nicht mittendrin eine Zeile einfach einfügen kann.
Das Problem mit der Ordnungsnummer selbst ist allerdings wichtig, denn:
Der Export über $#Rechnung_InterneNummer#$, $#Rechnung_Nummer#$ oder $#Lieferschein_Nummer#$ würde seit so oder so nicht mehr richtig funktionieren.
Die DHL-Ordnungsnummer muss ja "unique" pro Paket sein. Selbst bei zwei Paketen des selben Lieferscheins sind ja die Gewichte unterschiedlich.
Für das richtige Gewicht könnte man die Sendung in zwei Lieferscheine splitten, was auch sinnvoll wäre.
Also brauchen wir irgendeine Nummer, die für den Export jedes einzelne Paket identifiziert. Von den exsistierenden wüßte ich nicht welche.
Und von egal welcher "unique" Nummer müssen die letzten Ziffern und nicht die ersten angezeigt werden.
Ginge evtl. mit der lfd. Nummer der tVersand zu lösen, falls der Export der letzte Vorgang in der Abarbeitung der gesammelten Abläufe ist und daher das Paket (die Pakete) in der Tabelle schon existiert.
Oder man müßte auf jeden Fall die Paket vorher anlegen, was aber im Moment nicht geht, ohne den Status versandt zu setzen,
obwohl das ja eigentlich erst nach Einlesen der Sendungsnummern passieren sollte.
Allerdings wird im Moment bei zwei Paketen auf einem Lieferschein nur eines davon an Intraship exportiert......
Falls man bei zwei Paketen immer zwei Lieferscheine erstellen soll, weiß ich aber nicht, wieso man bei einem Lieferschein ein Zweites hinzufügen kann.
.....ich merk schon, es wird kompliziert
.......oder ich hab einen Riesendenkfehler irgendwo....
Ich habe, seit ich letztes WE auf die Openbeta umgestiegen bin, vor ein paar Tagen erstmalig wieder eine "Live-Übertragung" an Intraship gemacht.
Dabei habe ich festgestellt, das sich da so ein paar Dinge geändert haben.
Ich kann nur nicht sagen, ab welcher Version, da ich mit der 099817 angefangen habe, und den Export jetzt in der 099819 das erste Mal genutzt habe.
Dass Ihr die "$#Lieferschein_Nummer#$" bei "Sendungsreferenz" in allen Vorlagen (sogar in allen von uns selbsterstellten) eingebracht habt, ist ja schön.
Ich hatte vorher in diesem Feld die $#Rechnung_Nummer#$ genutzt, da ich selten zwei Pakete aus einer Rechnung versende.
In den einzelnen Ausnahmefällen hatte ich das Paket bei Intraship händisch dupliziert und die weiteren Sendungsnummer händisch in die Rechnungsanmerkung kopiert.
Nur habt ihr noch irgendetwas geändert, was ich nicht komplett nachvollziehen kann. Ich hatte auch bei Ordnungsnummer die $#Rechnung_Nummer#$ genutzt.
Jetzt ist dort $#Rechnung_InterneNummer#$. Als ich $#Rechnung_Nummer#$ benutzt hatte, war alles prima und er hat als Ordnungsnummer die "letzten" 10 Ziffern exportiert.
Folgende Fehler passieren:
Es erscheint im Exportfile dann bei der ersten Ordnungsnummer "dd2626MMyy" und bei den weiteren "dd2626MM".
Wenn ich $#Rechnung_Nummer#$ nutze kommen die "ersten" 10 Ziffern (bzw 8 Ziffern) und nicht die "letzten", wie vorher.
Bei $#Lieferschein_Nummer#$ das Gleiche.
Woher ddmmyy kommen ist mir ein Rätsel. Bei anderen getesteten Variablen wie z.B. $#Firma_HausNr#$ o.ä. erscheinen die Datumsvariablen nicht.
Die $#Rechnung_InterneNummer#$ gibt übrigens auch bei allen anderen Feldern und Vorlagen, wo man sie testet, ddmmyyyy mit aus.
Kann es sein, dass ihr für die Variable $#Rechnung_InterneNummer#$ aus Versehen ein Datumsformat festgelegt habt?
Die verkürzten Stellen kann ich mir evtl. erklären.
Da ich der erste war, der einen mehrzeiligen Intrashipexport realisiert hatte, bevor Ihr den "Zeilenumbruch" hinzugefügt hattet, mußte ich ein Umbruchsteuerzeichen im Prefix der zweiten bis vierten Ordnungsnummer mittles Toad und Excel direkt in die Datenbank injizieren. Händisch ging es ja nicht und Eure Variable für "Zeilenumbruch" gab es damals auch nocht nicht.
Die Feldzeichenangabe maxleng von 10 Zeichen funktionierte immer prima. Jetzt scheint jedoch das Prefix mitgezählt zu werden.
LfCr müssten als unsichtbare Steuerzeichen imho ja genau zwei sein. Beim Umstellen auf 12 Zeichen für die zweite bis vierte Ordnungsnummer ist die 10er Länge dann logischerweise auch wieder da.
Diese kleine Anpassung ist bei mir ja nicht das große Problem, aber es kann ja sein, dass diese neue Art der Zählung der Feldgöße von Euch nicht beabsichtigt war.
Falls Ihr irgendwo einen Excel-Export eines Intraship-Satzes aus der Datenbank inkl. des "neuen Zeilenumbruch" habt, wäre toll.
Dann könnte ich ihn Importieren und meine paar Spezalitäten hinzufügen. Ganz neu von Hand aufbauen wäre grausam, da man ja nicht mittendrin eine Zeile einfach einfügen kann.
Das Problem mit der Ordnungsnummer selbst ist allerdings wichtig, denn:
Der Export über $#Rechnung_InterneNummer#$, $#Rechnung_Nummer#$ oder $#Lieferschein_Nummer#$ würde seit so oder so nicht mehr richtig funktionieren.
Die DHL-Ordnungsnummer muss ja "unique" pro Paket sein. Selbst bei zwei Paketen des selben Lieferscheins sind ja die Gewichte unterschiedlich.
Für das richtige Gewicht könnte man die Sendung in zwei Lieferscheine splitten, was auch sinnvoll wäre.
Also brauchen wir irgendeine Nummer, die für den Export jedes einzelne Paket identifiziert. Von den exsistierenden wüßte ich nicht welche.
Und von egal welcher "unique" Nummer müssen die letzten Ziffern und nicht die ersten angezeigt werden.
Ginge evtl. mit der lfd. Nummer der tVersand zu lösen, falls der Export der letzte Vorgang in der Abarbeitung der gesammelten Abläufe ist und daher das Paket (die Pakete) in der Tabelle schon existiert.
Oder man müßte auf jeden Fall die Paket vorher anlegen, was aber im Moment nicht geht, ohne den Status versandt zu setzen,
obwohl das ja eigentlich erst nach Einlesen der Sendungsnummern passieren sollte.
Allerdings wird im Moment bei zwei Paketen auf einem Lieferschein nur eines davon an Intraship exportiert......
Falls man bei zwei Paketen immer zwei Lieferscheine erstellen soll, weiß ich aber nicht, wieso man bei einem Lieferschein ein Zweites hinzufügen kann.
.....ich merk schon, es wird kompliziert
.......oder ich hab einen Riesendenkfehler irgendwo....