Authors:

Architecture Team
S/4HANA Service Software Design Description
Management

SELECT Statements on
Business Transaction Tables
in Custom Code: Migration
from CRM 7.0 to S4CRM

Version Status Date Change

2.0 Released 03.05.2019

Migration of SELECT Statements on Business Transaction Tables in Custom Code

Contents
1 Introduction and General Remarks ________________________________________ 3
2 Accesses to Business Transaction Data ___________________________________ 3
2.1 General Remarks ___________________________________________________________ 3
2.2 Basic Principles of the Persistency Redesign ____________________________________ 3
2.3 Analysis of SELECT Statements _______________________________________________ 4
2.4 Determination of Header/Item Table ____________________________________________ 5
2.4.1 Unknown business object type _______________________________________________ 5
2.4.2 Known business object type _________________________________________________ 5
2.5 Renamed and Unsupported Fields _____________________________________________ 5
2.6 Special Cases ______________________________________________________________ 5
2.6.1 Shadow Tables ___________________________________________________________ 5
2.6.2 SELECT Statements Involving CRMD_ORDER_INDEX ___________________________ 6
2.6.3 Selection of Partners on Item Level ___________________________________________ 6
2.7 Examples _________________________________________________________________ 7
3 Technical Details ______________________________________________________ 9
3.1 Extensions and Sets ________________________________________________________ 9
3.2 List of New Complex Tables _________________________________________________ 11
3.3 List of Renamed Fields _____________________________________________________ 11
3.4 New Partner, Status and Appointment Fields ___________________________________ 12
3.4.1 Partner Fields ___________________________________________________________ 12
3.4.2 Status Fields ____________________________________________________________ 12
3.4.3 Appointment Fields _______________________________________________________ 13
3.5 List of Fields in CRMD_ORDER_INDEX ________________________________________ 14

© Copyright SAP SE 2019 Confidential Page 2 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

1 Introduction and General Remarks

With the delivery of “SAP S/4HANA for customer management 2.0” (henceforth referred to as S4CRM
2.0) as add-on to S/4HANA 1809, on-premise edition, basic customer management functionality is now
available in S/4HANA, with a strong focus on service management. Customers who are considering
performing a migration of their CRM 7.0 installation to S4CRM 2.0 require information which parts of
their custom code can be migrated, and which adaptations are necessary.

This document describes the required changes in custom code that accesses business transaction data
via direct SELECT statements on the underlying database tables. These adaptations are necessary
since the persistency of CRM business transactions has been redesigned, resulting in new database
tables.

Disclaimer: SAP does not guarantee that the information contained, especially the lists in section 3, is
complete and 100% error-free. Corrections and enhancements might be performed in future versions of
this document.

2 Accesses to Business Transaction Data

2.1 General Remarks
The primary persistence of CRM business transactions (sometimes also referred to as “One Order”
documents) has been redesigned to a substantial extent, in order to comply with HANA requirements to
the data model and offer transactional and analytical applications on the same persistency, avoiding
index tables. Basically, we distinguish two types of accesses to transactional data in custom code:
• You are using an API to fetch data. This could be one of the BAPIs which were released in CRM
7.0, for example BAPI_BUSPROCESSND_GETDETAILMUL, the internal API
CRM_ORDER_READ, or even lower level APIs like CRM_ORDERADM_H_READ_OB. In this
case, an adaptation is not required. These APIs function as they did before. Note, however, that
the release of all BAPIs was withdrawn in S4CRM, and that the internal APIs have never been
released anyway, so that the use of these APIs is at the customer’s own risk.
• You are executing a direct SELECT statement on the tables of the business transaction data
model. In this case, adaptations will be necessary. The most common and frequent cases are
discussed below, with a guidance on how to convert the statement in S4CRM.

2.2 Basic Principles of the Persistency Redesign

In order to convert custom code SELECT statements, some basic understanding of the persistency
redesign is necessary. The most important features are summarized below. We assume some familiarity
with the business transactions (“One Order”) framework, in particular, we frequently refer to the
“components” or “segments” of the transaction (entity table CRMC_OBJECTS) which can be either
extensions (1:1 or 1:n relationship to header or item) or sets (m:1 or m:n relationship). The components
which are relevant for S4CRM 2.0 are listed in section 3.1.

1. For each object type (aka business transaction category, entity table CRMC_SUBOB_CAT),
there is one database table for the header. Likewise, for each item object type (entity table
CRMC_SUBOB_CAT_I), there is one database table for the item. Some header or item object
types are combined in a common table. The assignment of the database table to a business
object is accomplished through the so-called acronym which is a four-character abbreviation of
the business object. This relation is stored in table CRMS4C_ACRONYM. The names of the
new database tables follow the naming convention CRMS4D_<acronym>_H for the header
tables and CRMS4D_<acronym>_I for the item tables. The key of the new tables consists of:

