What is RICEFW in SAP?

Advertisement
All the functional and technical consultants work on
RICEFWs during their SAP project life cycle in the
realization phase. This blog talks about the RICEFW
and its purpose in an SAP project. RICEFW stands for

Reports, Interface, Conversion, Enhancements, Form

s, and Workflows. When the business requirement
cannot be fulfilled by standard SAP functionalities,
then we require a RICEFW. All objects are defined
using the RICEFW classifications in any
implementation, roll-out, migration, or upgrade
project.

RICEFW vs WRICEF
Another name for RICEFW is WRICEF. It means
exactly the same thing but just uses a different
naming convention. WRICEF stands
for Workflows, Reports, Interface, Conversion, Enhanc
ements, and Forms. As you can see, these are the
same objects but just in a different order. It is usually
up to personal preferences which name to use. So,
some SAP projects use RICEFW acronym while others
WRICEF acronym. In the rest of this blog, we will use
RICEFW acronym but all the points will also be valid
for WRICEF.

How RICEFW is used in an SAP project?

An SAP implementation project life cycle has several
stages. During the blueprinting and analysis stage of
the project, we study the business requirements and
map those requirements in SAP to provide solutions.
The requirements which cannot be satisfied by
standard SAP application are called gaps. Based on
the category of the gap, objects are created in the
form of a RICEFW item. Each gap will have one
RICEFW object and the total inventory of RICEFW
objects is considered as the task list of deliverables to
be developed and managed.

Project functional teams are expected to fully test all

the RICEFW objects and would have to be passed by
the business users. These are the pre-requisite for
business go-live in SAP. The quality of RICEFW
objects plays a key role in determining the project’s
success.
The below diagram illustrates the project phases and
the significance of RICEFW in the realization phase.

Significance of RICEFW in the SAP Project

RICEFW (Reports, Interfaces, Conversions,

Enhancements, Forms, Workflows)

Reports
A report in SAP is a custom transaction that is built-up
using one or multiple programs that reads the
required information from the database and
produces/displays output after report execution based
on the input criteria entered on the selection screen of
the transaction, by an end-user. It is like a display of
information in the required format based on a given
selection.
These are the following categories of reports:

1. Standard reports available in SAP – given by

standard SAP only.
2. Customized developed reports – developed by the
project team taking standard SAP reports as
reference.
3. Queries – generates our own report by using
standard SAP tables.
In case the standard reports do not have the required
features to satisfy the customer’s requirement, then
the project team develops custom reports. For this, it
is necessary to understand the complete requirement
and then finalize the selection screen, key fields, and
the output format that should be generated when the
report is executed. This is then considered as a
RICEFW object.
Sample of A Typical Report Transaction

Interfaces
In most of the companies, there are several processes
in departments such as Planning, Shipping, Inventory
Management, QA, etc., that are managed in external
third-party systems that are Non-SAP systems. For
example: during shipping, they use third-party logistic
systems to pick/pack and ship the delivery. For that,
the SAP delivery information is sent to the external
Non-SAP system, and the Pick, Pack, and Shipment
information is received in the SAP system through a
middleware. These EDI communications are done
through Interfaces and IDocs are used for this data
transfer.

SAP has its standard EDI structures having defined

segments and fields. But still, we need to construct
custom segments and fields as all the required
segments are not available in the standard. For that,
the functional consultant needs to give the details of
what data needs to be transferred, received, and the
segments, fields, etc., to the ABAP team. This is then
considered as another RICEFW object.

Interface between SAP and Third-Party Systems

Conversion
When the SAP is implemented or upgraded, the
organization is going to sunset its legacy systems.
Thus, their business live data needs to be uploaded in
the SAP application. To upload the data in the SAP
system such as the Material Master, Business Partner,
Batch Master, Inventory, Bill of Materials,
Open Purchase Orders, etc., the data needs to be
converted from one form to another as per the
system’s requirement. This is called a Conversion.
Here, the business team extracts the data out of their
legacy systems. The project team then wants to
upload that data into the SAP system by making use
of the SAP data migration tools like BDC, LSMW,
LTMC, etc. Here, the functional consultant works with
the client team and the technical team to write some
programs that will read the data from those files and
load it into the SAP application. These will then be the
new objects in the RICEFW list.

Enhancements
If the business requirement cannot be satisfied by
standard SAP features, then the project team will add
some custom functionalities by modifying the SAP
standard. These are called enhancements. The
enhancements are developed by technical ABAP
consultants making use of BADIs, enhancement
frameworks, or user exits. These will be the new
RICEFW objects where the project functional team
works with the business team to gather the
requirement and then work with the technical team to
modify or leverage the SAP standard and create a new
custom solution as per business requirement. One
example could be to develop RF capabilities at the IM
level. Standard SAP has given the RF at the WM
or EWM level. But if the client is managing the
warehouse at the IM level and looking for RF
capabilities, then this would be an enhancement.

