Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Convert variable

Former Member
0 Kudos

Hi,

I need to convert a variabel.

p_lifnr is now 123999.

I need it to be 0000123999.

Is there any FM that can fix this ?

select * from EKKO where lifnr = p_lifnr.

//Martin

1 ACCEPTED SOLUTION

former_member214131
Active Contributor
0 Kudos

Hello,

If LIFNR is defined as type: char, then FM CONVERSION_EXIT_ALPHA_INPUT will pad the variable with leading zeros.

Regards, Murugesh AS

8 REPLIES 8

Former Member
0 Kudos

Hi Martin,

data l_lifnr(10) type n.
move p_lifnr to l_lifnr.

Now <b>l_lifnr</b> will contain the data in the format that you require.

Regards,

Anand Mandalika.

andreas_mann3
Active Contributor
0 Kudos

hi,

there's a form routine:

PERFORM ALPHAFORMAT(SAPFS000) USING p_lifnr p_lifnr .

regards Andreas

Message was edited by: Andreas Mann

former_member214131
Active Contributor
0 Kudos

Hello,

If LIFNR is defined as type: char, then FM CONVERSION_EXIT_ALPHA_INPUT will pad the variable with leading zeros.

Regards, Murugesh AS

0 Kudos

Hi everybody,

You *all* are right. I only try to make my tiny contribution.

Generally speaking, every domain (associated to a data element, associated to a field of a table) can have its own conversion routine.

For instance, take a look into domain LIFNR (thru transaction SE12). At frame "Output characteristics", pls watch field "Conversion routine". In this case, it shows "ALPHA". That means there should be (at least) two function modules, one for input->output, the other one for output->input. In fact, if you double-click onto this field, you will get a matchcode with such function modules.

I personally use these function modules instead of filling out with zeroes manually.

Please let us know if it helped. Best regards,

Alvaro

Former Member
0 Kudos

Hello Martin,

There's one thing that you need to observe. If you are talking about the SAP standard field LIFNR, then the field will already contain the zeroes prefixed. The only thing is that you don't get to see it when you display it, say for example on the list. Just look at the following example, which might be a bit amusing to you.

data : p_lifnr type lifnr.

select single lifnr
  from lfa1
  into p_lifnr
 where lifnr gt 1. " Just to make sure that you select a numeric value"


write p_lifnr.

skip 2.
* We know thast LIFNR is 10 characters long.
do 10 times.
  write : / p_lifnr+0(sy-index).
enddo.

I shall leave the reasoning to you, coz I trust it's good fun <i>trying</i> to discover what happens <i>behind the screens..</i> Just see if you can make sense out of it. And get back if you have some doubts.

Regards,

Anand Mandlaika.

P.S: BTW, if you already know how this whole thing works, then I'm sorry for assuming that you may not have known it .

christian_wohlfahrt
Active Contributor
0 Kudos

Hi!

Unfortunately you're <b>NOT</b> all right.

If lifnr contains at least one character (not only numbers), then NO leading zeros will be added by conversion_exit_alpha_input. That's the only correct handling, approach with variable type n is not working for all circumstances.

Regards,

Christian

0 Kudos

Hello Christian,

Obviously the comment that I have made put in the code (for the WHERE clause of the SELECT statement) in my explanation above was not articulate enough. I <b>did</b> mean that LIFNR would have to be a <i>numeric</i> value for the logic to work. But yes, the where condition is not <u><i>sufficient</i></u> to discard the alpha-numeric values for LIFNR.

Secondly, though <i>possible</i>, I did not consider it <i>likely</i> that LIFNR would have an alpha-numeric value (in which case I should've probably omitted the WHERE clause altogether, you say?:-)).

Regards,

Anand Mandalika.

christian_wohlfahrt
Active Contributor
0 Kudos

Hello Anand,

I guess, I made my sentence to short:

instead of 'not all right' -> 'not everyone was right' (or something like this) - I like to direct your focus on cases with characters.

Example code of Anand can be extended by using no where-clause - but who wants to write 20 000 vendors.

To show some examples:

Internal External

'1-001 ' '1-001 '

'30A001 ' '30A001 '

'0000000001' '1 '

'0000001001' '1001 '

Like Alvaro already mentioned: a lot of fields follow conversion rule alpha (e.g. mara-matnr). There will be customers, which use combinations of chars and nums; be careful (in general, not just Anand ).

By the way: FM CONVERSION_EXIT_ALPHA_INPUT calls immediatly a system function (C-routine), so performance should be very good.

Regards,

Christian

P.S.: I didn't mean to offend you