Customizing or Enhancement?
When creating a new appointment, the UI fields Account and Contact are marked as mandatory fields.
After entering the Account, the partner determination runs. If there is only one contact person determined, field Contact is filled automatically based on customizing settings. However, the error from mandatory field check is still there. The error will be cleared if the ‘ENTER’ key is pressed.
It is a standard system behavior. In this case, the mandatory field check runs first, then the partner determination runs to determine the contact person. The system needs a ‘trigger’ to restart the mandatory field check, because it is hard for the system to know when the UI fields input are finished completely.
However, the end user does not accept the system behavior. Because they think it is strange that the error is still there since the field is already filled. And if there are more than one contact person found, there is no such problem after selecting the contact person from the partner selection pop up.
To by pass the issue, I could think about 2 work arounds:
1. Customizing change.
In the used partner determination procedure, set 1 to ‘Selection Limit’ for partner function ‘Contact Person’.
After that, there will also be a selection pop up when there is one contact person found. And the error ‘Make an entry in field’ will be removed after selecting the contact person.
2. Enhance the UI to delete the error message once the contact person is filled.
Add a check against the contact person value in the get_* method. Once the contact person value is filled, delete the error message BSP_WD 022 for the contact person from CL_BSP_WD_MESSAGE_SERVICE’s MESSAGE_TAB and BSP_MESSAGES.
I prefer the customizing change. Or convincing the customer to accept the standard system behavior, since the error is a temporarily displayed only. The UI enhancement may cause additional problem, and it is not supported by system upgrade.
What is your choise? Customizing or Enhancement?
My choice is to report this to SAP via OSS as an obvious bug, and demand that they fix it, on the grounds that I pay an enormous amount of money to them each year in "maintenance fees" and you are supposed to get something back for that money.
They won't, if this was perceived as a bug then something would already have been done.
If there is a clear bug like the one described above in any software I had written, it would be fixed within the hour, as soon as I became aware of the error.
All too often, when there is an obvious error and you raise an OSS note back comes the reply "this is not an error, this is working as designed" which translates to "we have make a conscious decision for this not to work properly, so live with it".
When it comes to "convince the custom to accept standard behaviour" that sounds a bit like:-
Customer: This parrot what you have sold me is dead.
SAP : No, it's not, it's sleeping.
Customer: I tell you it is dead, it has shuffled off this mortal coil etc etc
SAP: No, no, being dead is standard behaviour for a parrot. That parrot is working as designed.
And so on......
It's funny that I faced this issue on each and every project I worked on... and each time I solved it with only one simple line of coding into method DO_FINISH_INPUT of the respective view controller:
me->typed_context->btpartnerset->collection_wrapper->publish_current( ).
In fact the reason why the system is behaving like this in SAP standard is only because when you enter a business partner in a business transaction, partner determination will run in background (which will in turn fill-in the API buffer with a contact person). The problem is: at this point there is no way the BOL buffer knows that a new contact person was added to the API buffer unless you "force" a BOL buffer refresh. This is something we can easily do with the above line of coding... and surprizingly you'll find the exact same line of coding in SAP standard method DO_PREPARE_OUTPUT. Unfortunately this method is called AFTER the mandatory field check was performed... hence leading to erroneous error messages because of a line of code inserted to late in the process.
I already opened a customer incident with this solution and was answered the usual "system works as designed". So I just keep on adding this line of code on every SAP CRM system i'm working on...
Cheers,
Nick.
Generally speaking I'm all for configuration over customization/enhancements. HOWEVER, in this case I also agree that the "Standard" system response is not adequate or desirable. My clients often require at least one, but often want the ability to add multiple contacts. Therefore the coding enhancement is the preferred method.
Thanks Nick for sharing this bit of code with the group.
Hi Guys, I had similar problem when I switched configuration within DO_CONFIG_DETERMINATION / SET_CONFIG_KEYS, message BSP_WD 022 stayed for the previous configuration.
It was confusing, mandatory fields are gone, but error messages are there...
Resolved with one line of code:
me->view_manager->get_message_service( )->delete_bsp_messages( iv_condition = cl_bsp_wd_view_controller=>co_mandatory_field_empty ).
BR, Dima