SAP's ERP products (R/3, ECC etc.). Possibly applicable for other related products 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 operations and support as well (including maintenance, enhancements, upgrade, production 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 like RICEF, FRICE-W and RICEF-W (where W stands for workflows).
Company: Deloitte Consulting LLP
Salai has more than eight years of experience as an ABAP developer in SAP ERP projects. He specializes in building interfaces for SAP ERP systems and in automating business processes in SAP with using SAP business workflow solutions. He has worked for 10+ SAP clients and his projects experience ranges across implementations, rollouts, production support, sustenance, enhancements, upgrades, automated 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 2001.
Table of Contents
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 projects 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, project 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 "Enhancement" or an "Interface" depending on it's functionality.
Below is a table that can help to determine the FRICE class of a certain development.
* Conventionally, forms are not interactive. But, with the introduction of interactive forms from Adobe, this could change. The ABAP community would need to take consensus if they have to be categorized as forms or as inbound interfaces
** Interfaces and conversion may have user interaction for triggering and/or error 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
Forms are ABAP programs and objects that create readable, formatted and printable outputs that are often exchanged with partners (customers, vendors, banks, employees, 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 simply 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 interactive forms, OLE etc. to develop "Forms".
Some examples of forms are Purchase Orders (MM), Sales Invoices (SD), Shipping Label (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 form of lists from the SAP database. Mostly, reports are viewed online, on the screen. But often, they are also downloaded or sent as attachment in emails (usually spreadsheets or xls) or sent to the spool (and may be printed). Performance heavy reports (that uses lots of data or takes long time to run) and periodic reports 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 to create reports. The classical method, though, was to create reports with "WRITE" statements in the ABAP programs. SAP Query is another tool to generate reports. Certain SAP modules have specialized reporting tools like the Report Painter in FI. The QuickViewer is another tool for personalized reporting, that is created in the live system on a need basis.
Some examples of reports are AR aging report, AP cash forecast report, General ledger balance report (FI), Backorders report (SD), Inventory reconciliation report (MM), Purchase price variance report (MM), US EEO-1 report (HR) etc.
Interfaces are ABAP programs, functions and other objects that enable the transfer and exchange of data and information betweeen two or more systems. Usually, interface fetch data from the source system and send them to target systems (outbound) or update the target system with the data sent from the source system (inbound), without any user intervention. Online users may be involved for error processing 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. However, if the data is interactively keyed into the system by the user, it should not be termed as an interface.
Interfaces can be developed as RFC enabled functions (for remote calls), IDOC processing function modules, ABAP programs that can process or generate files or can 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 interface (SD), advance shipment notification (SD), bank payment request interface (AP), lockbox interface (AR), material master interface (MM), benefits interface to providers (HR), goods receipts (IM), cashed checks reconciliation (AP) etc.
Conversions are programs that enable the transfer of data to the new system being implemented, from a previously live system. The source system (which was holding the data) may retire or co-exist after the conversion. Conversions are also known 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 fit the new system. If the source system will not be retired at the end of the conversion, 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 (for very little data), BDCs or BAPI calls or function calls, or generates IDocs etc.
Conversion objects depend totally on the module being implemented. Some examples of conversions are customer master (AR/SD), vendor master (MM/AP), general ledgers (FI), open sales orders (SD), open purchase orders (MM), GL history (FI), open receivable items (AR), open payable items (AP), bank master data (FI/AP/Treasury), 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 that is generated by the standard SAP system. Enhancements are required wherever the configurations provided by the standards SAP system are not sufficient to realize the requirements of the implementation or the system. These can be validations, extra user inputs, additionally captured data, additonally created data, workflows, 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 of ABAP objects in an implementation or project.
Enhancements can be user exits, BADI implementations, business transaction events (BTE), transactions, dialog or executable ABAP programs that use BAPI calls or function calls or BDCs or IDocs, functions, form exits, field exits, workflow objects, tasks, templates etc.
Enhancements vary widly depending on the solution, module, organization and industry. Some examples can be an additional validation for credit check in a BADI when 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 labels, derivation rules for profit center in a form exit when an accounting document is created, an email alert generating program when there are errors in an interface, an ABAP program that generates in transit goods movements whenever a inter company goods movement is created etc.
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, excluding the fact that they can be multi-step, workflows mostly have the same chanrecteristics of enhancements - they can be interactive, the source and target are the same sytem where they reside and they update data in the system.
Many objects like functions, workflow tasks, idoc processing functions, IDocs etc. are usually widely reused. Hence it is not a good practice to classify them as any kind of FRICE object.
For e.g., a function creating a customer can be used in an enhancement as well as in an interface. Similarly an idoc that is creating a purchase order can be used 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 utilities for the support team or the business users. For e.g., moving files, deleting files, sending a file as an email, uploading or downloading a file to the server etc.
For sake of simplicity, such utilities are also classified as "Enhancements".
Data dictionary objects like tables, structure, indices etc. are meant to be available 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 only 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 functional certainity that those data dictionary objects cannot be used for any other FRICE object.
FRICE ID and object mapping
It is essential to maintain a master list of all customizations (FRICE) and their related ABAP object, not only during an implementaion but also during the lifecycle 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 program 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 many 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 SAP script or smartform. An IDoc and an idoc processing function can be used in multiple interfaces.