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.

The navigation from account relationship view BP_DATA/AccountRelationshipsEF to account overview page by click "done" or "back" button is always not possible, for instance, no response or keep a blank page.

To resolve the problem, please make sure the following notes been implemented in the system, if not, implement the following notes in order:

<1> 1943769 - Restore the Pagination state when Assignment block is left for navigation.

<2> 1979904 - Exception when clicked on Done button in BP_DATA/AccountRelationshipsEF.

<3> 2036792 - Side effect note 1979904, navigation not possible from BP_DATA/AccountRelationshipsEF

If the issue persists after applying the above notes, please check the following customizing:

<1> SPRO-> Customer Relationship Management -> UI Framework -> UI Framework Defination -> Maintain Runtime Framework Profile

<2> Select profile "Default"

<3> In the "History Settings" section, the value of "Operation Mode" should be maintianed as "N" (Application Controlled Recording).

This is a continuation of my previous blog: Condition Master Data - Customizing Download.

In this blog, I would like to discuss about condition master data download, which is performed in order to bring down the condition records from ECC to CRM.

Once you confirm that condition customizing object DNL_CUST_CNDALL has been downloaded to CRM successfully, you can proceed with bringing down the contents from condition master tables from ECC, by performing an initial load of condition master data objects.

As mentioned in my previous blog, condition master data objects can be viewed using transaction R3AC5 in CRM.

Example for condition master data objects (standard):

Object DNL_COND_A065 - To bring down pricing records from ECC table A065 to CRM

Object DNL_COND_G001 - To bring down listing records from ECC table KOTG001 to CRM

Object DNL_COND_D001 - To bring down material determination records from ECC table KOTD001 to CRM

Once the download is performed, its always better to check the logs in transaction SLG1 of CRM, to view errors occured during the download, as below:

Object: COND_EXCHANGE

Subobject: CONDITIONS

From/To (Date/Time): <Date Range - Start of Download till Download Completed>

You may not be able to view the errors occured during condition master download, using transaction SMW01 for BDoc type: CND_M_SUP. Hence, its always recommended to check the logs to confirm the status of the download.

Below are some of  important points/scenarios, to keep in mind/refer, with respect condition master data download from ECC to CRM:

• Do no change anything in SAP standard delivered condition objects. Rather, you can copy a standard object to a new Z* object and fulfill your requirement.

• Before loading the master data using Z* condition object, in case of customer specific condition table, make sure that table is active. This can be checked using table /SAPCND/T681 in CRM, value of field GESTA should be 5 for that KOTABNR. If not, you can try to activate the table using below customizing path:

          SPRO-->IMG-->CRM-->Basic Functions-->Pricing-->Define settings for Pricing-->Create condition tables

         Condition Table : CUSXXX

         Click on Activate Condition Table.

Sometimes it may happen that in transaction SE11 table would be active but in above customizing it would still display as Inactive.

• If you suspect or observe any kind of data inconsistency in any of condition tables, then you can refer SAP Note: 664815 - Check of data inconsistency in condition tables, in order to check/delete the inconsistencies.

• You observe that not all condition records have been downloaded to CRM, even after performing an initial load of respective download object. It is important to note here that, performing download of master data like Products, Business Partnersand Sales Organization is necessary, before performing a download of condition object.

          SAP Note: 877842 - Initial Download does not download all the records to CRM, can be referred here.

• You define customer specific condition object in transaction R3AC5, to download customer specific condition table. But during regenerating the filters, you get below message: 'Function module /1CRMGC/CND_M_SUP_FIL does not exist'.        
  SAP Note: 1826448 - Change in Authorization Check of  RS_FUNCTIONMODULE_INSERT, can be referred here.

• To maintain a table in CRM, which was originally created/maintained in R/3, you need to make an entry in R/3 table MNTCNT for this table and then perform a customizing download. In order to maintain a table in CRM, this table should have entry in CRM table /SAPCND/T681M and in CRM table /SAPCND/T681 field DATA_ORIGIN should be ‘B’. If this field value is ‘A’ and if there is no entry in CRM table /SAPCND/T681M,then it means, that particular table can be maintained in R/3.

