Formatierung bei Itab in CSV
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Ich gebe mit CL_RSDA_CSV_CONVERTER=>STRUCTURE_TO_CSV eine Itab für Excel aus, das klappt soweit, nur mit einigen Feldtypen gibt’s Probleme:
• Datum wird als 20230701 ausgegeben
• Betrag wird teils als Datum „10.Nov“ behandelt 😃 ansonsten zB -450.12 und nicht mit Komma
• Ein Wert mit 31 Stellen davon 16 Dezimale (Entfernung in km) wird 560,1234500000 KM als 560.123.450.0000 ausgegeben
Im nachhinein im Programm an der Formatierung rumzudödeln gefällt mir garnicht, geht die typbezogene Formatierung irgendwie eleganter? Ich möchte nicht dass die User da noch ewig in Excel rumformatieren müssen.
• Datum wird als 20230701 ausgegeben
• Betrag wird teils als Datum „10.Nov“ behandelt 😃 ansonsten zB -450.12 und nicht mit Komma
• Ein Wert mit 31 Stellen davon 16 Dezimale (Entfernung in km) wird 560,1234500000 KM als 560.123.450.0000 ausgegeben
Im nachhinein im Programm an der Formatierung rumzudödeln gefällt mir garnicht, geht die typbezogene Formatierung irgendwie eleganter? Ich möchte nicht dass die User da noch ewig in Excel rumformatieren müssen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4370 / 221 /
1174
)
»
Es geht schon "besser" ... wenn man es selber macht ;)
Die ganzen ABAP to CSV Lösungen in SAP haben immer den einen oder anderen Schönheitfehler der sie meines Erachtens nicht 100% nutzbar erscheinen lassen.
Warum der SAP_CONVERT_TO_CSV für mich generell durchfällt habe ich bereits eingehend erklärt: https://www.abapforum.com/forum/viewtop ... 18&t=25508
Die CL_RSDA_CSV_CONVERTER=>STRUCTURE_TO_CSV finde ich auch nicht das gelbe vom Ei, weil man da die Formatierungen, die Excel haben möchte, nicht sauber reinbekommt (z.B: Datum). Von führenden Nullen ganz zu schweigen und zudem ist das Default-Trennzeichen für Felder der Beistrich und nicht der Strichpunkt wie es im CSV eigentlich vorgesehen ist.
Womit aber jeder CSV Export den ich in SAP kenne, Probleme hat, ist die Textauszeichnung und die Maskierung von Sonderzeichen. Immer wenn das Datensatztrennzeichen (z.B. CR+LF) oder das Feldtrennzeichen im Inhalt vorkommt, muss der gesamte Wert unter Hochkomma (") gesetzt werden. Und wenn ein Hochkomma vorkommt, muss ein doppeltes Hochkomma verwendet werden.
Zu deinen Problemen:
Ein Datum könntest du vor deinem Export formatiert in ein eigenes Char-Feld schreiben.
Dezimaltrennzeichen werden in Excel anhand der Systemsprache ermittelt. Daher ist bei einem deutschen Excel auch ein Beistrich zu verwenden. In SAP kann man die Sprachumgebung auslesen und dann entsprechend wiederum in ein eigenes Char-Feld den richtig formatierten Text ausgeben.
Lange Zahlen (und auch führende Nullen) müssen als Text formatiert werden, damit Excel diese nicht abschneidet. Auch hier hilft ein eigenes Char-(oder String)-Feld und den Inhalt unter Hochkommas angeben. Für führende Nullen gibt es noch einen Trick indem man den Inhalt als Berechnung formatiert ("=""0001002""").
Die ganzen ABAP to CSV Lösungen in SAP haben immer den einen oder anderen Schönheitfehler der sie meines Erachtens nicht 100% nutzbar erscheinen lassen.
Warum der SAP_CONVERT_TO_CSV für mich generell durchfällt habe ich bereits eingehend erklärt: https://www.abapforum.com/forum/viewtop ... 18&t=25508
Die CL_RSDA_CSV_CONVERTER=>STRUCTURE_TO_CSV finde ich auch nicht das gelbe vom Ei, weil man da die Formatierungen, die Excel haben möchte, nicht sauber reinbekommt (z.B: Datum). Von führenden Nullen ganz zu schweigen und zudem ist das Default-Trennzeichen für Felder der Beistrich und nicht der Strichpunkt wie es im CSV eigentlich vorgesehen ist.
Womit aber jeder CSV Export den ich in SAP kenne, Probleme hat, ist die Textauszeichnung und die Maskierung von Sonderzeichen. Immer wenn das Datensatztrennzeichen (z.B. CR+LF) oder das Feldtrennzeichen im Inhalt vorkommt, muss der gesamte Wert unter Hochkomma (") gesetzt werden. Und wenn ein Hochkomma vorkommt, muss ein doppeltes Hochkomma verwendet werden.
Zu deinen Problemen:
Ein Datum könntest du vor deinem Export formatiert in ein eigenes Char-Feld schreiben.
Dezimaltrennzeichen werden in Excel anhand der Systemsprache ermittelt. Daher ist bei einem deutschen Excel auch ein Beistrich zu verwenden. In SAP kann man die Sprachumgebung auslesen und dann entsprechend wiederum in ein eigenes Char-Feld den richtig formatierten Text ausgeben.
Lange Zahlen (und auch führende Nullen) müssen als Text formatiert werden, damit Excel diese nicht abschneidet. Auch hier hilft ein eigenes Char-(oder String)-Feld und den Inhalt unter Hochkommas angeben. Für führende Nullen gibt es noch einen Trick indem man den Inhalt als Berechnung formatiert ("=""0001002""").
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
deejey
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
ok, habs schon geahnt ... der Kunde hat leider auch nicht abap2excel, das hat einige coole Sachen zu bieten.
Dieses SAP-Gerümpel geht mir so auf den Senkel ich will Fußball spielende Roboter programmieren und nicht so einen Schmarrn 😎
Dieses SAP-Gerümpel geht mir so auf den Senkel ich will Fußball spielende Roboter programmieren und nicht so einen Schmarrn 😎
Beitrag
von DeathAndPain (Top Expert / 1904 / 247 /
407
)
»
Umm... das halte ich nicht für ein SAP-Problem, sondern für etablierte Definition von csv-Dateien. Excel und LibreOffice machen es nicht anders, wenn sie csv-Dateien erzeugen. So gesehen macht SAP es genau richtig.a-dead-trousers hat geschrieben: ↑18.07.2023 14:45Womit aber jeder CSV Export den ich in SAP kenne, Probleme hat, ist die Textauszeichnung und die Maskierung von Sonderzeichen. Immer wenn das Datensatztrennzeichen (z.B. CR+LF) oder das Feldtrennzeichen im Inhalt vorkommt, muss der gesamte Wert unter Hochkomma (") gesetzt werden.
Beitrag
von a-dead-trousers (Top Expert / 4370 / 221 /
1174
)
»
Irgendwie versteh ich dich jetzt nicht?DeathAndPain hat geschrieben: ↑20.07.2023 14:55Umm... das halte ich nicht für ein SAP-Problem, sondern für etablierte Definition von csv-Dateien. Excel und LibreOffice machen es nicht anders, wenn sie csv-Dateien erzeugen. So gesehen macht SAP es genau richtig.a-dead-trousers hat geschrieben: ↑18.07.2023 14:45Womit aber jeder CSV Export den ich in SAP kenne, Probleme hat, ist die Textauszeichnung und die Maskierung von Sonderzeichen. Immer wenn das Datensatztrennzeichen (z.B. CR+LF) oder das Feldtrennzeichen im Inhalt vorkommt, muss der gesamte Wert unter Hochkomma (") gesetzt werden.
Meinst du, Excel und LibreOffice machen es richtig indem sie die Trennzeichen NICHT maskieren?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1904 / 247 /
407
)
»
Ich glaube, das war ein Missverständnis. ich hatte Dich so verstanden, dass die SAP-Exporte das so machen und hatte daher eingewendet, dass das doch normal sei. Nach Deiner jetzigen Rückfrage begreife ich, dass Du es umgekehrt gemeint hast, dass die SAP-Exporte die Trennzeichen also nicht einfügen, obgleich dies eigentlich notwendig wäre.
Wenn das so sein sollte, war mir dieser Umstand bislang nicht bewusst. Tatsächlich geben meine Programme CSV an verschiedenste Systeme aus, und da ist nie ein Feedback hinsichtlich eines derartigen Problems zurückgekommen. Typische Empfängersysteme scheinen damit also klarzukommen. Wichtig ist nur, dass das Trennzeichen (typischerweise Semikolon, zuweilen auch das Tab-Symbol) nicht in den Nutzdaten vorkommen darf.
Wenn das so sein sollte, war mir dieser Umstand bislang nicht bewusst. Tatsächlich geben meine Programme CSV an verschiedenste Systeme aus, und da ist nie ein Feedback hinsichtlich eines derartigen Problems zurückgekommen. Typische Empfängersysteme scheinen damit also klarzukommen. Wichtig ist nur, dass das Trennzeichen (typischerweise Semikolon, zuweilen auch das Tab-Symbol) nicht in den Nutzdaten vorkommen darf.
Beitrag
von a-dead-trousers (Top Expert / 4370 / 221 /
1174
)
»
Und um genau diese Vorraussetzung geht es hier. Wenn man die nicht einhalten kann sind die SAP Bausteine schlicht und einfach unbrauchbar.DeathAndPain hat geschrieben: ↑26.07.2023 12:29Wichtig ist nur, dass das Trennzeichen (typischerweise Semikolon, zuweilen auch das Tab-Symbol) nicht in den Nutzdaten vorkommen darf.
Man müsste die Maskierung vorab mit einer eigenen Exportstruktur bzw. -tabelle erledigen um danach mit den SAP Bausteinen den tatsächlichen Export machen zu können. Das ist IMHO aber so aufwändig, dass man sich die SAP Bausteine gleich ganz schenken kann und den CSV Export am Besten einmal komplett selbst entwickelt so wie man es braucht. Diese Lösung kann man dann nach Bedarf auch wiederverwenden und der investierte Mehraufwand hat sich ganz schnell wieder amortisiert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1904 / 247 /
407
)
»
Na ja, man könnte einfach vor dem Aufruf einen REPLACE ALL OCCURRENCES OF ... IN TABLE ...-Befehl über die auszugebende Datentabelle laufen lassen und damit jegliche Vorkommen des Trennzeichens in den Nutzdaten mit der escapten Fassung ersetzen. Das wäre ein einziger Befehl. Anschließend könnte man dann den Standard-SAP-Baustein nutzen.
Beitrag
von a-dead-trousers (Top Expert / 4370 / 221 /
1174
)
»
Und was ist, wenn der Inhalt eines Feldes dadurch zu lange wird?
Außerdem funktioniert der Befehl nur für character-like oder byte-like Tabellen. Sobald ein anderer Datentyp verwendet wird (oder gemischt) funktioniert es schon nicht mehr.
Außerdem funktioniert der Befehl nur für character-like oder byte-like Tabellen. Sobald ein anderer Datentyp verwendet wird (oder gemischt) funktioniert es schon nicht mehr.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
30
Antw.
Antw.
14062
Views
Views
3
Antw.
Antw.
3484
Views
Views
5
Antw.
Antw.
4691
Views
Views
2
Antw.
Antw.
1672
Views
Views
3
Antw.
Antw.
1776
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CLFMAS: Change Pointer - Combining one or more Change Pointers in Single IDOC
vor 8 Stunden von gtoXX 2 / 7064
vor 8 Stunden von gtoXX 2 / 7064
Umherspringende Methoden im quelltextbasierten Class Builder
vor 8 Stunden von black_adept 96 / 7403
vor 8 Stunden von black_adept 96 / 7403
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CLFMAS: Change Pointer - Combining one or more Change Pointers in Single IDOC
vor 8 Stunden von gtoXX 2 / 7064
vor 8 Stunden von gtoXX 2 / 7064
Umherspringende Methoden im quelltextbasierten Class Builder
vor 8 Stunden von black_adept 96 / 7403
vor 8 Stunden von black_adept 96 / 7403