1 Order

CRM Programming Fundamentals
This is a reference only
CRM Programming
Fundamentals
Contents
1. One Order Object Model................................................................................3
2. One Order Reporting Framework................................................................16
3. Commonly used Function Modules in CRM..............................................19
4. Commonly used BadIs in CRM...................................................................27
5. Copy Control in Business Transactions....................................................30
6. Transaction CRMV_EVENT..........................................................................32
7. Debugging in middleware............................................................................37
8. Error handling in CRM..................................................................................38
9. Overview of Customizing.............................................................................42
10. Helpful Reports...........................................................................................43
1. One Order Object Model

The CRM One Order documents are created in transaction CRMD_ORDER.
The Header table that is updated by the created document is CRMD_ORDERADM_H.
The primary key for this table is GUID (Global Unique Identifier). For each document
created, a unique number (GUID) is generated by the system which depends on the
Logical name of the system. The field Object ID of table CRMD_ORDERADM_H
contains the document number.
The Item table for One Order document is CRMD_ORDERADM_I. Each Item of a
One Order document has a different GUID. The Header GUID of the Item is stored in
field HEADER of table CRMD_ORDERADM_I.
One-Order Object Model
Administration header and Extension have the same GUID
Administration header Extension
CRMD_ORDERADM_H CRMD_ACTIVITY_H
CRMD_OPPORT_H
CRMD_ORDERADM_I
CRMD_SERVICE_I
Set
CRMD_LINK CRMD_SALES
Link handler
CRMD_SHIPPING
Administration header and Set have different GUID. They are

linked via the Link Handler
Note
Normally, an extension contains H or I in the name. It shows if this extension belongs to the
header or to the item. Typically extensions store information which is specific to the
header/item. The information which can belong to both header and item is typically stored
in sets.
Data Model:-
Administration (Header / Item)

Header identifies the order in the system
Item holds the relation to the order
Extension
1:1 Relation to the administration header OR to the administration

item
Sets (Link Handler)

1:1 relation to the header and/or the item
optimal data space because sharing of header and item data is
possible
possibility to assign the same data to header and items
it is only allowed to reference to an admin segment (1 level)
Data model
Orderadm_h Activity_h Opport_h
GUID Data REF_GUID Data REF_GUID Data
Orderadm_i Product_i Service_i
Header GUID Data REF_GUID Data REF_GUID Data

Sets / Link Handler:-
Data model: Sets / Link Handler
Orderadm_ Orgma
h Link Handler n
GUI Dat GUI Dat
D a D a
Orderadm_
i HG01 - OG01 Orgma
Heade GUI Dat n
r D a GUI Dat
D a
IG02 OG02
Orderadm_
i
Heade GUI Dat
r D a
SETS <-> EXTENSIONS

Sets are data structures that should be The product data is an extension of the item
used by several objects (reusable data. As all extensions are always linked to
structures). one header or one item, it does not need its
The sales set is an example of a set. It own handle or guid. This also applies for the
can be assigned to several items. fields table. A reference object type is also
Therefore a link handler is necessary. not necessary, as an extension can always be
assigned either at header or item level.
LINK-HANDLER: => DB table: CRMD_LINK

Function module: CRM_LINK_GET_OW
Example: Order 5041922

Header-Guid: 7BD735B78D3F60499A4797FE7B56922B
(search CRMD_ORDERADM_H with object_id = 5041922)
Item-Guid: 4EC37010164E7846AAE59325700181CA
(search CRMD_ORDERADM_I with header = Header-Guid)
Sales data => SET Product data => EXTENSION