• header object type + header object ID for the header table, and

© Copyright SAP SE 2019 Confidential Page 3 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

• header object type + header object ID + item number for the item table.

The (header/item) GUID is still available in the data part of the table.

2. Simple header extensions (i.e., those with a 1:1 correspondence to the header, for example
SERVICE_H) are completely integrated into the header table, i.e., the fields are genuine part of
the new table. Similarly, simple item extensions (for example, PRODUCT_I) are integrated into
the item table. There is no separate database table any more for a simple extension.
3. For a simple set (for example, SHIPPING), the fields are appended both to the header and the
item table. This means that each item has its own set of, e.g., shipping attributes. There is no
link handler or set logic any longer for these sets.
4. A selected set of header attributes (those which are relevant in queries or analytical
applications) is redundantly included in the item table, in order to avoid an expensive JOIN
operation between header and item table.
5. Complex sets and extensions (i.e., those with a 1:n relationship to header or item) usually
remain in a separate table (one exception: CUMULATED_I). However, two simplifications are
performed:
• Selected records from certain complex components are extracted as individual fields to
the header and/or item table, because these are frequently used in queries or analytical
applications. This applies, in particular, to the sets PARTNER, STATUS and
APPOINTMENT. For example, there are individual fields for the sold-to and ship-to
party, the life cycle and the billing status, or the contract start and end date. These fields
are redundant, i.e., the complete set of partners, statuses, dates, etc. is still available in
an extra database table.
• The key structure of the separate tables for the complex components is
changed. Instead of a single record GUID, the key of a header or item extension now
consists of the key fields of the header or item table, plus additional key fields. Similarly,
the key of a new set table contains the key of the item table, plus additional key fields.
Records which belong to the header have an initial item number. The link handler (table
CRMD_LINK) is not used any longer.
Note: This does not apply to components which use a database table from a lower
software layer. In particular, the persistence of the segments APPOINTMENT,
STATUS, TEXT is unchanged.

An overview over the tables for the complex components in the new data model is given in
section 3.2.

2.3 Analysis of SELECT Statements

Following the basic principles of the redesign, a custom SELECT statement should be analyzed as
follows:
• If the involved tables are the root tables CRMD_ORDERADM_H, CRMD_ORDERADM_I, or a
flat extension or set, then the statement can directly be converted to the new header/item tables.
The only additional step is to determine the acronym of the table. This is discussed below.
• If the SELECT statement selects one particular record from the partner table
CRMD_PARTNER, check whether the requested partner function (category) is represented as
separate field in the header/item table. In such a case, the JOIN can be avoided, and the query
can be directed to the header/item table alone. Similar considerations apply to the selection of
statuses or appointments. Please refer to section 3.4 for a mapping of partner function
categories, system statuses and appointment types to fields in the new database tables.
• Statements which select several records from a complex component (for example, PARTNER
or SCHEDLIN) must be converted to the new database table of the complex component.

© Copyright SAP SE 2019 Confidential Page 4 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

2.4 Determination of Header/Item Table

We can distinguish two cases:
1. Only the GUID of the header/item is known, not the business object type.
2. The business object type is known (plus GUID or ID or other attributes).

2.4.1 Unknown business object type

In this case, the business object type can be retrieved by a SELECT statement on the so-called shadow
tables CRMS4D_BTX_H, CRMS4D_BTX_I. Example:

SELECT SINGLE objtype_h

FROM crms4d_btx_h
INTO lv_bus_object
WHERE guid = lv_header.

The shadow tables can be viewed as reduced versions of the original root tables
CRMD_ORDERADM_H and CRMD_ORDERADM_I. They contain only the very basic attributes and
mainly serve to determine the business object type from the GUID.

2.4.2 Known business object type

In general, we can distinguish the following cases:
• The program containing the SELECT statement is dealing with only one business object, for
example activities. In this case you can directly use the new header table for that business
object; for activities this would be CRMS4D_ACTV_H.
• Similarly, if you are dealing with a limited number of business objects, you can use a CASE
statement with the corresponding table name.
• If you cannot restrict the type of the business objects, and the code should be future proof if
more business objects are to be included at a later stage, then you can use a dynamic code
as follows:

lv_table_name =
cl_crms4_acronym_cb=>get_table_name( lv_object_type ).
SELECT … FROM (lv_table_name) WHERE …

2.5 Renamed and Unsupported Fields

A couple of database fields had to be renamed, for technical or semantical reasons. Please check in the
list given in section 3.3 whether the fields involved in the custom code SELECT statement are affected.
This refers, of course, to the field list as well as to the WHERE condition.

Fields which are neither contained in the new database tables, nor in the list of renamed fields, are not
supported in S4CRM 2.0. This applies, for example, to the database field CRMD_ORDERADM_H-
SCENARIO.

