OK - the situation is that I need asset data from ANLA/B/C/H/U/V/Z in a 4.6 system, but politics won't allow me to get on the 4.6c box to write an extract that will directly create the "baltd" record required by the SAP asset program RAALTD11_UNICODE.
So I've got to use SE16 extracts from the asset tables, and because the volume of data is high, I've got to use ALV List output preference instead of ALV grid.
So I run an extract and choose "local file" off the toolbar, then choose "spreadsheet", and wind up with what I think is a nice tab-delimited file on the desktop.
Problem is - for 3 and 4 byte NUMC fields, SE16 puts them out right-justified in 5-byte fields with leading spaces, and for 8-byte NUMC fields, SE16 puts them out right-justified in 10-byte fields with leading spaces.
(No I know what you're thinking ... but Excel is NOT replacing leading zeroes with spaces - I'm opening the file directly in Excel and going thru the dialog to declare the input fields as text before the spreasheet pops - AND - this dialog is preserving leading zeroes in all other cases where there are zeroes in the input, like for main asset number anla-anln1.)
The above behavior is the case even when the NUMC field is completely filled in the database, like '2010' in anla-urjhr - it comes out on the desktop as ' 2010'.
Is this because SE16 is leaving space for signs?
Or is it a 4.6 idiosyncrasy that's been subsequently corrected?
Or is it just a "feature" that "we the unwary" have to deal with when we try to use SE16 instead of a real extract program, forgetting that it's always "pay me now or pay me later" in the IT business?
