CR712011-CRM_ABAP_V1.4

ãIndia SAP CoE, Slide 1

CRM ABAP

Srinivasarao KasaSouptik BanerjeeAmit BiswasHimanshu Bhandari


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.


1 Prepare Me

2 TellMe

3 ShowMe

4 LetMe

5 HelpMe

Part 1 - SAP CRM Programming


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-DocumentThe 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 user-definable 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 Prepare Me

2 TellMe

3 ShowMe

4 LetMe

5 HelpMe


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 BP’s, 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


• 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 Data Model


One Order Data Model Contd…

CRMD_ORDERADM_H CRMD_ACTIVITY_H

CRMD_OPPORT_H

CRMD_LINK CRMD_SALES

CRMD_SHIPPING

CRMD_ORDERADM_I

CRMD_SERVICE_I

Administration header

Link handler

Extension

Set

Administration header and Extension have the same GUID

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.


One Order Data Model Contd…Administration (Header / Item)

Header identifies the order in the systemItem 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 itemoptimal data space because sharing of header and item data is possiblepossibility to assign the same data to header and itemsit is only allowed to reference to an admin segment (1 level)


One Order Data Model Contd…Orderadm_h

GUID Data

Activity_h

REF_GUID Data

Orderadm_i

GUID DataHeader

Opport_h

REF_GUID Data

Service_i

REF_GUID Data

Product_i

REF_GUID Data


One Order Data Model Contd…SETS <-> EXTENSIONS

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.

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.

LINK-HANDLER: => DB table: CRMD_LINKFunction module: CRM_LINK_GET_OW

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

Sales data => SET(search CRMD_LINK with GUID_HI = Item-GuidOBJTYPE_SET (Sales = 11, see CRMC_OBJECTS)Then search CRMD_SALES with Guid = GUID_SET.


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_DATABAPI_BUPA_ADDRESSES_GETBAPI_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_MATCOMM_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


• 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

One Order Prog. - Layer Model 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.



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


• 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.

Data Posting between Layers Contd…


CRM One Order Flow

CRM_ORDER_READ_OW

CRM_ORDER_SAVE_OW CRM_ORDERADM_H_SAVE_OBCRM_ORDERADM_I_SAVE_OBCRM_LINK_SAVE_OWCRM_ORDER_UPLOAD_SINGLE

CRM_ORDER_READ

CRM_ORDER_MAINTAIN

CRM_ORDER_SAVE

CRM_ORDER_MAINTAIN_MULTI_OW

CRM_ORDER_MAINTAIN_SINGLE_OW

CRM_ORDER_H_MAINTAIN_OWCRM_ORDERADM_H_MAINTAIN_OW

CRM_ORDER_I_MAINTAIN_OW CRM_ORDERADM_I_MAINTAIN_OW

I II III


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 Segment’s 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 Segment’s 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_OWCRM_ORDER_MAINTAIN_SINGLE_OW

CRM_ORDER_H_MAINTAIN_OWCRM_ORDER_H_PREPARE_OWCRM_ORDERADM_H_MAINTAIN_OWCRM_<OBJECT>_MAINTAIN_OW.........CRM_ORDER_H_COMPLETE_OW

CRM_ORDER_I_MAINTAIN_MULTI_OWCRM_ORDER_I_MAINTAIN_SINGLE_OW

CRM_ORDERADM_I_MAINTAIN_OWCRM_<OBJECT>_MAINTAIN_OW

.........CRM_ORDER_I_COMPLETE_SINGLE_OW

CRM_ORDER_I_COMPLETE_MULTI_OWCRM_ORDER_COMPLETE_SINGLE_OW

CRM_ORDER_COMPLETE_MULTI_OWCRM_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) Layer that implements the database update

Ending: *_DB (for database buffer) Layer containing the database buffer

Ending: *_OW (for object work area) Layer that contains the current data to be processed

Ending: *_OB (for object buffer) Layer in which current data is buffered