2.6 Special Cases

2.6.1 Shadow Tables
A frequent case is that a SELECT statement on table CRMD_ORDERADM_H is executed to convert
between the GUID and the transaction ID. Also, object type and transaction type are frequently selected
from this table. In these cases, the shadow table CRMS4D_BTX_H can be used. A similar statement
applies to items.

© Copyright SAP SE 2019 Confidential Page 5 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

2.6.2 SELECT Statements Involving CRMD_ORDER_INDEX

The index table CRMD_ORDER_INDEX has frequently been used for SELECT statements in order to
save JOIN operations with the partner, status or appointment tables. The principle that selected records
from these complex components were part of a flat table has already been applied here. If this feature
is used, the SELECT statement can be carried over to the new database tables with only minor
adjustments.

Regarding the partner fields, the logic of CRMD_ORDER_INDEX was that the partner function category
is indicated by the field PFT_nn, where nn is the number of the partner function category (according to
table CRMC_PARTNER_PFT), and the partner number is contained in field PARTNER_NO. In the new
design, dedicated fields are available for the individual partner function categories. The correspondence
is given in the list in section 3.5. Those fields PFT_nn which are not listed in the table have no
counterpart in one of the flat tables. In this case, a JOIN with CRMS4D_PARTNER is required. Example
3 in section 2.7 illustrates the new logic.

Finally, another two frequently used fields from CRMD_ORDER_INDEX are the two date fields DATE_1
and DATE_2. These two fields capture the most important business object specific dates. The
calculation differs from object type to object type. Section 3.5 contains a table with the detailed logic and
the correspondence to the new database tables.

2.6.3 Selection of Partners on Item Level

When partners on item level are selected via a JOIN operation with CRMS4D_PARTNER, a special
feature of the PARTNER set must be taken into account. Although the link handler is not used in S4CRM,
the set logic (items sharing the set with the header) was reintroduced for the PARTNER set in order to
save database space. An additional item number field ITEM_NO_PARTNER was introduced in the item
tables. If this item number is initial (value 000000), the item shares the partners with the header. If it is
equal to the number of the item itself, the item has its own partner set. The effect on a sample SELECT
statement is illustrated below:

Code without set logic (wrong, will not work!):

SELECT DISTINCT i~object_id FROM crms4d_serv_i AS i

JOIN crms4d_partner AS p
ON i~objtype_h = p~objtype_h
AND i~object_id = p~object_id
AND i~number_int = p~number_int
WHERE i~posting_date = '20170601'
AND p~partner_fct = 'Z0000018'
AND p~partner_no = '0000006708'

Code with set logic (correct):

SELECT DISTINCT i~object_id FROM crms4d_serv_i AS i

JOIN crms4d_partner AS p
ON i~objtype_h = p~objtype_h
AND i~object_id = p~object_id
AND i~item_no_partner = p~number_int
WHERE i~posting_date = '20170601'
AND p~partner_fct = 'Z0000018'
AND p~partner_no = '0000006708'

© Copyright SAP SE 2019 Confidential Page 6 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

2.7 Examples
Example 1: This example shows how a SELECT statement involving three different tables can be
simplified in S4CRM. At the same time, it demonstrates how the keyword AS can be utilized for renamed
fields in order to keep the internal table definitions stable.

Code in CRM 7.0:

SELECT a~guid
a~header
a~product
a~ordered_prod
a~description
b~process_qty_unit
c~net_value
c~net_value_man
FROM crmd_orderadm_i AS a
LEFT JOIN crmd_product_i AS b ON a~guid = b~guid
LEFT JOIN crmd_pricing_i AS c ON a~guid = c~guid
INTO CORRESPONDING FIELDS OF TABLE lt_item
FOR ALL ENTRIES IN lt_header WHERE header = lt_header-guid.

Code in S4CRM 2.0:

SELECT item_guid AS guid

header_guid AS header
product
ordered_prod
description_i AS description
process_qty_unit
net_value_i AS net_value
net_value_man_i AS net_value_man
FROM crms4d_serv_i
INTO CORRESPONDING FIELDS OF TABLE lt_item
FOR ALL ENTRIES IN lt_header WHERE header_guid = lt_header-guid.

Example 2: If a JOIN operation with a complex component is required, it is no longer necessary to use
the link handler as intermediate table. The following code is taken from the “end of purpose” check for
business partners:

Code in CRM 7.0:

SELECT
p~partner_no AS partner_no
h~guid AS object_guid
FROM crmd_orderadm_h AS h
INNER JOIN crmd_link AS l ON l~guid_hi = h~guid
INNER JOIN crmd_partner AS p ON p~guid = l~guid_set
INTO CORRESPONDING FIELDS OF TABLE lt_pguid_oguid
WHERE p~partner_no IN it_partner_range.

