Sunday, August 31, 2008

The Basics - What's RICEF?

What is RICEF? Many a times asked in interviews! Unfortunately a lot of people fail to answer a simple question, even though working on it for years.

You usually come accross the word RICEF when searching for SAP ABAP Developer jobs.RICEF isn't a standard SAP acronym. It's not defined by SAP like we have ABAP, ALV, etc. It's a comon term used to describe five areas of technical developments in SAP.

RICEF stands for Reports, Interfaces, Conversions, Enhancements, Forms.

R- ReportsR stands for Report developments. All the technical objects/developments that deal with programing of SAP Reports. It includes different types of reports; Simple reports where you output using WRITE statements, Simple ALV reports, ALV Grid, ALV Grid with advanced functionality,etc.

I - InterfacesI stands for Interface developments. Interfaces are ALE/IDOCs development. Involves not just ABAP programming for IDOCs but also IDOC customization.

C - ConversionC stands for conversion objects. Conversion refers to BDC programing. Data upload from legacy system in flat files format to SAP system is done via Conversion Objects. This involves uploading data through BDC, LSMW, BAPI, etc.

E - EnhancementsEnhancements are User Exits, Customer Exits, BADI's etc. ABAP code that has to be written in order to enhance SAP system functionality.

F - FormsForms include SAP Smartforms, SAP Scripts. Technical development that deals with fetching necessary data from SAP system and displaying in terms of forms for printout are classified as under Forms.

Common questions :-1. As an ABAPer, why do I care what RICEF means? What does it have to do with me?Well it's really simple. It's just that one must know the category of the technical development he is working upon.

2. What's the use of RICEF?SAP Project managers usually refer technical development in terms of RICEF objects.Project technical team leads usually distinguish the objects based on this categorization and assign them to team on basis of experience. Reports being a first choice for beginners and Enhancements being the favourite choice for experts.

CONVERSION : Legacy System To Flat File. INTERFACE : Flat File to SAP System. When you transfer legacy data into the R/3 System, you need to ensure that it is in the SAP format. There are several ways of doing this: Converting the data in the legacy system has the advantage that the user is familiar with the programming language that it uses. Converting the data in the R/3 System using ABAP has the advantage of automatic type conversion. You can use the structure definitions of the ABAP Dictionary directly. Converting the data with Excel. You can use this method for simple and complex conversions for flat structures. You use interfaces defined by SAP for the standard transfer. The legacy data must be delivered in a suitable format to supply these interfaces. The interface descriptions are defined in the R/3 System and the transfer method is developed and formulated according to these descriptions.

DIFFERENCE BETWEEN CONVERSION AND INTERFACE:

A Conversion means data that is converted from one format to another format and from one system to another.So when you first implement SAP, you are actually replacing some of your legacy systems, but you are not completely trashing the data. You still need some of that data from the systems that are being replaced. So you pull the data out of your legacy systems and put them on some files. You then want to load that data into your new SAP system.

That is when you write some programs which will read that data and load it into SAP. Imagine you had a home grown purchasing system. You are now replacing all that with SAP. But until SAP goes live, you want to keep using your home grown purchasing system.So during go live, you want to transfer the POs from your legacy system to SAP. Now a PO in your legacy system may not have the same fields as a PO in SAP. So you convert the data.

Ex: BDC,LSMW

Interfacing is connecting two or more different entities. In our case, it is connecting one or more systems with SAP. Now extending our previous example, you are replacing some legacy applications but there are some applications that you don't want to replace yet.You need to somehow pass data back and forth between SAP and these remaining systems. Data may be going one way or the other way or both ways. You will still need to do some data transformations/translations etc to make the data understandable to the receiving system.This will continue as long as you want to keep the systems running alongside SAP.

Ex: idoc,bapi

In short, conversions are written to load data into SAP onetime. These are typically file based.

Interfaces are written to exchange/update/send/receive data between SAP and other systems on an ongoing basis. These can be in many forms, file based, idoc based, real time(business connector, XI etc are useful in this), xml, and the list goes on.

 Input and Output Conversions  Depending on the data type of the field, there is a conversion when the contents of a screen field are converted from display format to SAP-internal format and vice versa. If this standard conversion is not suitable, it can be overridden by defining a conversion routine in the underlying domain.

Conversion routines are identified by a five-place name and are stored as a group of two function modules. The function modules have a fixed naming convention. The following function modules are assigned to conversion routine xxxxx:

