In my previous blog How is status drop down list entry generated in Order detail page I research how the status drop down list entries are generated without any status profile assigned to transaction type. In this blog let’s take things one step further, to figure out the logic of drop down list where the status profile is assigned.
I copy a standard transaction type SRVO into ZSRV and assign a profile CRMOPPOR to it.
This is the setting of CRMOPPOR:
The first two statuses OLI1 and OLI2 will be ignored by the logic mentioned below simply because their stonr flag is 00:
And this is the runtime rendered drop down list:
Still set breakpoint on the same method CL_CRM_UIU_STATUS_INFO=>GET_STATUS_INFO, and open Service Order detail page.
First the current user status and system status is retrieved by FM CRM_STATUS_READ_OW:
These two statuses could also be directly queried from table CRM_JEST.
Then the same logic as introduced in previous blog, the eight statuses maintained in status profile CRMOPPOR is looped and each row is passed to FM CRM_STATUS_MAINTAIN_OW to perform status check:
This is the status data for service order before I make change:
Now I change the status to Won:
E0001 transfers to E0003, this transition is manually specified by me.
And why I1002 leads to the current new system status I1005 and I1027?
In include CRM_STATUS_CON, I1005 means “Completed” and I1027 means “Won”.
When status is changed from E0001 to E0002, business transaction WINN is set since it is maintained here:
And go to tcode BS32, locate WINN and click Where-used list icon:
And here is the answer why system status I1005 and I1027 are set automatically.
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:
要获取更多Jerry的原创文章，请关注公众号"汪子熙":