Code in S4CRM 2.0:

SELECT
p~partner_no AS partner_no

© Copyright SAP SE 2019 Confidential Page 7 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

h~guid AS object_guid
FROM crms4d_btx_h AS h
INNER JOIN crms4d_partner AS p
ON h~objtype_h = p~objtype_h AND
h~object_id = p~object_id
INTO CORRESPONDING FIELDS OF TABLE lt_pguid_oguid
WHERE p~partner_no IN it_partner_range
AND p~number_int = '000000'.

Example 3: It is shown how the logic of the PFT_nn fields from CRMD_ORDER_INDEX can be carried
over to the new database tables. The code is taken from the selection of service order or confirmation
items which need to be released for billing. Note that the semantics of the billing status has changed in
S4CRM:

Code in CRM 7.0:

SELECT item
INTO CORRESPONDING FIELDS OF TABLE lt_guid_idx_i
FROM crmd_order_index
FOR ALL ENTRIES IN lt_guid_adm_h
WHERE header = lt_guid_adm_h-guid
AND object_type IN lr_obj_type
AND partner_no IN impt_partno
AND service_org IN impt_srv_oe
AND stat_bill = 'X'
AND pft_1 = 'X'.

Code in S4CRM 2.0:

SELECT item_guid AS item

INTO CORRESPONDING FIELDS OF TABLE lt_guid_idx_i
FROM crms4d_serv_i
FOR ALL ENTRIES IN lt_guid_adm_h
WHERE header_guid = lt_guid_adm_h-guid
AND objtype_i IN lr_obj_type
AND sold_to_party IN impt_partno
AND service_org IN impt_srv_oe
AND stat_billing = 'A'
AND stat_for_billing = ' '.

Example 4: This code is take from the archiving preprocessing program. Here, a dynamic SELECT
statement must be used since the code covers all possible business object type. At the same time, JOIN
operations with the status table CRM_JEST can be avoided thanks to the incorporation of statuses in
the header tables.

Code in CRM 7.0:

SELECT guid object_type

INTO (l_objects-obj_guid, l_objects-objtype)
FROM crmd_orderadm_h
UP TO l_maxobjects ROWS
WHERE object_id IN so_xobjid
AND process_type = <fs_sel>-process_type
AND changed_at < <fs_sel>-utcdate

© Copyright SAP SE 2019 Confidential Page 8 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

AND verify_date LT v_utcdate

AND exists
( SELECT objnr FROM crm_jest
WHERE stat = 'I1005'
AND inact = ' '
AND objnr = crmd_orderadm_h~guid )
AND NOT EXISTS
( SELECT objnr FROM crm_jest
WHERE stat = 'I1102'
AND inact = ' '
AND objnr = crmd_orderadm_h~guid ) .

Code in S4CRM 2.0:

CALL METHOD cl_crms4_acronym_cb=>get_table_name

EXPORTING
iv_object_type = ls_proc_type-object_type
RECEIVING
rv_table_name = lv_dbtab
EXCEPTIONS
table_not_found = 1
OTHERS = 2.
IF sy-subrc <> 0.
CONTINUE.
ENDIF.

SELECT header_guid objtype_h

INTO (l_objects-obj_guid, l_objects-objtype)
FROM (lv_dbtab)
UP TO l_maxobjects ROWS
WHERE object_id IN so_xobjid
AND process_type = <fs_sel>-process_type
AND changed_at_h < <fs_sel>-utcdate
AND verify_date < v_utcdate
AND stat_open = ' '
AND stat_archivable = ' '.

3 Technical Details
3.1 Extensions and Sets
For convenience, we are providing the list of sets and extensions within the One Order model which
are relevant in S4CRM 2.0. The brief explanation in column “Role in S4CRM” means:

• “Absorbed”: The component has been integrated into the new header/item table(s). There is
no separate database table any more for this component.
• “Unchanged”: The persistence of these components is unchanged with respect to CRM 7.0.

In case there is a new database table for the component, the name of the database table is given.
Some components require special explanations:

© Copyright SAP SE 2019 Confidential Page 9 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