CONVERSION_EXIT_xxxxx_INPUT CONVERSION_EXIT_xxxxx_OUTPUT

The INPUT module converts from display format to internal format, and the OUTPUT module converts from internal format to display format.

When is a Conversion Routine Executed?

If a screen field refers to a domain with a conversion routine, this conversion routine is executed automatically when entries are saved in this screen field or when values are displayed in this screen field. The conversion routine of the domain is also triggered when the field contents are output with the WRITE statement.

Table SPFLI in the flight model contains information about the flights offered by the carriers. The time for each flight is recorded in field FLTIME. Enter and display the time of the flight in input templates in the form HHH:MM (hours:minutes). Store the flight time entered in the database as an integer number (number of minutes of the flight). An entry 3:27 is therefore stored in the database as 207 (3 hours, 27 minutes = 207 minutes).

Field FLTIME refers to domain S_DURA, to which conversion routine SDURA is assigned. The value is thus converted by the two function modules CONVERSION_EXIT_SDURA_INPUT and CONVERSION_EXIT_SDURA_OUTPUT.

A conversion routine can also be triggered by specifying its five-place name in the attributes of a field in the Screen Painter or with the addition USING EDIT MASK <Name of conversion routine> in the WRITE command in the program. With the USING NO EDIT MASK addition in the WRITE statement, you can skip a conversion routine defined for a domain when outputting.

Parameters

The two function modules of a conversion routine must have precisely two parameters with the names INPUT and OUTPUT for the value to be converted and the converted value.

The INPUT parameter in the INPUT conversion and the OUTPUT parameter in the OUTPUT conversion should not have any reference fields because the value passed in the call could have a different length than that expected.

Programming Conversion Routines

ABAP statements that result in an interruption of processing (such as CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT, COMMIT WORK, ROLLBACK WORK, MESSAGE I, MESSAGE W) are not allowed in conversion routines.

Only A messages are meaningful in output conversion, but A, E and S messages can be triggered in input conversion (although S messages are not very meaningful here). E messages result in an error dialog. Exceptions are not intercepted in the call.

The output conversion is also triggered with WRITE and WRITE TO. The conversion routine may therefore occur very frequently with lists. The output conversion should therefore be programmed as efficiently as possible.

No external performs should be used in conversion routines. Programs that are called externally use the table work areas of the first calling main program. In conversion routines this can result in errors that cannot be easily analyzed since they are sometimes called at unpredictable times in the program flow.

Type Conversions Every time you assign a data object to a variable, the data types involved must either be compatible , that is, their technical attributes (data type, field length, number of decimal places) must be identical, or the data type of the source field must be convertible into the data type of the target field.

In ABAP, two non-compatible data types can be converted to each other if a corresponding conversion rule exists. If data types are compatible, no conversion rule is necessary.

If you use the MOVE statement to transfer values between non-compatible objects, the value of the source object is always converted into the data type of the target object. With all ABAP operations that perform value assignments between data objects (for example, arithmetic operations or filling internal tables), the system handles all the necessary type conversions as for the MOVE statement. If you try to assign values between two data types for which no conversion rule exists, a syntax error or runtime error occurs.

The following sections contain the conversion rules for incompatible ABAP data types:

Conversion Rules for Elementary Data Types

Conversion Rules for References

Conversion Rules for Structures

Conversion Rules for Internal Tables

With some ABAP statements that pass data between different objects, the alignment of the data objects is also important.

Alignment of Data Objects

 

Conversion Rules for Elementary Data Types  There are eight predefined ABAP data types. There are 64 possible type combinations between these elementary data types. ABAP supports automatic type conversion and length adjustment for all of them except type D (date) and type T (time) fields which cannot be converted into each other.

The following conversion tables define the rules for converting elementary data types for all possible combinations of source and target fields.

Source Type Character

Conversion table for source type C

Target ConversionC The target field is filled from left to right. If it is too long, it is filled with blanks from the right. If

it is too short, the contents are truncated at the right-hand end. D The character field should contain an 8-character date in the format YYYYMMDD .F The contents of the source field must be a valid representation of a type F field as described

in Literals .N Only the digits in the source field are copied. The field is right-justified and filled with trailing

zeros.I

P