(search CRMD_LINK with GUID_HI = Item-Guid (search CRMD_Product_I
Guid_SET = 55F37D59A6DE8F40996EBFDB6ED5C582 with Guid = Item-Guid)
OBJTYPE_SET (Sales = 11, see CRMC_OBJECTS)
Then search CRMD_SALES with Guid = GUID_SET.
Working with Business Transactions SAP GUI
Display or
hide
locator
Maximum /
minimal
display
Display
business
partner
cockpit
Application log:
Settings Compress Work with several Displays error
header data documents in parallel messages
A Service Order looks as follows:
Service Process
Service process has leading transaction category BUS2000116.
Transaction to maintain service process: CRMD_BUS2000116
Assigned transaction categories: Service, Sales, Business activity.
Service process can be distributed into R/3.
Main partner function category: Sold-to party
Additional customizing for Service Process:
Subject profile (for codes)
Transaction type for confirmation
Service process also contains parts of customizing from Business
Activity and Sales document.
Information available in Service process:
Header data Shipping

Service data Billing
Subject + IBase Products
Status Partner
Activity data Actions
Objects Organizational data
Pricing Dates
Conditions Texts
Service Process II
Service process has a specific UI different from sales document or
activity. Fast entry, Item detail, Transaction data buttons are
available and can be used to switch between screens.
Service process can contain different items:

Sales items
For sales items a sales order can be created in R/3 for complete delivery
process
Service items
To identify the customer wishes, contains planning-relevant data
Spare parts
Material which is required in the context of a service item
BADI for Service Process:

CRM_SERVICE_I_BADI for item data (no service-specific header
data)
The Follow-up documents like, Confirmation from the Service Order can be created as
shown below:
Then, copy the items as needed. Select the Items & Copy:
Service Confirmation
Service Confirmation has leading transaction category BUS2000117.
Transaction to maintain service confirmation: CRMD_BUS2000117
Assigned transaction categories: Service, Sales, Business activity.
Working times and spare parts from service conformation are
posted to R/3. Main partner function category: Sold-to party.
Additional customizing for Service Confirmation:
Subject profile (for codes)
Confirmation also contains parts of customizing from Business
Activity and Sales document.
Information available in Service Confirmation:
Header data Conditions

Service data Billing
Subject Products
Status Partner
Activity data Actions
Objects Organizational data
Pricing Dates
Texts
Service Confirmation II
Service confirmation like a service process has a specific UI
different from sales document or activity. Fast entry, Item detail,
Transaction data buttons are available and can be used to switch
between screens.
Service confirmation can contain different items. These items are

normally copied from the service process for which the confirmation
is created:
Service items
Working time is distributed to payroll data of HR system and costs to CO.
Spare parts
Goods issue is posted to MM and costs to CO.
In order to create a confirmation from a service process the process

should have status Released both on header and item level. As
soon as confirmation is saved, the service process status is set to
Confirmed.
Similarly, we can create Billing Requests from Confirmation.

All these documents update the same database tables. But are differentiated from each
other by PROCESS_TYPE and OBJECT_TYPE in table CRMD_ORDERADM_H.
Architecture of the systems (CRM & R/3):-
IPC
CRM system OLTP R/3
CRM Online
Middleware
R/3 Adapter
Plug-In
BW Adapter
BW APO
Middleware RFC
CRM------------>BDOC------------>R/3
DB tables
R/3 CRM
VBAK CRMD_ORDERADM_H
VBAP CRMD_ORDERADM_I
VBEP CRMD_SCHEDLIN
MAEPV/MAAPV CRMD_PRODUCT_I
VBKD CRMD_PRICING
KONV PRCD_COND Workareas:
VBUK/VBUP CRM_JEST*
- lu_orderadm_h_wrk old data (like *VBAK)
* For an overview on the different status see - ls_orderadm_h_wrk local data
Include CRM_STATUS_CON - gs_orderadm_h_wrk global data
Most of the tables have the GUID as a key field

e.g. 0F53ADA4ADA3A440A3E5288A3055F739
(GUID: Universal Unique Identifier, data type

CRMT_OBJECT_GUID, domain SYSUUID, RAW 16)
Layers of programming model in business transactions:-
User interface layer (UI)
Interaction layer (IL)
Object layer
Object Buffer (OB) Object Work area (OW)
Database layer
Database Buffer (DB) Database Update (DU)
Each layer should communicate only to directly linked layers:

UI to IL, IL to UI and OW (OB), OW (OB) to IL or DB, DB to OW
(OB)
User Interface GUI-Screens / Web / ...
For Screen For WEB

Communication between
Interaction Layer
common UI and Business Logic,
Transport and conversion of data,
Screen sequence control,
BAPI Methode Methode Methode Methode
API (def. Methods) Methods to create, read and change

Well defined interfaces
Definition of business rules
Interpretation of the customizing
Merge and checks
Object Layer
Applicationlogic
Database Layer Read and save data from/to database

CRM Layer model II
User read
- UI -
Interface save
Interaction
- IL -
Layer
Object - OW - Customizing - CD -
Layer Business Dialo
- OB - logic - CB - g
Modified Method
Data s
Database - DB -
Layer Original
- DU - Data
Update D
task
B
User Interface in Business Transaction:-

User Interface in Business Trans.
User interface in business transactions consists of all screens/subscreens and
screen sequence controlling customizing that is provided by SAP and should
be changed by the customer very carefully.
Screens that are shown in transaction CRMD_ORDER are located in the
function groups ending with _UI. Example: CRM_OPPORT_UI.
Example: screen 7111.
Typical flow logic of the CRM screen:
PBO
get data from Interaction Layer
* get data from Interaction Layer
MODULE DATA_7110_GET.
perform field checks
* Modify Screen Fields
MODULE DATA_7110_FIELDCHECK.
PAI
put data to Interaction Layer
MODULE DATA_7110_PUT ON CHAIN-REQUEST.
User Interface in Business Trans. II

Screen sequence controlling customizing defines which the screens should
be displayed, in which order, etc. This customizing defines the way how
business transaction is displayed.
Transaction to maintain
screen sequence
controlling: CRMV_SSC
Customer Extensions in Business Transact.

Customers can extend standard CRM business transactions with their own
fields/screens. In order to enable this, two special extensions were added into
CRM business transactions object model. These extensions are CUSTOMER_H
and CUSTOMER_I.
IMG documentation: Customer Relationship Management -> Basic Functions ->
System Modifications -> Business Add-in for Customer Enhancements on Header
Level.
The structure to be extended with customer fields on header level:
CRMT_CUSTOMER_H_EXT.
Structure CRMT_CUSTOMER_H_EXT is already included into all important
structures and database tables.
Logic of CRM_ORDER
I II III
CRM_ORDER_READ CRM_ORDER_READ_OW
CRM_ORDER_H_MAINTAIN_OW
CRM_ORDER_MAINTAIN_MULTI_OW CRM_ORDERADM_H_MAINTAIN_OW
CRM_ORDER_MAINTAIN
CRM_ORDER_MAINTAIN_SINGLE_OW
CRM_ORDER_I_MAINTAIN_OW
CRM_ORDERADM_I_MAINTAIN_OW
CRM_ORDER_SAVE CRM_ORDER_SAVE_OW CRM_ORDERADM_H_SAVE_OB

CRM_ORDERADM_I_SAVE_OB
CRM_LINK_SAVE_OW
CRM_ORDER_UPLOAD_SINGLE
Overview of Naming conventions used by SAP:
Naming conventions
Development classes (packages): Variables:

CRM_ + object name lv_ + variable name / gv_ + variable name
Example: CRM_ACTIVITY_H Example: lv_guid, gv_guid
Function groups: Structures:
CRM_ + object name + layer ls_ + structure name / gs_ + structure name
Example: CRM_ACTIVITY_H_OB Example: ls_orderadm_h_wrk
Function modules: Internal tables:
CRM_ + object name + function name + layer lt_ + table name / gt_ + table name
Example: CRM_ACTIVITY_H_PUT_OB Example: gt_orderadm_h_wrk
DDIC structures:
CRMT_ + object name + structure type
Example: CRMT_ACTIVITY_H_WRK
DDIC tables:
CRMD_ + object name
Example: CRMD_ACTIVITY_H
2. One Order Reporting Framework

One Order Reporting Framework is used to retrieve the documents for particular
Selection criteria. Direct Selection from database table is not advised.
As an example we will retrieve Documents, based on the Process type & Sales
organization.
Let us compare with a SELECT statement to make it more understandable. Assume, the
documents are retrieved from table XYZ, so our SELECT statement will be as follows:
SELECT <document no>

FROM TABLE XYZ
WHERE PROCESS_TYPE = Block 1
AND SALES_ORG = Block 3
Block 2
In One Order Reporting Framework we will select Documents as follows:
First of all we will build the WHERE clause as mentioned above for the SELECT
statement. It is build using classes & methods. Class CL_CRM_REPORT_QUPART
and Method GET_QUPART_BY_TOKEN is used for this purpose.
Block 1 is built as follows:
CALL METHOD cl_crm_report_qupart=>get_qupart_by_token

EXPORTING
iv_entityname = 'CL_CRM_REPORT_EXT_ORDERADM_H'
iv_fieldname = 'PROCESS_TYPE'
iv_token = 'RAN'
it_rangetab = it_type[]
IMPORTING
ev_qupart = iv_qupart-querypart.
The parameter, iv_entityname contains the name of the Segment for which the data will
be retrieved. The parameter values can be found in program
CRM_OBJECT_NAMES_CON.
The parameter, iv_fieldname contains the name of the field for which the Selection
Clause is built.
iv_token, is used to let the system know the type of operand you are passing in the
parameter it_rangetab. In our example, RAN means Range Table. Go to domain
CRM_REPORT_TOKEN to see all possible values.
Parameter it_rangetab contains the range table we are passing to the method. This range
table contains the values the user has entered in the selection screen for Process Type.
Do not use the method call if it_type[] is initial.
The parameter ev_qupart, contains final query built by the method for Block 1.
iv_qupart is of type CRMT_REPORT_QUERYPART_TA.
We need to store all these queryparts in an internal table which can be passed to the
method which does the selection based on these queryparts (WHERE CLAUSE).
So, an internal table say, it_qupart of type CRMT_REPORT_QUERYPART_TA is
created, where the parameter iv_qupart returned by the method is appended.
Now, before building the query part for Sales organization (Block 3), we need to build
Block 2. (Because there is more than one field in WHERE clause).So, how to build Block
2 now:-
Same methods are used as follows:
EXPORTING
iv_token = 'AND'
IMPORTING
ev_qupart = iv_qupart_and-querypart.
Now, iv_qupart_and is appended to internal table it_qupart.

Block 3 has to be built now same like Block 1 and appended to internal table it_qupart.
EXPORTING
iv_entityname = 'CL_CRM_REPORT_SET_ORGMAN'
iv_fieldname = 'SALES_ORG'
iv_token = 'RAN'
it_rangetab = it_sales_org[]
IMPORTING
ev_qupart = iv_qupart-querypart.
Now, we do not need Block 2 anymore as we do not have any further fields for selection.
Internal table it_qupart contains the complete WHERE CLAUSE. We will see how this
is used to retrieve the Documents.
Create Object:
CREATE OBJECT cl_question Constructor

EXPORTING
it_query = it_qupart[]
iv_accessrule_name = 'CL_CRM_REPORT_ACCRULE_ONEORDER'.
cl_question refers to Class CL_CRM_REPORT_QUESTION.

It_qupart is the internal table that we populated above.
'CL_CRM_REPORT_ACCRULE_ONEORDER' refers to the One Order Reporting
Framework.
CALL METHOD cl_question->refresh.
CALL METHOD cl_question->get_ext_object

EXPORTING
iv_name = gc_objectname_reporting-locatorlist
IMPORTING
ev_instance = l_list.
lv_locatorlist ?= l_list.
Where,
l_list TYPE REF TO cl_crm_report_ext.
lv_locatorlist TYPE REF TO cl_crm_report_ext_locatorlist.
Finally, call the following Method:
CALL METHOD lv_locatorlist->get_extension

EXPORTING
it_requested_columns = lt_requ_columns
IMPORTING
et_extension = lt_list.
Where,
lv_locatorlist TYPE REF TO cl_crm_report_ext_locatorlist.
lt_requ_columns TYPE crmt_report_requ_columns_ta.

(For the Columns you require.For example:
ls_requ_columns-column = 'GUID'.
ls_requ_columns-requested = abap_true.
APPEND ls_requ_columns TO lt_requ_columns.
ls_requ_columns-column = 'OBJECT_TYPE'.
ls_requ_columns-column = 'OBJECT_ID'.
ls_requ_columns-column = 'PROCESS_TYPE'.
APPEND ls_requ_columns TO lt_requ_columns.)
lt_list TYPE crmt_report_locatorlist_ta. This contains the final list of selection.
3. Commonly used Function Modules in CRM

The function module OWN_LOGICAL_SYSTEM_GET can be used to get the name of
the Logical System.
The function module CRM_STATUS_READ is used to read the status of the document.
The function module CRM_STATUS_CHANGE_FOR_ACTIV_OW is used to change

the Status of documents, both Header & Item.
Even function module 'CRM_STATUS_MAINTAIN_OW' can be used to change the
status of a document.
For example:
ls_status_com-activate = 'X'.
ls_status_com-ref_guid = ls_guid.
ls_status_com-ref_kind = ''.
ls_status_com-status = 'E0029'.
INSERT ls_status_com INTO TABLE lt_status_com.
CLEAR lt_input_field_names.
INSERT gc_fieldname_activate INTO TABLE lt_input_field_names.
CALL FUNCTION 'CRM_STATUS_MAINTAIN_OW'

EXPORTING
it_status_com = lt_status_com
* IT_STATUS_COMINT =
iv_check_only = ''
* IV_TRACE =
* IV_NO_1O_MAINTAIN = FALSE
* IV_FORCE_1O_MAINTAIN = FALSE
* IV_GET_ACTUAL_EXCPN = FALSE
CHANGING
ct_input_field_names = lt_input_field_names
EXCEPTIONS
not_allowed =1
error_occurred =2
warning_occurred =3
OTHERS =4
.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
The function module CRM_ORDER_CHECK_AUTHORITY_GEN is used to check

the modification authorization for a document.
The function module NREL_GET_NEIGHBOURHOOD is used to read the document

flow.
For example:
CALL FUNCTION 'NREL_GET_NEIGHBOURHOOD'

EXPORTING
is_object = v_borident
* IT_ROLERANGE =
it_relrange = v_relrange[]
i_depth = '00'
* BYPASS_BUFFER =''
* IMPORTING
* EP_EXIST_LINKS =
TABLES
links = it_links
* ROLES =
The structure v_borident should contain the object GUID, Object type and logical
system name.
The structure v_relrange should be like this :

v_relrange-sign = 'I'.
v_relrange-option = 'EQ'.
v_relrange-low = 'VONA'.
v_relrange-high = ''.
APPEND v_relrange.
CLEAR v_relrange.
The internal table it_links is returned by the function module which contains all the
documents linked with the object GUID passed in the structure v_borident.
The function module CRM_SRV_UPDATE_DOCFLOW is used for creating Document

Flow. This function module can be used to create document flow between R/3 & CRM
documents as well.
Even function module CRM_ORDER_MAINTAIN can be used to create document
flow.
For example:
ls_guid = ls_documents-guid.
INSERT ls_guid INTO TABLE it_guid.
* Fill input fields for maintain

ls_input_field_names-fieldname = 'OBJKEY_A'.
INSERT ls_input_field_names INTO TABLE lt_input_field_names.
ls_input_field_names-fieldname = 'OBJTYPE_A'.
ls_input_field_names-fieldname = 'OBJKEY_B'.
ls_input_field_names-fieldname = 'OBJTYPE_B'.
ls_input_field_names-fieldname = 'VONA_KIND'.
ls_input_field_names-fieldname = 'BREL_KIND'.
ls_input_field_names-fieldname = 'BREL_MODE'.
ls_input_field_names-fieldname = 'RELTYPE'.
ls_input_field-ref_guid = ls_guid.
ls_input_field-ref_kind = gc_object_kind-orderadm_h.
ls_input_field-objectname = 'DOC_FLOW'.
ls_input_field-field_names[] = lt_input_field_names[].
ls_input_field-logical_key = '1'.
APPEND ls_input_field TO lt_input_field.
ls_doc_link-objkey_a = ls_guid.
ls_doc_link-objtype_a = gc_object_type-service.
ls_doc_link-objkey_b = ls_documents-material_document.
ls_doc_link-objtype_b = 'BUS2017'.
ls_doc_link-brel_mode = gc_object_kind-orderadm_h.
ls_doc_link-logsys_b = ls_documents-logical_system.
ls_doc_link-reltype = 'VONA'.
ls_doc_link-brel_kind = gc_object_kind-orderadm_h.
ls_doc_link-log_key = '1'.
INSERT ls_doc_link INTO TABLE ls_doc_flow-doc_link.
ls_doc_flow-ref_guid = ls_guid.
ls_doc_flow-ref_kind = gc_object_kind-orderadm_h.
INSERT ls_doc_flow INTO TABLE lt_doc_flow.
CALL FUNCTION 'CRM_ORDER_MAINTAIN'

CHANGING
ct_input_fields = lt_input_field
ct_doc_flow = lt_doc_flow
EXCEPTIONS
error_occurred = 1
document_locked = 2
no_change_allowed = 3
no_authority =4
OTHERS = 5.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
The function module CRM_CREATE_BREL_TO_CONTRACT_OW is used to link

document flow to a contract. This function module is used to update Released Value in a
contract. The function module CRM_DELETE_BREL_TO_CONTRACT_OW is used
to reverse the document flow, in case of deletion.
The function module CRM_INTLAY_GET_PROCESS_TYPE is used to determine

Process Type for a document.
The function module which contains the string INTLAY returns data from the
Interaction Layer. For example, if you are processing a document, and you need the
HEADER GUID of the document which is not available in your program, you can use
those FMs which will return the desired data. Because, the Interaction Layer is populated
when we use function modules like CRM_ORDER_READ etc.
The function module BBP_PD_ALL_GET_OBJECT_ID is used to get the Object ID

from the Object GUID.
The function module CRM_STATUS_BUFFER_REFRESH is used to refresh the

buffer. This function module should be used to refresh the buffer after any change of
status of the document.
The function module CRM_1O_CALL_FOREIGN is used to call transaction

CRMD_ORDER. You have to pass the document number which you have to open. You
can open the document either in Change/Display mode.
The function module CRM_ORDERADM_H_GUID_GET_OW is used to get the

GUID from Object ID.
The function module CRM_HEADER_GUID_GET_OBJ_ID is used to get the Object

ID from GUID.
The function module CRM_ORDER_GET_HEADER_GUID is used to get Header

GUID from Item GUID.
The function module 'IB_CONVERT_INTO_TIMESTAMP' can be used to convert to

timestamp.
The function module 'CRM_ACTIVITY_H_MAINTAIN_OW' to Create/Change Activity

Header Data.
For example:
* Check whether Activity Header Category Data exists for this Order
CALL FUNCTION 'CRM_ACTIVITY_H_READ_OB'
EXPORTING
iv_guid = iv_header_guid
IMPORTING
es_activity_h_wrk = lx_act_h_wrk
EXCEPTIONS
parameter_error =1
record_not_found =2
at_least_one_record_not_found = 3
OTHERS = 4.
IF sy-subrc <> 0.
* MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

* WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
MESSAGE i022(zcrm_dev).
PERFORM update_message USING iv_header_guid.
EXIT.
ENDIF.
* If no Activity Header Exists, then Create (MODE = A)
* If it exists then change with (MODE = B)
IF lx_act_h_wrk IS INITIAL.
lx_act_h-mode = 'A'.
ELSE.
lx_act_h-mode = 'B'.
ENDIF.
lx_act_h-ref_guid = iv_header_guid. "Head GUID
lx_act_h-category = 'ZR1'.
* Input Fields to be changed
lx_input_field_names-fieldname = 'CATEGORY'.
INSERT lx_input_field_names INTO TABLE lit_input_field_names.
lx_input_field_names-fieldname = 'MODE'.
INSERT lx_input_field_names INTO TABLE lit_input_field_names.
* Create/Change Activity Header Category Data
CALL FUNCTION 'CRM_ACTIVITY_H_MAINTAIN_OW'
EXPORTING
is_activity_h_com = lx_act_h
CHANGING
ct_input_field_names = lit_input_field_names
EXCEPTIONS
header_create_error = 1
header_change_error = 2
parameter_error =3
admin_h_reference_error = 4
OTHERS = 5.
IF sy-subrc <> 0.
* MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
* WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
MESSAGE i022(zcrm_dev).
PERFORM update_message USING iv_header_guid.
EXIT.
ENDIF.
Use of function module CRM_ORDER_READ:-

The function module CRM_ORDER_READ is used to read the Segment Data of a One
Order Document.
The function module is used to read Header as well as Item details (all segments) by
passing the Header GUID of the document in the parameter IT_HEADER_GUID of
the function module.
To read only Item specific detail, pass the Item GUID of the document in the parameter
IT_ITEM_GUID of the function module.
You can read more than one document details by passing more than one GUID in the
parameter IT_HEADER_GUID.
The function module CRM_ORDER_READ returns data of all the Segments of the
document. To read only specific Segment data, pass the Segment Name in the parameter
IT_REQUESTED_OBJECTS of the function module, to enhance performance.
The function module first try to read required data from OW (work area), if not available
looks at the OB which is the Object Buffer. If still fails, finally it retrieves the data from
Database. So, if you look at standard CRM function modules, you will find, suffixes as
_OW / _OB/ _DB. Based on your requirement from where you want to read the
data, you need to use the respective function module.
Use of Function Module CRM_ORDER_MAINTAIN:-

The function module is used to Maintain/Change One Order Document.
Depending on the Segment data you are modifying, you need to pass the changed data in
the respective parameter of the Segment.
For example, if you are modifying Activity data of the Header, you need to pass
parameter IT_ACTIVITY_H, similarly, for Activity Item you need to pass data in
IT_ACTIVITY_I.
It is mandatory to populate the Changing Parameter CT_INPUT_FIELDS. This
parameter contains the name of the Segment you are modifying. You can modify as many
segments you want to. But you need to pass all the Segments name in the parameter
CT_INPUT_FIELDS. You can get the name of the Segments in the table
CRMC_OBJECTS. If you are modifying any Segment, for which need to populate the
field LOGICAL_KEY in the parameter CT_INPUT_FIELDS, you need to generate the
LOGICAL_KEY each time you use. For example, function module
CRM_BILLPLAN_FIND_LOGICAL_KEY is used to generate the LOGICAL_KEY to
be used to modify the Segment for BILLING PLAN.
You need the LOGICAL_KEY to modify the Segments BILLING PLAN,
CUMULATED_I, Product Details, and to CANCEL a document.
Do not forget to use the function module CRM_ORDER_SAVE to save the changes
followed by COMMIT/ROLLBACK work.
Finally, call the function module CRM_ORDER_INITIALIZE to refresh the buffer.

Care must be taken for locking/unlocking the document before making any changes.
Few points to remember about the function module:-

Function CRM_ORDER_MAINTAIN
Function module CRM_ORDER_MAINTAIN is used for any action performed for
business transaction.
Recursive calls are not permitted
All extensions and sets are passed to this function module
Multiple documents can be maintained with one call
Input fields (parameter CT_INPUT_FIELDS) are used to identify which fields of the
corresponding set/extension should be changed
The function calls CRM_ORDER_MAINTAIN_MULTI_OW to maintain multiple
documents
CRM_ORDER_MAINTAIN_MULTI_OW separates the documents and calls
CRM_ORDER_MAINTAIN_SINGLE_OW for each of them in case of
creation/change/deletion and CRM_ORDER_COPY_SINGLE_OW in case of copying
or creating follow-up document
CRM_ORDER_MAINTAIN_SINGLE_OW function calls
CRM_ORDER_H_MAINTAIN_OW to maintain header information and
CRM_ORDER_I_MAINTAIN_MULTI_OW to maintain item information
CRM_ORDER_H_MAINTAIN_OW calls in a certain order maintenance function
modules for extensions and sets belonging to header
At the end CRM_ORDER_H_COMPLETE_OW is called and events planned for the
end of header processing are executed
Sequence of function modules called within CRM_ORDER_MAINTAIN:-

CRM Layer model IV
CRM_ORDER_MAINTAIN
CRM_ORDER_MAINTAIN_MULTI_OW
CRM_ORDER_H_PREPARE_OW
CRM_ORDERADM_H_MAINTAIN_OW
CRM_<OBJECT>_MAINTAIN_OW
.........
CRM_ORDER_H_COMPLETE_OW
CRM_ORDER_I_MAINTAIN_MULTI_OW
CRM_ORDER_I_MAINTAIN_SINGLE_OW
CRM_ORDERADM_I_MAINTAIN_OW
.........
CRM_ORDER_I_COMPLETE_SINGLE_OW
CRM_ORDER_I_COMPLETE_MULTI_OW
CRM_ORDER_COMPLETE_SINGLE_OW
CRM_ORDER_COMPLETE_MULTI_OW
CRM_ORDER_FINAL_CALLS_OW
4. Commonly used BadIs in CRM

The BadI CRM_ORDER_STATUS can be used to process any logic when there is a
change of STATUS in the document at the Header/Item level.
In the method BEFORE_CHANGE you can put your logic/validation etc while the
status is changed. And in case of error, raise the exception NOT_ALLOWED. So, the
status change will not be allowed. In the method AFTER_CHANGE you can use your
logic that needs to be processed after the status is changed. You cannot raise any
exceptions. You can put filters for which Status change the BadI should be triggered.
Note: - The parameter CHECK_ONLY is used in two ways.
If you want to throw error messages when the user is trying to change the Status, then
trigger the BadI when the CHECK_ONLY parameter is initial.
If you want to hide the Status, then trigger the BadI when the CHECK_ONLY
parameter contains X.
The BadI CRM_ORDER_FIELDCHECK is used to dynamically make a field INPUT

OFF in transaction CRMD_ORDER.The method FIELDCHECK is used for the same.
Example: -
METHOD if_ex_crm_order_fieldcheck~fieldcheck.
INCLUDE crm_direct.
DATA: lv_status_completed TYPE crmt_boolean,

ls_input_field_names TYPE crmt_input_field_names,
ls_pre_status_completed TYPE crmt_status_prestate,
ls_sales_wrk TYPE crmt_sales_wrk,
lv_mode TYPE crmt_mode,
lv_object_type TYPE swo_objtyp,
ev_header TYPE crmt_object_guid,
lt_crmt_status_tab TYPE crmt_status_tab,
wa_crmt_status TYPE crmt_jstat,
l_set,
crmd_orderadm_h TYPE crmd_orderadm_h.
ev_header = is_fieldcheck_com-ref_guid.
CALL FUNCTION 'CRM_ORDERADM_H_READ_OW'

EXPORTING
iv_orderadm_h_guid = ev_header
IMPORTING
ev_mode = lv_mode
ev_object_type = lv_object_type
EXCEPTIONS
admin_header_not_found = 0.
IF lv_object_type IS INITIAL.
CALL FUNCTION 'CRM_ORDERADM_I_READ_OW'
EXPORTING
iv_guid = ev_header
iv_include_deleted_item = ' '
IMPORTING
ev_header_guid = ev_header
EXCEPTIONS
item_not_found =1
OTHERS = 2.
CALL FUNCTION 'CRM_ORDERADM_H_READ_OW'

EXPORTING
iv_orderadm_h_guid = ev_header
IMPORTING
ev_mode = lv_mode
ev_object_type = lv_object_type
EXCEPTIONS
admin_header_not_found = 0.
ENDIF.
CHECK ( lv_object_type = gc_object_type-service ).
*** Make the CATEGORY field Display ==> Header

IF iv_object_name = gc_object_name-activity_h.
LOOP AT ct_input_field_names INTO ls_input_field_names.
IF ls_input_field_names-fieldname = 'CATEGORY'.
ls_input_field_names-changeable = gc_changeable-no.
MODIFY ct_input_field_names
FROM ls_input_field_names
TRANSPORTING changeable.
ENDIF.
ENDLOOP.
ENDIF.
ENDMETHOD.
5. Copy Control in Business Transactions

Copy Control in Business Transactions

Copy control is a functionality that controls copying business transactions
and creating follow-up documents.
Copy control is set up for transaction types and for item categories. The first
one controls the copying of header data and the second one item data.
Customizing of copy control: IMG -> Customer Relationship Management ->
Transactions -> Basic Settings -> Copy Control for Business Transactions.
By default only a part of the information is copied from preceding to follow-

up transaction:
Transaction description (copied by default)
Partners (controlled by the partner determination procedure and access
sequence)
Texts (controlled by text procedure and access sequence)
Items (if specific criteria are met)
The rest of the information can be copied only using a BADI

CRM_COPY_BADI.
Copy Control in Business Transactions II

Copy control also defines which transaction types are available in the
drop-down menu to create a follow-up transaction. By default copying
from Business Activity and Task is available into all transaction types.
The same applies when Business Activity or Task is created as a follow-
up for any transaction.
For other transaction types (not Activity or Task) the document should
not contain errors in order to create a follow-up transaction.
Copying from/to Business Activity or Task can be explicitly restricted

with BADI CRM_COPY_BADI. But this will not remove Activities and
Tasks from the drop-down list of available transaction types. They will
still be available in the menu, but copying will be restricted after
selection.
If one document is created as a follow-up to another, the organizational

data in the follow-up document is not changeable. This is controlled in
function module CRM_ORGMAN_SALES_AREA_FC. A modification
should be done in order to enable organizational data maintenance in a
follow-up transaction.
BADI for Copy Control

Copy control has a special BADI CRM_COPY_BADI to enable the customers to
influence the copy process. The BADI is filter-dependant. Several implementations
with different filter values can be programmed. Filter value is then specified in the
customizing as a copy routine field.
The following methods are available:
SHIPPING Method for Object SHIPPING
COPY Method for COPY object (copying requirement)
ORDERADM_I Method for ORDERADM_I object
PRODUCT_I Method for PRODUCT_I object
ORDERADM_H Method for ORDERADM_H object
PRICING Method for object PRICING
SALES Method for SALES object
ACTIVITY_H Method for ACTIVITY_H object
ORDPRP_I Method for Object ORDPRP_I (Contracts Assortment)
BILLPLAN Method for BILLPLAN object
BILLING Method for BILLING object
OPPORT_H Method for OPPORT_H object
LEAD_H Method for Object LEAD_H
SCHEDLIN_I Method for Object SCHEDLIN_I
FINPROD_I Method for Object FINPROD_I
SERVICE_I Method for Object SERVICE_I
PRICING_I Method for Object PRICING_I
PAYPLAN Method for Object PAYPLAN
CUSTOMER_I Method for Object CUSTOMER_I
CUSTOMER_H Method for Object CUSTOMER_H
DATES Method for object DATES
CANCEL Method for object CANCEL
DOC_FLOW Method for Object DOC_FLOW
Method COPY can be used to restrict copying if some criteria are not met.
Other methods are used to copy necessary information from a preceding to a follow-up
document. They have all necessary information as the parameters.
6. Transaction CRMV_EVENT
In transaction CRMV_EVENT you can configure your own function module which will
be triggered based on the configuration.
Event Handler
Maintenance Transaction: CRMV_EVENT (Table with all events)

Function Modules: CRM_EVENT_SET_EXETIME_OW
CRM_EVENT_PUBLISH_OW
Example: Event: END_ORDERADM_H

Function Module: CRM_ORDERADM_H_MAINTAIN_OW
Table with all events that are registered on event

end_orderadm_h are processed now
PERFORM EXECUTE_CALLBACKS_PLANNED
USING LV_GUID_HDR
IV_EXETIME
LT_PLAN_EXETS <= table with CallBacks
CHANGING LV_CALL_RCODE
LT_EVENT_RCODE.
Transaction: CRMV_EVENT for Header processing
Distinguish between Header and Item
Event is published by function module

CRM_EVENT_PUBLISH_OW
As an example see below:-
As mentioned above, the function module /ASML1/CRM_BILLREQ_SET_BLOCK

will be triggered at the end of the billing request when a billing request is created with
reference. And it will trigger for the HEADER segment. You can set whether the function
module should be triggered for header level or at item level. Also, you can set other
attributes as shown above. Please go through the transaction to explore further options.
Have a look at the parameters that can be used in the function module. The parameters
are filled based on the EVENT.
The function module should be updated in the table CRMC_EVENT_CALL.
Note: - If you want to update any data in the database table, please take care whether your
function module is handling data at the database level or object buffer level. If you are
working at the object layer but you need to update database table, do not try to update the
tables using CRM_ORDER_MAINTAIN or anything else. Just populate the object buffer
with the data you want to be updated in the database. System will take care of the update.
Event Handler IV
The execution of a specific event is normally done in a following order:
Events are planned for execution in a CHANGE function module. All
necessary parameters are provided (old/new data, etc.). This is done in
function CRM_EVENT_PUBLISH_OW.
In MAINTAIN function module the execution time of the event is set and all
events planned for that execution time are executed. This is done in function
CRM_EVENT_SET_EXETIME_OW.
When the event is executed it is removed from the internal table with planned
events.
Event table is delivered by SAP and normally should not be changed by the
customers. Only in rare cases when certain functionality requires an
additional event to be added or an existing event to be changed this can be
done after prior consulting with responsible developer.
Events influence the whole transaction processing and may cause
performance problems if they are not properly set up.
When & where the EVENT is triggered:-

Event Handler
CRM_ORDER_MAINTAIN
CRM_ORDER_MAINTAIN_MULTI_OW
CRM_ORDER_H_PREPARE_OW
CRM_<OBJECT>_PUBLISH_OW
CRM_EVENT_SET_EXETIME_OW (end_<OBJECT>)
.........
CRM_ORDER_H_COMPLETE_OW
CRM_EVENT_SET_EXETIME_OW (end_header_maintain)
CRM_ORDER_I_MAINTAIN_MULTI_OW
CRM_ORDER_I_MAINTAIN_SINGLE_OW
CRM_<OBJECT>_PUBLISH_OW
CRM_EVENT_SET_EXETIME_OW (end_<OBJECT>)
.........
CRM_ORDER_I_COMPLETE_SINGLE_OW
CRM_EVENT_SET_EXETIME_OW (end_item_maintain)
CRM_ORDER_I_COMPLETE_MULTI_OW
CRM_ORDER_COMPLETE_SINGLE_OW
CRM_EVENT_SET_EXETIME_OW (end_order_maintain)
CRM_ORDER_COMPLETE_MULTI_OW
CRM_EVENT_EXETIME_MULTI_OW (end_order_multi_maintain)
CRM_ORDER_FINAL_CALLS_OW
Event Handler
Orderadm_i_publish_ow Event handler Event consumer

After_change (old- / new values) Plan (End_Item_Maintain) ......
CRM_PRODUCT_I_Unit_EC CRM_PRODUCT_I_Unit_EC
CRM_PRIDOC_UPDATE_EC
. Plan (End_Order_Maintain) CRM_PARTNER_DETERM_EC
. CRM_PRIDOC_UPDATE_EC
.
schedlin_i_publish_ow
After_change (old- / new values)
.
.
.
Event handler CRM_PRODUCT_I_Unit_EC

CRM_EVENT_SET_EXETIME_OW Plan (End_Item_Maintain) After_change Orderadm_i
(end_Item_maintain) CRM_PRODUCT_I_Unit_EC (old- / new values)
.
.
Plan (End_Order_Maintain)
. CRM_PRIDOC_UPDATE_EC
CRM_PRIDOC_UPDATE_EC
CRM_EVENT_SET_EXETIME_OW After_change Orderadm_i
(end_Order_maintain) (old- / new values)
7. Debugging in middleware
It is important to know how to debug the middleware, since in CRM the documents are
distributed in R/3.
In CRM, before you SAVE the document go to transaction SMQS and De-Register the
R/3 destination. Then SAVE the document.
Now go to transaction SMQ1. You will see the document available in the Outbound
Queue. You can debug the document now. This is the scenario when the document is
transferred from CRM R/3.
For R/3 CRM:

While creating the document in CRM, SAVE the document with error (have an error in
the document while SAVING it). Go to transaction SMQR. You will get the document
number in this transaction. Select the document and De-Register it. Now, the document
has been processed in R/3 and is in the Inbound Queue. Go to transaction SMQ2 and
debug the document.
If you want to see the BDoc messages go to transaction SMW01. If the document has
not been processed (yellow traffic light), you can reprocess the document.
8. Error handling in CRM

Application Log and Messages
Application log is a Basis functionality used in CRM to store error messages
in CRM documents. Application log is saved together with corresponding
business transaction.
The application log can be displayed in CRMD_ORDER transaction for a
currently opened document. An alternative way to display application is to
use transaction SLG1. The object is CRM_DOCUMENT.
SLG1 can be used to monitor for example order upload errors (CRM -> R/3).
In the application log the user can see 3 types of messages:
E error messages (stored in the application log after saving)
W warning messages (deleted from application log after saving)
I information messages (deleted from application log after saving)
Messages in the application log are identified by message class and message
number. Theres a possibility to display detailed information about the
message and to navigate to the corresponding field in CRMD_ORDER
transaction.
SE91 transaction can be used to display message information (in case the
customer provides only a number of the message and not the text).
Application Log and Messages II

CRM messages have also so-called level or degree. The level of the messages
defines if this message will be shown in the application log for a specific user.
In the user master record (SU01) theres a parameter CRM_USER_LEVEL.
This one specifies the level of the user.
The standard settings for message levels (degrees) can be found in
transaction CRMC_MSGS.
The customer can overwrite system settings with transaction CRMC_MSGC.
Restriction: message type cannot be lowered (for example from E to W), it can
only be set to higher one (W to E).
After setting message level to 9 it will not be shown in the application log.
Messages are collected in the function module CRM_MESSAGE_COLLECT,

deleted in CRM_MESSAGES_DELETE.
CRM_MESSAGES_SEARCH can be used to search for messages.
The function module 'CRM_MESSAGES_CHECK_FOR_ERRORS' is used to check

whether any error occurred in the transaction CRMD_OREDR while processing.
The function module 'CRM_MESSAGES_SEARCH' is used to search for error messages
if any error has occurred.
The function module 'BAL_LOG_MSG_READ' is used to read the error messages that
has occurred while processing the transaction CRMD_ORDER.
Example:-
FORM check_object_for_errors USING iv_obj_guid TYPE crmt_object_guid
iv_obj_kind TYPE crmt_object_kind
CHANGING p_t_msg TYPE bapiret2_t
p_error_occured TYPE crmt_boolean.
DATA:
lt_msg_handle TYPE bal_t_msgh,
ls_log_msg_handle TYPE balmsghndl,

ls_log_msg TYPE bal_s_msg.
*/ (re)init
CLEAR p_error_occured.
*/ check object for errors

CALL FUNCTION 'CRM_MESSAGES_CHECK_FOR_ERRORS'
EXPORTING
iv_ref_object = iv_obj_guid
iv_ref_kind = iv_obj_kind
EXCEPTIONS
errors_exist = 1
OTHERS = 2.
IF sy-subrc EQ 0. "no errors
EXIT.
ENDIF.
*/ search for error messages

CALL FUNCTION 'CRM_MESSAGES_SEARCH'
EXPORTING
iv_ref_object = iv_obj_guid
iv_ref_kind = iv_obj_kind
IMPORTING
et_msg_handle = lt_msg_handle
EXCEPTIONS
appl_log_error = 1
error_occurred = 2
OTHERS = 3.
IF sy-subrc NE 0. "error
PERFORM msg_add USING msgty_s sy-msgid sy-msgno
sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
CHANGING p_t_msg.
EXIT.
ENDIF.
* fill message tab

LOOP AT lt_msg_handle INTO ls_log_msg_handle.
CALL FUNCTION 'BAL_LOG_MSG_READ'
EXPORTING
i_s_msg_handle = ls_log_msg_handle
IMPORTING
e_s_msg = ls_log_msg
EXCEPTIONS
log_not_found = 1
msg_not_found = 2
OTHERS = 3.
IF sy-subrc <> 0.
PERFORM msg_add USING msgty_s sy-msgid sy-msgno
sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4

CHANGING p_t_msg.
ELSE.
PERFORM msg_add USING ls_log_msg-msgty
ls_log_msg-msgid
ls_log_msg-msgno
ls_log_msg-msgv1
ls_log_msg-msgv2
ls_log_msg-msgv3
ls_log_msg-msgv4
CHANGING p_t_msg.
IF ls_log_msg-msgty EQ msgty_e
OR ls_log_msg-msgty EQ msgty_a.
p_error_occured = abap_true.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM. " check_object_for_errors
Note:-
The function module CRM_MESSAGE_COLLECT will add message to display in the
window at the top of transaction CRMD_ORDER.
You can use function module *INTLAY* to get the GUID for the document you are
processing. Because the Interaction Layer is populated when there is Function Module
processing like CRM_ORDER_READ, CRM_ORDER_MAINTAIN, etc
9. Overview of Customizing
Transactions
Item categories
Copying control
Pricing
10. Helpful Reports
Report Function
CRM_MESSAGES You can use this report to influence the following

parameters:
Degree of usage (degree of detail)
The degree of detail specifies which user receives
what range of messages. The F4 help provides you
with the possible values for selection. (9 = BDOCs
are shown in the order)
CRM_ORDER_READ Read orders with CRM_ORDER_READ
CRM_ORDER_DELETE Delete orders with CRM_ORDER_DELETE
CRM_ORDER_MAINTAIN Maintain orders with CRM_ORDER_MAINTAIN
CRM_ODE_CHECK_DOC CRM data exchange of customer orders: Check

documents concerning inconsistency

1 Order

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 Order

Uploaded by

Copyright:

Available Formats

CRM Programming Fundamentals

This is a reference only

1. One Order Object Model

Administration header and Set have different GUID. They are

Administration (Header / Item)

1:1 Relation to the administration header OR to the administration

Sets (Link Handler)

Orderadm_h Activity_h Opport_h

GUID Data REF_GUID Data REF_GUID Data

Orderadm_i Product_i Service_i

Header GUID Data REF_GUID Data REF_GUID Data

Sets / Link Handler:-

Data model: Sets / Link Handler

SETS <-> EXTENSIONS

LINK-HANDLER: => DB table: CRMD_LINK

Example: Order 5041922

Sales data => SET Product data => EXTENSION

Working with Business Transactions SAP GUI

A Service Order looks as follows:

Header data Shipping

Service process can contain different items:

BADI for Service Process:

Header data Conditions

Service confirmation can contain different items. These items are

In order to create a confirmation from a service process the process

Similarly, we can create Billing Requests from Confirmation.

Architecture of the systems (CRM & R/3):-

Most of the tables have the GUID as a key field

(GUID: Universal Unique Identifier, data type

Layers of programming model in business transactions:-

User interface layer (UI)

Interaction layer (IL)

Each layer should communicate only to directly linked layers:

User Interface GUI-Screens / Web / ...

For Screen For WEB

BAPI Methode Methode Methode Methode

API (def. Methods) Methods to create, read and change

Database Layer Read and save data from/to database

CRM Layer model II

User Interface in Business Transaction:-

User Interface in Business Trans. II

Customer Extensions in Business Transact.

CRM_ORDER_SAVE CRM_ORDER_SAVE_OW CRM_ORDERADM_H_SAVE_OB

Overview of Naming conventions used by SAP:

Development classes (packages): Variables:

2. One Order Reporting Framework

SELECT <document no>

CALL METHOD cl_crm_report_qupart=>get_qupart_by_token

Now, iv_qupart_and is appended to internal table it_qupart.

CREATE OBJECT cl_question Constructor

cl_question refers to Class CL_CRM_REPORT_QUESTION.

CALL METHOD cl_question->refresh.

CALL METHOD cl_question->get_ext_object

Finally, call the following Method:

CALL METHOD lv_locatorlist->get_extension

lv_locatorlist TYPE REF TO cl_crm_report_ext_locatorlist.

lt_requ_columns TYPE crmt_report_requ_columns_ta.

lt_list TYPE crmt_report_locatorlist_ta. This contains the final list of selection.

3. Commonly used Function Modules in CRM

The function module CRM_STATUS_CHANGE_FOR_ACTIV_OW is used to change

CALL FUNCTION 'CRM_STATUS_MAINTAIN_OW'

The function module CRM_ORDER_CHECK_AUTHORITY_GEN is used to check