• BILLPLAN: This set consists of four tables in CRM 7.0 (CRMD_BILLPLAN,

CRMD_BILLPLAN_D, CRMD_BILLPLAN_DA, CRMD_BILLPLAN_DF). CRMD_BILLPLAN is
a flat subset and has therefore been integrated into header and item tables.
CRMD_BILLPLAN_D contains the billing plan dates. Since only periodic billing plans are
supported, this table contains only one line and has therefore also been integrated into header
and item table. The remaining two tables are not required in S4CRM 2.0.
• DOC_FLOW: Relationships of type VONA used to be stored in table CRMD_BINREL. This
has to be changed to SMZB_BINREL (which has an identical structure). All other involved
tables (for example, CRMD_BRELVONAE) remain unchanged.
• ORDPRP_I: This is a flat item extension, holding references to two master PPRs (partner
product ranges) which contain the object and the product list assigned to a service contract
item. Partner product ranges are not supported any longer. The object list is now stored in
table CRMS4D_REFOBJ which also contains the reference objects for a service order. For
the product list, the new database table CRMS4D_ORDPRP_I has been created.
• PAYPLAN: This set consists of four tables in CRM 7.0 (COMD_PAYPLAN,
COMD_PAYPLAN_D, COMD_PAYPLAN_DC, COMD_PAYPLAN_DP). COMD_PAYPLAN is
a flat subset and has therefore been integrated into header and item tables. Relevant fields
from COMD_PAYPLAN_D and COMD_PAYPLAN_DC have been moved to the new database
table CRMS4D_PAYPLAN_D. The COMD_PAYPLAN_DP fields are not supported.
• SERVICE_OS: This set used to be the bracket around SUBJECT and REFOBJ in CRM 7.0.
The separate database table CRMD_SRV_OSSET has become obsolete by integrating the
subject profile and the profile type into table CRMS4D_SRV_SUBJ.

Component Type Cardinality Role in S4CRM

ACTIVITY_H Header extension 1:1 Absorbed
APPOINTMENT Set 1:n Unchanged
BILLING Set 1:1 Absorbed
BILLPLAN Set 1:n Absorbed, see text
BILLREQ_I Item extension 1:n CRMS4D_BILLREQ_I
CANCEL Set 1:1 Absorbed
CANCEL_IR Set 1:n CRMS4D_CANCEL_IR
CHKLST Item extension 1:1 Absorbed
CUMULATED_I Item extension 1:n Absorbed
DOC_FLOW Set 1:n Partially changed, see text
LEAD_H Header extension 1:1 Absorbed
OPPORT_H Header extension 1:1 Absorbed
OPPORT_I Item extension 1:1 Absorbed
ORDPRP_I Item extension 1:1 Special case, see text
ORDERADM_H Header root Absorbed
ORDERADM_I Item root Absorbed
ORGMAN Set 1:1 Absorbed
PARTNER Set 1:n CRMS4D_PARTNER
PAYPLAN Set 1:n CRMS4D_PAYPLAN_D
PRICING Set 1:1 Absorbed
PRICING_I Item extension 1:1 Absorbed
PRODUCT_I Item extension 1:1 Absorbed
REFOBJ Set 1:n CRMS4D_REFOBJ
SALES Set 1:1 Absorbed
SCHEDLIN Item extension 1:n CRMS4D_SCHEDLIN
SERVICE_H Header extension 1:1 Absorbed
SERVICE_I Item extension 1:1 Absorbed
SERVICE_OS Set 1:n Obsolete (see text)
SHIPPING Set 1:1 Absorbed
SRV_REQ_H Header extension 1:1 Absorbed
STATUS Header and item extension 1:n Unchanged
SUBJECT Set 1:n CRMS4D_SRV_SUBJ

© Copyright SAP SE 2019 Confidential Page 10 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

SURVEY Set 1:n CRMS4D_SURVEY

TEXTS Set 1:n Unchanged
TEXT_GEN Set 1:n Unchanged

3.2 List of New Complex Tables

Component Table CRM 7.0 Table S4CRM 2.0
BILLREQ_I CRMD_BILLREQ_I CRMS4D_BILLREQ_I
CANCEL_IR CRMD_CANCEL_IR CRMS4D_CANCEL_IR
ORDPRP_I CRMD_ORDPRP_I CRMS4D_ORDPRP_I
PARTNER CRMD_PARTNER CRMS4D_PARTNER
PAYPLAN_D COMD_PAYPLAN_D CRMS4D_PAYPLAN_D
COMD_PAYPLAN_DC
REFOBJ CRMD_SRV_REFOBJ CRMS4D_REFOBJ
SCHEDLIN CRMD_SCHEDLIN CRMS4D_SCHEDLIN
SUBJECT CRMD_SRV_SUBJECT CRMS4D_SRV_SUBJ
SURVEY CRMD_SURVEY CRMS4D_SURVEY

3.3 List of Renamed Fields

