Skip to Content

SET_PREDOC / PREDOC_CAN_BE_SET > inconsistent behavior with identical customizing

Dear CRM experts

There is a very confusing issue/behavior with our new Defect2Correct process flow.

ZMIN Defect is a predecessor document for ZMTM Defect Correction.

Via customizing setting “Make Settings to Change Transaction Types” I defined which status value shall be set in the predecessor document based on the status value of the successor document and vice versa. I spend the last 2 days trying to figure out, why the behavior of these settings are not consistent. All settings seem to be correct and are identical for all status, yet they all result in another behavior.

Here are the three cases where ZMTM does not trigger the status change of ZMIN as expected or does not trigger the error messages as expected or doesnt apply the cancel as expected:

1. If ZMTM reaches Status E0002 In Correction its predecessor doc ZMIN shall be set to E0002 In Process -> does not work and SET_PREDOC / PREDOC_CAN_BE_SET does not trigger a cancel if pre doc in edit mode. If pre doc is in display mode, status change to E0002 In Process is NOT applied

2. If ZMTM reaches Status E0011 Functional Test its predecessor doc ZMIN shall be set to E0002 In Process -> WORKS as expected! SET_PREDOC / PREDOC_CAN_BE_SET does trigger a cancel if pre doc in edit mode and error message is displayed. If pre doc is in display mode, status change to E0002 In Process IS applied

3. If ZMTM reaches Status E0004 Retest Requested, its predecessor doc ZMIN shall be set to E0017 Retest Requested -> WORKS partially -> SET_PREDOC / PREDOC_CAN_BE_SET does trigger a cancel but no error message is displayed. If pre doc is in display mode, status change to E0017 Retest Requested IS applied

In second case cancel and error message works as expected. In first case only error message works but no cancel (of status change in display mode) is applied. In the third case, cancel works, but no error message is displayed.

Why is the behavior not consistent, even though all Customizing is always identical!?

I am aware, that ZMIN is an Incident from ITSM and ZMTM is a Change Document. Nevertheless, as some of the actions work, this can not be the reason for the observed inconsistencies.

I reckon, there must be some hidden settings that causes these inconsistencies. But I have really no idea where else to look…

I appreciate any input from your side!

Best regards and many thanks,

Lennart

defect2correct-question2sap-01.png

defect2correct-question2sap-02.png

defect2correct-question2sap-03.png

defect2correct-question2sap-04.png

defect2correct-question2sap-05.png

defect2correct-question2sap-06.png

defect2correct-question2sap-07.png

defect2correct-question2sap-08.png

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Jul 08 at 01:21 PM

    Thanks to the related question (https://answers.sap.com/questions/11236598/setpredoc-status-for-predecessor-works-inconsisten.html) which poped up after submitting my question, I was able to solve the issue, that Reset to In Correction did not trigger the status change of ZMIN to E0002 In Process.

    The action was an original copy of the action delivered by SMTM (SMTM_TESTED_AND_NOT_OK_TM - Reset to "In Correction"). It hat an additional entry in the method call: RESET_STATUS with value X

    Removing this expression solved one of my issues.

    Still the inconsistencies in displayed error messages persists.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.