CR712011 CRM Abap V1 4

CRM ABAP
Srinivasarao Kasa Souptik Banerjee Amit Biswas Himanshu Bhandari
India SAP CoE, Slide 1
Definition
To process back end operations of CRM and to enable communication with other SAP (R/3 , IS-U ) and non SAP systems which uses Function modules (FM), Business Add Inns (BADI), Remote Function Calls (RFC) Application Programming Interfaces (API) and BAPIs.
Part 1 - SAP CRM Programming

1 2
Prepare Me TellMe
3
ShowMe
LetMe HelpMe
5
Purpose
In SAP CRM mixed documents are possible, for example, Activity plus Sales Order plus Service Order in one document. The Business Transactions (Activities, Tasks, Leads, Opportunities, Contracts, Quotations, Sales Orders, Service Notifications, Service Orders, Complaints etc .) in SAP CRM use the CRM One Order model, which is the foundation for a: Unified structure for all business partner-specific transactions Multi-functional business transactions: one instance approach Easy transformation between different transaction object types. Design of central components as compactly / slim as possible CRM has its Own Data model, which is different from R/3. The three important data models that we need to understand in CRM are: Business Transactions (One Order) Business Partner Product Master
Use
R/3-Sales-Document E.g. 210 fields in one table (item table) not all fields are used by all document types CRM-Document The same data are split into 5 tables. Each document type uses the appropriate tables sales data shipping data pricing purchase data partners Service The split of fields into small logical business groups enables the re-usage of objects/business groups, what in the end avoids big redundant programs and/or module pools. The core components can always be reused. Therefore: No redundant coding for different transaction types necessary. Less error prone.
Post Processing Framework

The Post Processing Framework (PPF) provides SAP applications with a uniform interface for the condition-dependent generation of actions (for example, printing delivery notes, faxing order confirmations, or triggering approval procedures). The actions are generated if specific conditions are fulfilled for an application document, for example a specific status is set (approval by some person) or a specific date has been reached (two weeks before end of contract). The actions are then processed either directly or in a scheduled report later on.
Purpose
Actions are used in maintaining and improving business relationships. We can schedule and start predefined conditions with the Actions by means of userdefinable conditions from transaction and marketing objects. Followings are the basic use of Actions in PPF Create follow-up transactions automatically Printing, sending e-mails, and faxing with Smart Forms Starting a workflow to automate the process Execution of custom functionality developed in BADI
Date Management
Dates are important for the correct processing of all business transactions. It is particularly necessary in global business processes, covering several countries and time zones, to have a date management system that can convert time zones and the factory calendar in documents of business partners involved in a transaction. The component Date Management enables you to process as many dates as you require in a document. You can either enter dates yourself, or, using date rules, have the system calculate these. In Customizing, you can define date types, durations and date rules to meet your requirements.
Purpose
The component Date Management offers a flexible tool for defining dates and processing these in documents. It also provides the same interface for all CRM Documents, as well as the same processing and controlling (Customizing) of dates. Date Management covers the following functions: You can define dates (date types) and durations to meet your requirements. That means you can name the date types and durations according to your company terminology. For every transaction at the header and/ or item level, you can define which date type you need for the transaction. By doing this, you avoid saving unnecessary date types on the database. The same applies for durations. To assign dates and durations, you group the desired date types and durations together in a date profile and assign this to a transaction type or an item category. You can calculate dates using predefined rules. In date rules, you can link whichever date types and durations you require, as well as other date rules with each other, so that you get calculation chains.

1 2
Prepare Me TellMe
3
ShowMe
LetMe HelpMe
5
CRM Data Model

Transaction SD11 can be used to view the CRM Data Model. The data model is called CRM
To the right is an extract of the business transaction model. Besides this all other objects used by CRM (like BPs, Products, etc.) can also be seen in here
CRM Data Model
Contd
Highlight a node and press the button Sub-tree followed by Graphic. This will generate a graphical view of the tables with the proper hierarchy
One Order Data 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.

Administration header Extension
Contd
Administration header and Extension have the same GUID