Component Field name (CRM 7.0) Field name (S4CRM)
CHKLST AZCSTEP_GRP CHKL_STEP_GROUP
CHKLST AZCSTEP_ID CHKL_STEP_ID
CHKLST AZCSTEP_NO CHKL_STEP_NO
CHKLST AZOPTION_ID CHKL_OPTION_ID
CHKLST AZPSTEP_GRP CHKL_PREV_GROUP
CHKLST AZPSTEP_NO CHKL_PREV_NO
CHKLST TRIGGER_ID CHKL_TRIGGER_ID
CUMULAT_H GROSS_WEIGHT GROSS_WEIGHT_H
CUMULAT_H NET_WEIGHT NET_WEIGHT_H
CUMULAT_H WEIGHT_UNIT WEIGHT_UNIT_H
CUMULAT_H VOLUME VOLUME_H
CUMULAT_H VOLUME_UNIT VOLUME_UNIT_H
CUMULAT_H GROSS_VALUE GROSS_VALUE_H
CUMULAT_H NET_VALUE NET_VALUE_H
CUMULAT_H NET_VALUE_MAN NET_VALUE_MAN_H
CUMULAT_H TAX_AMOUNT TAX_AMOUNT_H
CUMULAT_H FREIGHT FREIGHT_H
CUMULAT_H NET_WO_FREIGHT NET_WO_FREIGHT_H
ORDERADM_H GUID HEADER_GUID
ORDERADM_H DESCRIPTION DESCRIPTION_H
ORDERADM_H CREATED_AT CREATED_AT_H
ORDERADM_H CREATED_BY CREATED_BY_H
ORDERADM_H CHANGED_AT CHANGED_AT_H
ORDERADM_H CHANGED_BY CHANGED_BY_H
ORDERADM_H OBJECT_TYPE OBJTYPE_H
ORDERADM_I GUID ITEM_GUID
ORDERADM_I CREATED_AT CREATED_AT_I
ORDERADM_I CREATED_BY CREATED_BY_I
ORDERADM_I CHANGED_AT CHANGED_AT_I
ORDERADM_I CHANGED_BY CHANGED_BY_I
ORDERADM_I OBJECT_TYPE OBJTYPE_I
ORDERADM_I HEADER HEADER_GUID
ORDERADM_I DESCRIPTION DESCRIPTION_I
PRICING_I NET_VALUE_MAN NET_VALUE_MAN_I
PRICING_I NET_VALUE NET_VALUE_I
PRICING_I NET_PRICE NET_PRICE_I

© Copyright SAP SE 2019 Confidential Page 11 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

PRICING_I TAX_AMOUNT TAX_AMOUNT_I

PRICING_I FREIGHT FREIGHT_I
PRICING_I GROSS_VALUE GROSS_VALUE_I
PRICING_I NET_WO_FREIGHT NET_WO_FREIGHT_I
PRICING_I TOTAL_DISCOUNT TOTAL_DISCOUNT_I
PRODUCT_I GROSS_WEIGHT GROSS_WEIGHT_I
PRODUCT_I NET_WEIGHT NET_WEIGHT_I
PRODUCT_I WEIGHT_UNIT WEIGHT_UNIT_I
PRODUCT_I VOLUME VOLUME_I
PRODUCT_I VOLUME_UNIT VOLUME_UNIT_I
SALES REQ_DLV_DATE REQ_DLV_DATE_H
SALES REQ_TIMEZONE REQ_TIMEZONE_H
SALES RULE_REQ_DATE RULE_REQ_DATE_H
SERVICE_H SERVICE_ID TEMPL_SEARCHTERM
SCHEDLIN_I LATEST_TIME_CONFIRMED LATEST_CONF_DATE
SCHEDLIN_I LATEST_TIME_ORDER LATEST_REQ_DATE

3.4 New Partner, Status and Appointment Fields

As already indicated in section 2.2, dedicated records of the complex sets PARTNER, STATUS and
appointment have been added redundantly to the header and item tables. The tables in this section
contain the corresponding mappings. The partner fields are defined through the mapping to the partner
function category, the status fields are mapped from system statuses, and the appointment fields from
appointment or duration types. Not all fields are available in all header/item tables; only fields which are
relevant for the business logic are appended to the flat tables.

3.4.1 Partner Fields

Field Description Mapped from partner function

category
SOLD_TO_PARTY Sold-to Party 0001 (Sold-To Party)
SHIP_TO_PARTY Ship-to Party 0002 (Ship-To Party)
BILL_TO_PARTY Bill-to Party 0003 (Bill-To Party)
PAYER Payer 0004 (Payer)
SALES_REP Sales Representative 0005 (Employee)
ACTIVITY_PARTNER Activity Partner 0006 (Activity Partner)
SALES_PROSPECT Sales Prospect 0006 (Activity Partner)
CONTACT_PERSON Customer Contact Person 0007 (Contact Person)
PERSON_RESP Employee Responsible 0008 (Person Responsible)
COMPETITOR Competitor 0009 (Competitor)
SERVICE_TEAM Service Team 0016 (Service Team)
SERVICE_EMPLOYEE Executing Service Employee 0025 (Service Employee)
RESP_GROUP Responsible Group 0034 (Organization Responsible)

3.4.2 Status Fields

Field Description Field Value Description Mapped

