topic Re: Avoid convt_no_number in Application Development and Automation Discussions

Avoid convt_no_number

franzs — Mon, 11 May 2015 12:25:51 GMT

Hello,

I want to avoid a short dump of type convt_no_number.

I've found that solution:


  DATA: gv_to_convert TYPE string VALUE 'abc',
        gv_int        TYPE p LENGTH 6 DECIMALS 3.

  TRY.
      gv_int = gv_to_convert.
    CATCH cx_sy_conversion_no_number.
      WRITE 'not a number'.
  ENDTRY.

Is there another cleaner solution? I'm searching e. g. a method like is_numeric().

Of course I can encapsulate the coding above in a own method ...

But is there any SAP method or function module for that check?

I searched in cl_abap* classes, but I didn't found anything.

Regards

Franz

Re: Avoid convt_no_number

alisson_fragozo — Mon, 11 May 2015 12:59:39 GMT

Hi Franz,

Use the CO operator, ex:

IF variable CO '0123456789'.

WRITE: 'Is a number!'.

ENDIF.

Re: Avoid convt_no_number

Former Member — Mon, 11 May 2015 13:18:26 GMT

Well, that won't work with 123.45

Rob

Re: Avoid convt_no_number

alisson_fragozo — Mon, 11 May 2015 13:28:29 GMT

DATA: variable TYPE string VALUE '123.45'.

DATA: length TYPE i,

last TYPE i.

last = length = STRLEN( variable ).

SUBTRACT 1 FROM last.

IF variable(length) CO '1234567890.'

AND variable+last(1) NE '.'

AND variable(1) NE '.'.

WRITE:/ 'Is a number'.

ENDIF.

Re: Avoid convt_no_number

Former Member — Mon, 11 May 2015 13:33:23 GMT

Well, I think the OP is asking for a cleaner solution.

And I don't think it works for "1234.567.89"

Rob

Message was edited by: Rob Burbank

Re: Avoid convt_no_number

RaymondGiuseppi — Mon, 11 May 2015 14:12:06 GMT

Decimal, Thousands Separators and minus sign (leading/trailing) can also be language/country dependant. So I suppose the OP hopes for a standard method/function module that manage that as well as overflow.

But, I only find some method that use the TRY/MOVE/CATCH/ENDTRY syntax themselevs as IN CL_DBA_FORMAT=>IS_NUMERIC or similar methods...

data:
     num    type p.
   try.
     num = value.
     numeric = abap_true.
    catch cx_sy_conversion_no_number.
     numeric = abap_false.
    catch cx_sy_conversion_overflow.
     numeric = abap_false.
   endtry.

So in original code, replaced with

DATA: gv_to_convert TYPE string VALUE 'abc.
 IF cl_dba_format=>is_numeric( value = gv_to_convert ) EQ abap_false.
   WRITE 'not a number'.
 ENDIF.

Regards,

Raymond

Re: Avoid convt_no_number

naimesh_patel — Mon, 11 May 2015 14:36:41 GMT

Even this doesn't work with 12,345.67


data: lo_check type ref to CL_DBA_FORMAT.

 create OBJECT lo_check.
 if lo_check->is_numeric( '12,345.67' ) = 'X'.
 write: 'Good'.
 else.
   write: 'not a number'.
ENDIF.

I think the logic needs to remove commas, dots, signs; if it raises cx_sy_conversion_no_number and try again.

Regards,
Naimesh Patel

Re: Avoid convt_no_number

Former Member — Mon, 11 May 2015 15:22:59 GMT

Hi,

I think Raymond suggestion is the best. The class CL_DBA_FORMAT=>IS_NUMERIC will work as required. Just remember to write the input number to system format before calling the method.

Example: 12,345.67, or 12.234,67, etc.. To 12345.67

Regards,

Thales Schmidt

Re: Avoid convt_no_number

franzs — Mon, 11 May 2015 15:32:55 GMT

Hi Raymond,

yes, you're right - I'm searching a standard method.

The solution with "IF ... CO .." seems not to solve the problem. There're to much country dependant possibilities ...

As Naimesh Patel wrote - cl_dba_format=>is_numeric don't work neither.

Regards

Franz

Re: Avoid convt_no_number

franzs — Mon, 11 May 2015 15:34:36 GMT

Hi Thales Schmidt,

but how can I convert the input number into the correct format?

The input is entered by the user ...