CRMD_ORDERADM_H CRMD_ORDERADM_I CRMD_ACTIVITY_H CRMD_OPPORT_H CRMD_SERVICE_I
Set
CRMD_LINK
Link handler
CRMD_SALES 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.

Administration (Header / Item) Header identifies the order in the system Item holds the relation to the order Extension
Contd
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)

Orderadm_h
Contd
Opport_h
REF_GUID Data
Activity_h
GUID
Data
REF_GUID
Data
Orderadm_i
Product_i
Service_i
Header
GUID
Data
REF_GUID
Data
REF_GUID
Data

SETS <-> EXTENSIONS
Sets are data structures that should be used by several objects (reusable structures). The sales set is an example of a set. It can be assigned to several items. Therefore a link handler is necessary.
Contd
The product data is an extension of the item data. As all extensions are always linked to one header or one item, it does not need its own handle or guid. This also applies for the fields table. A reference object type is also 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
Sales data => SET (search CRMD_LINK with GUID_HI = Item-Guid OBJTYPE_SET (Sales = 11, see CRMC_OBJECTS) Then search CRMD_SALES with Guid = GUID_SET.
Product data => EXTENSION (search CRMD_Product_I with Guid = Item-Guid)
Business Partner Data Model

In CRM all types of partners (sold-to, ship-to, prospect, vendor, etc) are considered business partners. This allows to use partners in transactions based on roles they occupy. Central Data stored in BUT000. Most tables/segments start such as BUT* or CRMM_BUT_*. Relationships stored in BUT050. Partner id is primary key BUPA guid is secondary key. Most API's & BAPI's for the Business Partner starts with : BAPI_BUPA_* or BUPA_* Some of common ones are: BAPI_BUPA_CREATE_FROM_DATA BAPI_BUPA_ADDRESSES_GET BAPI_BUPA_ADDRESS_GET_DETAIL
Product Master Data Model

Technically a product does not have any segments until assigned to product category.
The product subtype hierarchy R3PRODSTYP defines this i.e MAT_FERT which has Set Types: COMM_PR_MAT COMM_PR_UNIT
You must assign a product to a valid category before you can assign it segment data. The three important tables are: COMM_PRODUCT COMM_PR_FRG_REL COMM_PRMAT
One Order Prog. - Layer Model
Contd
A four-layer model is used as a basis for programming in the CRM system. This model makes a strict differentiation between the user interface, interaction, application logic and database access. Every layer is separate and contains data in a local memory. Access to the individual levels is carried out via the interfaces, but can only occur between the next direct layer or in the same layer. (for example, you can not access the user interface directly from the database layer).
This architectural approach has the following advantages: Layers can run on different platforms Layers can be exchanged Logic runs from one exact point and is always the same Maintenance friendly Minimization of database resources
Contd
Database Layer: The database layer is the interface to the database. All database operations for one object are carried out at this level (read, delete, add, change). The last original copy of the document before the changes were saved is kept in the local memory of the database layer. Object Layer: The object layer contains the complete application logic for editing an object (Changing order header, adding item, determining price....). The following examples are also included: Reading Customizing data Determining default values Implementing integrity rules Change object using default values and entries Maintain application log Register object (sub-objects link to main object, partner order...) Publish object for events or other objects (for example, saving, partner processing...) Definition of rules, the object condition in which the fields are changeable and the condition in which they are not. The condition after the last change is kept in the local memory of the object layer.
Contd
Interaction Layer: The interaction layer controls the business transaction process. It uses the user entries (field changes, function keys...), the methods called up from the object (FCODE control), the objects which should be displayed and processed, or the elements in the relevant user interfaces are activated (screen or field control). The interaction layer is described in a separate document.
User Interface: The user interface carries out the following tasks: Displaying and entering values (VIEW one or more objects) Visualizing sub-objects in a transaction and the relevant functions Other screen options such as foreign key checks and database accesses should not be implemented.
One order layer Model Vs MVC
Data Posting between Layers
Data Posting between Layers
Contd
The function module CRM_ORDERADM_I_READ_OB is called up from the function group CRM_ORDERADM_I_OW, in order to write the admin item into the work area. If the corresponding admin item is not in the object buffer, then CRM_ORDERADM_I_READ_OB calls up the function module CRM_ORDERADM_I_READ_DB, in order to read the item from the DB buffer.
If the item is not kept in the DB buffer, the function module CRM_ORDERADM_I_READ_DB calls up CRM_ORDERADM_I_SELECT_S_DB.
If it is not kept in a buffer, the item goes from the DB into the DB buffer, from there into the object buffer and from there into the work area. After the item has been processed in the work area, it is written in the object buffer using the function module CRM_ORDERADM_I_DATA_PUT_OB. When saving, FB CRM_ORDERADM_I_SAVE_DB calls up the generic module CRM_ORDER_TABLE_SAVE. This generic module determines first of all the admin items that should be added or changed in the database. Afterwards it calls up the posting module CRM_ORDERADM_I_SAVE_DU, which writes the admin items in the update task into the database.
CRM One Order Flow

I
II
III
CRM_ORDER_READ
CRM_ORDER_READ_OW
CRM_ORDER_MAINTAIN_MULTI_OW CRM_ORDER_MAINTAIN
CRM_ORDER_H_MAINTAIN_OW CRM_ORDERADM_H_MAINTAIN_OW
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
CRM One Order Flow
Contd
DISPLAY: The generic function module CRM_ORDER_READ (and the connected segment FMs) is called in order to retrieve all relevant data for the one order document. MAINTAIN: The generic function module CRM_ORDER_MAINTAIN (and the connected segment FMs). Updates the documents object layer after user interaction or for system defaulting. SAVE: The generic function module CRM_ORDER_SAVE (and the connected segment FMs). Persists the document and the changes in the database. DO NOT CALL any SAVE related function modules (*_save_*) during the maintain cycle or vice versa. The latest call in order to prepare the document data for saving (checks, manipulation) should be done in BAdI ORDER_SAVE. Use the *_OB FMs in order to modify specific segments.
Use of 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.
Use of 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.
Use of CRM_ORDER_MAINTAIN Contd

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.
Note: Care must be taken for locking/unlocking the document before making any changes.
Call Stack for CRM_ORDER_MAINTAIN

CRM_ORDER_MAINTAIN CRM_ORDER_MAINTAIN_MULTI_OW CRM_ORDER_MAINTAIN_SINGLE_OW CRM_ORDER_H_MAINTAIN_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_<OBJECT>_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
One Order Objects Naming Conventions

Function Modules and Reports: <component>_<object>_<method>_<layer> Example: CRM_ORDERADM_H_READ_OB
If you are working with several layers, the following conventions apply: (Analogue to the 4 layer model: D/O/I/U)
Ending: *_DU (for database update) Ending: *_DB (for database buffer) Ending: *_OW (for object work area) Ending: *_OB (for object buffer) Ending: *_IL (for interaction layer) Ending: *_UI (for user interface) Ending: *_CD (for Customizing dialogue) Ending: *_CB (for Customizing buffer) Ending: *_FC (for Fieldcheck) Ending: *_EC (for Event callback) Ending: *_AC (for Archiving) Layer that implements the database update Layer containing the database buffer Layer that contains the current data to be processed Layer in which current data is buffered Layer containing the interface (flow logic/field selection) Layer containing the interface (screen) Layer containing Customizing maintenance Layer containing the read module for Customizing Layer containing fieldcheck mehods for fieldselection Layer containing callback methods for event handler Layer containing methods archiving
Commonly Used Some BADIs

A variety of BADIs are available around One Order Business Transactions. Below are the collection of selected BAdIs:
CRM_COPY_BADI Copy control for One Order documents
CRM_ORDER_INDEX_BADI
CRM_ORDER_FIELDCHECK CRM_CONFIRM_01 CRM_UPLOAD_BEA_FILL COM_PAYCARD_BADI ORDER_SAVE CRM_DATAEXCHG_BADI CRM_COND_COM_BADI CRM_BWA_MFLOW CRM_30A_USER_EXITS
Update of table CRMD_ORDER_INDEX

Field check during transaction processing Update of field catalog to APO Mapping of fields to Billing Engine Extend Structure for Communication with Clearing House Check and manipulate data before docs are saved Data Exchange with R/3 Extension of communication structure for pricing BW Extraction Data Exchange with Mobile Clients/Mobile Bridge
Events & Callback Function Module

During processing each part of CRM document, (e.g. Partners, Customer fields, Organizational data, etc.) specific events are triggered in SAP CRM. Against these events special function modules are executed. These are called Callback Function Modules. If we need to perform certain activity against any business transaction changes; both for UI & data migration scenarios, we can use Callback function module. Callback function modules basically return the old and new value of the data after an operation and thus gives you a snapshot of what data changed in the process. These callbacks function module names are suffixed with "_EC" at the end. It means they have special interface that is needed when module is to be used as callback. Callbacks are executed by SAP CRM if they are connected to certain events. In transaction CRMV_EVENT standard configurations are maintained.

Callbacks are used mainly for processing documents. For example in standard they are used to copy organizational data from previous document when creating new follow-up document. The most classic use of Callback modules is in Data Exchange. The callback modules help the application decide what data has changed, and thus, what must be sent over to the other connected systems. Custom callback is configured through Maintenance view CRMV_EVENT_CUST. This view is used to register function modules for events. When an event is published, the event handler finds all function modules (callbacks) registered for this event and runs them based on the priority and execution time set at the configuration.

Suppose we want to send an Email to a supervisor every time a user changes the BP name. The only way we can know if the BP name has changed is by comparing the database for BUT000-NAME_FIRST and BUT000-NAME_LAST between before and after the operation. To do this, we can just call module BUP_MEMORY_BUT000_CALLBACK, or BUPA_GENERAL_CALLBACK. This returns the BUT000 state before and after in 2 tables - ET_BUT000_OLD and ET_BUT000_NEW. So you can easily compare the contents and react accordingly

T. Code - CRMV_EVENT
Callback Configuration
View CRMV_EVENT_CUST:
Fields in this view are explained from next slide onwards.
Transaction category (SUB_TYPE)
(contd.)
Business transaction category (Sales, service, contact, opportunity etc.). Every process type contains a main transaction category (generally sales BUS2000115) followed by secondary transaction categories. For example, the process type SRVO (Service order) contains the categories Sales (BUS2000115), Service (BUS2000116) and Business Activity (BUS2000126). Execution time (EXE_TIME) The point during the processing of a transaction when you want to run your callback i.e.. immediately, end of item processing, before save etc. Priority (PRIO) Priority of callback. Acts as an additional sort criterion as to when callbacks are carried out. Object name (OBJ_NAME) The object you are interested in (e.g. Partner).
Event (EVENT)
(contd.)
The event you are interested in (e.g. AFTER_CREATE, save, end of header processing). Note: Events are maintained under Definitions - Events (Maintenance View CRMC_EVENTS). Checkbox for Perform function for document item (ONLY_ITM) The callback should be carried out at item level. Checkbox for Do not process function if error occurs (ERROR_CHECK) If, for some reason, the callback raised an error, this flag causes the message to be passed on to the calling program.
Call callback (CB_FREQ)
(contd.)
This is a very important field to maintain Frequency and characterization of the callback. It determines how often the function module should be called. The following values are allowed: Call to Header/Item, with Object, Event, Attr., Old/New Data (SPACE): The callback can be carried out for headers and items. The callback is provided with the object name, the event, old and new data. Old data is the old version of the work area structure. New data is the new version of the work area structure. The structure to be passed is defined in table CRMC_EVENT_STRUC. If old and new data are required and the callback should run immediately (EXE_TIME = 001) once an event is published, you must use this setting and not 'K'. (K is explained below).
Call to Header/Item with Object, Event, Attr. W/Out Old/New (A): Like SPACE, but without old and new data.
(contd.)
Call to Header/Item, W/Out Object, Event, Attr., Old/New Data (B): The callback can be carried out for header and items. Old and new data are not provided.
Call Just Once Per Transaction (C): The callback is carried out only once per transaction. Old and new data are not provided. Note: This is the only setting that should be used with EXE_TIME 080 (Save).
Call to Hdr /Item with Object/Event/attr.+ Compressed Old/New (K): The callback can be carried out for headers and items. The callback is provided with the object name, the event, and cumulated old and new data. This means that if an event is published more than once, you get the old data from the initial call, and the new data from the final call. All changes in between are irrelevant. Normally, you need to set SPACE if you want to react immediately and K if you react later. However, for specific partner data, i.e. if you are registered for a change to a specific partner function (field attri1 = 0001 or similar) and not general partner changes (field attri1 = <*> ) you need to use SPACE, as partner data cannot be cumulated.
How to check which callbacks are executed?

To check which function modules are executed after certain activity in system, we can put a break point in function module CRM_EVENT_SET_EXETIME_MULTI_OW. In <FUNC_EXET>-FUNC_NAM we will have function module's name. Also a good idea is to go to CRMV_EVENT transaction code, and filter callbacks from its configuration. If we are looking for what is executed after changing customer fields on service document, we can search for transaction category Service process, object name Customer header data, and event AFTER_CHANGE. This way we will surely find all interesting callbacks.
Features of Actions
To process Actions at Transaction level, Action profile needs to be configured and assigned to Transaction Type definition. List of all scheduled actions for the Transaction can be displayed on the Actions tab of transaction document. Following information is displayed in the list for each action: Status (action scheduled, action processed) Description (purpose of action) Conditions (settings for action definition and conditions are displayed) Creator, Creation date
Features of Actions
There are various processing types for actions: Methods (Business Add-Ins)
Contd
Methods are Business Add-In (BADI) implementations. You can define your own BADI implementation to adapt actions to your processes and needs. (EXEC_METHODCALL_PPF is the relevant BADI.) Examples for standard methods include the following:
COPY_DOCUMENT (create a follow-up document) COMPLETE_DOCUMENT (set status completed within document) CREDIT_MEMO (create credit memo item) REPAIR_ITEM (create a repair item) 1O_EVENT_CREATE (create a workflow event)
Features of Actions:
SAP Business Workflow
Contd..
This is suitable for more complex processes, for example, a follow-up transaction that includes an approval process. Smart Forms SAP Smart Forms must be used to print, e-mail or fax documents such as an order confirmation. You can use the graphics tool, SAP Smart Forms, to design the layout of output forms. SAP delivers several Smart Forms for outputs in SAP CRM: Form CRM_ORDER_CONFIRMATION_01 (suitable for faxes, letters, and email) Form CRM_ORDER_LEASING_01 (suitable for faxes, letters, and e-mail) Form CRM_OPPORTUNITY_01 (suitable for faxes, letters, and e-mail)
Define Action Profile & Action Definition

Actions can be accessed and configured via IMG -> Customer Relationship Management ->Basic Functions -> Actions -> Actions in Transactions

To create an Action Profile - Click on CREATE ACTIONS WITH WIZARD
Click CONTINUE. Enter the Details to create Action Profile.
Click CONTINUE. Enter the Details to create Action.

Click CONTINUE. Enter the Details to set Action.


A scheduled action can be processed at different times. In the Processing Time Details, there are 3 Options. Therefore, processing can be started immediately with the scheduling of an action. Alternatively, processing can be started after document posting. It is also possible that the actions are first only scheduled and processing is not started until later using a selection report or by setting a background job.
Click CONTINUE. Enter the Details to set Action.


The settings for partner determination are only necessary if the action is to be found depending on the business partner. Above all, this makes sense for processing with print, fax or e-mail. The output is sent to the corresponding business partner(s).
Click CONTINUE and select the Processing.


The processing that we select is the one on which we want the Action to work on. Processing can be of various types such as: Method Call Smart Forms Workflow For this example select Method Call
Click CONTINUE and Enter the BADI name that you want to assign with this Action.
Click the create icon to create a new implementation of the BADI: EXEC_METHODCALL_PPF
Contd
Click to create a new BADI Implementation
Give a new Implementation Name and Continue.
Contd
BADI Implementation
Give the Details and activate the Implementation
Write the code for processing logic in the method EXECUTE and Set the Parameter RP_STATUS = 1 for successfully processed action

After Set Up the Processing Click CONTINUE and Enter Action Description.
Click CONTINUE and assign Schedule Condition.


Skip Assign Schedule Condition and Start Condition to create manually later and Click Complete to finish the creation of Action profile and Action definition
Define Condition
We can change and define a condition for the previously created actions via IMG -> Customer Relationship Management ->Basic Functions -> Actions -> Actions in Transactions->Change Actions and Condition->Define Condition
Define Condition
Contd
Select the Action Profile and appropriate Action Definition. And then go to the tab Schedule Condition. Schedule Condition decides whether an action should be scheduled for processing or not. An action is therefore generated only if the schedule condition is met. It is not mandatory to assign a schedule condition.
Define Condition
Contd
Click Edit Condition in previous step, fill the details and click on the Condition Definition. Choose the condition value and save
You can also Create a Start Condition. Start Condition is checked before an action is executed. The Action is executed only if the Start Condition is satisfied.
Components of Date Management

As already discussed, date management consists of primarily Date Duration Date Rules The following slides would provide an overview on what each component represents.

Date
Contd..
Definition - A defined time period that is made up of a start time and an end time. Use - You use dates in calendar functions (for example, in activities), as well as for all dates that play a role in both business transactions (for example, valid-to dates, cancellation dates) and in actions (date-dependent conditions). Structure - A date is made up of a start time and an end time. The start time is within the time period, the end time is not. Dates that have the same start and end time are also called milestones. Dates are further described by the date type and distinguished in the system by a unique indicator (GUID). Dates need a reference object so that the system can interpret them uniquely.

Duration
Contd..
Definition - A timeframe between two points in time consisting of a number value and a time unit, for example 1 month. Use - The system uses durations when calculating dates. Durations are always given in entire numbers. You cannot combine two different units, for example the duration 1 hour 20 minutes would have to be expressed as 80 minutes. Structure - A duration always consists of a number value and a time unit, for example 5 days. The number value has no defined meaning without the time unit. The duration always has a local reference, that is, a reference object via which the time zone and the calendar can be determined.

Date Rules
Contd..
Definition - Rules for calculating times. The calculation can depend on other times, durations and reference objects. Use - The system can calculate times (dates) in transaction documents using date rules, for example the cancellation date of a contract. You can use predefined date rules or define your own date rules. You define date rules in Customizing for Customer Relationship Management under Basic Functions Date Management Define: Date Types, Duration Types and Date Rules. Date rules are defined in XML.You cannot delete date rules. Structure - Date rules can use times, date types, durations. Date rules have different versions. When date rules are changed, a new version of this date rule is created automatically. This ensures that date rules used in an existing document cannot be changed. The new version of the date rule is valid from the time it is created and is used automatically when a new document is created.

Reference Object
Contd..
Use - The system needs reference objects to be able to calculate dates. By referencing to a reference object, each time becomes a local date and a local time. As the system works internally with time stamps in global time UTC, it needs the reference object to translate the time into UTC. For durations, the system needs a reference object to determine the correct factory calendar (workdays and holidays). You can control which time zone and which factory calendar a date type or duration refers to by means of the reference object. For example, you can determine that the date type valid to in quotations is calculated in the users time zone who creates the quotation, regardless of the main location of the organization. The reference object for a date or duration is always defined independently of the date profile. That is why it is possible for a date type or duration to have different reference objects depending on the date profile. Different date types can have different reference objects within a date profile.
In Customizing for Customer Relationship Management under Basic Functions Date Management Define Date Profiles, select the valid reference objects for each date profile, and then, in the date profile, define a reference object for every date type and duration type.

1 2
PrepareMe TellMe
3
Show Me
LetMe HelpMe
5
Refer CRM data model

We can give any one order document from the tx:CRMD_ORDER.

Run the report CRM_ORDER_READ to know where and all one order data get stored. Example, Header data will be stored under structure ET_ORDERADM_H. The same can be referred to table CRMD_ORDERADM_H Similarly we can business partner data in business partner related tables

Take the key ,GUID , and Search in corresponding table

Suppose we want to change the status for Service Request Transaction from Open to In Progress when Employee Responsible is assigned to it and this has to be performed both from Web UI as well as backend. To do so, we have created a new Callback function module ZTSK_ASSIGNED_TO_CHANGE and assigned it to Transaction Category - CRM Service Request (BUS20000223) & Object PARTNER . The event for this scenario is AFTER_CREATE, as the function module will be triggered after creation of Employee Responsible partner. The value of Attribute is set to 0008 (as Function Category for Employee Responsible is 0008) so that call back function module will not triggered for every new partner addition at transaction level.

In the Callback function module, retrieve the current User Status for Transaction by calling function module CRM_ORDERADM_H_STATUS_READ_OW.

If the current status is Open, then it uses function module CRM_STATUS_CHANGE_EXTERN to change status to In Progress.
Process Actions (T. Code: SPPFP)

You can monitor and trigger the processing of actions for several documents and marketing objects using the action monitor. For example, if you have set the processing time for an action (for example, output) as Process Using Selection Report in Customizing, you can select the actions and trigger processing manually with this program. Also action monitor can be useful for actions where time dependent conditions need to be fulfilled after a certain time without any changes to the document. The program should be executed regularly so that actions are also started in these cases. If you regularly schedule the program as a background job, the system can automatically start certain actions, whose start conditions have been fulfilled, at a particular time. Define a variant for this in which you specify your selection criteria and select the flag Process without Dialog.
Processing Actions
Contd
Processing Actions
Contd
You select actions based on the application (in CRM, this is usually CRM_ORDER, except for Marketing Planner actions; use CRM_MKTPL), action profile, document number (application key), status (for example, unprocessed) If you select the flag Process without Dialog, system automatically processes the selected actions without first outputting a list. You receive a list of actions according to your selection criteria. In the status column, you can see whether the action is not processed (yellow) has been processed successfully (green) has been processed incorrectly (red) You can select individual actions in the list and trigger processing manually: for this, select the Process symbol. repeat processing. display output issue: For this, select the Preview symbol. display a processing log. For this, select the Processing Log symbol. You can also display whether the action has been changed, repeated, created manually or blocked.
Processing Actions
Date Management
In customizing, follow the path shown to reach date management.
Date Management
Configuring duration and date type in customizing.
Contd
Date Management
Configuring date rule in customizing.
Contd
When a new date rule is created the guid is automatically generated.
Date Management
Double click on the record opens the editor for date rule where the logic can be written in XML code or an ABAP function module can be called.
Contd
Date Management
Structure of the XML code
The first couple of lines are written as <?xml version="1.0"?> <SAPTimeRule>
Contd
The calculation is written in the tags as shown Here the date type PERIOD _DATE is incremented by 1 month and the new date is calculated. <VarTimeExp displayType="VarTime" name="RESULT" position="B">  </VarTimeExp> <MoveTimeExp displaytype="MoveTime" direction="+">  <VarTimeExp displayType="VarTime" name="PERIOD_DATE" position="B">  </VarTimeExp> <ConstDuraExp displaytype="ConstDura" duration="1" timeunit="MONTH">  <VarObjectExp displaytype="VarObject" name="SYSTEM"/>  </ConstDuraExp> </MoveTimeExp> Lastly all the open tags needs to be closed such as </MoveTimeExp> </AssignTimeExp> </ruleline> </TimeRuleTree> </SAPTimeRule>
Date Management
Date rule where ABAP function module is called.
Contd
Date Management
Structure of the ABAP function module.
Contd

1 2
PrepareMe TellMe
3
ShowMe
LetMe HelpMe
5
Change One Order Document

Create any one order using CRMD_ORDER Write one report to change the created one order by taking care of all necessary steps mentioned in previous slides
Check the changes in relevant tables

Define Call back function module for price change at Contract line item level and send approval notification mail to Sales Manager Pass the old & new price details on the Notification mail Check on CRMV_EVENT transaction what configuration is maintained for standard Callback function against Price change event
Actions
Define Action to trigger reminder mail to customer when Contract is expired Configure Action Profile and define Processing logic for Action to trigger reminder mail Configure Conditions for Action Profile and write logic in Start and schedule condition BADI Process Action using Transaction SPPFP and check status & processing log for already trigged actions
Date Management
Define date types, duration types and date rules.
Define date profile

Assign date profile to transaction type / item category. Create a date rule in XML or by calling ABAP function module.

1 2
PrepareMe TellMe
3
ShowMe
LetMe HelpMe
5
SAP CRM ABAP Help & Documentation

For overview on SAP CRM Technical and CRM data model refer http://wiki.sdn.sap.com/wiki/display/CRM/CRM+Developer%27s+Knowledge+Corn er For basics of ABAP refer http://help.sap.com/saphelp_nw70/helpdata/en/43/41341147041806e10000000a1553f 6/frameset.htm For overview of PPF refer http://help.sap.com/saphelp_nw70/helpdata/en/de/a38338d22aa947e10000009b38f8cf /frameset.htm For Step by Step Action Profile configuration refer http://wiki.sdn.sap.com/wiki/display/CRM/Action+profiles+in+SAP-CRM For Processing Actions refer http://help.sap.com/saphelp_sm40/helpdata/en/53/79f5397753057ee10000000a11402 f/content.htm For Date Management refer http://help.sap.com/saphelp_sm40/helpdata/en/d4/fce93a29768802e10000000a11402f /content.htm
Now You Should be Able to

Understanding of Business Transactions and One Order Overview Understanding Of One Order Data Model Understanding of One Order Layer approach and Programming Flow Understanding of Commonly used Function modules and BADIs Understanding of how CRM events and Call Back FMs works. Create and Configure Action Definition & Action Profile Configure Schedule Condition and Start Condition of an Action
Implement BADI for Processing an Action

Process and Schedule background job using Action Monitor (TCODE SPPFP) for an Action Create and configure date management
Thank You

CR712011 CRM Abap V1 4

Uploaded by

Copyright:

Available Formats

CR712011 CRM Abap V1 4

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

CR712011 CRM Abap V1 4

Uploaded by

Copyright:

Available Formats

CRM ABAP

Srinivasarao Kasa Souptik Banerjee Amit Biswas Himanshu Bhandari

India SAP CoE, Slide 1

India SAP CoE, Slide 2

Part 1 - SAP CRM Programming

India SAP CoE, Slide 4

India SAP CoE, Slide 5

Post Processing Framework

India SAP CoE, Slide 6

India SAP CoE, Slide 7

India SAP CoE, Slide 8

India SAP CoE, Slide 9

Part 1 - SAP CRM Programming

CRM Data Model

CRM Data Model

India SAP CoE, Slide 12

One Order Data Model

India SAP CoE, Slide 13

One Order Data Model

Administration header and Extension have the same GUID

One Order Data Model

India SAP CoE, Slide 15

One Order Data Model

India SAP CoE, Slide 16

One Order Data Model

LINK-HANDLER: => DB table: CRMD_LINK Function module: CRM_LINK_GET_OW

Product data => EXTENSION (search CRMD_Product_I with Guid = Item-Guid)

India SAP CoE, Slide 17

Business Partner Data Model

India SAP CoE, Slide 18

Product Master Data Model

India SAP CoE, Slide 19

One Order Prog. - Layer Model

India SAP CoE, Slide 20

One Order Prog. - Layer Model

India SAP CoE, Slide 21

One Order Prog. - Layer Model

One Order Prog. - Layer Model

India SAP CoE, Slide 23

One order layer Model Vs MVC

India SAP CoE, Slide 24

Data Posting between Layers

India SAP CoE, Slide 25

Data Posting between Layers

CRM One Order Flow

CRM_ORDERADM_H_SAVE_OB CRM_ORDERADM_I_SAVE_OB CRM_LINK_SAVE_OW CRM_ORDER_UPLOAD_SINGLE

India SAP CoE, Slide 27

CRM One Order Flow

India SAP CoE, Slide 28

India SAP CoE, Slide 29

India SAP CoE, Slide 30

Use of CRM_ORDER_MAINTAIN Contd

India SAP CoE, Slide 31

Call Stack for CRM_ORDER_MAINTAIN

One Order Objects Naming Conventions

India SAP CoE, Slide 33

Commonly Used Some BADIs

Update of table CRMD_ORDER_INDEX