Usually sales representatives need different account factsheets, for example an external and an internal one. The external factsheet is to be quickly printed out and taken to a customer meeting.

Unfortunately so far in SAP CRM only one factsheet could be assigned to the account overview page, per role. One main restriction was that the related Customizing table allowed only one factsheet per such a role (i.e. for example for a sales representative).

This is now resolved, from SAP CRM 7.0 on.

Check out SAP note 2104590.

This blog will explain the replication of Customer Master Data from ECC into CRM. This will be achieved by Middleware replication of ECC fields. In ECC we have the customer master data field called ‘Plan-Level Customer’.where as this ‘Plan-Level Customer’ field is not available in CRM. We will first create this field in CRM then we will map the ECC - ‘Plan-Level Customer’ field against CRM-- ‘Plan-Level Customer’ field.

In ECC

In ECC—XD02 (Tcode)

Click on MORE data…

Change the Plan-Level Customer and click the Save.

After clicking on save, the Master Data will flow from ECC to CRM.

In CRM

Step involved in debugging the Master Data flow of ECC into CRM.

In CRM- SMQR (Tcode)

Step 1:

De-Register the R3A*- Quee- This is inbound quee in CRM for R/3 Data.

Step 2:

In CRM- SMQ2 ( Tcode)

Open the inbound Quee –

Once Master Data of BP gets saved in ECC, the ECC Data get captured in the above quee.

Just double click on it..

There is the DEBUG-LUW icon will be there. Which will start the debugger.

Place the breakpoint in the INBOUND Quee FM

Expand the CP_BP_STRUCT to see the R/3 Field data.

Path:

C_BP_STRUCT-CENTRAL_DATA-COMMON-DATA-ZZFLD00001D

C_BP_STRUCT-CENTRAL_DATA-COMMON-DATAX-ZZFLD00001D

In DATA field-

In DATAX field-

In ECC for the Customer -50059571 we have given PLC as ‘AT1005014’.The same PLC is successfully mapped against the CRM PLC field. This shows ECC PLC field has flowed correctly to the CRM PLC Field.

Middleware replication will update in the Database table

Now we will see how to achieve this ECC replication into CRM Field.

Step involved in customer Master Data Replication

Step1:

In CRM:

As we know we need to create this PLC field first. Let us create this field through ‘AET’.

Step 2:

In ECC, Tcode :SM30 and maintain table TBE24. Create a product and mark it active.

Step 3:

In ECC,Tcode :SM30 and maintain table TBE34 for the event DE_EIOUT.

Note: ZSFM_SEND_PLC_TO_CRM_DE_EIOUT should be created prior.

Step 4:

In ECC Tr. SE11, look for the structure BSS_CENTI, double click on CI_CUST and create structure CI_CUST,  structure CI_EEW_BUT000 (CRM -STUCTURE).

In ECC

In CRM

Caution: Both the data type and length should be same. Otherwise mapping will be done incorrectly.

Step 5;

Follow the same for the structure BSS_CENTIX double click on the CI_CUST_X and create structure CI_CUST_X.

ECC:

In CRM:

Caution: Both the data type and length should be same. Otherwise mapping will be done incorrectly.

Step 6;

In the Function Module : The below Parameters are important to send the ECC Master Data Feild

Code:

FUNCTION zsfm_send_plc_to_crm_de_eiout.

* LOCAL DATA
DATA:    ls_extern           TYPE busei_com_extern,
lv_partner_guid     TYPE sysuuid_c,
ls_ct_main_extern   TYPE busei_com_extern_t.

FIELD-SYMBOLS:  <ls_extern> LIKE LINE OF ct_main_extern,
<ls_xknb1>  TYPE knb1.


******************************************************
*         MAPPING KNB1  to Business Partner
******************************************************
LOOP AT it_xknb1 ASSIGNING <ls_xknb1> WHERE kunnr EQ iv_customer.

READ TABLE ct_main_extern INDEX 1 ASSIGNING <ls_extern>.
IF sy-subrc = 0.

*----Add the PLC code
<ls_extern>-central_data-common-data-ci_include-zzfld00001d = <ls_xknb1>-zzplc.
<ls_extern>-central_data-common-datax-ci_include-zzfld00001d = 'X'.

ELSE.

ls_extern-header-object = 'BusinessPartner'.
ls_extern-header-object_instance-bpartner = iv_customer.

CALL FUNCTION 'PI_BP_CRM_MAP_KUNNR_TO_BP'
EXPORTING
iv_customer       = iv_customer
IMPORTING
ev_partner_guid   = lv_partner_guid
EXCEPTIONS
partner_not_found = 1
OTHERS            = 2.

