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. 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 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.
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 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.
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.
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_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_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_OPPORT_H_MAINTAIN_OW
- SAP Managed Tags:
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