Forms
Forms are print outputs generated from SAP
application after saving the transactional data. Some
examples are Purchase Order print, Material
Document print, Delivery docket, Pick Ticket, Physical
Inventory count sheet, Labels print, etc. Standard SAP
has a pre-defined format and template for all these
forms, but these pre-defined forms may not be
meeting business requirements as they may like to
add a company’s logo or print legal text on the forms.
This requires the functional team to work with ABAP
and develop custom forms as per the business
requirement.

How is an example of a typical purchase order form:

 Sample Purchase
Order Form

Workflow
Workflow is the flowing of transactional data from one
level to another in a sequence as per the organization
hierarchy. At every level, one or more actions are
required. Once taken, the workflow advances to the
next level. For example: when the purchase order is
created for a value of more than 1000 USD, this is
going to the Manager for approval, once approved it
will go to the VP for a second-level approval, and so
on. In case the workflow as per business requirement
is not available in a standard SAP application, then
this results in a new RICEFW object. Here, the
functional consultant coordinates with the technical
team and develops the custom object-of-approval flow
logic containing the details of data to be sent, under
which condition this workflow is to be triggered, etc.

IDoc (intermediate document)

y

IDoc (intermediate document) is a standard data structure used

in SAP applications to transfer data to and from SAP system applications and
external systems. Using IDocs, companies with SAP ERP systems, for
example, can exchange data with external entities like their partners or
customers.

Key Features

 IDOCs are independent of the sending and receiving systems.

(SAP-to-SAP as well as Non-SAP)
 IDOCs are independent of the direction of data exchange e.g.
ORDERS01: Purchasing module: Inbound and Outbound
 IDOCs can be viewed in a text editor. Data is stored in character
format instead of binary format.

What does the IDoc interface do?

It enables the exchange and posting of business documents, the
unification and simplification of various application systems as well as
error handling even before the actual data is sent
Structure of an IDOC

The I doc structure consists of 3 parts –

The I doc structure consists of 3 parts –

1. The administration part(Control Record)- which has the type of idoc,

message type, the current status, the sender, receiver etc. This is
referred to as the Control record.
2. The application data (Data Record) – Which contains the data. These
are called the data records/segments.
3. The Status information (Status Record)- These give you information
about the various stages the idoc has passed through.

You can view an I-DOC using transaction WE02 or WE05

As seen the screenshot above IDOC record has three parts Control, Data and
Status. Let’s look into them in detail – Control Record
  All control record data is stored in EDIDC table. The key to this table is
the IDOC Number
 It contains information like IDOC number, the
direction(inbound/outbound), sender, recipient information, channel it is
using, which port it is using etc.
 Direction ‘1’ indicates outbound, ‘2’ indicates inbound.

Data Record

 Data record contains application data like employee header info, weekly
details, client details etc
 All data record data is stored in EDID2 to EDID4 tables and EDIDD is a
structure where you can see its components.
 It contains data like the idoc number, name and number of the segment
in the idoc, the hierarchy and the data
 The actual data is stored as a string in a field called SDATA, which is a
1000 char long field.

Status Record

 Status record is attached to an I-DOC at every milestone or when it

encounter errors.
 All status record data is stored in EDIDS table.
 Statuses 1-42 are for outbound while 50-75 for inbound

IDOC Types
An I DOC Type, (Basic) defines the structure and format of the business
document that is to be exchanged. An IDOC is an instance of an IDOC
Type , just like the concept of variables and variables types in programming
languages. You can define IDOC types using WE30
oncerning EDI concept in SD: the EDI concept
is intended to realize the sales and distribution
process completely automatically with the
help of electronical documents. These
documents are sent from one customer to
another, are processed mostly on the
background and give a possibility to realize the
sales process extremely efficiently.

If MM-customer would like to purchase the

goods then he creates the IDOC of type
ORDERS and send it to SD-customer. On the
SD-side the IDOC is processed via the function
module IDOC_INPUT_ORDERS and creates the
sales order. As confirmation the SD-side can
send to MM-side the Order-Response IDOC
(function IDOC_OUTPUT_ORDERS). The MM-
customer can every thime send a change to
the existiong order, then on SD side the
ORDCHG IDOC will be processed. It can
change the order like in VA02. The creation of
the invoice can be made via IDOC of message
type INVOIC (function IDOC_OUTPUT_INVOIC).

So, the process can be realized completely

automatically between SD and MM partners
with the help of IDOCs: ORDERS, ORDCHG,
ORDRSP, INVOIC.

That's all concerning the SD-EDI.

Additional processes in SD, where EDI are

used:

1) application of delivery schedules to the

scheduling agreement: IDOC of type DELINS

2) creation of a delivery order to the

scheduling agreement: IDOC of type DELORD

3) creation of external agent service delivery

to scheduling agreement: IDOC of type
EDLNOT

4) creation of credit advice / credit memo in

the frames of self-billing: IDOCs of type
GSVERF, SBWAP and for external invoice
creation SBINV.

It is all processes which are realized in the SD

module via EDI.