The source field must contain the representation of a decimal number, that is, a sequence of digits with an optional sign and no more than one decimal point. The source field can contain blanks. If the target field is too short, an overflow may occur. This may cause the system to terminate the program.

T The character field should contain a 6-character time in HHMMSS format.X Since the character field should contain a hexadecimal-character string, the only valid

characters are 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. This character string is packed as a hexadecimal number, transported left-justified, and padded with zeros or truncated on the right.

 

Source Type Date

Conversion table for source type D

Target ConversionC The date is transported left-justified without conversion.D Transport without conversion.F The date is converted into a packed number. The packed number is then converted into a

floating point number (see corresponding table). N The date is converted into a character field. The character field is then converted into a

numeric text field (see corresponding table).I

P

The date is converted to the number of days since 01.01.0001.

T Not supported. Results in an error message during the syntax check or in a runtime error.X The date is converted to the number of days since 01.01.0001 in hexadecimal format.

 

Source Type Floating Point Number

Conversion table for source type F

Target ConversionC The floating point number is converted to the <mantissa>E<exponent> format and

transported to the character field. The value of the mantissa lies between 1 and 10 unless the number is zero. The exponent is always signed. If the target field is too short, the mantissa is

rounded. The length of the character field should be at least 6 bytes.D The source field is converted into a packed number. The packed number is then converted

into a date field (see corresponding table).F Transport without conversion.N The source field is converted into a packed number. The packed number is then converted

into a numeric text field (see corresponding table).I

P

The floating point number is converted to an integer or fixed point value and, if necessary, rounded.

T The source field is converted into a packed number. The packed number is then converted into a time field (see corresponding table).

X The source field is converted into a packed number. The packed number is then converted into a hexadecimal number (see corresponding table).

 

Source Type Integer

Type I is always treated in the same way as type P without decimal places. Wherever type P is mentioned, the same applies to type I fields.

 

Source Type Numeric Text

Conversion table for source type N

Target ConversionC The numeric field is treated like a character field. Leading zeros are retained.D The numeric field is converted into a character field. The character field is then converted into

a date field (see corresponding table).F The numeric field is converted into a packed number. The packed number is then converted

into a floating point number (see corresponding table).N The numeric field is transported right-justified and padded with zeros or truncated on the left.I

P

The numeric field is interpreted as a number, and transferred to the target field, where it is right-justified, and adopts a plus sign. If the target field is too short, the program may be terminated.

T The numeric field is converted into a character field. The character field is then converted into a time field (see corresponding table).

X The numeric field is converted into a packed number. The packed number is then converted into a hexadecimal number (see corresponding table).

 

Source Type Packed Number

If the program attribute Fixed point arithmetic is set, the system rounds type P fields according to the number of decimal places or fills them out with zeros.

Conversion table for source type P

Target ConversionC The packed field is transported right-justified to the character field, if required with a decimal

point. The first position is reserved for the sign. Leading zeros appear as blanks. If the target field is too short, the sign is omitted for positive numbers. If this is still not sufficient, the field is truncated on the left. ABAP indicates the truncation with an asterisk (*). If you want the leading zeros to appear in the character field, use UNPACK instead of MOVE.

D The packed field value represents the number of days since 01.01.0001 and is converted to a date in YYYYMMDD format.

F The packed field is accepted and transported as a floating point number.N The packed field is rounded if necessary, unpacked, and then transported right-justified. The

sign is omitted. If required, the target field is padded with zeros on the left.I

P

The packed field is transported right-justified. If the target field is too short, an overflow occurs.

T The packed field value represents the number of seconds since midnight and is converted to a time in HHMMSS format.

X The packed field is rounded if necessary and then converted to a hexadecimal number. Negative numbers are represented by the two's complement. If the target field is too short, the number is truncated on the left.

 

Source Type Time

Conversion table for source type T

Target ConversionC The source field is transported left-justified without conversion.D Not supported. Results in an error message during the syntax check or in a runtime error.F The source field is converted into a packed number. The packed number is then converted

into a floating point number (see corresponding table). N The date is converted into a character field. The character field is then converted into a

numeric text field (see corresponding table).I

P

The date is converted to the number of seconds since midnight.

T Transport without conversion.X The date is converted to the number of seconds since midnight in hexadecimal format.

 

Source Type Hexadecimal

Conversion table for source type X

Target ConversionC The value in the hexadecimal field is converted to a hexadecimal character string, transported

