‎2009 Nov 01 1:40 PM
Hi All,
we are getting a short dump, can you please help me with this:
Runtime Errors CONVT_NO_NUMBER
Exception CX_SY_CONVERSION_NO_NUMBER
An exception occurred that is explained in detail below.
The exception, which is assigned to class 'CX_SY_CONVERSION_NO_NUMBER', w
caught in
procedure "SEL_BINPUT" "(FORM)", nor was it propagated by a RAISING clause.
Since the caller of the procedure could not have anticipated that the
exception would occur, the current program is terminated.
The reason for the exception is:
The program attempted to interpret the value "1,131.64 " as a number, but
since the value contravenes the rules for correct number formats,
this was not possible.
Whole numbers are represented in ABAP as a sequence of numbers, possibly
with an algebraic sign.
The following are the possibilities for the representation of floating
point numbers:
[algebraic sign][mantissa]E[algebraic sign][exponent]
[algebraic sign][whole number part].[fraction part]
For example, -12E+34, +12E-34, 12E34, 12.34
If the error occurred in your own ABAP program or in an SAP
program you modified, try to remove the error.
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"CONVT_NO_NUMBER" "CX_SY_CONVERSION_NO_NUMBER"
"SAPMF05B" or "MF05BFS0"
"SEL_BINPUT"
I looked into the notes but couldn't find any.
any help will be really appreciated.
Thank you.
Rajeev Gupta
‎2009 Nov 01 2:00 PM
Hi Rajeev,
1,131.64 looks like the external (US-english) representation of a number. This cannot be implicitly converted to a numeric fomat.
You can convert the value before moving it to the target. We do this as follows (generic solution). Usulayy we use it for generic handling of editable grid input, but it could help in your context:
DATA:
lv_type TYPE string,
lr_dat TYPE REF TO data,
ls_tabfield TYPE tabfield,
lv_tabname TYPE tabname,
lv_fieldname TYPE fieldname,
lv_field TYPE scrfname.
FIELD-SYMBOLS:
<dat> TYPE ANY.
* find any structure or table field with characteristics for the internal value
ls_tabfield-tabname = <table or structure of target field>.
ls_tabfield-fieldname = <fieldname in above structure or table>.
CONCATENATE <tbn> <col>
INTO lv_type SEPARATED BY '-'.
* create a data object of the required type
CREATE DATA lr_dat TYPE (lv_type).
ASSIGN lr_dat->* TO <dat>.
CALL FUNCTION 'RS_CONV_EX_2_IN'
EXPORTING
input_external = <Input value in external representation>
table_field = ls_tabfield
* CURRENCY = CURRENCY
IMPORTING
output_internal = <dat>
EXCEPTIONS
...
* handle any errorRegards,
Clemens
‎2009 Nov 01 2:00 PM
Hi Rajeev,
1,131.64 looks like the external (US-english) representation of a number. This cannot be implicitly converted to a numeric fomat.
You can convert the value before moving it to the target. We do this as follows (generic solution). Usulayy we use it for generic handling of editable grid input, but it could help in your context:
DATA:
lv_type TYPE string,
lr_dat TYPE REF TO data,
ls_tabfield TYPE tabfield,
lv_tabname TYPE tabname,
lv_fieldname TYPE fieldname,
lv_field TYPE scrfname.
FIELD-SYMBOLS:
<dat> TYPE ANY.
* find any structure or table field with characteristics for the internal value
ls_tabfield-tabname = <table or structure of target field>.
ls_tabfield-fieldname = <fieldname in above structure or table>.
CONCATENATE <tbn> <col>
INTO lv_type SEPARATED BY '-'.
* create a data object of the required type
CREATE DATA lr_dat TYPE (lv_type).
ASSIGN lr_dat->* TO <dat>.
CALL FUNCTION 'RS_CONV_EX_2_IN'
EXPORTING
input_external = <Input value in external representation>
table_field = ls_tabfield
* CURRENCY = CURRENCY
IMPORTING
output_internal = <dat>
EXCEPTIONS
...
* handle any errorRegards,
Clemens
‎2009 Nov 01 2:31 PM
Hie Rajeev
could you check the user settings for amounts in SU01.
Place break point at location in source code, run transaction and check what values
are contained in the variables containing the amounts, also
try and change the amount settings during runtime by replacing the commas
with periods and vice versa and see how the program reacts.
regards
Prince Isaac
‎2009 Nov 01 6:42 PM
... or use any other dirty method which will work sometimes but not always and will cause trouble from time to time.
Regards,
Clemens
‎2009 Nov 02 1:54 AM
Hi Rajeev, <li>In which version you are running the transaction or program. Because I found one note which may be suitable to you. <li>Check the OSS note 45831. This note describes exactly what the problem you have. Thanks Venkat.O
‎2009 Nov 02 3:15 AM
‎2009 Nov 02 3:00 PM
Hi rajeev,
Did you resolve this?
We had our EhP4 upgrade and am facing the same issue from the same program.
Please share the solution, if you find any.
Thanks,
Kiran
Edited by: kiran dasari on Nov 2, 2009 10:06 PM
‎2009 Nov 03 6:46 AM
http://www.sapnet.ru/abap_docu/ABENUEB-ABFB-SYSEXC.htm
or use
CATCH SYSTEM-EXCEPTIONS CONVT_NO_NUMBER .
ENDCATCH .
‎2009 Nov 03 7:04 AM
Hi Rajeev,
Use MOVE statement, and modify the internal table/variable, you are currently trying to process.
MOVE will convert the quantity value from user format to system format.
Before doing any calculations/processing, use MOVE statement.
And before final display as ALV output or IDOC, use WRITE statement to convert it into user settings.
One thing you need to take care is format of variables.
MOVE char20 to qty (eg: mara-meins)
WRITE qty (eg: mara-meins) to char20
Let us know if you are still unable to rectify this dump.
Thanks,
Nisha Vengal.
‎2009 Nov 03 7:52 AM
Hi Rajeev,
It's a great pity you did not mention what you actionally do to get the dump. Is it a SAP standard program, what are the (known) modifications/enhancements/exits/badis?
Did you do what the dump says (search for notes)?
Possibly the notes can help:
Note 45831 RFBIBL00 -> FB05 / CONVERT_NO_NUMBER
Note 774295 Dump CONVT_NO_NUMBER w/ select. by means of paym. adv. note
Kind regards,
Clemens