• For Usage = Listings, it is always recommended not to perform an initial download from R/3 to CRM multiple times which might cause performance issues. Rather, initial load should be carried once and then maintenance has to be shifted from R/3 to CRM.

         SAP Note: 1591754 - Listings download from ECC to CRM, can be referred here.

• For performance issues, SAP Note: 1483757 - Slow processing tRFC, qRFC in a high load environment, can be referred.

• SD_COND is the archiving object in ECC and CND_RECORD is the archiving object in CRM, for condition records.

Below are some of the scenarios/issues you may face, during condition master data download/DIMa, with possible solutions:

This may not include complete list of errors that may occur during condition master data download !!! Also, solution might vary from one business scenario to another. So, please evaluate the situation before applying the solution mentioned here, which is mainly based upon my experience in this area.Also, some of SAP Notes mentioned here may look old but still they are of much relevance.

If you face any such issues mentioned earlier, while performing condition master data download, then its always better to apply the proposed solution, first in Test/Development/Quality system before applying the changes to productive client.

In my next blog, I will try to touch upon Condition Master Data upload.

Hope you find this blog useful

Your suggestions, feedback, comments on this blog are most welcome.

In DQA task screen, if you find the hyperlink to target group on the Validation Group field is not working, please refer to the following solution:

1. Go to customizing SPRO-> Customer Relationship Management-> UI Framework->Business Roles->Define Business Role, double click on the current business role you are using and find out the Navigation Bar Profile.
2. Go to customizing SPRO-> Customer Relationship Management-> UI Framework->Technical Role Definition-> Define Navigation Bar Profile (T-code CRMC_UI_NBLINKS), select the navigation bar profile and click on the folder "Define Generic OP Mapping" on left hand side.
3. Find entry with Object Type = SEG_TARGETGROUP, Obj. Action = B (Display), maintain the Target ID as TSEGFR_ED2 and Highlight as MKT-SEG-SR. If this entry does not exist, then please create this entry. Please refer to the standard TPM-PRO as an example:
   

Please also refer to my KBA:

2121556 - Hyperlink for target group is not working in DQA task

Related SAP component: CRM-MD-DQA

This is a continuation of my previous blog: Condition Master Data - Customizing Download.

In this blog, I would like to discuss about condition master data download, which is performed in order to bring down the condition records from ECC to CRM.

Once you confirm that condition customizing object DNL_CUST_CNDALL has been downloaded to CRM successfully, you can proceed with bringing down the contents from condition master tables from ECC, by performing an initial load of condition master data objects.

As mentioned in my previous blog, condition master data objects can be viewed using transaction R3AC5 in CRM.

Example for condition master data objects (standard):

Object DNL_COND_A065 - To bring down pricing records from ECC table A065 to CRM

Object DNL_COND_G001 - To bring down listing records from ECC table KOTG001 to CRM

Object DNL_COND_D001 - To bring down material determination records from ECC table KOTD001 to CRM

Once the download is performed, its always better to check the logs in transaction SLG1 of CRM, to view errors occured during the download, as below:

Object: COND_EXCHANGE

Subobject: CONDITIONS

From/To (Date/Time): <Date Range - Start of Download till Download Completed>

You may not be able to view the errors occured during condition master download, using transaction SMW01 for BDoc type: CND_M_SUP. Hence, its always recommended to check the logs to confirm the status of the download.

Below are some of  important points/scenarios, to keep in mind/refer, with respect condition master data download from ECC to CRM:

• Do no change anything in SAP standard delivered condition objects. Rather, you can copy a standard object to a new Z* object and fulfill your requirement.

• Before loading the master data using Z* condition object, in case of customer specific condition table, make sure that table is active. This can be checked using table /SAPCND/T681 in CRM, value of field GESTA should be 5 for that KOTABNR. If not, you can try to activate the table using below customizing path:

          SPRO-->IMG-->CRM-->Basic Functions-->Pricing-->Define settings for Pricing-->Create condition tables

         Condition Table : CUSXXX

         Click on Activate Condition Table.