Value from
system
status
STAT_LIFECYCLE Lifecycle status A Open I1002
B In process I1003
C Completed I1005
D Released I1004
STAT_LIFECYCLE_OPPT Lifecycle status of A Open I1002
opportunity B In process I1003
C Won I1027

© Copyright SAP SE 2019 Confidential Page 12 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

D Lost I1028
E Completed I1005
STAT_RELEASED Release status <space> Not released I1004
X Released
STAT_QUOTATION Quotation status <space> Order I1055
X Quotation
STAT_ERROR Error status <space> No errors I1030
X Contains errors
STAT_DELIVERY Delivery status <space> Not relevant
A Not delivered
B Partially delivered I1421
C Completely delivered I1137
STAT_GOODS_ISSUE Goods issue status <space> Not relevant
A Not goods issued
B Partially goods issued I1422
C Completely goods I1423
issued
STAT_BILLING Billing status <space> Not relevant
A Not billed
B Partially billed I1431
C Completely billed I1073
STAT_FOR_BILLING Billing release <space> Not released for billing I1094
status X Released for billing
STAT_ARCHIVABLE Archivable <space> Not archivable I1100
X Archivable
STAT_ARCHIVED Archived <space> Not archived I1101
X Archived
STAT_CANCELLED Cancellation status <space> Not cancelled I1032
X Cancelled
STAT_CHKLST_EXEC Execution Status of A Not to be executed I1391
Checklist Item B Execution in progress I1393
C Executed I1394
STAT_DUPLICATE Duplicate Status Y Duplicate I1098
N No Duplicate
STAT_ACCEPTED Acceptance Status Y Accepted I1079
N Not accepted
STAT_NOTIF_REQUIRED Lead Deduplication Y Notification required I1930
Notification N Notification not required
Required
STAT_OPEN Not completed <space> Completed I1005
X Open (reverse)

3.4.3 Appointment Fields

Field Description Mapped from

VALID_FROM Valid from date VALIDFROM (date type)
VALID_TO Valid to date VALIDTO (date type)
QUOT_START Quotation: Valid from date QUOTSTART (date type)
QUOT_END Quotation: Valid to date QUOTEND (date type)
SRV_CUST_BEG Requested start date SRV_CUST_BEG (date type)
SRV_CUST_END Requested end date SRV_CUST_END (date type)
SRQ_WORK_DURA Work duration of service SRQ_WORK_DUR (duration)
transaction
SRQ_WORK_UNIT Work duration unit of service (corresponding time unit)
transaction
SRQ_TOT_DURA Total duration of service SRQ_TOT_DUR (duration)
transaction

© Copyright SAP SE 2019 Confidential Page 13 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

SRQ_TOT_UNIT Total duration unit of service (corresponding time unit)

transaction
DATE_FROM Start date of an activity Function module
DATE_TO End date of an activity CRM_APPT_GET_ACTIVITY_DATE_OW
LEAD_START Lead start date LEAD_START (date type)
LEAD_END Lead end date LEAD_END (date type)
CONTSTART Contract start date CONTSTART (date type)
CONTEND Contract end date CONTEND (date type)
SRV_RFIRST First response by SRV_RFIRST (date type)
SRV_RREADY Due by SRV_RREADY (date type)

3.5 List of Fields in CRMD_ORDER_INDEX

CRMD_ORDER_INDEX Available in header Available Field name Comment
field table in item
table
GUID No counterpart in
S4CRM
HEADER X X HEADER_GUID
ITEM X ITEM_GUID
OBJECT_TYPE X X OBJTYPE_H OBJTYPE_H contains
OBJTYPE_I the header object type
(available in both
header and item
tables), OBJTYPE_I
contains the item
object type (only
available in item
tables)
PROCESS_TYPE_IX X X PROCESS_TYPE
CURR_PHASE X (only in CURR_PHASE
CRMS4D_OPPT_H)
IMPORTANCE X (only in PRIORITY
CRMS4D_OPPT_H)
PARTNER_NO deviating logic, see
text
SALES_ORG X X SALES_ORG
DIS_CHANNEL X X DIS_CHANNEL
DIVISION X X DIVISION
SERVICE_ORG X X SERVICE_ORG
SALES_OFFICE X X SALES_OFFICE
SALES_GROUP X X SALES_GROUP
PURCH_ORG Not supported
PO_NUMBER_UC Not supported
STAT_OPEN X X STAT_OPEN
STAT_PROCESS Not supported
STAT_RELEASED X X STAT_RELEASE
STAT_BILL X X STAT_BILLING, Logic changed
STAT_FOR_BILLING
STAT_SERVICE_DWP Not supported
STAT_PLANNED Not available as extra
field
STAT_QUOT X X STAT_QUOTATION
PRIVATE_FLAG_IX X (only in PRIVATE_FLAG
CRMS4D_ACTV_H)
STAT_INQ Not available as extra
field

