08-04-2009 8:49 PM
Hi ABAP masters,
working in database support for several years I've very often seen the problems that arise from the awkward data type NUMC.
A numeric type stored as characters.
What I always wondered is: what is this data type really good for?
The leading zero output display alone is hardly a valid reason to waste storage and complicate the usage of the data of that type.
I cannot imagine any use for this data type that wouldn't be better done by using integer types.
So, if you know what the reasoning behind this data type is, please let me know.
thanks and best regards,
Lars
08-04-2009 9:25 PM
Hi Lars,
Although it is indeed complicated in handling that data objects, there are some places where using them is better choice that using char types. I.e
- postal codes
- PO box numbers
- screen fields where only digits are allowed
Ok, you may say that above are examples of leading zeros usage but it's much easier to handle them as strings as well. When concatenating we don't have to worry about zeros we might forget in front of data objects, which of course can change value we are interested in - if not provided.
Very often happend to me that in excel when comparing some values (after importing some data file) I forgot about leading zeros (i.e for some SUBTYPE field) which turned out be a pay in the neck before I indentified the issue. That's why I really appreciate N type in ABAP
Also range should be of special importance here. Max bytes for N is 65535, while for integer is only 4 bytes, which implies what a®s said about field length.
Regards
Marcin
08-04-2009 9:00 PM
One advantage for NUMC will be maximum length
NUMC = 1-255
I think for Integer
INT1 = 3
INT2 = 5
INT4 = 10
a®
08-04-2009 11:11 PM
Hello a®s,
that sounds reasonable, although I get the feeling that this is your best guess, is it?
But can you do anything with such large numbers (arithmetic operations?) or can you just store and retrieve them?
thanks and best regards,
Lars
08-04-2009 9:21 PM
From what I understand, SAP can't buffer the tables unless the keys are in character type. The use of a numeric type with leading zeros stored as character is then necessary.
Altough I think I haven't seen an standard table key declared as numc, when that is necessary the alpha conversion is used against a character field
08-04-2009 11:01 PM
> Altough I think I haven't seen an standard table key declared as numc, when that is necessary the alpha conversion is used against a character field
Hi Ramiro,
ahem... MANDT is NUMC, BUKRS is NUMC ...
regards,
Lars
---> I've to take that back a bit... MANDT is indeed CLNT (the 3 character version of NUMC...)
Edited by: Lars Breddemann on Aug 5, 2009 12:02 AM
08-04-2009 9:25 PM
Hi Lars,
Although it is indeed complicated in handling that data objects, there are some places where using them is better choice that using char types. I.e
- postal codes
- PO box numbers
- screen fields where only digits are allowed
Ok, you may say that above are examples of leading zeros usage but it's much easier to handle them as strings as well. When concatenating we don't have to worry about zeros we might forget in front of data objects, which of course can change value we are interested in - if not provided.
Very often happend to me that in excel when comparing some values (after importing some data file) I forgot about leading zeros (i.e for some SUBTYPE field) which turned out be a pay in the neck before I indentified the issue. That's why I really appreciate N type in ABAP
Also range should be of special importance here. Max bytes for N is 65535, while for integer is only 4 bytes, which implies what a®s said about field length.
Regards
Marcin
01-13-2014 5:18 AM
02-25-2014 2:39 PM
if 5A is assigned to BUKRS it will be stored in DB as 5A only
Example:
PARAMETERS p_year TYPE I. "instead of Integer we can use type N LENGTH 4 also here
DATA v_month TYPE N LENGTH 2.
DATA v_day TYPE N LENGTH 2.
DATA v_year TYPE N LENGTH 4. then calculations will be easy
DATA FDATE TYPE D.
v_year = p_year.
v_day = 1. "1st day of Month
DO 12 TIMES.
v_month = sy-index. "Leading zero will be added automatically
CONCATENATE v_year v_month v_day INTO FDATE.
WRITE / FDATE. "Every month 1st day of selected year
ENDDO.
Example: Customer number contains uneven digits. It should be converted to a 10 digit number
with "C" as 1st Character. Logic will be
PARAMETERS custno TYPE I.
DATA v1 TYPE N LENGTH 10.
DATA str_custno TYPE C LENGTH 11.
v1 = custno. "customer number will be converted to 10 digit number
CONCATENATE 'C' V1 INTO str_custno.
please correct me, if I am wrong
Thanks and Regards
Nagababu Tubati
02-25-2014 3:28 PM
Hi,
Numc fields can be concatenated.
Have a look at http://scn.sap.com/docs/DOC-47512 and the program included :
*----------------------------------------------------------------------*
TYPES: BEGIN OF tp_vald_1 .
* Note the RENAMING WITH SUFFIX .
INCLUDE TYPE tp_ent_xxx AS ent_001 RENAMING WITH SUFFIX _ent_001 .
INCLUDE TYPE tp_ent_xxx AS ent_002 RENAMING WITH SUFFIX _ent_002 .
INCLUDE TYPE tp_ent_xxx AS ent_003 RENAMING WITH SUFFIX _ent_003 .
INCLUDE TYPE tp_ent_xxx AS ent_004 RENAMING WITH SUFFIX _ent_004 .
INCLUDE TYPE tp_ent_xxx AS ent_005 RENAMING WITH SUFFIX _ent_005 .
INCLUDE TYPE tp_ent_xxx AS ent_006 RENAMING WITH SUFFIX _ent_006 .
INCLUDE TYPE tp_ent_xxx AS ent_007 RENAMING WITH SUFFIX _ent_007 .
INCLUDE TYPE tp_ent_xxx AS ent_008 RENAMING WITH SUFFIX _ent_008 .
INCLUDE TYPE tp_ent_xxx AS ent_009 RENAMING WITH SUFFIX _ent_009 .
INCLUDE TYPE tp_ent_xxx AS ent_010 RENAMING WITH SUFFIX _ent_010 .
INCLUDE TYPE tp_ent_xxx AS ent_011 RENAMING WITH SUFFIX _ent_011 .
INCLUDE TYPE tp_ent_xxx AS ent_012 RENAMING WITH SUFFIX _ent_012 .
INCLUDE TYPE tp_ent_xxx AS ent_013 RENAMING WITH SUFFIX _ent_013 .
col_pos TYPE n LENGTH 3 ,
CONCATENATE 'ENT_' <st_alv_hdrc_1>-col_pos INTO fieldname .
* Get specific week entry
ASSIGN COMPONENT fieldname OF STRUCTURE st_bffr_8 TO <st_ent_xxx> .
<st_ent_xxx>-paymentsum = <st_sflight>-paymentsum .
Regards .
02-25-2014 4:33 PM
Dear all
I am quite surprised to see this ancient thread coming to life again
In order to close the thread I assigned "correct answer" now to the first 'grave digger' from 2012 and "helpful answer" to every other contributor. Please note that this is not meant as a valuation of your contribution, I really appreciate every one of them.
My conclusion is: NUMC is handy for list processing of formatted numbers - just that .
As it is in principle possible to convert NUMC to a numeric data type and vice versa, there is not a hard functional limitation present with numeric data types.
NUMC simply is more easy to use for certain use cases.
Thanks again everybody,
Lars
12-15-2022 12:01 AM