Sometimes it may happen that in transaction SE11 table would be active but in above customizing it would still display as Inactive.

• If you suspect or observe any kind of data inconsistency in any of condition tables, then you can refer SAP Note: 664815 - Check of data inconsistency in condition tables, in order to check/delete the inconsistencies.

• You observe that not all condition records have been downloaded to CRM, even after performing an initial load of respective download object. It is important to note here that, performing download of master data like Products, Business Partnersand Sales Organization is necessary, before performing a download of condition object.

          SAP Note: 877842 - Initial Download does not download all the records to CRM, can be referred here.

• You define customer specific condition object in transaction R3AC5, to download customer specific condition table. But during regenerating the filters, you get below message: 'Function module /1CRMGC/CND_M_SUP_FIL does not exist'.        
  SAP Note: 1826448 - Change in Authorization Check of  RS_FUNCTIONMODULE_INSERT, can be referred here.

• To maintain a table in CRM, which was originally created/maintained in R/3, you need to make an entry in R/3 table MNTCNT for this table and then perform a customizing download. In order to maintain a table in CRM, this table should have entry in CRM table /SAPCND/T681M and in CRM table /SAPCND/T681 field DATA_ORIGIN should be ‘B’. If this field value is ‘A’ and if there is no entry in CRM table /SAPCND/T681M,then it means, that particular table can be maintained in R/3.

• For Usage = Listings, it is always recommended not to perform an initial download from R/3 to CRM multiple times which might cause performance issues. Rather, initial load should be carried once and then maintenance has to be shifted from R/3 to CRM.

         SAP Note: 1591754 - Listings download from ECC to CRM, can be referred here.

• For performance issues, SAP Note: 1483757 - Slow processing tRFC, qRFC in a high load environment, can be referred.

• SD_COND is the archiving object in ECC and CND_RECORD is the archiving object in CRM, for condition records.

Below are some of the scenarios/issues you may face, during condition master data download/DIMa, with possible solutions:

This may not include complete list of errors that may occur during condition master data download !!! Also, solution might vary from one business scenario to another. So, please evaluate the situation before applying the solution mentioned here, which is mainly based upon my experience in this area.Also, some of SAP Notes mentioned here may look old but still they are of much relevance.

If you face any such issues mentioned earlier, while performing condition master data download, then its always better to apply the proposed solution, first in Test/Development/Quality system before applying the changes to productive client.

In my next blog, I will try to touch upon Condition Master Data upload.

Hope you find this blog useful

Your suggestions, feedback, comments on this blog are most welcome.

Actually, we have a pretty good manual in help.sap.com about these steps.

The link is:

http://help.sap.com/saphelp_crm70/helpdata/EN/a1/2bfc3f37c2e569e10000000a155106/frameset.htm

But I've met several incidents reported the manual is not working.

If you are one of them, please follow the steps below again.

Especially, step 5) which is not included in the manual.

1) Perform an initial load of the necessary Customizing settings from  

    SAP ECC to SAP CRM (Initial load of DNL_CUST_THIT)

2) Map the ERP customer hierarchy categories to the CRM account hierarchies.  

    SPRO → Customer Relationship Management → Master Data → Business Partner

    → Account Hierarchy → Data Exchange of ERP Customer Hierarchies with SAP CRM

    → Assign ERP Customer Hierarchy Type to CRM Hierarchy Category.

3) Synchronize filter for DNL_BUPA_KNVH in R3AC1.  

    Download the ERP table KNVH (customer hierarchies) to SAP CRM (Initial load of DNL_BUPA_KNVH)

4) Start the creation of account hierarchies in SAP CRM using transaction BPH_DNL

5) Initial load object BUPA_KNVH to enable delta load.  ★This is important !

Hope it helps.

Dean Yan

Some customer complains the object CUST_MAT_INFO cannot be loaded successfully from ERP to CRM.

If you are also facing the issue, please check the settings as below.

1> In ERP system, check if the the events in TBE31 for download object CUST_MAT_INFO as described in note 758622 are activated.

                      00504001        BC-MID   CRS_CUST_MAT_COLLECT_DATA_CRE

                      00504002        BC-MID   CRS_CUST_MAT_COLLECT_DATA_CHA

                      00504003        BC-MID   CRS_CUST_MAT_COLLECT_DATA_DEL

