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:
REPORT ZORDER_CREATE. DATA: lt_input_fields TYPE crmt_input_field_tab, ls_input_field LIKE LINE OF lt_input_fields, ls_field_name LIKE LINE OF ls_input_field-field_names, lv_guid TYPE guid_16, lt_orderadm_h_com TYPE crmt_orderadm_h_comt, ls_orderadm_h_com LIKE LINE OF lt_orderadm_h_com, ls_com_structure TYPE string, lv_selection_needed TYPE crmt_boolean, lt_save TYPE crmt_object_guid_tab, lt_saved TYPE crmt_return_objects, lt_opp_h TYPE CRMT_OPPORT_H_COMT, ls_opp_h LIKE LINE OF lt_opp_h, ls_saved LIKE LINE OF lt_saved. START-OF-SELECTION. CALL FUNCTION 'GUID_CREATE' IMPORTING ev_guid_16 = lv_guid. PERFORM call_order_maintain. PERFORM call_order_save. FORM call_order_maintain. CLEAR: ls_orderadm_h_com, ls_input_field, lt_input_fields. ls_orderadm_h_com-guid = lv_guid. ls_orderadm_h_com-description = 'created by code on:' && sy-timlo. ls_orderadm_h_com-process_type = 'OPPT'. ls_orderadm_h_com-mode = 'A'. APPEND ls_orderadm_h_com TO lt_orderadm_h_com. ls_input_field-ref_guid = lv_guid. ls_input_field-ref_kind = 'A'. ls_input_field-objectname = 'ORDERADM_H'. ls_field_name-fieldname = 'DESCRIPTION'. APPEND ls_field_name TO ls_input_field-field_names. ls_field_name-fieldname = 'MODE'. APPEND ls_field_name TO ls_input_field-field_names. ls_field_name-fieldname = 'PROCESS_TYPE'. APPEND ls_field_name TO ls_input_field-field_names. APPEND ls_input_field TO lt_input_fields. ls_opp_h-ref_guid = lv_guid. ls_opp_h-expect_end = '20170401'. APPEND ls_opp_h TO lt_opp_h. CLEAR: ls_input_field. ls_input_field-ref_guid = lv_guid. ls_input_field-ref_kind = 'A'. ls_input_field-objectname = 'OPPORT_H'. APPEND 'EXPECT_END' TO ls_input_field-field_names. APPEND 'STARTDATE' TO ls_input_field-field_names. INSERT ls_input_field INTO TABLE lt_input_fields. CALL FUNCTION 'CRM_ORDER_MAINTAIN' EXPORTING IT_OPPORT_H = lt_opp_h CHANGING ct_orderadm_h = lt_orderadm_h_com ct_input_fields = lt_input_fields EXCEPTIONS OTHERS = 99. IF sy-subrc = 0. WRITE:/ 'Order maintain function is done successfully.'. ENDIF. ENDFORM. FORM call_order_save. INSERT lv_guid INTO TABLE lt_save. CALL FUNCTION 'CRM_ORDER_SAVE' EXPORTING it_objects_to_save = lt_save iv_update_task_local = abap_true iv_no_bdoc_send = abap_true IMPORTING et_saved_objects = lt_saved EXCEPTIONS document_not_saved = 1. IF sy-subrc <> 0. WRITE: / 'Opportunity created failed'. ELSE. READ TABLE lt_saved INTO ls_saved INDEX 1. WRITE: / 'Opportunity created successfully, id: ' , ls_saved-object_id. ENDIF. COMMIT WORK AND WAIT. ENDFORM.
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) 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 subroutine STATUS_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.
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 in CRM_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.
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.