Hallo,
ich versuche gerade einen Export in eine Textdatei hinzubekommen und scheitere an zwei Dingen:
Ich habe im Datensatz zwei berechnete Felder (mit Buchungssätzen, also Strings im csv-Format), die untereinander in eine Textdatei geschrieben werden sollen.
Dafür gibt es eine Einstellung, das klappt gut.
Aber: der erste Buchungssatz ist u.U. leer und das erzeugt dann im Exportfile eine Leerzeile, mit der das Buchhaltungsprogramm nicht umgehen kann.
Ich habe also versucht, nicht zwei Felder sondern nur eine Formel ausgeben zu lassen:
Einen „bedingten Zeilenumbruch“ konnte ich damit leider nicht erzeugen. Was muss ich der Formel mitgeben, dass an den Stellen ein Zeilenumbruch im Export zustandekommt?
Am Ende des Inhaltes von Feld1 produziert der Export immer einen Unterstrich „_“. Ich erhalte also
Inhalt von Feld1_Feld2
Ich habe das Klammern der Felder aber abgeschaltet. Und eine andere Einstellung finde ich nicht.
als schnelle erste Hilfe würde ich sagen, dass man es eventuell mit der Funktion IsNullOrEmpty versucht. Der Umbruch wird, so glaube ich, mit dem ¶ beim Export verwendet.
«If(IsNullOrEmpty(Feld1),"" ,Feld1 +"¶" +Feld2)»
Ich habe es nicht getestet, aber das könnte klappen, beste Grüße und schönes Wochenende aus Illingen
Frank Wietzel
@Frank_Wietzel
Vielen Dank für die Hinweise!
Leider erhalte ich mit dem „offiziellen“ Zeilenumbruch auch keinen Zeilenumbruch…
Meine Zeilen schauen nun so aus:
Hallo, @Frank_Wietzel: Vielen Dank für Ihre Zeit und Mühe, mittlerweile erhalte ich auch eine Exportdatei, die unsere Buchhaltung einlesen kann.
Folgende Anmerkungen möchte ich dem Thread noch beifügen:
Chr$(10) + Chr$(13) erzeugt eine Leerzeile, Chr$(13) reicht aus
Der Editor (Notepad) von Win10 Server stellt die erzeugten Zeilenumbrüche nicht dar… Egal ob chr(10) +chr(13), chr(13), „¶“, … Dargestellt wird NUR der Zeilenumbruch am Ende eines Datensatzes. (Das bringt mich zu der Frage: Welches geheimnisvolle Zeichen fügt der Export hier ein?).
Wenn ich die Datei aber auf meinen Arbeitsplatzrechner kopiere, stellen Notepad, Notepad++, Ultraedit etc. die Datei korrekt dar. Auch Copy und Paste bringt ein korrektes Ergebnis…
Kurzum: Der ASCII-Editor von Windows hat mich mehrere Tage beschäftigt.
Vielen Dank an alle, die sich Gedanken gemacht haben!
Gruß
Wolfgang
Ich erhalte bei meinem Export eine Datei, die als Zeilenendzeichen nur <CR>s hat, das kann Notepad++, aber leider das Buchhaltungsprogramm nicht.
Je nachdem, wo ich die Datei zwischenspeichere, sorgt der Kopiervorgang für ein Windows-konformes Ergänzen zu (was auch meine Frage aus dem letzten Post beantwortet).
Ich habe heute einen Support Case eröffnet, das Verhalten des Exports scheint fehlerhaft zu sein. Ich zitiere einmal die Mail, die ich vom Support erhalten habe:
Nach Rücksprache mit unserer Entwicklungsabteilung können wir Ihnen folgendes mitteilen:
Es gibt einen Workaround, um das von Ihnen beschriebene Verhalten zu umgehen. Hierfür müssen Sie bei der Option „Die Spalten sollen eingerahmt werden durch folgendes Zeichen“ einen anderen Wert als „keine“ setzten (siehe Screenshot).
Im Anschluss können Sie die zusätzlich erstellten Zeichen über Bearbeiten-> Ersetzten wieder automatisch entfernen lassen.
Da unsere Entwicklungsabteilung bereits an einer Lösung bezüglich des von Ihnen gezeigten Verhaltens arbeitet, bitten wir Sie um etwas Geduld. Sobald wir neue Informationen diesbezüglich haben, werden wir Sie umgehend darüber informieren.
Als Alternative Zwischenlösung kann auch Notepad++ die Zeilenenden umschalten:
Das „Macintosh (CR)“ lässt sich per rechter Maustaste und Kontextmenü umschalten:
Ihr benötigtes Zielformat ist - offen gestanden - ziemlich äh unorthodox. Sie möchten einerseits einzelne „Felder“ ein-und-desselben Datensatzes untereinander per Zeilenumbruch exportiert bekommen, andererseits sollen aber auch die Datensätze an sich untereinander per Zeilenumbruch getrennt exportiert werden. Und darüber hinaus sollen aber ggf auch keine Leerzeilen erzeugt werden, so dass Sie innerhalb der zu exportierenden „Feldes“ selbst per Formel dann auch nochmals Hand anlegen und zusätzlich nochmal eigene Zeilenumbrüche auslösen können wollen.
Ich will wirklich nicht unken, aber ob ein Standard-Textexport-Format, das klaglos bei vielen Kund:innen seit Jahren seinen Dienst in den normalen Szenarien versieht, dazu wirklich in dieser Kombination „verbiegbar“ sein wird, da habe ich arge Zweifel. Ich muss Sie da in jedem Fall leider hinsichtlich des Cases um eine Portion Geduld bitten.
Ich würde Ihnen für dieses feste, spezielle Format eigentlich empfehlen, den Export über ein Script zu bewerkstelligen, bei dem Sie die volle Kontrolle über Format und Aufbau der Zieltextdatei nach eigenem Gutdünken haben.
@beggstein
Hallo, Herr Eggstein,
Dass das Format eher ungewöhnlich ist, will ich gar nicht bestreiten.
Ich bin auch nur eher zufällig über die Einstellung gefallen, die die Trennung der einzelnen Datensätze durch ermöglicht. Hätte ich gewusst, dass ich mich da in das Minenfeld von MS-DOS, Macintosh und Unix-Zeilenenden begebe, hätte ich wohl von Anfang an die Lösung per Skript angestrebt.
Aber es sah aus, als ließe sich alles was ich brauche komfortabel im Assistenten zusammenbauen
Ich hätte wahrscheinlich den Absprung etwas eher finden sollen.
Chr$(10) + Chr$(13) produziert ein UNIX-Zeilenende (also ein reines LF)
Chr$(13) produziert ein Macintosh-Zeilenende. Das ist die Variante, die ich im Augenblick am einfachsten weiterverarbeiten kann.
Chr$(13) + Chr$(10) ergibt im Export ein „_“
Der Unterstrich kommt auch, wenn ich den Feldern per Datenbanktrigger ein abschließendes CR-LF (also chr$(13) + chr$(10)) anhängen lasse und dann den Export anstoße.
Mir scheint, dass der Export die Zeichen, die im Feld „die einzelnen Spalten sollen getrennt sein durch“ durch einen „_“ ersetzt (was ja für eine trennzeichenbasierte Weiterverarbeitung notwendig ist). Lässt sich dieses Verhalten durch das „Einrahmen“ steuern?
Der Exporter will das Format „beschützen“: wenn CR+LF aus seiner Sicht eine Sonderbedeutung hat (nämlich Satzende) und jetzt IM FELDINHALT (Ihre Formel ist am Ende auch ein „Feldinhalt“) eben diese(s) „Sonderzeichen“(kombination) vorkommt, dann ersetzt er diese(s) durch ein „_“, weil ja sonst das Format (aus seiner Sicht) gebrochen würde: das CR+LF in dem Feldinhalt würde ja dann zu einem Satzende führen, obwohl noch weitere Feldinhalte für den aktuellen Datensatz folgen könnten. ZUMINDEST dann, wenn Sie kein Einrahmungszeichen angegeben haben.
Wenn Sie ein Einrahmungszeichen angeben, dann sollte er CRLF als Feldinhalt durchlassen, weil er dann ja weiß, dass alles durch das Einrahmungszeichen „geklammert“ wird. (Konsequenterweise würde er vermutlich das Einrahmungszeichen, wenn es Teil eines Feldinhaltes ist, in ein „_“ umwandeln, weil dieses ja auch wiederum das Format - hier: das Einrahmungsformat - brechen würde.)
Puuuh, klingt komplizierter als es ist.
Was man hier jetzt eigentlich bräuchte, wäre eine [X] Ersetze keine Dateninhalte mit Format-Sonderbedeutung, denn ich weiß was ich tue-Option. und Sie könnten dann bei Chr$(13) + Chr$(10) bleiben und alles ist erledigt.
Spoiler: für diesen Wunsch habe wir aktuell einfach keine Ressourcen, aber evtl. fällt uns noch was simples Kreatives ein… Falls Sie als Einrahmungszeichen z.B. den „\“ auswählen könnten, weil das z.B. garantiert in Ihren Daten nicht vorkommt, dann könnten Sie dies tun und am Ende in der Datei alle „\“ durch „“ (nichts) ersetzen. Dann sollte alles passen.
Gibt es eine Möglichkeit, nach dem Export automatisch ein Skript laufen zu lassen, das die Datei „nachbearbeitet“, sprich: existiert ein Ereignis, das durch den Export angestoßen wird und das ich für diesen Zweck verwenden kann?
Ansonsten schreibe ich den Export selber. Der lästigste Teil daran ist wohl, dass ich das ganze Drumherum (Standardpfad, Dateinamen,…) bereitstellen muss. Im Assistenten ist das alles schon da…
Mir ist es wichtig, dass die Datei einfach (halb-)automatisch weiterverarbeitet werden kann, der damit betraute Anwender soll nicht auch noch an eine Formatkonversion denken müssen.
Aber das „Expertenhäkchen“ gefällt mir gut… Bei den Ideen bekäme es ein Upvote von mir
Ich glaube einen Event gibt es nicht, zumindest daucht er bei mir nicht auf.
Du kannst aber die SDK-Methode Export verwenden.
Dann wäre der „Workflow“ in deinem Script drin.
Diese Idee (also nicht das Skript abhängig vom Export sondern den Export abhängig vom Skript) ist super — aber leider zu spät.
Ich habe gestern den Export ausprogrammiert, ich muss also den cRM-Assistenten nicht mehr mit Gewalt an meine Bedürfnisse anpassen.
Abschließend (auch wenn Sie mittlerweile den Export per Script ausprogrammiert haben) kann ich berichten, dass die Ersetzung ab Version 12 durch ein ESCAPE-Zeichen (Chr$(27)) unterdrückt werden kann:
Chr$(27)+Chr$(13)+Chr$(10) wird also einen CR+LF Zeilenumbruch exportieren, anstatt dass zum Schutz der Konsistenz des Formats CR+LF in „_“ gewandelt wird.
[Verbesserung] {Export} Beim Textexport wurden Spaltentrenner und Zeilentrenner in Feldformeln automatisch durch Unterstriche ersetzt, um das Format nicht zu brechen. Nun kann im Einzelfall mit dem zusätzlichen Präfix Chr$(27) in der Formel explizit diese Ersetzung verhindert werden.
Sie möchten einerseits einzelne „Felder“ ein-und-desselben Datensatzes untereinander per Zeilenumbruch exportiert bekommen, andererseits sollen aber auch die Datensätze an sich untereinander per Zeilenumbruch getrennt exportiert werden. Und darüber hinaus sollen aber ggf auch keine Leerzeilen erzeugt werden, so dass Sie innerhalb der zu exportierenden „Feldes“ selbst per Formel dann auch nochmals Hand anlegen und zusätzlich nochmal eigene Zeilenumbrüche auslösen können wollen.
.
=> woher kommen dann die (anderen) standalone-CRs (ohne LF), wenn die nicht vom Exporter-Datensatzende herrühren?
und Sie könnten dann bei Chr$(13) + Chr$(10) bleiben und alles ist erledigt.