If you want to access data of the export controls checks for subsequent processes, you can use one of the following functions:
|Requirement||Function module / Class|
|Read the whole data of the export controls check, as shown in the Export Controls Cockpit.||/AEB/CL_CMP_PB_EC_DATA_READ_BC|
|Read the approval and clearing data for items. The parameter IM_ORG_UNIT and IM_ENGN_CALL_PARAMS are optional. Both parameters will be determined by the functions itself.||/AEB/CMP_PB_EC_GET_CLEA_FOR|
|Read the history from the export controls check.||/AEB/CMP_PB_EC_GET_HISTORY_FOR|
|Read the data for a questionnaire created by an export controls check||/AEB/CL_CMP_PB_QUEST_BC|
|Read further informations about the license. Hint: The function only has informations for licenses from license managment. Not for the general licenses from export controls. (= data service licenses)||/AEB/CL_CMP_PB_EC_LIC_INFO_BC|
Assuming you have released the order 5050 , item 10 and want to read the licence data from the assigned licence. In this example, the licence statement is retrieved this way:
DATA: lic_info_bc TYPE REF TO /aeb/cl_cmp_pb_ec_lic_info_bc, vbeln TYPE /aeb/cmp_pb_doc_no, lic_result TYPE REF TO /aeb/if_cmp_pb_ec_lici_res_do, lic_infos TYPE /aeb/cmp_if_cmp_pb_ec_li_i_dos, lic_info TYPE REF TO /aeb/if_cmp_pb_ec_lic_info_do, lic_statement TYPE string, jurisdiction TYPE REF TO /aeb/if_cmp_pb_juri_do. vbeln = '000005050'. lic_info_bc = /aeb/cl_cmp_pb_ec_lic_info_bc=>new_for( vbeln ). lic_result = lic_info_bc->get_license_info_for_item( '000010' ). lic_infos = lic_result->get_lic_info_dos( ). LOOP AT lic_infos INTO lic_info. jurisdiction = lic_info->get_jurisdiction( ). IF jurisdiction->get_ident_code( )->v = 'DE-EU-Plugin'. "or 'US-EAR-Plugin' lic_statement = lic_info->get_license_statement( ). EXIT. ENDIF. ENDLOOP.
To handle the update event of a questionnaire you can use the following BAdIs:
|Service transaction (S4)||/AE1/CMP_RA_ST_01|
Let's implement a simple scenario were we update a Z-field of VBAK with the status of the questionnaire which is linked to the sales order.
DATA: questionnaire TYPE REF TO /aeb/if_cmp_pb_quest_do, lcl_completed TYPE /aeb/01_boolean, total_result_type TYPE string. questionnaire = im_questionnaire_bc->get_questionnaire( ). IF questionnaire IS INITIAL. "Questionnaire was invalidated => no relevant results RETURN. "you might implement a reset here instead ENDIF. lcl_completed = questionnaire->get_is_completed( ). IF lcl_completed = 'X'. "if not completed: Old Questionnaire was invalidated but new incomplete version exists RETURN. "you might implement a reset here instead ENDIF. "getting the identcode for all critical results "DATA: " critical_results TYPE /aeb/if_cmp_pb_quest_critr_do=>tt_quest_critr_do, " critical_result TYPE zraqresults-z_raq_result. "critical_results = questionnaire->get_critical_results( ). "LOOP AT critical_results INTO critical_result. " critical_result = critical_result->get_identcode( ). " ... "ENDLOOP. total_result_type = questionnaire->get_total_result_type( ). UPDATE vbak SET zz_quest_res = total_result_type WHERE vbeln = im_vbeln.
Just use the passed parameter im_questionnaire_bc to get the questionnaire. Get the total result type and update the VBAK table. In this context the table is locked so no other process can change it.
If you don't want to use a direct SQL update Statement to update your SAP document, but an officially released Bapi from SAP like BAPI_SALESORDER_CHANGE there are a few things which you have to consider. Bapis like BAPI_SALESORDER_CHANGE call the user exits/BAdIs where the online check is typically implemented, which means an additional Compliance check is triggered when calling the SAP Bapi. In most cases, this check is not needed, as the AEB standard also does a recheck of the SAP document after the HDL_QUESTIONNAIRE_UPDATED BAdI is called.
To prevent that the Bapi BAPI_SALESORDER_CHANGE triggers an online check there is an public helper class (/AEB/CL_CMP_PB_CHK_HP) which is also an importing parameter of the BAdI method. This class has the method SUPPRESS_CHECK which has to be called before every Bapi call and the method RESET_SUPPRESS_CHECK which enables the check again for the next Bapi call. A recommended use of the Bapi in this BAdI implementation would therefore look like the following:
DATA: return TYPE TABLE OF bapiret2, order_header_in TYPE bapisdh1, order_header_inx TYPE bapisdh1x. im_public_check_helper->suppress_check( ). order_header_in-purch_no_c = '0815'. order_header_inx-purch_no_c = 'X'. order_header_inx-updateflag = 'U'. CALL FUNCTION 'BAPI_SALESORDER_CHANGE' EXPORTING salesdocument = im_vbeln order_header_in = order_header_in order_header_inx = order_header_inx TABLES return = return. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'. im_public_check_helper->reset_suppress_check( ).
Please note that you also need to call the BAPI_TRANSACTION_COMMIT so that the data you have changed can also be used by our following Compliance check, or else the check would still check the old data.
If you would like to implement some checks and would like to raise an error you can raise the exception like in the following code example.
raise EXCEPTION type /AEB/CX_cmp_pb_quest_sc EXPORTING _badi_name = 'ZCL_IM_AEB_RA_SDOC_01' _error_msg_string = 'Handle questionnaire not possible' textid = /aeb/cx_cmp_pb_quest_sc=>hdl_questionnaire_upd_failed.
Updated 2 months ago