IF sy-subrc = 0.

ls_extern-header-object_instance-bpartnerguid = lv_partner_guid.
ls_extern-header-object_task = 'U'.
*----Add the PLC code
ls_extern-central_data-common-data-ci_include-zzfld00001d = <ls_xknb1>-zzplc.
ls_extern-central_data-common-datax-ci_include-zzfld00001d = 'X'.

APPEND ls_extern TO ct_main_extern.

ENDIF.
ENDIF.

ENDLOOP.

ENDFUNCTION.

In CRM, you can assign the same Contact Person to more than one accounts. However, in ERP this is not possible. You need to have more than one Contacts (i.e. more than one instance of the same contact with same data) assigned to the different Customers. In ERP, the contact person is just like a “table” for a customer. Due to the different data model between ERP and CRM, the number of contact person could not the same. Therefore, some customers want to know how to stop the replication of Contact person between ERP and CRM. Here I summarize what I know regarding this topic and hope it helps in future.

1.       Prevent the Contact person replication from ERP to CRM.

The filters in R3AC1 works for the replication from ERP to CRM, and the object for Contact person is CUSTOMER_REL. In order to stop the contact person replication from ERP to CRM, you could set filter KNVK-PARNR = ‘0’ (or ‘X’) for object CUSTOMER_REL in R3AC1.

Kindly refer to SAP KBA 2138103 for more details.

2.       Prevent the Contact person replication from CRM to ERP.

You have two options to block the replication of Contact person from CRM to ERP.

1>     The filters in SMOEAC works for the delta load from CRM to ERP. (The filters for Initial load from CRM to ERP is set in R3AC1.) You can try using the intelligent subscription for BUPA_MAIN and set filter for IS_CUSTOMER for specific ERP site. This will stop contact persons replication, but in this case, only “Customers” will be replicated from CRM to ERP.

For this scenario, you can check KBA 1834681 for the steps and proceed ahead.

2>     You can create a Z function module as mentioned in note 638628 and register it in transaction CRMC_BUT_CALL_FU. This will check the role and you can delete the MAIN EXTERN structure. Similarly, you can alter the Z FM to check the BUPA_REL scenario as well.

3.       Prevent the Contact person replication from CRM to ISU.

You could implement note 2194365 and register the function module BUPA_OUTBOUND_FILTER_RELATION in transaction CRMC_BUT_CALL_FU. It can prevent certain business partner roles from being replicated between CRM and ISU.

The most important note in condition transfer area, SAP Note 514952, contains the steps that must be performed in order to generate in CRM the condition tables from ECC. As members of SAP CRM Product Support team, we have helped our customers in issues related to condition tables for several years and we have noticed that many of the problems in condition table generation are related to missing or incorrect steps while implementing that note. That is the reason why we decided to create a report for automatic troubleshooting of the steps in the note. The coding of the report, along with some related explanations, is in KBA:

2211042 - Automatic check issues in CRM generation of ECC condition tables (note 514952)

The report takes approximately 20 minutes to be implemented, but this small effort should pay off if you have to generate many condition tables, as it usually happens .You need to create a report in CRM system with a few selection texts and a function module in your ECC system that will collect the information related to the condition table fields. Then you can trigger the report from the CRM system indicating the ECC condition table name and the RFC destination of the ECC system from which you want to transfer the data.

You will get the results with traffic lights indicating whether the mapping has been correctly implemented for each of the fields.

There is a particular case that is not covered by the tool. The report checks if the field mapping settings for the selected ECC condition table have been correctly performed, but it does not analyze whether the condition table has been already generated or not. What happens if the condition table was already generated but you have changed the fields in the ECC condition table, or changed the data elements of any of its fields? In that case, if the steps in note 514952  have been correctly implemented considering the field changes in ECC, the report would show green lights for all the fields. However, as the condition table had been previously generated in CRM with the old fields, this is preventing the new table to be created. The solution for these cases is the deletion of the old condition table in CRM and the steps that must be performed are documented in KBA:

2028581 Cannot delete condition table or change its fields

A particular case, where the data element must be changed for a field is also documented in blog:

Have you ever needed to change condition tables generated in CRM?

The process for the deletion of a condition table might be tricky and this blog contains many screenshots to make it easier to understand. In the example taken for that blog, the old condition table does not contain condition records, it is still empty. If your old condition table contains condition records, you should also check the mentioned KBA 2028581.

We hope the new tool can be useful for you. Any feedback in the KBA of the tool, 2211042 , or in this blog is welcome.

José Ignacio Martin & Luis Rivera Gallego