left-justified to the target field, and padded with zeros.D The source field value represents the number of days since 01.01.0001 and is converted to a

date in YYYYMMDD format.F The source field is converted into a packed number. The packed number is then converted

into a floating point number (see corresponding table).

N The source field is converted into a packed number. The packed number is then converted into a numeric text field (see corresponding table).

I

P

The value of the source field is interpreted as a hexadecimal number. It is converted to a packed decimal number and transported right-justified to the target field. If the hexadecimal field is longer than 4 bytes, only the last four bytes are converted. If it is too short, a runtime error may occur.

T The source field value represents the number of seconds since midnight and is converted to a time in HHMMSS format.

X The value is transported left-justified and filled with X'00' on the right, if necessary.

 

https://help.sap.com/saphelp_46c/helpdata/en/fc/eb3434358411d1829f0000e829fbfe/content.htm

Type Conversions  Every time you assign a data object to a variable, the data types involved must either be compatible , that is, their technical attributes (data type, field length, number of decimal places) must be identical, or the data type of the source field must be convertible into the data type of the target field.

In ABAP, two non-compatible data types can be converted to each other if a corresponding conversion rule exists. If data types are compatible, no conversion rule is necessary.

If you use the MOVE statement to transfer values between non-compatible objects, the value of the source object is always converted into the data type of the target object. With all ABAP operations that perform value assignments between data objects (for example, arithmetic operations or filling internal tables), the system handles all the necessary type conversions as for the MOVE statement. If you try to assign values between two data types for which no conversion rule exists, a syntax error or runtime error occurs.

The following sections contain the conversion rules for incompatible ABAP data types:

How to convert date format to MM/DD/YYYY This question is Not Answered.

Senthilkumar T N Nov 18, 2005 4:35 AM

Hi,

   How to convert date format to MM/DD/YYYY.

 

Thanks,

Senthil

Helpful Answer by sasikumar palanichamy

7043 Views o Topics: ABAP

Average User Rating(0 ratings)

Re: How to convert date format to MM/DD/YYYY

Vera Venkata Nekenti Nov 18, 2005 4:44 AM (in response to Senthilkumar T N)

WRITE: sy-datum MM/DD/YYYY

.

o Report Abuse o Like (0)

o Re: How to convert date format to MM/DD/YYYY

Senthilkumar T N Nov 18, 2005 4:51 AM (in response to Vera Venkata Nekenti)

Hi Venkat,

          I want to assign MM/DD/YYYY foramt to another variable. So is there is any function is available otherwise how to convert apart from using write statement.

 

Thanks,

Senthil

Report Abuse Like (0)

Re: How to convert date format to MM/DD/YYYY

Raghava Myneedu Nov 18, 2005 4:58 AM (in response to Senthilkumar T N)

Senthil ,

You can also try this

Date  =  YYYYMMDD

Concatenate date4(2) ‘ /’ date6(2) ‘/’  date(4) into Date2.

 

Cheers

Raghava

Report Abuse Like (0)

Re: How to convert date format to MM/DD/YYYY

Vera Venkata Nekenti Nov 18, 2005 5:00 AM (in response to Senthilkumar T N)

data : l_date(10) type c .

concatenate sy-datum6(2) '/' sy-datum4(2) '/' sy-datum(4) into l_date.

write : l_date.

o Report Abuse o Like (0)

Helpful Answer Re: How to convert date format to MM/DD/YYYY

sasikumar palanichamy Nov 18, 2005 5:05 AM (in response to Senthilkumar T N)

hi,

 

tri with this function module

 

data :l_date(10) type c

 

CALL FUNCTION 'CONVERT_DATE_TO_EXTERNAL'

EXPORTING

   DATE_INTERNAL                  = SY-DATUM

IMPORTING

   DATE_EXTERNAL                  = l_date.

 

 

this function module converts date from 20050601 to external format  which is specified in user profile

 

cheers,

sasi

o

ABAP - Function module for converting any External date format to Internal format

Added by Narendran Muthukumaran, last edited by Guest on Apr 26, 2007 (view change)

Author: Narendran MuthukumaranSubmitted: 04/25/2007

Description: This is function module can be used for converting any External date format to Internal format.

The following SAP's external formats which can be found in the user settings are supported in this function module.

DD.MM.YYYYMM/DD/YYYYMM-DD-YYYYYYYY.MM.DDYYYY/MM/DDYYYY-MM-DD