© Copyright SAP SE 2019 Confidential Page 14 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

STAT_CREDIT Not available as extra

field
INVCR_DATE X X INVCR_DATE
DATE_1 See table below
DATE_2 See table below
DATE_3 Not relevant
DATE_4 Not relevant
NO_APPT No counterpart
PRODUCT_ID X PRODUCT_ID
CATEGORY_ID X PROD_HIERARCHY
CATALOG_ID Not supported
CATALOG_ITEM Not supported
DESCRIPT_PARTNER Not available as extra
field
NET_VALUE X NET_VALUE_H
CURRENCY X X CURRENCY
POSTING_DATE_HD X X POSTING_DATE
PATH_ID Not supported
IR_EXISTS Not supported
TEMPLATE_TYPE_IX X X TEMPLATE_TYPE
OBJECT_TYPE_HDIX X X OBJTYPE_H
HEAD No counterpart
PFT_1 X X SOLD_TO_PARTY
PFT_2 X X SHIP_TO_PARTY
PFT_3 X X BILL_TO_PARTY
PFT_4 X X PAYER
PFT_5 X X SALES_REP
PFT_6 X X ACTIVITY_PARTNER, ACTIVITY_PARTNER:
SALES_PROSPECT CRMS4D_ACTV_H
SALES_PROSPECT:
CRMS4D_OPPT_H/I
PFT_7 X X CONTACT_PERSON
PFT_8 X X PERSON_RESP
PFT_9 X X COMPETITOR
PFT_16 X X SERVICE_TEAM
PFT_25 X X SERVICE_EMPLOYEE
PFT_34 X X RESP_GROUP

For convenience, the table below explains the logic how the two date fields DATE_1 and DATE_2 are
filled. Typically, they are populated from a dedicated appointment type, sometimes from a special
database field or through some piece of extra logic. In the first case, the appointment type is given in
the second column.

Business Object DATE_1/2 logic Counterpart S4CRM

Type
Activity Determined via function module CRMS4D_ACTV_H-DATE_FROM
CRM_APPT_GET_ACTIVITY_DATE_OW CRMS4D_ACTV_H-DATE_TO
Lead DATE_1: LEAD_START CRMS4D_OPPT_H-LEAD_START
DATE_2: LEAD_END CRMS4D_OPPT_H-LEAD_END
Opportunity DATE_1: CRMD_OPPORT_H-STARTDATE CRMS4D_OPPT_H-STARTDATE
DATE_2: CRMD_OPPORT_H-EXPECT_END CRMS4D_OPPT_H-EXPECT_END
Service Confirmation DATE_1: SRVC_ACTUAL (from timestamp) (no counterpart)
DATE_2: SRVC_ACTUAL (to timestamp) CRMS4D_SERV_H-DUE_ON
Service Contract DATE_1: CONTSTART CRMS4D_SERV_H-CONTSTART
DATE_2: CONTEND CRMS4D_SERV_H-CONTEND
Service Contract DATE_1: QUOTSTART CRMS4D_SERV_H-QUOT_START
Quotation DATE_2: QUOTEND CRMS4D_SERV_H-QUOT_END

© Copyright SAP SE 2019 Confidential Page 15 of 16

Migration of SELECT Statements on Business Transaction Tables in Custom Code

Service Contract DATE_1: VALIDFROM CRMS4D_SERV_H-VALID_FROM

Template DATE_2: VALIDTO CRMS4D_SERV_H-VALID_TO
Service Order DATE_1: SRV_CUST_BEG CRMS4D_SERV_H-SRV_CUST_BEG
DATE_2: SRV_CUST_END CRMS4D_SERV_H-SRV_CUST_END
Service Order DATE_1: QUOTSTART CRMS4D_SERV_H-QUOT_START
Quotation DATE_2: QUOTEND CRMS4D_SERV_H-QUOT_END
Service Order DATE_1: VALIDFROM CRMS4D_SERV_H-VALID_FROM
Template DATE_2: VALIDTO CRMS4D_SERV_H-VALID_TO
Service Request DATE_1: SRV_CUST_BEG of the only non- CRMS4D_SERV_I-SRV_CUST_BEG
checklist item
DATE_2: SRV_RREADY of the only non- CRMS4D_SERV_I-SRV_RREADY
checklist item
Service Request DATE_1: VALIDFROM CRMS4D_SERV_H-VALID_FROM
Template DATE_2: VALIDTO CRMS4D_SERV_H-VALID_TO
Task Determined via function module CRMS4D_ACTV_H-DATE_FROM
CRM_APPT_GET_ACTIVITY_DATE_OW CRMS4D_ACTV_H-DATE_TO

© Copyright SAP SE 2019 Confidential Page 16 of 16