Avoiding WAITING queues for BUPA_REL BDOCs for performance

Hello everyone,

I would like to share some ideas how one could avoid WAITING queues when processing BUPA_REL BDOCs.

When we create a relationship between two business partners, CRM system generates one BUPA_REL BDOC and two queues, respectively for each individual business partner. In most of the cases, it is not causing any problems, because SAP CRM is intended to operate with many pairs of business partners, considered these pairs are not linked to each other.

However, sometimes there are scenarios, when one BP is linked to many business partner, e.g. when you operate with corporate account and its employees. In these cases the relationships are often generated massively and should be replicated across the landscape (e.g. SAP ERP) in the meaningful time frame.

In this case, we will see many individual queues waiting for the related partner to be processed within its own queue. For N relationships, we will then have N individual queues waiting for one big queue with N entries. This is illustrated n the picture above.

Such a design was implemented in order to ensure the consistency of the BP processing. BUPA_MAIN BDOCs are processed within the same queues (CSABUPA*) and therefore this mechanism ensures that we will never create a relationship to the non-existing BP, as we will always be waiting the previous queue to finish.

However, sometimes, this can be ignored as all BP could have been created and replicated beforehand. In this case, we do not need a main BP queue and therefore the individual queues won’t be waiting for anything. This can significantly speed up a performance (as much, as many you have dialog work processes configured in the system).

Processing of the BUPA_REL is happening inside the FM BUPA_MWX_BDOC_CREATE_REL pair by pair. The queues are written into the table LS_CLASSIC_BDOC-CRMW_BUPR_HEAD.

If you skip writing a main BP queue into this table, this queue will not be generated, and the others will not be waiting for it.

But as I said this can only be implemented for the partners which have been already replicated and only for some specific business cases as all the negative consequences probably are not discovered yet. You can do a check against the table CRMM_BUT_CUSTNO to get information, whether the BP has been already replicated or not.

To implement a logic, you can register your own function in CRMC_BUT_CALL_FU or use an implicit enhancement.

Please do not consider it as SAP recommendation. Implement it carefully as it’s totally on your own risk. In case of problems or doubts, open an incident to SAP.

Thanks, Dima

In standard, if you delete the partner funcion from ERP system, the relationship will not be deleted automatically and it remains in CRM.

Let me explain the reason firstly:

There is a general data protection scheme in CRM in that nothing should be automatically deleted, the relationship can only be deleted manually in CRM.

It cannot be trigged automatically from R/3. This system is behaving correctly by not deleting the relationship on the CRM side. The deletion of Partner Functions does not mean that the corresponding Relationship is to be deleted, because this relationship may be used within other sales area and therefore would cause inconsistencies.

However,

in order to achieve the behavior that the CRM relationship is also deleted when the partner function is deleted in ERP, the customer can implement the funcion module Z_BUPA_DELETE_RELATIONSHIP in transaction CRMC_BUT_CALL_FU as per note 497146. (The recommandation of the position of this entry is 1400000.)

Please note this function module will only trigger for delta replication. Besides, this function module only takes affect for Partner Functions created/deleted from the time the function module is created and activated.

To remove the inconsistencies already present before you implemented it you can make use of the note 682427.

But, there are still entries existing which could not be removed by the note 682427 if there is entry in table CRMM_BUT_FRG0081. It is due to that the particular relationship may be used within another sales area and therefore would cause other inconsistencies.

Therefore, the note 682427 is only used to delete the relationships in CRM that are no longer assigned a partner function.

To remove the remaining inconsistencies, I will provide you the following two workarounds:

<1> You can use SDIMA to find out the data inconsistency and run a request to bring ERP and CRM synchronized. Creat SDIMA instance and run a request load.

<2> You can also delete all CRM relationships and then perform a new initial load for object CUSTOMER_REL.

Hope this blog helps on partner function deletion issue.

There has been many documents and blogs in the forum discussing about condition upload/replication and its debugging from ECC to CRM system. However in most of the cases condition records are created and maintained in ECC, there are few situations where the records are created and maintained in CRM and later replicated to ECC. One of such scenario is condition maintenance for Trade Promotion Management (TPM) which includes conditions for Campaign Determination, Rebates, Pricing and Free Goods. In this blog I like share my experience on how to debug the data flow and the points you should look for.

Pre-requisites: I like to assume that the reader is aware of concepts of Business objects, initial load and queue monitoring.

Transaction to view adapter object is R3AC5. Conditions upload objects usually have name UPL* or ZUPL* with required description containing the table name. SAP has provided few upload objects that can be used as reference for creating our own objects.

The mapping modules CND_MAP_MAST_EXCHANGE_MAIN_MBD and CND_MAP_MAST_UPLOAD_R3A play an important role.

Step 1> Start initial load for the object using transaction R3AS. Before running initial load start the debugger by entering /h in command box.

Step 2> Upon starting the load and debugging starts, keep a break point for function module SMOF_START_DOWNLOAD_OR_REQUEST. This is the place where the load will start. The FM calls SMOF0_INIT_DNL_START which will in turn triggers further processes.

Step 3> Function Module SMOF0_INIT_DNL_START calls FM CRS_FIRST_DOWNLOAD_TRIGGER from where data fetching and sending process starts. By default, this FM is called in background task that cannot be debugged. However during debugging we have an option avoid running in background and debug the flow. Variable da_smofparsfa-parval1 should be set to 'X' so that program flow takes the ELSE part of the condition so that FM CRS_FIRST_DOWNLOAD_TRIGGER is called as an RFC to the same system.

Step 4> Function Module CRS_FIRST_DOWNLOAD_TRIGGER is called as an RFC in the same CRM system. This FM calls the extractor module CND_MAST_EXTRACT_GUIDS_MAIN that fetches the condition record GUIDs (field VARNUMH in condition table) by calling FM CND_MAST_GET_GUIDS and prepares to send the data. Note that at this step, only the key field for the records (GUIDs) are fetched and not the entire data of the records.

Step 5> Once the key values of condition records is available, sub-routine CRS_SEND_TO_SERVER is called. The sub-routine calls FM CRS_SEND_TO_SERVER where filtering of data. This FM in turn calls the FM CRM_MAP_XML_AND_SEND_TO_SERVER that will convert the values to XML format and prepares to send the data. The execution reaches a point when FM BAPI_CRM_SAVE is called in background task as a RFC to the same CRM system further, which we can not debug.

Step 6> Though further debugging is not possible because BAPI_CRM_SAVE is executed in background task, we have other ways to achieve the same. It creates an inbound queue with the name CRI_<object name>_R3AI (queue name can depend on the configuration that has been set up) which can be stopped using transaction SMQR. So, before you execute the background task de-register the queue in SMQR, which will stop processing of the queue that can be viewed in transaction SMQ2.

Step 7> Go to transaction SMQ2 -> Double click on the queue entry with name CRI_<object name>_* -> select the first entry and click on 'Debug LUW' button which takes you to a debugger screen with call to BAPI_CRM_SAVE. The FM does not have code logic of its own but it directly calls CRM_GENERIC_CRM_IN function module.

Step 8> The next step in debugging is call to MAP_BAPIMTCS_AND_PROCESS. This is the entry point for preparing and processing of data before send. It calls the mapping module (R3 to CRM that is maintained for the object) CND_MAP_MAST_EXCHANGE_MAIN_MBD that will prepare the global internal tables before calling CND_MAP_MAST_INIT_CDB_MAIN.

Step 9> Function Module CND_MAP_MAST_INIT_CDB_MAIN checks for any on going loads on the same table. So far the flow has only list of GUIDs of the condition records and nothing else. The list of GUIDs is passed to FM CND_MAST_DATA_EXTRACT which extracts the condition records and populates the data to a working set. A working set contains data for every condition record in it which will later be used for further processing. The next step in process is to call CND_MAP_MAST_CONV_SAVE.

Step 10> Function module CND_MAP_MAST_CONV_SAVE handles updating of conversion tables like CND_MAPM_CNV_REC, CND_MAPM_CNV_AGM etc. It further calls FM CND_MAST_INT_DEEP_FILL which will create the BDOC segments and fill data in it. Further processing involves middleware aspects which we do not need at this point.

Step 11> As the last point in process chain, function module CND_MAP_MAST_UPLOAD_R3A is called which inturn calls FM CND_MAP_MAST_EXT_FRAME for mapping the data to BAPI structures and send the data to ERP system.

The Data Integrity Manager (DIMa) is a standard tool to compare the business objects in different databases. It can be used to compare the data such as BP, product, condition between CRM database and R/3 back-end database or CDB database.

In this blog, I will post the detailed steps about how to create a new DIMa Instance and how to use it to compare the data. I will take comparison for CRM BP and ERP customer as an example.

1. Run T-code SDIMA
2. Click on button “New DIMa Instance”. Now you could see the DIMa Instance Wizard. Click on “Continue”.

   3.  Give a name for the instance, and choose the DIMa object as per your comparison. In this case, I will compare the CRM BP and ERP customer, so I choose object “CUSTOMER”. Then continue.

5.       4.  Here you should choose the correct RFC destination. (It is better to take the suggested value list and then choose the appropriate RFC destination).

For the “filter mode”, it has “N- All filters” mode and “C- DIMa filters only” mode. If you choose “C- DIMa filters only”, then for comparison, the R/3 adapter object (Initial download object) filters are not considered. Normally, we choose “All filters” mode.

    5.  Click on “add a new line” button, here you could add the filter and select the data you want to compare. Please note the LOW field should be maintained as 10-digits number. The leading zeroes are needed. Then continue.

    6. Click on “complete”. A new DIMa instance is created.

    7. Right click on the instance name in the left. Choose “Start comparison” which is for header comparison. When it finished, right click on the instance name again, choose “Start detail comparison”. The header comparison only checks whether business objects exist, the detail comparison checks whether the objects are identical in both databases.

    8.  Then you will see the comparison result. In my case, the data is equal to each other in CRM and ERP. If the data is not equal to each other, the “message” field will have a flag. You could click on the check box, the difference will be listed.

Here is an important note regarding DIMa. It contains a note list for different business objects.

531217 - Data Integrity Manager (DIMa)

Some customers report incident because they found there is R3AD* entry with status “STOP” in SMQ1 of ECC system.

Actually, these STOP entries are inserted correctly when the initial/request load starts for an object.

In this blog, I will explain the reason of this behavior.

The entry is to avoid delta changes to flow when initial/request load is happening. It is necessary to ensure the data inconsistency. If a request load is running, then it is possible that a delta queue containing newer changes to the same object is created before the request has finished processing. In such case, if this queue were to process immediately, the changes it contains would be over-written by the older, obsolete data contained in the request.

Once the initial/request loads are finishes, the STOP entries are deleted automatically on the ECC outbound queue. Thus, please do not delete them manually.

Sometimes, the customers report that the STOP entries are not removed even the initial/request load finishes.

If you encounter this, you can check for the entries in table SMOFDSTAT/SMOFRSTAT table with status “R (running)”. This is blocking the deletion of the STOP entries in SMQ1 of your ECC system. You could reset the status of these initial/request loads to status “D (done)” and then delete the STOP entries in SMQ1 of your ECC system. Afterwards, your delta flow can start again.

In some incidents, the customers also ask why during initial/request load for MATERIAL, the generic R3AD_* entry is added rather than the R3AD_MATERIA* entry which has different behavior with the loading for Customer or BP.

This is also correct. Normally, when you do initial/request load for Customer or BP, the R3AD entry containing the specific object is created, such as R3AD_CUSTOME* or R3AD_BUPA* as the following screenshot shows.

However, when load the materials, the generic R3AD_* entry is created rather than simply an R3AD_MATERIA* entry. The reason is that some other objects have dependencies relating to the MATERIAL. So during the initial/request load of MATERIAL, the download of all delta loads must be stopped to ensure data consistency.

Here is an approach which can change this behavior.

    1. Go to transaction SM30 in ECC system.
    2. Enter the table CRMQNAMES and select the Edit mode.
    3. Add entry MATERIA to the field CRMOBJPART in the following entry:

             Object Name:MATERIAL
             Sorting:1
             Name of BAPI structure:BAPIMATMRA
             Field of BAPI structure:COMPETITOR
    4. Save the change.

You could do the above settings as mentioned in note 966758, then there is R3AD_MATERIA* entry instead of R3AD_* entry during the initial/request load of MATERIAL.

Hope this blog can help you understand the behavior of R3AD* entries with "STOP" status

As part of SAP CRM system connected with SAP ECC data transfer happens in the form of BDOC’s from vice versa .On daily basis there are so many data’s like Business partner, material, sale order getting replicated.

If we check in SMW01 Bdoc monitoring Tcode whichever data got transferred successfully will appear as Green color, if it is in progress / intermediate means yellow color and error means it gets red color.

As per standard activity using standard jobs all Green bdocs are been removed from the SAP CRM system in order keep the database clean to access the table content without much time consuming.

Normally error bdoc’s coming in OLTP windows from SAP ECC are processed on daily basis monitoring activity. But some Bdocs error cannot be cleared off due to various reason and remains in the system by occupying the space. Ex: If contact is having Central block, the same contact will be removed in ECC, but exists in other systems.

The irrelevant error Bdoc needs to be deleted as depicted in the below mentioned SAP CRM page

As part of best practice SAP used to send us a report in the name of SAP early watch Alert as raising red flag. By deleting these irrelevant Bdocs from the SAP CRM system will keep our database clean and also performance will be improved.

Note : Every 6 month by following this activity will be helpful for us to keep a track.

If anyone has any points to be added are always welcome.

Happy Learning!!!

Overview:

Many times we have requirement to restrict access through ACE (Access Control Engine) but the related object seems not to be available in Super object type. For example I have requirement to activate ACE for Product Category but the super object is not available in SAP CRM 7.3

Details for Super Object:

So I had to make a new ACL, GRP and UCT tables and Extension class. I have copied ACL, GRP and UCT tables from PRODUCT super object entry and make three new DDIC tables (no extra fields are required as these tables have similar structure through all Super object). I have coped extension class from ACCOUNTCRM super object entry. Please find below code snippet from method IF_CRM_ACE_OTYPE_OF_GUIDS~GET_OTYPE_OF_GUIDS extension class:

DATA:
     lwa_guid_with_otype TYPE crms_ace_objs_with_type.

   FIELD-SYMBOLS:
     <ls_obj_guid> TYPE crms_ace_object_guid.

   CONSTANTS:
     lc_crm_super_type TYPE crmt_prt_otype
                            VALUE 'PRODUCTCATEGORYCRM'.

*=> copy imported as long as there is no otype determination support
*   for the stype

   LOOP AT it_object_guids ASSIGNING <ls_obj_guid>.
     lwa_guid_with_otype-object_type = lc_crm_super_type.
     lwa_guid_with_otype-is_bor_otype = space.
     lwa_guid_with_otype-object_guid = <fs_obj_guid>-object_guid.
*=> add object guid with CRM object type to result list
     APPEND ls_guid_with_otype TO et_otype_of_guids.
   ENDLOOP.

I had selected PRODUCTCATEGORYCRM as Super Object and configured relevantly.

Details for Object:

I had chose same PRODUCTCATEGORYCRM as Object to configure with Super Object. Identification Type is GUID and a new Info class id, Info class ID is representation with class copied from CL_CRM_ACE_PR_INFO_DEFAULT. In IF_CRM_ACE_DETAILS~GET_DETAILS method code must be written to select GUID from ID and ID from GUID (similar coding from GET_OBJECTS_BY_FILTER of AFO class).

Other Configuration for AFO, OBF and AFU class are same for other ACE implementation and can be found from other class.

Challenge and calling ACE:

When SAP Standard has the Super Object type not available then ACE is not called automatically through SAP Standard code (generally in FILTER method).

Solution would be either Enhance ONSEARCH event handler or GENIL class enhancement for Serach, I have chosen GENIL class enhancement as it would be called from all search functionality! what ever after getting the search result below code should be called with GUID entries:

Call ACE Runtime methodes
       TRY.
           CALL METHOD cl_crm_ace_runtime=>check_multiple_objects_guid
             EXPORTING
               im_object_type  = 'PRODUCTCATEGORYCRM'
             CHANGING
               ch_object_guids = li_ace_guids.
         CATCH cx_crm_ace_unsupported_action .
       ENDTRY.

*     Check the filtered results
       LOOP AT li_hier_select INTO lwa_hierarchy_selection.

         READ TABLE li_ace_guids TRANSPORTING NO FIELDS WITH KEY object_guid = lwa_hierarchy_selection-hierarchy_guid.
         IF sy-subrc NE 0.
           DELETE li_hier_select WHERE hierarchy_guid = lwa_hierarchy_selection-hierarchy_guid.
         ENDIF.
       ENDLOOP.

       SORT li_hier_select BY hierarchy_id.

Hope it would be helpful to all who are struggling, if you have questions or comment please add it!

Tips:

In Class CL_CRM_ACE_USER_OBJECTS_CACHE method CHECK_MULTIPLE_OBJECTS_BY_ACL you can check for ACL table selection and analyze filtered output.

Problem :

There might be a scenario when an end user searches for product and found 2 similar records under result list

SAP CRM Web client UI view :

We need to use 2 programs in order to delete the duplicate products from SAP CRM database.

Solution :

COMC_PR_TOOL_REG :

In this program we will maintain user name and program name details.some times due to client copy same products will be available twice need to take call and delete appropriate one.

COM_PRODUCT_DELETE_SINGLE :

In this program we specify the product,product type,logical system  needs to deleted

SAP CRM WEB UI :

Cross check if only a single product is visible under result list

Please let me know if you have any other points to be added on top of this piece of work,Thank you!

Many customers are asking how to delete old bdocs or why the entries in table SMW3_BDOC* are becoming more and more.

The report SMO6_REORG2 can be used to delete the obsolete bdocs. And it is recommended to be run in the production system periodically. So the entries in table SMW3_BDOC* would not be increasing so fast.

The report SMO6_REORG2 calls many different reports and you can see the options for reorg different objects. You can find more details in note 206439.

Before running the SMO6_REORG2 report, you might consider running basis report RSRLDREL2 for relation table SMW0REL to delete the object links for BDoc's. Please see KBA 1922644 for details.

In the program SMO6_REORG2, you can define variants to separate the options in different jobs. As mentioned in note 493156, the parameter "Days to hold" means the days to hold the bdocs from now and it should be a low whole number. The default and recommended value is 7.

Additionally, this report SMO6_REORG2 only deletes successfully processed Bdocs. The Bdocs with errors cannot be deleted because that will cause data inconsistency. If you want to delete previous unsuccessful Bdocs, you can manually set the Bdoc status to "set to processed" in SMW01 by menu "Bdoc Message-> Process-> Delete". After that, run the report SMO6_REORG2 again, the bdocs can be deleted.

Here is also a note 1138051 which contains the parameter to prevent creating object links between bdoc. But this is not very recommended.

In this blog, I want to share with you the steps to use a different consumer for CRM instead of the default "CRM".

Recently, I encounter an issue that the default consumer "CRM" has been used by an SRM system before the CRM system is configured. If the consumer "CRM" is also used for CRM, the change from ECC will replicate both to CRM and SRM. Because this SRM system has been used in production for a long time, and customers could not risk changing the consumer for the SRM system, they want to define a different CRM consumer since the CRM system is not in production yet.

Here are the steps for how to use a new CRM consumer:

(1) In ECC system, go to t-code SM30 and edit view CRMCONSUM. Define a new consumer referring to the default "CRM". e.g. I defined "CRME" in the following screenshot.

(2) In ECC system, go to t-code SM30 and edit view CRMRFCPAR,  define a default entry for the new consumer and enter the RFC destination for CRM.

(3) In CRM tcode SE38, execute report SMOF_CHANGE_CONSUMER

(4) In the selection screen, you can enter the consumer, object name, and source/target site type. For the consumer field here, you need to enter the current consumer (old consumer "CRM"). If you do not specify any field for consumer/adapter object/site type, all entries will be listed.

(5) In the next screen, please enter the new consumer.

Then select the adapter objects you want to change the consumer (or select all), and press the button "change user"

(6) Consumers in CRM are changed:

(7) If you check in R3AC1/R3AC3/R3AC5, the consumers of the objects are changed accordingly

(8) If you have filters, you need to synchronize the filters to ECC.

You can do it manually using the synchronize filter button in the filter settings, or use the report SMOF_SYNCHRONIZE_FILTERS_ALL.

(9)There is another setting which needs to pay attention to. It is the ECC table CRMSUBTAB. It contains the function modules used for upload/download for the adapter objects. You need to copy the entries from default consumer "CRM" to the new CRM consumer.

In this blog, I am sharing some general steps for improving the performance of reorganization job SMO6_REORG2.

1. Run the basis report RSRLDREL2 for relation table SMW0REL before running SMO6_REORG2 report. This will delete the object links for BDoc's.
2. Run report "RSMW0_CLEAN_TABLE_NEW" which will delete the obsolete entries ( which does not have corresponding entries in SMW3_BDOC) from SMW3_BDOC2 table.
3. Please ensure that indexes are updated regularly as described in note 707820.
4. Perform manual steps in SAP Note 493156 (Performance of BDoc message related object links).
5. Perform manual steps in SAP Note 1254264 (Customizing Object links). This note refers to three parameters:
   • MOBBRIDGE_NO_LINKS (note 691628)
   • MW_NO_MBDOC_LINKS (note 792954)
   • MW_NO_OUTMBDOC_OBJ_LINKS/ MW_NO_INMBDOC_OBJ_LINKS (note 1138051)
6. The report SMO6_REORG2 calls many different reports and you can see the options for reorg different objects. You can define variants to separate the options in different background jobs.
   
   

Some customers asked "Oh! Why there are some address numbers in ADRC table but do not have any business partner in BUT020 table??"

OK, don't worry about that because it is possible. Let me tell you the reason:

The table ADRC is the master table over all addresses (like BUT000 is the master table over all BPs).

So this means that if an address exists in ADRC it does not automatically need to exist in BUT020.

You could check the "ADDR GROUP (Address group)" field in table ADRC. If it is filled with value "BP" then this entry isreally a BP address and must exist in BUT020. Else we do not care because it is an other address type.

Address types are defined in table TSAD7. Another usefull table is ADRV where you can see the usagein the different application tables.

So if you found the numbers of the entries in ADRC and BUT020 are not the same next time, don't feel too surprised about that.

You can display business partner relationships in different formats in the SAP GUI.

How to use this functionality?

This is achieved by changing the value of "Format" field.

• As a list:
  
  You can see all the relationships of a business partner for all relationship categories, or select a particular relationship type to display the relationships of that relationship category.
  
  
  
  
• As a hierarchy:
  
  In the hierarchical display format, you can see all the relationships of a business partner belonging to each relationship type you have selected on a specified key date (1:n view).
  
  
  You can also select the appropriate display level in order to display a complex relationship set for a BP. By right-clicking on the BP in the relationships, you can display its incoming/outgoing relationships.
  
  
  
• As a network:
  
  All the relationships of a business partner of a selected relationship type on a specified Key Date (1:n view) are displayed graphically. The business partners are represented as nodes, and the business partner relationships are represented as lines between the nodes.
  
  You can select the display level here, and use buttons to enlarge or reduce the display.
  You can choose between portrait and landscape format when displaying relationships. For example, I choose horizon display:
  
  
  The graphical display format also allows you to view all the incoming and outgoing business partner relationships as well as the relationships for additional business partners simultaneously. For example, BP 472 is contact person for 6000000971 and 6000002723, and it also has contact person 6000003397:
  

Is this supported in CRM WEBUI?

This functionality is only available in SAP GUI, and not available in CRM WEBUI.

See Also

Displaying Business Partner Relationships - SAP Business Partner - SAP Library

Gap or overlap is not allowed for standard address.

It is a standard behavior of CRM system.

And this is the reason you get errors like below.

- Address is standard address; restriction to validity not allowed

- Validity period incompatible with validity of address

- Restricting the validity of a standard address is not allowed

I'll do some test to help you to understand it.

Case 1

I'll change "Valid From" of a standard address from following screen.

I changed it from "01.01.0001" to "01.01.2015". It can be changed without any problem.

Case 2

This time, I'll change the the "Valid From" of a standard address from following screen.

What would be the result ?

4. Following error occurs.

What is the difference between two scenarios ?

In case 1, If we change the “Valid From” to “01.01.2015”, the duration “01.01.0001 – 31.12.2014” of a standard address becomes empty.

But as we know, time gap is not allowed for standard address.

So system tries to find another non-standard address to fill the duration.

As a result, address “Sendo3” is separated to 2 parts.

One is a standard address with duration “01.01.0001 – 31.12.2014”, the other one have duration “01.01.2015 – 31.12.9999”.

But in case 2, when system tries to find another non-standard address to fill the duration.

System can determine two addresses -- sendo2 and sendo3.

As a result, error occurs. Because system don't know which address (sendo2 or sendo3) should be separated.

Dean Yan

Recently I am preparing an internal middleware training session and I need to provide more detail about the Consolidated Database in architecture picture below.

Here below is copied from standard training course: "The Consolidated Database is a logical part of the entire CRM database, which also contains application data.

CRM Middleware server owns the consolidated database where CRM data is stored centrally. The consolidated database comprises the contents of all mobile clients’ local databases."

A frequently asked question is: Can you give some example of CDB? For example if I would like to look for a CDB for product / material in CRM system, how can I find it without google?

Here below is how I teach. Since we don't have any hint where to start, I suggest to always start from package. As rule of thumb all middleware framework package starts with SM, so package SMO3 is identified.

Then tcode SE80, use Repository Information System, specify SMO3 as package and filter by Table description:

Here below are just what I am looking for.

We can do simple verification. Suppose I have one material in ERP system QI3/502 and after it is downloaded to CRM, a product with id 1367 is generated.

Then in CRM, I can find a corresponding entry for this product in CDB table SMOMARA I found in previous step.

With the same approach we can also find some CDB table which only stores CRM specific data, for example product hierarchy or category which makes sense only in CRM:

Take SMOCATREL for example, it stores the assignment information of product categories of a given product.

Just specify the product guid into field SFAMARA and we can get three records in DB, which represent the three assigned product categories for this product:

This information exactly matches the fact in transaction code COMMPR01:

There are two ways to avoid the generation of the bdoc messages.

1. If you don't want the CSA* queue in CRM inbound queue and you don't want the bdocs to be generated, you could do the following steps:

          Go to transaction SMW3_00

          Enter the bdoc type for unwanted bdocs (You can find the bdoc type in R3AC1 for each object)

          Set the indicator "do not send"

2. You could set the field Discard data indicator (DISCARDDAT) in table CRMRFCPAR for the specific object type and even for the specific load type (initial/request/delta load).

          Go to transaction SM30

          Enter the object type (the objects can be found in R3AC1) and the load type for unwanted bdocs

          Set "X" for field DISCARDDAT