2> In ERP system, check whether 'CRM_FILTERING_ACTIVE' is maintained for object CUST_MAT_INFO in the table CRMPAROLTP.

3> In CRM/ERP system, make sure the entries maintained as mentioned in note 787589.

4> In CRM sytem, if you check the parent object for CUST_MAT_INFO in R3AC1, you will find there are 3 entries:

                     BUPA_MAIN

                     MATERIAL

                     DNL_PLANT

     These entries are basically present in DB table SMOFOBJPAR.

     Instead of BUPA_MAIN, the parent object should be CUSTOMER_MAIN as per note 711254 states.

     Please implement the corrections then run initial load of CUSTOMER_MAIN.

      Also, the other two parent objects MATERIAL, DNL_PLANT should also be initial loaded sucessfully before you retest the load of object CUST_MAT_INFO.

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 497176. (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.

Ever appreciated the configurable data retrieval parameters?

They can help you to see only the business transactions that are of interest for you, for example the open ones of high priority.

One of the assignment blocks that supports this is the “Interaction History” in the accounts overview page.

With a lot of motivation and hope you possibly had started to configure them and struggled: Only transaction category but not transaction type for filtering is supported?

Good news is that with implementing SAP note 2104946 new parameters for filtering are supported. Not only transaction type but quite a few further ones.

Check it out.

The SAP note is valid for SAP CRM 7.0 EHP3, EHP2, EHP1.

With this note you also get a BAdI that helps you to use also own attributes as parameters for data retrieval.

Many companies struggle with having a lot of obsolete account and contact data in SAP CRM. For sales representatives but also for other users of CRM that deal with prospects and customers it is often a pain when either finding too many almost identical data records, or finding data that is just obsolete. This costs time - and money.

You can now use a nice feature that can help you to decrease the number of obsolete contact data records in SAP CRM: As a user you can decide for setting the status "To be archived" for a contact when deleting the last contact relationship of this contact to an account. This is available in the "Contacts" assignment block of the "Account" overview page, for corporate accounts, individual accounts and groups.

This feature has the very important advantage that you give the control of such data to the people that have the knowledge: The users that know a contact, know exactly if this contact is not relevant anymore. They are the right persons to decide if the status “To be archived” should be set. As an example think about a person that died in the meantime. How embarrassing to have such a person still stored as a contact in SAP CRM.

To use this feature check out SAP Note 2104152. It is available for SAP CRM 7.0 for EHP3, EHP2, and EHP1.

Some customers are confused about how does the merge of communication data work. Here I will summarize the standard behavior when doing merge for communication data and relavant notes.

1. Basic knowledge for account merge:

There are 2 approaches of merging accounts:

(1) Online mode: If nodes are ONLY put in variant CLEARING, it will be displayed in "Referenced Data".

The online merge is triggered by pressing "confirm" and then "save".

(2) Background mode : In transaction BUSWU02, if you put the nodes in CLEAR_REP, the data will be merged as background job.

When merging the BP, you will not see the data in "Referenced Data" in merge screen.

The background merge job will be triggered by pressing "start" button.

After the background job is finished in SM37, you can see the data moved to master account.

2. The behaviors of merging communication data via Online mode and Background mode are different:

(1) Online merge for communication data:

For online merge, you are able to select which one (data of Master or Source) to be merged.

*All items which are checked (Master and/or Source side) should be visible in the Merged Account and all unchecked items should not be visible in the Merged Account.

*All checked items of the Source will be copied to the Master (they will be available in the Merged Account) and will not be deleted from the Source.

*All checked items of the Master will stay there (they will be available in the Merged Account).

*All unchecked items of the Source will not be copied to the Master and will not be deleted from the Source. *All unchecked Items of the Master will get deleted from the Master.

Regarding the last point, if you want the communication data of Master data retains even you unchecked it, you could implement the consulting note 2000885 to do the enhancement.

(2) Background merge for communication data:

* When Master and Source both has the communication data, no need to merge.

* When Master has no value into some communication such as email, it should be copied email value from Source.

* And always copy the address and replace the old standard address.

Eg.1

Master Account: #123, Street A, City A - 11111. T: 111 1111, Email: test@test.com (Standard Address)

Source Account: #234, Street B, City B - 22222. T: 222 2222, Email: test2@test.com (Standard Address)

After Merge,

Master Account: #123, Street A, City A - 11111. T: 111 1111, Email: test@test.com (Standard Address) and #234, Street B, City B - 22222. T: 222 2222, Email: test2@test.com (Non-standard address)

Eg.2

Master Account: No address / communication data

Source Account: #234, Street B, City B - 22222. T: 222 2222, Email: test2@test.com (Standard Address)

After Merge,

Master Account: #234, Street B, City B - 22222. T: 222 2222, Email: test2@test.com (Standard Address)

3. Please see also the following notes:

1539775 - Merge Accounts: Communication data of master account is lost

1259396 - Merge Accounts: communication data

2000885 - Communication data of master account is overwritten after merge     (consulting note)

2121483 - Background: Address and communication data not moved from source to target     (consulting note)

Hope the above information helps!

Thanks very much.

For CRM account hierarchies, we do not have a standard function/report to delete the hierarchies from the Account Hierarchy application. The reason is the hierarchies are used in several places like Territory Management, Pricing, Trade Promotion Management etc. and there is no routine available to check if the deletion can be permitted or not based on the usage.

We can only delete assignments of hierarchy nodes and business partners, as mentioned in SAP library : Working with Account Hierarchies - Business Partners - SAP Library

But if you really want to clean up CRM tables from the Hierarchy which is not required anymore, you can use a custom report ZDELE_BUPA_HIERARCHY.
Source code is the following:

-----------------------------------------------------------------------

REPORT  zdele_bupa_hierarchy.

DATA lv_tree_guid TYPE bu_tree_guid.

PARAMETERS testrun TYPE char1 AS CHECKBOX DEFAULT 'X'.

PARAMETERS tree TYPE bu_tree_search_term.

SELECT SINGLE tree_guid FROM but_hier_tree INTO lv_tree_guid

  WHERE search_term = tree.

IF sy-subrc = 0.

  IF NOT testrun = 'X'.

    DELETE FROM but_hier_tree WHERE tree_guid = lv_tree_guid.

    DELETE FROM but_hier_tree_d WHERE tree_guid = lv_tree_guid.

    DELETE FROM but_hier_node WHERE tree_guid = lv_tree_guid.

    DELETE FROM but_hier_node_d WHERE tree_guid = lv_tree_guid.

    DELETE FROM but_hier_struct WHERE tree_guid = lv_tree_guid.

    DELETE FROM but_hier_node_bp WHERE tree_guid = lv_tree_guid.

    COMMIT WORK.

    WRITE: / 'Tree ',tree,' with GUID ',lv_tree_guid, 'was deleted.'.

  ELSE.

    WRITE: / 'Tree ',tree,' with GUID ',lv_tree_guid, 'can be deleted.'.

  ENDIF.

ENDIF.

-------------------------------------------------------------------

Please create report ZDELE_BUPA_HIERARCHY locally in the CRM server. By default, the program is started in the test mode (TESTRUN flag selected).

Please note, that this report deletes hierarchy from CRM table only, CDB tables are not changed. If condition records refer to hierarchy nodes that were deleted by the report, error messages occur.

It is also strongly not recommended to delete BP Group Hierarchies in Productive environment.

As you all know ECC and CRM system are different in many ways , Web UI , Middleware, Pricing engine, Authorization and the list goes on ... another difference which is not usually not much discussed is the post client copy processes to make the system work again . The main reason for this is Middleware . A standalone CRM  may be same as an ECC system but when CRM is linked to ECC and middleware comes into picture things start getting more complicated.

I have listed some of the most important and general tasks which should be done after the client copy.

These are generic steps there can be additional steps like availability check or Time sheet integration etc ..

Usually companies need to apply some business rules, which roles a BP (business partner) can have at the same time.

For example, a BP cannot be a headquarter” and a “branch” at the same time, or an “employee” and a “third-party” at the same time.

It is crucial to ensure such role consistency in SAP CRM. Otherwise companies risk dealing with their business partners in a proper way.

Imagine addressing prospects incorrectly with marketing campaigns just because you cannot safely identify who is a brand new prospect for your company. Marketing messages cannot reach such incorrectly addressed people. This is not good for your brand, and it can cost quite a bit money already by addressing too many “irrelevant” people.

With applying SAP note 2104189 you can now ensure BP roles being consistent. You can define BP exclusion groups, and can now use them in CRM WebClient UI.

Please note that the already available life-cycle concept cannot be used in parallel.

Now a days it is a quite common scenario to enhance the sales order with the additional custom fields which will have to flow from CRM to ECC and vice versa. There are different ways to achieve this scenario like applying the Business Transaction Events or intermediate FM calls etc.. But comparatively this will be the better approach. In this blog I am going to explain the scenario of the additional filed (AET/EEWB) flow from CRM to ECC. In next blog will publish the data flow from ECC to CRM.

   Before the implementation better to check the all relevant settings of middle ware like sales document adapter object filter, SMOF tables and Administration Console.

• Structures need to enhance by adding the additional field in the CRM
  
  

Finding the relevant structure:
  Please check the CRMD_ORDERADM_H and CRMD_ORDERADM_I to find the structure, you will find the DUMMY attribute, you will get this structure in the appending structure description. 

• Structures need to enhance by adding the additional field in the ECC 
  

            Finding the relevant structure:

               Please check the VBAK,VBAP and VBEP to find the structure, you will find the DUMMY attribute, you will get this structure in the appending structure description.

          Note : All the OZX structure has to be appended with Update flag with char 1.

• Now in CRM Side need to be implement CRM_DATAEXCHG_BADI enhancement.
             

　METHOD　if_ex_crm_dataexchg_badi~crm_dataexch_after_bapi_fill.
　
　　　　　　　　　　　　　　　　　　　　<lfs_bapishd1x>　TYPE　bapisdhd1x.
　　　　DATA　:　lwa_orderadm_h　LIKE　LINE　OF　it_bus_trans_msg-orderadm_h,
　　　　　　　　　lwa_bapirex　　　　TYPE　bapiparex,
　　　　　　　　　w_data(240)　　　　TYPE　c.
　　　　

　　　　LOOP　AT　it_bus_trans_msg-orderadm_h　INTO　lwa_orderadm_h.
　　　　　　　　CLEAR　lwa_bapirex.

　　　　　lwa_bapirex-structure　=　'BAPE_VBAK'.
　　　　　lwa_bapirex-valuepart1+0(10)　=　lwa_orderadm_h-object_id.
　　　　　lwa_bapirex-valuepart1+10( fieldlength)　=　lwa_orderadm_h-XXXXXXXXXXXX.


　　　　　APPEND　lwa_bapirex　TO　ct_bapiparex.
　　　　　CLEAR　lwa_bapirex.

　　　　　lwa_bapirex-structure　=　lc_bape_vbakx.
　　　　　lwa_bapirex-valuepart1+0(10)　=　lwa_orderadm_h-object_id.
　　　　　lwa_bapirex-valuepart1+10(1)　=　'X'.

　　　　　APPEND　lwa_bapirex　TO　ct_bapiparex.
　　　　　CLEAR　lwa_bapirex.
　　　　　　
　　　　ENDLOOP.
　　ENDMETHOD.

          Checking  the data :

                      Go to SMW01 and find the related sales order queue with name. Please check the data in extended structure, there e you will find the data in the segment.

• Now the BAPIPAREX structure to be send to ECC sales documents to the internal ECC BAPI. So this will be possible by enhancing the BADI_SD_SALESDOCU_BAPI. This enhancement triggers any time while sales order data coming from any other systems like CRM, BI/BW and any third party system. So here we can maintain 2 ways to restrict the application from the required.
                     

1. Check function module CRM0_READ_RFC_DEST. Pass the value 'CRM' to the importing parameter I_CONSUMER.
2. Check the VBKLA(3) which is equals to the CRM, where sometimes it will be over crossed  by the scenarios which are also mmaintain in the ECC also. So better to avoid this.
   
   

Method : IF_BADI_SD_SALESDOCU_BAPI~MOVE_EXTENSIONIN

IF　cs_vbakkom-vbkla(3)　=　'CRM'. // better to use by sy-uname from the CRM0_READ_RFC_DEST
　 DATA　:　lwa_bapirex　　　　TYPE　bapiparex.
　　　　　　CLEAR　:　lwa_bapirex.
      READ　TABLE　it_extensionin　INTO　lwa_bapirex　WITH　KEY　structure　=　‘BAPE_VBAK'.
　　　     IF　NOT　lwa_bapirex　IS　INITIAL.
　　　　　cs_vbakkom-XXXXXXXXX　=　lwa_bapirex-valuepart1+10(field length).
　　　　　ENDIF.
　　　　　CLEAR　:　lwa_bapirex.
　　　 READ　TABLE　it_extensionin　INTO　lwa_bapirex　WITH　KEY　structure　=　‘BAPE_VBAKX'.
　　　　　IF　NOT　lwa_bapirex　IS　INITIAL.
　　　　　cs_vbakkomx-XXXXXXXXX　=　lwa_bapirex-valuepart1+10(1).
　　　　　ENDIF.
ENDIF.

• Now this communication structure to be added to the ECC side by using sales order MV45AFZZ include.
    Here we need to check the correct location of the include like move VBAK,MOVE VBAP, MOVE VBEP or SAVE user exits inside of the include. so that we can get better performance.Else it would be bit better if we find any other BAdI or User exit for the same.
  
      IF　us_vbakkom-vbkla(3)　=　'CRM'. // // better to use by sy-uname from the CRM0_READ_RFC_DEST
  　　        IF　NOT　us_vbakkom　IS　INITIAL.
  　　　　     vbak-XXXXXXXXX=　us_vbakkom-XXXXXXX.
  　　        ENDIF.
      ENDIF.
  

I have summarized some useful tables which is used often for SAP CRM middleware, including middleware general parameter related tables, adapter object related tables, filter related tables, queue name related tables, Bdoc flow and Bdoc message related tables, load status tables and RFC related tables etc.

Useful tables for CRM Middleware

Middleware general parameter related tables:

Adapter Object related tables:

Filter related tables:

Queue Name tables:

Bdoc Type Flow related tables:

Bdoc message related tables:

Load status related tables:

RFC related tables:

DIMA related tables:

I will try to add more in the future.

Hope this helps.

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.

Customers always have requirement to improve the performance for initial/request/delta load between ERP and CRM. In order to achieve this, you could set the following parameters to make the queues being processed parallel.

Please also note the following points regarding processing the queue parallel:

* Please also increase the value of parameter MAX_PARALLEL_PROCESSES in table SMOFPARSFA of CRM system which controls the maximum number of parallel loads.

* Please note there is a maximum value 100 which prevents more queues being used. So the number of the parallel processing queues should not be larger than 100.

There are two facts that didn’t like each other too much…

Fact No. 1: Many customers merge accounts in SAP CRM; with that they use BUPA_CLEAR.

Fact No. 2: All customers enhance accounts.

A great tool for enhancing accounts is the well-known Application Enhancement Tool (AET). But so far merging of accounts that were enhanced with AET too often meant quite a big and surprising burden for the customers: Own coding was necessary to consider such enhancement also during merge.

This burden is gone now.

Just check out SAP Note 2104164 and apply it.

Actually there is not much to say about it: It is a feature that many users appreciate. Giving you an immediate context of where an account is located can help you with all the side  - but most important - tasks that are not processed by software, or stored in a data base

For example, if you travel a lot to your customers it helps you to quickly see where they are, how close to each other, and what this could mean for your travel route, or meeting schedule. Looking at a map is much clearer for doing this, instead of looking at a list.

In case you are interested in applying such functionality in SAP CRM check out SAP Note 2104728.