Vous êtes sur la page 1sur 2

Go to start of metadata

CRM Business Transactions

As a depature from regular ERP "fat table" design, CRM embraces a new data model concept for business transactions called the "oneorder" concept. The one order concept is relatively simple, yet very elegant. Each busines transaction type is store in common set of
tables which we will call segments, and then has segments specific to the business transaction type. This means a sales order, activity,
lead, opportunity, complaint, etc. all live in the same central tables. This allows for an easier technical copy control and search. The order
guid is used to handle this.
Basic Data Model
Let's a take a look at the structure of a business transaction
Primary Header Table: CRMD_ORDERADM_H which is also known as ORDERADM_H
Primary Item Table: CRMD_ORDERADM_I which is known as ORDERADM_I
These tables are then related to various segments through a linkage table known as CRMD_LINK. Examples of segments are
Extensions to Data Model
The header of a business transaction and items of a business transaction can be extended using the EEWB. By using this tool it is
recommend to extend the tables CRMD_CUSTOMER_H and CRMD_CUSTOMER_I. These segments are considered fully qualified
segments of the business transaction and have all the other features as a regular segment of the transaction. By using these segments via
the EEWB, we can re-use the fields throughout the whole CRM application without much extra effort.
The fields are added via the customing includes that are named in the fashion CI_EEW_CUSTOMER_H and CI_EEW_CUSTOMER_I.
BADI Framework for Business Transactions
Each segment offers a badi for validating the segment and adding additional fields of the segment. The badi's follow the convention
CRM_<segment>_BADI except for PARTNER and PAYPLAN segments which start with COM.
In addition the following BADI's are available:
CRM_COPY_BADI - Copy Control
ORDER_SAVE - manipulate data before save
Please keep in mind in all badi's should not call any SAVE related function modules. You should use the *_OB api function modules to
modify the data at this layer to avoid recursion errors. Also please keep in mind that badi for a segment is only triggered when the data in
that segment has been updated or "touched".
Event Framework
The event handler framework is used by the CRM business transaction framework to notify changes within the transaction to other
segments within. The event framework can be accessed through transaction CRMV_EVENT. You can determine what events are called
as a business transaction is edited by setting the user parameter CRM_EVENT_TRACE to 'X' on your userid. The report
CRMV_EVENT_TRACE will allow you to see the results. The event framework is quite useful when a badi will not meet your requirements.
API's & BAPI's for business transactions

PRODUCT MASTER DATA - Three important tables



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:
You must assign a product a valid category before you can assign it segment data!

In CRM all types of partners (sold-to, ship-to, prospect, vendor, etc) are considered business partners. This allows for us to use partners in
transactions based on roles they occupy.
Data Model

We call Business Partners: "BUPA's" per naming convention in CRM

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

Extensions are handled via the EEWB. Don't try to write these from scratch unless you know BDT and prefer doing things in
more painful fashion.
API's & BAPI's for the Business Partner
Common ones are: