Imagine you see an error message in WebUI or in some other interface. You manage to identify the message class and number, go to SE91, do a Where-used and find - nothing. The reason is that either Where-used was not updated correctly or (most likely) somebody did not both to use the message command to output the message but just hardcoded the message ID, number and type.
The questions and answers of a (returned) CRM survey can be easily accessed via database tables. But if you want to access the section belonging to a question, you need to get your hands dirty and access the Survey XML.
This can be done as follows:
To create an account in CRM using BOL, proceed as follows:
A bit old, but still valid, SAP's R/3 style guide for message texts often comes in handy.
Like:
If you have a problem in your ERP/CRM middleware, here are some handy places that you can set your breakpoints in:
When you're communicating with an external SAP system, you should use the released BAPIs if you can.
I don't use RFCs and BAPIs that often, so one thing that struck me today was that BAPIs don't refresh their buffer when you call them.
My expectation was: BAPIs are for external calls, so they should make sure you always get the most-up-to-date data and handle the buffer themselves.
I was wrong.
BAPIs will default to accessing the buffer, which makes sense performance-wise.
In case you were looking to include a new tab in a business object that displays related sales orders for a customer, you might have stumbled across the standard screen /BYD_COD/SalesOnDemand/SalesOrder/UI/COD_SALESORDER_EC.EC.uicomponent.
The problem with this screen was that the "RequestFireOnInitialization" flag was set to false - the standard would fire the inport from the customer screen, so didn't need this setting.
I've raised an incident regarding this and with the latest C4C hotfix (1911.03) SAP have set the above mentioned flag to true.
Most C4C users are certainly aware that SAP has switched off HTML5 with the 1911 release and that it is - according to SAP - "technically impossible" to re-enable HTML5 from 1911 onwards.
I did have some doubts if a) that is really true (it's "only" a frontend) or if that was just to encourage customers to switch to Fiori (which they should - takes some getting used to, but I've come to like it better) and b) if it is a good idea to make it technically impossible to switch back as they will have certainly forgotten some features.
When I read this article recently, I was instantly reminded of the problems my customers face when SAP makes yet another unannounced change. The facts in the article are:
TL;DR: If you are asking yourself whether you need two solutions, you don't. If you do need two solutions, you will not be asking yourself this question.