In the previous series of blogs the read and update on Opportunity header fields are discussed. In this blog another scenario will be explained: create scenario on Opportunity header fields. I will again use Closing Date ( and description field ) for example.

Execute the following report:

Once executed, a new Opportunity will be created.

Just like FILL_OW, CHANGE_OW, MERGE_OW, SAVE_EC and READ_OB which are already discussed below, there are another kinds of function module responsible for creation in One Order, whose naming convention is CRM*CREATE_OW.

Execute the report in this blog via SAT to study how CREATE_OW works.

Two CREATE_OW are involved in the create scenario:

(1) CRM_ORDERADM_H_CREATE_OW

(1) The main logic within this header administrative information creation function module is to create status object.

in CRM_STATUS_OBJECT_CREATE, lots of status related internal table are populated as buffer, and they will be persisted to database table by subroutineSTATUS_UPDATE once commit work is called.

Take internal table jest_buf for example, we will check whether we could find the corresponding entry for below record later in table CRM_JEST with objnr = 6C0B84B759DF1EE7848DA711530A4C22.

(2) CRM_ORDERADM_H_PUT_OB is called to put the header administrative data into corresponding object buffer:

This header administrative data does not contain any transaction specific field like Closing Date in Opportunity header, which will be handled by CRM_OPPORT_H_*_OW function module instead.

(2) CRM_OPPORT_H_CREATE_OW

From the gross execution time of this function module ( only 10 microseconds ) we can assume that no heavy logic is written within it.

In fact it only inserts the following three fields to OPPORT_H object buffer and that’s all.

The left logic are done in CRM_OPPORT_H_CHANGE_OW which has already been discussed in this blog: Logic of CHANGE_OW function module in One Order.

After report is executed successfully, go to table CRM_JEST and query objnr with guid 6C0B84B759DF1EE7848DA711530A4C22, and there is indeed one entry which are created by CRM_STATUS_OBJECT_CREATE inCRM_ORDERADM_H_CREATE_OW.

You may have doubt that in this test report, Opportunity start date is not specified explicitly, why finally it has value 2017-03-24?

It is hard code in CRM_OPPORT_H_MERGE_OW, if no value specified by consumer.

Further reading

I have written a series of blogs to explain how One Order API works. The blogs are written based on a simple scenario: read, change and save field “Closing Date” in Opportunity header level.

Buffer logic in One Order header extension Read

Change Scenario

CRM_ORDER_MAINTAIN

|- CRM_ORDER_MAINTAIN_MULTI_OW

|- CRM_ORDER_MAINTAIN_SINGLE_OW

|- CRM_ORDER_H_MAINTAIN_OW

|- CRM_OPPORT_H_MAINTAIN_OW

|- CRM_OPPORT_H_CHANGE_OW

|- CRM_OPPORT_H_READ_OB

|- CRM_OPPORT_H_FILL_OW

|- CRM_OPPORT_H_CHECK_OW

|- CRM_OPPORT_H_PUT_OB

|- CRM_OPPORT_H_PUBLISH_OW

Save Scenario

CRM_ORDER_SAVE

|- CRM_ORDER_SAVE_OW

|- CRM_EVENT_SET_EXETIME_MULTI_OW

|- CRM_OPPORT_H_SAVE_EC

|- CRM_ORDER_TABLE_SAVE

|- CRM_OBJECT_NAMES_DETERMINE

|- CRM_ORDER_UPDATE_TABLES_DETERM

|- CRM_ORDER_SET_OBJECTS_TO_SAVE

CRM_OPPORT_H_UPDATE_DU

Create Scenario

CRM_ORDER_MAINTAIN

|- CRM_ORDER_MAINTAIN_MULTI_OW

|- CRM_ORDER_MAINTAIN_SINGLE_OW

|- CRM_ORDER_H_MAINTAIN_OW

|- CRM_ORDERADM_H_MAINTAIN_OW

|- CRM_ORDERADM_H_CREATE_OW

|- CRM_OPPORT_H_MAINTAIN_OW

|- CRM_OPPORT_H_READ_OB

|- CRM_OPPORT_H_CREATE_OW

|- CRM_OPPORT_H_CHANGE_OW