Anda di halaman 1dari 7

FRICE (ABAP Development and Programming)

Skip to end of metadata

Added by Guest, last edited by Craig Cmehil on Dec 28, 2009 (view change)
show comment
Go to start of metadata
Applies to:
SAP's ERP products (R/3, ECC etc.). Possibly applicable for other related produc
ts like CRM, SRM, Portals etc.
FRICE is a classification used during the customization of SAP's ERP products (R
/3, ECC etc.) using ABAP Workbench. This is primarily used during implementation
of the solution, but it is also very vital for solution documentation during op
erations and support as well (including maintenance, enhancements, upgrade, prod
uction support etc.). This is possibly applicable for other related SAP products
like CRM, SRM, Portal etc. FRICE is an acronym for Forms, Reports, Interfaces,
Conversions and Enhancements. There are other acronyms for this categorization l
ike RICEF, FRICE-W and RICEF-W (where W stands for workflows).
Salai Sivaprakash
Company: Deloitte Consulting LLP
Created on: 16 Dec 2009
Author(s) Bio
Salai has more than eight years of experience as an ABAP developer in SAP ERP pr
ojects. He specializes in building interfaces for SAP ERP systems and in automat
ing business processes in SAP with using SAP business workflow solutions. He has
worked for 10+ SAP clients and his projects experience ranges across implementa
tions, rollouts, production support, sustenance, enhancements, upgrades, automat
ed validations and performance testing.
Salai is a Specialist Senior at Deloitte Consulting. He graduated from National
Institute of Technology (Trichy, India) in Computer Science and Engineering in 2
Table of Contents
Applies to:
Salai Sivaprakash
FRICE Classification
FRICE description
Other developments
Reusable components
Data dictionary
FRICE ID and object mapping
Related Content
FRICE Classification
FRICE is an acronym for Forms, Reports, Interfaces, Conversions and Enhancements
. There are other acronyms for this categorization like RICEF, FRICE-W and RICEF
-W (where W stands for workflows). It is a classification used in SAP ERP projec
ts to categorize and inventorize the ABAP programs and objects that are created
or customized in order to realize the solution.
The distribution of the FRICE and the number of FRICE usually gives a fair idea
of the complexity and the size of customization and of the project. Usually, pro
ject managers would further classify them by complexity.
FRICE classification is not same as ABAP object type or program type. For e.g.,
an executable ABAP program (se38) can be classified as as "Report" or an "Enhanc
ement" or an "Interface" depending on it's functionality.
Below is a table that can help to determine the FRICE class of a certain develop
Updates data?
Source of data
User Interaction
Possible ABAP Object Types
Spool, email(formatted), fax etc.
SAP scripts, smart forms, ABAP programs (driver program or include)
Screen, spool, file, email(list) etc.
May be
ABAP report programs, ABAP Query,
Interfaces (Outbound)
External system
ABAP programs, function modules, RFC enabled function modules, IDoc generating f
unction modules etc.
Interfaces (Inbound)
External system or online user
ABAP programs, function modules, RFC enabled function modules, IDoc processing f
unction modules etc.
Legacy application
ABAP programs, LSMW, CATT scripts, function modules etc.
May be
Transations, ABAP programs & screens, Userexits, function modules, BADIs, workfl
ow objects, tasks etc.
May be
May be
Workflow objects, Tasks, custom abap programs (interactive report programs)
* Conventionally, forms are not interactive. But, with the introduction of inter
active forms from Adobe, this could change. The ABAP community would need to tak
e consensus if they have to be categorized as forms or as inbound interfaces
** Interfaces and conversion may have user interaction for triggering and/or err
or handling. But in general, they are not considered interactive
*** Workflow in general are categorized as enhancements
^ The SAP system where the program/object resides/executes
FRICE description
Forms are ABAP programs and objects that create readable, formatted and printabl
e outputs that are often exchanged with partners (customers, vendors, banks, emp
loyees, benefit providers, governments etc.). The outputs can be printed or sent
via fax or sent in an email as an attachment (pdf, otf, rtf, doc) or even simpl
y displayed on the screen (and a user can choose to print, fax or email it).
SAP provides ABAP workbench tools like SAP Script, Smart forms, Adobe interactiv
e forms, OLE etc. to develop "Forms".
Some examples of forms are Purchase Orders (MM), Sales Invoices (SD), Shipping L
abel (SD), Checks (AP), Customer account statements (AR), Employment letters (HR
), US 1099 Tax Forms (AP), US W2 Tax Forms (HR), Pay slips (HR) etc.
Reports are ABAP programs that generates information (reports), usually in the f
orm of lists from the SAP database. Mostly, reports are viewed online, on the sc
reen. But often, they are also downloaded or sent as attachment in emails (usual
ly spreadsheets or xls) or sent to the spool (and may be printed). Performance h
eavy reports (that uses lots of data or takes long time to run) and periodic rep
orts are usually run as jobs in batch mode.
The ABAP workbench provides the ABAP Editor (se38) to create reports. ABAP List
Viewer - ALV (a set of ABAP functions) is very popularly used in ABAP programs t
o create reports. The classical method, though, was to create reports with "WRIT
E" statements in the ABAP programs. SAP Query is another tool to generate report
s. Certain SAP modules have specialized reporting tools like the Report Painter
in FI. The QuickViewer is another tool for personalized reporting, that is creat
ed in the live system on a need basis.
Some examples of reports are AR aging report, AP cash forecast report, General l
edger balance report (FI), Backorders report (SD), Inventory reconciliation repo
rt (MM), Purchase price variance report (MM), US EEO-1 report (HR) etc.
Interfaces are ABAP programs, functions and other objects that enable the transf
er and exchange of data and information betweeen two or more systems. Usually, i
nterface fetch data from the source system and send them to target systems (outb
ound) or update the target system with the data sent from the source system (inb
ound), without any user intervention. Online users may be involved for error pro
cessing or to trigger the interface (both voluntarily or involuntarily). In some
cases, an interface may load data into the system provided by a user - probably
as a file or a spreadsheet. In these cases, the data may be extracted from the
source by the user manually or the user may generate the data on their own. Howe
ver, if the data is interactively keyed into the system by the user, it should n
ot be termed as an interface.
Interfaces can be developed as RFC enabled functions (for remote calls), IDOC pr
ocessing function modules, ABAP programs that can process or generate files or c
an make RFC calls, or idoc generating ABAP programs/functions, ABAP programs or
functions that perform BDC etc.
Some examples of interfaces are orders interface (MM/SD), outbound sales order i
nterface (SD), advance shipment notification (SD), bank payment request interfac
e (AP), lockbox interface (AR), material master interface (MM), benefits interfa
ce to providers (HR), goods receipts (IM), cashed checks reconciliation (AP) etc
Conversions are programs that enable the transfer of data to the new system bein
g implemented, from a previously live system. The source system (which was holdi
ng the data) may retire or co-exist after the conversion. Conversions are also k
nown popularly as "migrations" or "data migration". Conversion may involve a lot
of manual or programatic corrections and changes to data, in order to make it f
it the new system. If the source system will not be retired at the end of the co
nversion, an interface may be built instead of a conversion. In which case, the
all necessary data is loaded at the time of "cutover" using the interface.
Conversions can be developed using ABAP programs that use LSMW, CATT scripts (fo
r very little data), BDCs or BAPI calls or function calls, or generates IDocs et
Conversion objects depend totally on the module being implemented. Some examples
of conversions are customer master (AR/SD), vendor master (MM/AP), general ledg
ers (FI), open sales orders (SD), open purchase orders (MM), GL history (FI), op
en receivable items (AR), open payable items (AP), bank master data (FI/AP/Treas
ury), employee personnel records (HR), employee benefits (HR), material master (
MM), bill of materials (MM) etc.
Enhancements are programs and objects that controls, changes or creates data tha
t is generated by the standard SAP system. Enhancements are required wherever th
e configurations provided by the standards SAP system are not sufficient to real
ize the requirements of the implementation or the system. These can be validatio
ns, extra user inputs, additionally captured data, additonally created data, wor
kflows, additional update to data, alerts etc. In general, refering to the FRICE
classification table above, when the program/object affects the update of data,
and the source of data in the SAP system where the program/object resides, and
the target system is the same as the source system, then the program/object can
be classified as an enhancement. Enhancements include the most number and kind o
f ABAP objects in an implementation or project.
Enhancements can be user exits, BADI implementations, business transaction event
s (BTE), transactions, dialog or executable ABAP programs that use BAPI calls or
function calls or BDCs or IDocs, functions, form exits, field exits, workflow o
bjects, tasks, templates etc.
Enhancements vary widly depending on the solution, module, organization and indu
stry. Some examples can be an additional validation for credit check in a BADI w
hen a sales order is changed, a retroactive billing documents created in a user
exit when a pricing condition is changed, a workflow triggered for approval when
a purchase requisition is created, custom transaction for creating packing labe
ls, derivation rules for profit center in a form exit when an accounting documen
t is created, an email alert generating program when there are errors in an inte
rface, an ABAP program that generates in transit goods movements whenever a inte
r company goods movement is created etc.
Other developments
Workflows are programs and objects that enable a multi step process. They can be
built using workflow objects or as single step tasks. They can also be created
using custom programming. They can be simple alerts or may involve user decision
or user action or user review or a background process involving an update.
For sake of simplicity, workflow are categorized as enhancements sincee, excludi
ng the fact that they can be multi-step, workflows mostly have the same chanrect
eristics of enhancements - they can be interactive, the source and target are th
e same sytem where they reside and they update data in the system.
Reusable components
Many objects like functions, workflow tasks, idoc processing functions, IDocs et
c. are usually widely reused. Hence it is not a good practice to classify them a
s any kind of FRICE object.
For e.g., a function creating a customer can be used in an enhancement as well a
s in an interface. Similarly an idoc that is creating a purchase order can be us
ed in multiple interfaces. An idoc can also be created or processed via multiple
functions. Thus it is best not to classify such objects.
Include programs that can be reused, like file handling, BDC actions etc. should
not be classified. They need to be listed as REUSABLE.
In an implementation or SAP environment, often it is required to create utilitie
s for the support team or the business users. For e.g., moving files, deleting f
iles, sending a file as an email, uploading or downloading a file to the server
For sake of simplicity, such utilities are also classified as "Enhancements".
Data dictionary
Data dictionary objects like tables, structure, indices etc. are meant to be ava
ilable for use for all programs in the system. They should not be classified as
part of any particular FRICE object. In few cases, when a structure is meant onl
y for a specific report or a table controls how an enhancemnt behaves, they can
be be classified as part of that FRICE object, but only when therer is a functio
nal certainity that those data dictionary objects cannot be used for any other F
RICE object.
FRICE ID and object mapping
It is essential to maintain a master list of all customizations (FRICE) and thei
r related ABAP object, not only during an implementaion but also during the life
cycle of the system - during operations, support, upgrade, enhancements etc.
Generally, the customizations are numbered as XNNN where NNN is a 3 digit serial
number for each type of FRICE object and X stands for the type of FRICE object.
So, forms will be listed as F001, F002, F003, ... etc., reports will be listed
as R001, R002, R003, ... etc. and likewise. This is called the FRICE ID.
Its a general convention to use the FRICE ID in the name of the object. But this
need not necessarily be the case. For e.g., we may use a standard SAP extract p
rogram for an interface. Or, SAP may restrict the naming convention, like in the
case of workflows.
FRICE ID and ABAP object mapping are N x N. That is, one object can be part of m
any FRICE and one FRICE can have multiple ABAP objects.
For e.g., a print form (say a label), can have a driver program ass well as a SA
P script or smartform. An IDoc and an idoc processing function can be used in mu
ltiple interfaces.