Regards

Franz

Re: Avoid convt_no_number

naimesh_patel — Mon, 11 May 2015 15:39:46 GMT

How about this type of implementation? I gave one more try when conversion error occurs after removing the dots, commas, and sign.


*
 CLASS lcl_format DEFINITION.
   PUBLIC SECTION.
     CLASS-METHODS:
       is_numeric
         IMPORTING value TYPE any
         RETURNING value(numeric) TYPE flag.
 ENDCLASS.                    "lcl_format DEFINITION


 START-OF-SELECTION.
   IF lcl_format=>is_numeric( '23,123.45-' ) = 'X'.
     WRITE: 'number'.
   ELSE.
     WRITE: 'no'.
   ENDIF.

 *
 CLASS lcl_format IMPLEMENTATION.
   METHOD is_numeric.

     DATA:
       num    TYPE p DECIMALS 5,
       c_num  TYPE string.

     TRY.
         num = value.
         numeric = abap_true.
       CATCH cx_sy_conversion_no_number.
         "one more try
         c_num = value.
         REPLACE '-' WITH '' INTO c_num.
         REPLACE ALL OCCURRENCES OF '.' IN c_num WITH ''.
         REPLACE ALL OCCURRENCES OF ',' IN c_num WITH ''.
         numeric = lcl_format=>is_numeric( c_num ).
         "fail safe to avoid loops
         if numeric is INITIAL.
           exit.
         endif.
       CATCH cx_sy_conversion_overflow.
         numeric = abap_false.
     ENDTRY.

   ENDMETHOD.                    "is_numeric
 ENDCLASS.                    "lcl_format IMPLEMENTAT

Regards,
Naimesh Patel

Re: Avoid convt_no_number

Former Member — Mon, 11 May 2015 16:46:20 GMT

Hi,

It depends on your location, and how users will enter the information.

For example, here in Brazil, users use comma to separate decimals and point to separate the thousands.

123.345,67

TRANSLATE number USING '. ,.'.

CONDENSE number NO-GAPS.

The above command would do the job.

If the input field is CHAR, you can also use the FM SCP_REPLACE_STRANGE_CHARS to replace strange characters. Or write a logic using the abap instruction REPLACE (using sy-abcde for example) to avoid letters.

But I think this solution is not what you are looking for, since you want a cleaner solution.

Regards,

Thales Schmidt

Re: Avoid convt_no_number

former_member432694 — Mon, 11 May 2015 17:35:12 GMT

Hi Franz,

You can use the function module 'CATS_NUMERIC_INPUT_CHECK'

Regards,

Yücel Vangölü

Re: Avoid convt_no_number

franzs — Tue, 12 May 2015 06:40:05 GMT

Thanks Naimesh Patel.

But this doesn't seems to be cleaner to me ...

Re: Avoid convt_no_number

franzs — Tue, 12 May 2015 06:42:54 GMT

Hi Thales Schmidt,

thank you for your idea.

But I think the cleanest solution is up to now to use the try/catch-logic.

Maybe an exception is not as evil as I think.

Regards

Franz

Re: Avoid convt_no_number

franzs — Tue, 12 May 2015 06:44:05 GMT

Hi Yücel Vangölü,

thank you for your hint.

But it doesn't work for '123,456.78'.

Regards

Franz

Re: Avoid convt_no_number

buddhika_krishantha — Tue, 12 May 2015 06:49:36 GMT

Use FM "NUMERIC_CHECK".

Re: Avoid convt_no_number

custodio_deoliveira — Tue, 12 May 2015 06:55:21 GMT

Just a tiny bit cleaner (in case you are in 740 SP5 or above):

DATA: gv_to_convert TYPE string VALUE 'abc.
IF NOT cl_dba_format=>is_numeric( gv_to_convert ).
WRITE 'not a number'.
ENDIF.

Cheers,

Custodio

Re: Avoid convt_no_number

matt — Tue, 12 May 2015 07:00:11 GMT

Exceptions aren't evil in this case at all. It's the simplest, cleanest solution.

btw - to convert '123,456.789' to a number, use WRITE - left-justified no-grouping. That way you're not concerned with the users decimal/grouping setting.

Re: Avoid convt_no_number

franzs — Tue, 12 May 2015 07:18:49 GMT

Hi Buddhika Krishantha,

tanks, but seems to work only for integer values.

Regards

Franz