This blog describes the logic how those status entries in the drop down list are populated.
And it will only focus on the scenario where no status profile maintained for transaction type.
The three entries you see in drop down list are retrieved from this method: CL_CRM_UIU_STATUS_INFO=>GET_STATUS_INFO
These three entries are generated via the following steps.
Step1. fetch all entries from table which is marked as active and is lifecycle status ( lifecycle flag <> space ), there are totally 47 records in my system.
Step2. Loop these 47 records to filter out those which do not fulfill some requirement.
For example, system I1003 ( in process ) combined with business process LCAC will be filtered out, because business process LCAC is not configured as permitted process for COH in table TJ05.
I1003 with LIPR is also filtered out but due to another reason that the customizing says only the following 13 object types are allowed,
and current service order has object type BUS2000116 which is not included, as a result I1003 with process LIPR should never appear in final drop down list.
This is the result which survives from the filtering in the first round.
Step3. Loop the result from previous step, call CRM_STATUS_MAINTAIN_OW to check whether the currently looped status could be reached.
This check is internally done via CRM_STATUS_CHANGE_FOR_ACTIVITY:
After the check of this function module is done, the four highlighted entries below are further filtered out. So finally in WebUI you can only see three entries: Open, In Process and Completed.
You can use the following report to trigger this check:
REPORT crms4_status_check. PARAMETERS: o_guid TYPE crmt_object_guid OBLIGATORY DEFAULT '6C0B84B754971ED78DB64E5AB75211A8', process TYPE tj01-vrgng OBLIGATORY DEFAULT 'INPR'. DATA: lv_not_allowed TYPE abap_bool, lv_error TYPE abap_bool, lv_obj_not_found TYPE abap_bool, lv_status_inconsistent TYPE abap_bool, lv_status_not_allowed TYPE abap_bool, lv_warning TYPE abap_bool. CALL FUNCTION 'CRM_STATUS_CHANGE_FOR_ACTIVITY' EXPORTING check_only = 'X' objnr = o_guid vrgng = process xnoauto = 'X' IMPORTING activity_not_allowed = lv_not_allowed error_occurred = lv_error object_not_found = lv_obj_not_found status_inconsistent = lv_status_inconsistent status_not_allowed = lv_status_not_allowed warning_occurred = lv_warning EXCEPTIONS activity_not_allowed = 1 object_not_found = 2 status_inconsistent = 3 status_not_allowed = 4 wrong_input = 5 warning_occured = 6. CASE sy-subrc. WHEN 1. WRITE:/ 'activity not allowed'. WHEN 2. WRITE:/ 'order not found'. WHEN 3. WRITE:/ 'status inconsistent'. WHEN 4. WRITE:/ 'status not allowed'. WHEN 5. WRITE:/ 'wrong input'. WHEN 6. WRITE:/ 'warning occurred'. WHEN 0. WRITE:/ 'this business process could be successfully carried out' COLOR COL_GROUP. ENDCASE.
For example when you specify business process as RELE, it will print out “activity not allowed”.
Why RELE is now allowed for current service order? Query table CRM_JEST with order guid, you can find this order has system status I1030 error.
Go to tcode BS22, find system status I1030 with business transaction RELE, here you can find the corresponding action is set as Forbidden.
In the backend this setting is stored in table TJ07: