Both of you, my readers, may have noticed that in Transportation Management Worklists (like Overview Road Freight Orders in SAP TM / Freight Orders in SAP S/4HANA) all buttons in the result lists are active, as soon as at least one record is selected. Even if some actions "do not make sense" for the selected documents. In the single-document UIs, "irrelevant" buttons are deactivated.
Naturally, it begs the question:
why this differentiated treatment?
It must be understood that disabling buttons isn’t done to prevent harmful operations on the document! The prevention and protection must occur in the action implementation because these actions may be called in non-UI context too. Having a button enabled when “it shouldn't be” mustn’t pose any danger to data consistency! If it does, then it’s a bug in the action and must be corrected at the proper place, in the implementation, and not be hidden under the carpet by disabling the button!
Disabling buttons is merely a convenience feature, which may guide the user - keep him or her on the “correct path”. Yes, it’s convenient to see only two (out of 42) buttons active, it certainly helps when trying to figure out what to do next with this document, but this also comes at a price, we'll see later which.
Coming back to worklists: about a decade ago, as we (re)started with SAP TM 8.0, we discussed the opportunity of applying document specific properties to their buttons too, but we ultimately rejected the idea - for two main reasons (and some minor ones, like effort to achieve that).
First, it is a question of
performance. In the single document UI, there is only one document for which action properties are to be determined – and this alone is sometimes an expensive endeavour. In the worklist however, we may request properties for many documents, operation which quickly becomes runtime hungry. Also, properties are determined by a backend functionality, which reads document data using BOPF and thus filling BOPF buffers – for many documents, this leads to increased memory consumption in the worklist application. Which we wanted to keep slim (that’s why we use the so-called BOPF Result Queries, which allow us to read a lot of data without filling BOPF buffers).
Secondly, it was the tricky question: how should the system react in case an action is allowed for certain documents and disallowed for others? Should it keep the button active (rendering the approach very similar to the current one, but with increased performance degradation; only in rarer situations the effect would be different)? Should it disable the button – confusing perhaps the user into thinking that the action cannot be executed for no documents at all? Even if one suspects that only few documents “block” the action, there’s no way to tell which...
There are arguments for both approaches, therefore we would have probably ended up with (yet another) configuration/personalization setting.
In the end we decided
against applying selection-dependent properties to the worklist buttons. We keep them all active, and it is the responsibility of the action implementation to ensure that it cannot be executed when inappropriate - with a message that informs the user about why it cannot be executed.
Currently, if more records are selected while using a worklist button, we have a “as-much-as-possible” approach – the action is executed for all documents for which is possible, and the user receives proper feedback on the rest.
Because that’s in my opinion the most annoying drawback of the approach implemented in the single document UI. The user sees that a certain action
is disallowed but receives no information on
why. Is it because a certain status was reached? Is it because certain data is incomplete? Where exactly - in the document, or in some related master data? Is it because a required authorization is missing? It’s because today it’s Friday, the 13th?
Some would say, “sure, a power user would know immediately that
Draw HBL Number is disabled in this particular Forwarding Order because the numbers were already drawn in all related Freight Units!” (I personally did not know, had to look into code!! ?). But then: such an all-knowing power user knows better than to use the button – and does not necessarily require it to be deactivated. Even if the button is active and used inadvertently, the system responds appropriately (with an informative error message; everything else is a bug, as I explained above).
---
Facing an unconfortable choice, we took the decision that ultimately avoided performance degradation. If someone is really adamant on having a selection-dependent property handling in the worklist, this can still be implemented customer-specific – but if one runs into performance issues, don’t say I did not warn about it!