The function module needs to created with the parameters as mentioned in the code.

FUNCTION z_convert_to_internal_format.*"----------------------------------------------------------------------*"*"Local interface:*" IMPORTING*" VALUE(IM_INPUT) TYPE CHAR10*" EXPORTING*" VALUE(EX_OUTPUT) TYPE SYDATUM*" EXCEPTIONS*" INVALID_DATE*"----------------------------------------------------------------------

* Get the format.

* DD.MM.YYYY IF im_input+2(1) = '.'. CONCATENATE im_input+6(4) im_input+3(2) im_input(2) INTO ex_output. ENDIF.

* MM/DD/YYYY IF im_input+2(1) = '/'. CONCATENATE im_input+6(4) im_input(2) im_input+3(2) INTO ex_output. ENDIF.

* MM-DD-YYYY IF im_input+2(1) = '-'. CONCATENATE im_input+6(4) im_input(2) im_input+3(2) INTO ex_output.

ENDIF.

* YYYY.MM.DD IF im_input+4(1) = '.'. CONCATENATE im_input(4) im_input+5(2) im_input+8(2) INTO ex_output. ENDIF.

* YYYY/MM/DD IF im_input+4(1) = '/'. CONCATENATE im_input(4) im_input+5(2) im_input+8(2) INTO ex_output. ENDIF.

* YYYY-MM-DD IF im_input+4(1) = '-'. CONCATENATE im_input(4) im_input+5(2) im_input+8(2) INTO ex_output. ENDIF.

* Check the valid date. CALL FUNCTION 'DATE_CHECK_PLAUSIBILITY' EXPORTING date = ex_output EXCEPTIONS plausibility_check_failed = 1 OTHERS = 2.

* Check if the output parameter is populated. otherwise raise an* exception. IF ex_output IS INITIAL OR sy-subrc <> 0. RAISE invalid_date. ENDIF.

ENDFUNCTION.

TABLES vbak.

DATA :BEGIN OF itab OCCURS 0,      vbeln LIKE vbak-vbeln,      erdat LIKE vbak-erdat,      END OF itab.

DATA :l_date(10) TYPE c.

SELECT-OPTIONS: s_vbeln FOR vbak-vbeln.

SELECT vbeln erdat FROM vbak       INTO TABLE itab      WHERE vbeln IN s_vbeln.

LOOP AT itab.*MOVE:itab-erdat TO sy-datum.

*CALL FUNCTION 'OPEN_FORM'*  EXPORTING*    device   = 'PRINTER'*    dialog   = 'X'*    form     = 'zscript_test '*    language = sy-langu.**CALL FUNCTION 'Write_form'*EXPORTING*  element = 'address'*  function = 'set'*  Type = 'Body'*  window = 'Main'.

CALL FUNCTION 'CONVERT_DATE_TO_EXTERNAL'  EXPORTING    date_internal = itab-erdat  IMPORTING    date_external = l_date.

WRITE: / l_date.ENDLOOP.

 What is BDC- its use, and how to use it? It is Batch Data conversion used for transferring some data other than sap into sap ... this is also a work of an ABAPer.

What is "UTS" Or may be it is "UST", something called Unit test?

Use: After developing any object we should write a test case proving that the object is working properly or not. This is done by the ABAPer. This is UNIT TEST CASE.

In BDC how can we handle Table Controls?

When you do your recording you will have a tab for Next line or Insert. You have to capture that in your recording. If your transaction code doesn't have that in the recording then you have to set up a page down (=P+) and loop it based on the line entries u c on teh screen.

Suppose we are transfer data through BDC from leagacy to SAP and their is some duplicate data in legacy system but we don't want this in SAP system .So how can we check that this data is already exist?

In BDC you would have all your legacy data in an internal table. Use Delete Adjacent dulpicates syntax to delete duplicate entries.

Can we use two transaction code in one BDC like XK01 & XD01 if yes how?

Yes, we can do that by combining the two bdc program codes together. Then you perform the program routine accordingly. However, it will make your BDC program very long and complex.

How can we handle errors in Function Module?

Exceptions is used to handle errors.

Can we use Session method & Call transaction both in one BDC if yes please give me example and scenerio where we use this?

You start your dataload using Call Transaction and if any errors occur push all those errors in a session so that your dataload takes place uninterrupted and you can processs ur errors later.