Skip to Content

OK – what’s the deal with NUMC fields in 4.6c SE11/SE16 extracts?

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?

You must be Logged on to comment or reply to a post.
  • Why don’t you use the SE16 Standard List display as opposed to ALV list/grid display. As far as I can see NUMC fields are displayed with leading zeros and these are retained when downloaded to Spreadsheet .XLS


    • Hi Che –

      Thanks for taking the time to reply.

      But in deference to Marilyn’s sense of propriety, I have answered the technical side of your question in an ABAP General forum post here:

      Answer to Che’s question about NUMC in SE16 exports from Standard Lists

      As you can see from the answer there, this matter is a very interesting example of how project politics can interact with project technical efforts in an unfortunate way.  (And as an apology to SAP and Marilyn, I probably should have blogged on this “political” aspect of the problem, rather than simply posting what appeared to be a “slam” at SAP.

      Here’s the political situation. 

      Due to the volume of data involved, SE16 should never have been used to try and extract data from the 4.6C legacy SAP system.  Rather, a “one-off” ABAP ‘foo” program should have been written.

      But on this particular project, the 4.6C legacy SAP system is not under control of the dev team doing the ECC 6 re-implementation, so the dev team would have had to ask a legacy programmer to write the extract  And this would have taken undue time.

      So for purely political reasons which are obviously not SAP’s fautl, I had to use SE16 even though it’s a misuse of the tool due to the volume of data involved.

      In general, this situation illustrates how 4.6C is SAP’s “ball and chain” (just like 370 BAL was IBM’s “ball and chain” for so many years.)

      There’s obviously no point in SAP going back and trying to fix every little problem in 4.6C, particularly when the problem results from a misuse of a particular tool, as in this particular case.

      So until the SAP customer base is dragged kicking and screaming to ECC 6, these kinds of issues are going to arise – again, particularly when project politics are involved.