Ending: *_IL (for interaction layer) Layer containing the interface (flow logic/field selection)

Ending: *_UI (for user interface) Layer containing the interface (screen)

Ending: *_CD (for Customizing dialogue) Layer containing Customizing maintenance

Ending: *_CB (for Customizing buffer) Layer containing the read module for Customizing

Ending: *_FC (for Fieldcheck) Layer containing fieldcheck mehods for fieldselection

Ending: *_EC (for Event callback) Layer containing callback methods for event handler

Ending: *_AC (for Archiving) Layer containing methods archiving


Commonly Used Some BADIs

CRM_COPY_BADI Copy control for One Order documents

CRM_ORDER_INDEX_BADI Update of table CRMD_ORDER_INDEX

CRM_ORDER_FIELDCHECK Field check during transaction processing

CRM_CONFIRM_01 Update of field catalog to APO

CRM_UPLOAD_BEA_FILL Mapping of fields to Billing Engine

COM_PAYCARD_BADI Extend Structure for Communication with Clearing House

ORDER_SAVE Check and manipulate data before docs are savedCRM_DATAEXCHG_BADI Data Exchange with R/3

CRM_COND_COM_BADI Extension of communication structure for pricing

CRM_BWA_MFLOW BW Extraction

CRM_30A_USER_EXITS Data Exchange with Mobile Clients/Mobile Bridge

A variety of BADIs are available around One Order Business Transactions.Below are the collection of selected BAdIs:


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)

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).

Callback Configuration (contd.)


Event (EVENT)

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)

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.



• 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.



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.

How to check which callbacks are executed?


Features of ActionsTo 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 Contd…There are various processing types for actions:

Methods (Business Add-Ins)

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: Contd.. SAP Business Workflow

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 e-

mail)• 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.



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 and select the Processing.

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 Enter the BADI name that you want to assign with this Action.

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 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…

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

BADI Implementation


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.


Components of Date Management Contd..

Date

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

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

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 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 user’s 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 PrepareMe

2 TellMe

3 Show Me

4 LetMe

5 HelpMe



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…


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 Contd…


Processing Actions


Date Management In customizing, follow the path shown to reach date management.


Date Management Contd…Configuring duration and date type in customizing.


Date Management Contd… Configuring date rule in customizing.

When a new date rule is created the guid is automatically generated.


Date Management Contd… 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.


Date Management Contd… Structure of the XML code

• The first couple of lines are written as <?xml version="1.0"?> <SAPTimeRule>

• 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 Contd… Date rule where ABAP function module is called.


Date Management Contd… Structure of the ABAP function module.


1 PrepareMe

2 TellMe

3 ShowMe

4 LetMe

5 HelpMe



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 PrepareMe

2 TellMe

3 ShowMe

4 LetMe

5 HelpMe


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+Corner

• For basics of ABAP refer http://help.sap.com/saphelp_nw70/helpdata/en/43/41341147041806e10000000a1553f6/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/79f5397753057ee10000000a11402f/content.htm

• For Date Management refer http://help.sap.com/saphelp_sm40/helpdata/en/d4/fce93a29768802e10000000a11402f/content.htm

http://wiki.sdn.sap.com/wiki/display/CRM/CRM+Developer's+Knowledge+Corner

http://wiki.sdn.sap.com/wiki/display/CRM/CRM+Developer's+Knowledge+Corner

http://help.sap.com/saphelp_nw70/helpdata/en/43/41341147041806e10000000a1553f6/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/43/41341147041806e10000000a1553f6/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/de/a38338d22aa947e10000009b38f8cf/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/de/a38338d22aa947e10000009b38f8cf/frameset.htm

http://wiki.sdn.sap.com/wiki/display/CRM/Action+profiles+in+SAP-CRM

http://help.sap.com/saphelp_sm40/helpdata/en/53/79f5397753057ee10000000a11402f/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

Date post:	18-Apr-2015
Category:	Documents
Upload:	valentini400
View:	548 times
Download:	4 times