Custom Checks for Block Overrule Checkbox
With the block refactoring done in TM 9.4 we introduced the functionality to overrule specific blocks by the user to still enable process steps like planning, execution or invoicing. The functionality was well received but we often get questions from customer projects about a more granular control over which kind of blocks should be overrulable e.g. “Compliance blocks should never be overruled” or which user should actually be able to overrule blocks.
We did not provide any customizing our authority object to handle this, but with wise foresight 😉 we already built the functionality in a way that it can easily be enhanced in your project to perform additional checks when clicking the “Overrule Blocks” checkbox.
The initial part of this enhancement is of course generic and well known to most of you, but I include it to provide an end-to-end guide:
Creation of Enhancement BO for /SCMTMS/TOR
Open Transaction BOBX.
On Header Toolbar Select Business Object Processing Framework -> Create -> Business Object Enhancement
Enter the name of your new enhancement business object according to the naming conventions of your project. For Super Business Object enter /SCMTMS/TOR.
Navigate to your enhancement object. The Object contains the structure of its original Super BO /SCMTMS/TOR.
Creation of Action Validation for Action Block~Overrule_Block
In the node tree of your Enhancement Object. Navigate to Node BLOCK -> Validations. Right click on folder validations and select Create Validation -> Action Validation.
Open Tab Trigger Actions. And select Action Block~OVERRULE_BLOCK
Maintain action as below.
After creation the implementing class is still empty.
Open Transaction SE24 and create a new class.
In the interface section of the class builder add interface /BOBF/IF_FRW_VALIDATION. Save the changes.
Navigate to tab methods and double click on Method /BOBF/IF_FRW_VALIDATION~EXECUTE to implement your specific logic.
In the simple example screenshot below, we will get the data of the processed block instances and check if any of the blocks(consider although on the UI you click one by one, technically the action can be called for multiple blocks at once) is of a specific kind. In this case a manual block with Block Reason Code “(29)Restriction for Follow-up processing“(Remember…just a technical example). If this is the case, we add the key of the block instance to the table et_failed_key so it will not be passed to the standard overrule processing logic later. We also throw an error message to the user saying that “Block must not be overruled”.
Activate all methods of the newly create class.
Enter the newly created class as Implementing Class in your created Action Validation of your Enhancement BO.
When trying to overrule a block that matches the condition in coding snippet line 18, the overrule information(flag, user, date&time) will not be set and the User is informed by the error message returned in line 21ff above.
In regards to the 2nd example of only enabling a specific user to overrule blocks, you could of course also implement a custom authority check in your action validation.