Quantcast
Channel: SAP CRM: Master Data & Middleware
Viewing all 62 articles
Browse latest View live

Allow several account factsheets (PDF) in the account overview page

$
0
0

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.


Navigation from view BP_DATA/AccountRelationshipsEF back to account overview not possible

$
0
0

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).

Condition Master Data Download

$
0
0

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.

 

 

ScenarioMessage DescriptionMessage Id/No:Possible Solution
Delta download of a condition record fails.

1) Make sure RFC connections are working fine. This can be tested using transaction SM59.

2)Depending on the Usage, make sure below entry corresponding to usage exist in R/3 table TBE31.

00503301        BC-MID   CRS_PRICES_COLLECT_DATA (Usage = A, Pricing)

00503302        BC-MID   CRS_LISTING_COLLECT_DATA (Usage = G, Listing & Exclusion)

00503309        BC-MID   CRS_FREEGOODS_COLLECT_DATA (Usage = N,Free goods)

00503310        BC-MID   CRS_AGREEMENTS_COLLECT_DATA (Usage = E,Rebates)

00503311        BC-MID   CRS_PRD_DET_COLLECT_DATA  (Usage = D,Mat. Determination) etc.

3) Make sure, R/3 table CRMRFCPAR has an entry like below for your  CRM RFC destination.

Consumer = CRM

ObjectName = CONDITIONS (*)

DOWNLOD = * (All load types) or D (Delta Load)

DISCARDDAT =  '  '

4) Make sure that R/3 table CRMPAROLTP, do not have an entry for:

PARNAME = CND_DELTA_SEND_AS_REQUEST

5) In CRM, check transaction CND_MAP_LOG_DISPLAY for Object = COND_EXCHANGE

Subobject = CONDITIONS for correct From/To dates.

This might give you some clues for possible errors.

6) Try to debug from R/3 by enabling System/Update debugging during condition record creation. FM: CRS_SEND_TO_SERVER

Unable to download condition object from R/3.Previous downloads were not completely finished: Termination.CND_MAP351

Delete the entry in table CND_MAPC_INF_DNL, if there exists already an

entry for the current object. This happens when previous load was aborted and CRM I/B and R/3 O/B queues were deleted manually.

Also note that, table CND_MAPC_INF_DNL is not client dependent.

During initial load of condition master data, records are not deleted properly and sometimes duplicate condition records get created. Or you observe some kind of data inconsistency between condition table, supplementary table and scale tables.

Refer SAP Note: 664815 - Check of data inconsistency in condition tables. Only when inconsistencies are removed, initial or delta load works correctly for that condition table.

Trying to change an existing condition record in R/3 using transaction VK12. But in CRM, update fails with error message in log saying:

Error when reading scale table *VO1 for application CRM and usage PR.

Errors when deleting data records for VARKEY

Error converting scale levels; KNUMH

SAP Note: 664815 should be followed to check and remove the data inconsistency.

This type of inconsistency happens when scale data is missing in table CNLCRMPRSCALEV01 but present in other scale tables like CNLCRMPRSCALEDIM

CNLCRMPRSCALEDEF

CNLCRMPRSCALEEVL etc.

Perform a request  for a particular KNUMH and make sure that scale data exists in all 4 tables related to scale.

Even after request load, entry is missing in scale table CNLCRMPRSCALEV01 but present in other scale tables, then it happens due to incorrect data maintenance in R/3.

One such scenario which I have come across is not maintaining field 'Scale Currency' in R/3 table KONP.

Request/Initial/Delta load do not bring down condition record to CRM.

Field content <BP-ID> from field KUNNR could not be converted.

Field content <ORG> from field VKORG could not be converted.

Field content <MATNR> from field MATNR could not be converted.

Message no. CND_MAP325

Error in conversion of field contents, KNUMH yyyyyy not converted

Message no. CND_MAP303

CND_MAP325

CND_MAP303

Make sure that master data like materials, BPs, Sales Org have been downloaded before trying to bring down the condition records for them.

SAP Note:877842 - Initial Download does not download all the records to CRM.

 

Sometimes it may happen that, when you are trying to create a material/article in R/3 followed by maintaining a condition record for that material/article. But in CRM, since these 2 are sent 2 different queues, it may happen that condition queue gets processed before material queue and hence resulting in an error message in logs.

This can be influenced using SAP Note:658272 - Condition download occurs before Article download.

You have defined a request load based on KNUMH to download some condition records. But request load brings down no data to CRM.

Bdoc CND_M_SUP is empty.

Make sure that KNUMH is complete during request definition. Meaning leading zeros for KNUMH should not be omitted.

Also, filtering is possible only on table key fields apart from KNUMH.

SAP Note: 454010 - Plug in development for request download extractors, can be referred here.

You create a DIMa instance to compare data between R/3 and CRM, for a customer specific condition table. But this results in queue failure.

SYSFAIL in CRM outbound queue  (R3AT_<DIMa_Instance>) saying

'DIMa instance could not be started'.

In trasnaction SDIMA_BASIC, make sure that DIMa object points to correct object name,

which should be present in transaction R3AC5. If not, correct the object name as per entry present in R3AC5 for that condition table.

Request download deletes condition records which were Inserted from the previous block with the same key fields but different Timestamps.

Change the Blocksize for condition object in R3AC5, so that blocksize value is higher than number of records for a VAKEY combination. This would avoid, condition records having same VAKEY combination falling across 2 different blocks, resulting in deletion of condition records having same VAKEY, which were inserted during previous block.

Error message in logs saying:

Deletion not possible./1CN/CCBCUSXXX is still in use in access

sequences.

Object CNCCRMPRCUSXXX or CNCCRMPRCUSYYY is still referenced to

object [CRM, PR, ZZZZ].

CND_MAP2  52

CND_MAP2  56

This type of error comes generally when table is getting deleted but unable to delete since table is still used by some access sequence. Hence before trying to delete the table, de-associate the mentioned table from access sequence and then try to delete the table.
Following steps can be followed:
- Delete the condition tables from access sequence ZZZZ.
- Now you can run report /SAPCND/RV12N001 for the relevant table,
for example CNCCRMPRCUSXXX with following data:

Application     CRM
Usage            PR
Table Number CUSXXX

Selection of objects to be deleted --> Flag all the checkboxes.

- Once the condition table has been deleted, you can download the new pricing customizing.

Error message in logs saying:There is no entry in the object directory (TADIR) for R3TR.....

The message could be raising because of the incorrect filter settings.

You should not delete the standard filter settings. Deletion of standard filter settings could lead to these kind of warning and error messages.

Make sure that all the standard filters are maintained in your adapter object in CRM.

During listing download, you observe this message in logs saying:

'No PPR type could be determined for appl. CRM and condition table SAPXXX'.

Split of VAKEY fields failed (Block 1; Appl. LI; Use CRM)

Below customizing needs to be checked:

SPRO --> IMG-->CRM --> Master data --> Listing --> Settings for Listings -->

Partner/Product Range settings for Listing Items and Assortments- ->

Define Partner/Product Range Types for Listings and Assortments and also check Define Access to Partner/Product Range

Maintaining the correct customizing should solve the issue.

You are trying to run DIMa instance in CRM using transaction SDIMA.Values for field KWAEH in additional table differ.

Check SAP Note: 1351981 - SDIMa issue with compare of condition data.
1540717 - KWAEH Field error when comparing condition data using DIMA.
1659290 - Condition data DIMA errors for fields KWAEH and SUPP_EXIST.
1826986 - DIMA error for SUPP_EXIST field.

1927543 - DIMA errors with MXKBAS and SUPP_EXIST fields

exists in your system. If not, then try to implement them.

Initial download of condition object DNL_COND_A011  fails.

'There may be dump in ST22 saying,

Error in mass insert in table CNCCRMPRSAP011.

SAP Note: 720114 - Initial download of condition object DNL_COND_A011 fails can be referred here.

Error message in logs saying:'Filter option set for field xxxxxx, table yyyyy in object  XYZ is not supported'

You need to check the filter settings for condition object in transation R3AC5.

Operator 'BT' (between) is not supported. It is recommended to use as evident from the long text of the message, only option 'Equal' and sign 'Inclusive' .

Not all records from condition table gets downloaded from R/3 to CRM.

Check the filter settings in transaction R3AC5 for that condition object.

Also, make sure that in R3AC5,  under the tab 'Mapping Modules:R/3 to CRM',

mapping module has been registered only once. Sometimes, double entry of this module exists, resulting in abnormal behaviour.

You have queries related to authorization concept for displaying/editing condition records.

SAP Note: 1853382 - Level of authorization checks cannot be maintained in downloaded pricing procedures,

SAP Note: 1166349 - Authorization check as of AP 7.00 , can be referred.

You are unable to archive the condition records for table, which is

maintained in CRM.

This is the standard behaviour. In CRM, condition records can be archived for table which are maintained in CRM. For R/3 maintained condition records, archiving should be performed in R/3 and should trigger an initial download to sync the data with CRM.

This check is performed using BAdI: /SAPCND/MNT_CHECK

You observe that some of the condition records are missing in CRM.You can perform a request load from CRM, for missing KNUMHs.
Condition records are not flowing into CDB or R/3.

Please make sure that you have not stopped the Bdoc flow in the following customizing:

SPRO-->IMG-->CRM-->CRM Middlware and Related Components-->Message Flow Setup

-->Bdoc Type Customizing. Make sure that for Bdoc Type 'CND_M_SUP', 'Do Not Send' is unchecked.

During condition master data download, SYSFAIL in CRM I/B queue saying:

"Message number 999999. Log is full"

"Message number 999999 is reached"

Sometimes, it may happen that there are too many logs
already in the system and might reach an overflow point wherein the application log cannot hold any more messages.

  1. Check table CND_MAPC_INF_DNL for OBJNAME = DNL_COND_AXXX or ZNL_COND_AXXX.
    Take a note of the REF_ID.
  2. Go to transaction SLG2. Under 'Expiry date' block, select
    option ‘Only logs which can be deleted before the expiry date'.

Under 'Selection Conditions' block, specify the following:

Object = COND_EXCHANGE, Sub object = CONDITIONS, External ID = REF_ID copied from step 1.Under 'Options' block, select 'Create List' and Execute.

 

A log will be displayed, which you can select and then
delete it.

 

Please note that table CND_MAPC_INF_DNL is filled only
temporarily with data during the exchange.

You can skip entering value in field External ID, in case no
entries exist in table CND_MAPC_INF_DNL.

 

SAP Note: 195157 - Application log: Deletion of logs, can be referred here.

 

 

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.

How to resolve issue: Hyperlink for target group is not working in DQA task

$
0
0

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:
    2-6-2015 4-07-05 PM.png

 

Please also refer to my KBA:

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

 

 

Related SAP component: CRM-MD-DQA

Condition Master Data Download

$
0
0

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.

 

 

ScenarioMessage DescriptionMessage Id/No:Possible Solution
Delta download of a condition record fails.

1) Make sure RFC connections are working fine. This can be tested using transaction SM59.

2)Depending on the Usage, make sure below entry corresponding to usage exist in R/3 table TBE31.

00503301        BC-MID   CRS_PRICES_COLLECT_DATA (Usage = A, Pricing)

00503302        BC-MID   CRS_LISTING_COLLECT_DATA (Usage = G, Listing & Exclusion)

00503309        BC-MID   CRS_FREEGOODS_COLLECT_DATA (Usage = N,Free goods)

00503310        BC-MID   CRS_AGREEMENTS_COLLECT_DATA (Usage = E,Rebates)

00503311        BC-MID   CRS_PRD_DET_COLLECT_DATA  (Usage = D,Mat. Determination) etc.

3) Make sure, R/3 table CRMRFCPAR has an entry like below for your  CRM RFC destination.

Consumer = CRM

ObjectName = CONDITIONS (*)

DOWNLOD = * (All load types) or D (Delta Load)

DISCARDDAT =  '  '

4) Make sure that R/3 table CRMPAROLTP, do not have an entry for:

PARNAME = CND_DELTA_SEND_AS_REQUEST

5) In CRM, check transaction CND_MAP_LOG_DISPLAY for Object = COND_EXCHANGE

Subobject = CONDITIONS for correct From/To dates.

This might give you some clues for possible errors.

6) Try to debug from R/3 by enabling System/Update debugging during condition record creation. FM: CRS_SEND_TO_SERVER

Unable to download condition object from R/3.Previous downloads were not completely finished: Termination.CND_MAP351

Delete the entry in table CND_MAPC_INF_DNL, if there exists already an

entry for the current object. This happens when previous load was aborted and CRM I/B and R/3 O/B queues were deleted manually.

Also note that, table CND_MAPC_INF_DNL is not client dependent.

During initial load of condition master data, records are not deleted properly and sometimes duplicate condition records get created. Or you observe some kind of data inconsistency between condition table, supplementary table and scale tables.

Refer SAP Note: 664815 - Check of data inconsistency in condition tables. Only when inconsistencies are removed, initial or delta load works correctly for that condition table.

Trying to change an existing condition record in R/3 using transaction VK12. But in CRM, update fails with error message in log saying:

Error when reading scale table *VO1 for application CRM and usage PR.

Errors when deleting data records for VARKEY

Error converting scale levels; KNUMH

SAP Note: 664815 should be followed to check and remove the data inconsistency.

This type of inconsistency happens when scale data is missing in table CNLCRMPRSCALEV01 but present in other scale tables like CNLCRMPRSCALEDIM

CNLCRMPRSCALEDEF

CNLCRMPRSCALEEVL etc.

Perform a request  for a particular KNUMH and make sure that scale data exists in all 4 tables related to scale.

Even after request load, entry is missing in scale table CNLCRMPRSCALEV01 but present in other scale tables, then it happens due to incorrect data maintenance in R/3.

One such scenario which I have come across is not maintaining field 'Scale Currency' in R/3 table KONP.

Request/Initial/Delta load do not bring down condition record to CRM.

Field content <BP-ID> from field KUNNR could not be converted.

Field content <ORG> from field VKORG could not be converted.

Field content <MATNR> from field MATNR could not be converted.

Message no. CND_MAP325

Error in conversion of field contents, KNUMH yyyyyy not converted

Message no. CND_MAP303

CND_MAP325

CND_MAP303

Make sure that master data like materials, BPs, Sales Org have been downloaded before trying to bring down the condition records for them.

SAP Note:877842 - Initial Download does not download all the records to CRM.

 

Sometimes it may happen that, when you are trying to create a material/article in R/3 followed by maintaining a condition record for that material/article. But in CRM, since these 2 are sent 2 different queues, it may happen that condition queue gets processed before material queue and hence resulting in an error message in logs.

This can be influenced using SAP Note:658272 - Condition download occurs before Article download.

You have defined a request load based on KNUMH to download some condition records. But request load brings down no data to CRM.

Bdoc CND_M_SUP is empty.

Make sure that KNUMH is complete during request definition. Meaning leading zeros for KNUMH should not be omitted.

Also, filtering is possible only on table key fields apart from KNUMH.

SAP Note: 454010 - Plug in development for request download extractors, can be referred here.

You create a DIMa instance to compare data between R/3 and CRM, for a customer specific condition table. But this results in queue failure.

SYSFAIL in CRM outbound queue  (R3AT_<DIMa_Instance>) saying

'DIMa instance could not be started'.

In trasnaction SDIMA_BASIC, make sure that DIMa object points to correct object name,

which should be present in transaction R3AC5. If not, correct the object name as per entry present in R3AC5 for that condition table.

Request download deletes condition records which were Inserted from the previous block with the same key fields but different Timestamps.

Change the Blocksize for condition object in R3AC5, so that blocksize value is higher than number of records for a VAKEY combination. This would avoid, condition records having same VAKEY combination falling across 2 different blocks, resulting in deletion of condition records having same VAKEY, which were inserted during previous block.

Error message in logs saying:

Deletion not possible./1CN/CCBCUSXXX is still in use in access

sequences.

Object CNCCRMPRCUSXXX or CNCCRMPRCUSYYY is still referenced to

object [CRM, PR, ZZZZ].

CND_MAP2  52

CND_MAP2  56

This type of error comes generally when table is getting deleted but unable to delete since table is still used by some access sequence. Hence before trying to delete the table, de-associate the mentioned table from access sequence and then try to delete the table.
Following steps can be followed:
- Delete the condition tables from access sequence ZZZZ.
- Now you can run report /SAPCND/RV12N001 for the relevant table,
for example CNCCRMPRCUSXXX with following data:

Application     CRM
Usage            PR
Table Number CUSXXX

Selection of objects to be deleted --> Flag all the checkboxes.

- Once the condition table has been deleted, you can download the new pricing customizing.

Error message in logs saying:There is no entry in the object directory (TADIR) for R3TR.....

The message could be raising because of the incorrect filter settings.

You should not delete the standard filter settings. Deletion of standard filter settings could lead to these kind of warning and error messages.

Make sure that all the standard filters are maintained in your adapter object in CRM.

During listing download, you observe this message in logs saying:

'No PPR type could be determined for appl. CRM and condition table SAPXXX'.

Split of VAKEY fields failed (Block 1; Appl. LI; Use CRM)

Below customizing needs to be checked:

SPRO --> IMG-->CRM --> Master data --> Listing --> Settings for Listings -->

Partner/Product Range settings for Listing Items and Assortments- ->

Define Partner/Product Range Types for Listings and Assortments and also check Define Access to Partner/Product Range

Maintaining the correct customizing should solve the issue.

You are trying to run DIMa instance in CRM using transaction SDIMA.Values for field KWAEH in additional table differ.

Check SAP Note: 1351981 - SDIMa issue with compare of condition data.
1540717 - KWAEH Field error when comparing condition data using DIMA.
1659290 - Condition data DIMA errors for fields KWAEH and SUPP_EXIST.
1826986 - DIMA error for SUPP_EXIST field.

1927543 - DIMA errors with MXKBAS and SUPP_EXIST fields

exists in your system. If not, then try to implement them.

Initial download of condition object DNL_COND_A011  fails.

'There may be dump in ST22 saying,

Error in mass insert in table CNCCRMPRSAP011.

SAP Note: 720114 - Initial download of condition object DNL_COND_A011 fails can be referred here.

Error message in logs saying:'Filter option set for field xxxxxx, table yyyyy in object  XYZ is not supported'

You need to check the filter settings for condition object in transation R3AC5.

Operator 'BT' (between) is not supported. It is recommended to use as evident from the long text of the message, only option 'Equal' and sign 'Inclusive' .

Not all records from condition table gets downloaded from R/3 to CRM.

Check the filter settings in transaction R3AC5 for that condition object.

Also, make sure that in R3AC5,  under the tab 'Mapping Modules:R/3 to CRM',

mapping module has been registered only once. Sometimes, double entry of this module exists, resulting in abnormal behaviour.

You have queries related to authorization concept for displaying/editing condition records.

SAP Note: 1853382 - Level of authorization checks cannot be maintained in downloaded pricing procedures,

SAP Note: 1166349 - Authorization check as of AP 7.00 , can be referred.

You are unable to archive the condition records for table, which is

maintained in CRM.

This is the standard behaviour. In CRM, condition records can be archived for table which are maintained in CRM. For R/3 maintained condition records, archiving should be performed in R/3 and should trigger an initial download to sync the data with CRM.

This check is performed using BAdI: /SAPCND/MNT_CHECK

You observe that some of the condition records are missing in CRM.You can perform a request load from CRM, for missing KNUMHs.
Condition records are not flowing into CDB or R/3.

Please make sure that you have not stopped the Bdoc flow in the following customizing:

SPRO-->IMG-->CRM-->CRM Middlware and Related Components-->Message Flow Setup

-->Bdoc Type Customizing. Make sure that for Bdoc Type 'CND_M_SUP', 'Do Not Send' is unchecked.

During condition master data download, SYSFAIL in CRM I/B queue saying:

"Message number 999999. Log is full"

"Message number 999999 is reached"

Sometimes, it may happen that there are too many logs
already in the system and might reach an overflow point wherein the application log cannot hold any more messages.

  1. Check table CND_MAPC_INF_DNL for OBJNAME = DNL_COND_AXXX or ZNL_COND_AXXX.
    Take a note of the REF_ID.
  2. Go to transaction SLG2. Under 'Expiry date' block, select
    option ‘Only logs which can be deleted before the expiry date'.

Under 'Selection Conditions' block, specify the following:

Object = COND_EXCHANGE, Sub object = CONDITIONS, External ID = REF_ID copied from step 1.Under 'Options' block, select 'Create List' and Execute.

 

A log will be displayed, which you can select and then
delete it.

 

Please note that table CND_MAPC_INF_DNL is filled only
temporarily with data during the exchange.

You can skip entering value in field External ID, in case no
entries exist in table CND_MAPC_INF_DNL.

 

SAP Note: 195157 - Application log: Deletion of logs, can be referred here.

 

 

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.

Activate Delta Load of ERP Customer Hierarchies to SAP CRM

$
0
0

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


Capture.PNG


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


Hope it helps.

Dean Yan

The settings about download of object CUST_MAT_INFO from ERP to CRM

$
0
0

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.

cust_mat_info.png

 

      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.

Partner function deletion issue

$
0
0

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.

sdima.png

 

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


Configurable data retrieval parameters: Good, but...

$
0
0

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.

Ever suffered from obsolete contact data records in SAP CRM?

$
0
0

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.

 

 

Merge account - Communication data

$
0
0

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.

How to delete Account Hierarchies - custom report

$
0
0

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.

Middleware configurations after client copy

$
0
0

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.

 

NoTasksT-codeSystemComments
1Change OLTP LOGSYS from PRD to QASBDLSCRM
2Change CRM LOGSYS from PRD to QASBDLSCRM
3Change OLTP LOGSYS  from PRD to QASBDLSECC
4Activating Status ReportingSMWPCRM
5Generating Filter Modules in Client CopiesGNRWPCRM
6Checking Table CRMCONSUM (SAP ERP)SM30 and SE16NECC
7Maintaining Table CRMRFCPAR (SAP ERP)SM30 and SE16NECC
8Maintaining Table CRMPAROLTP (SAP ERP)SM30 and SE16NECC
9Activating Event Control (SAP ERP)SM30 and SE16NECC
10Get the RFC user and RFc destination for CRM and ECC systemSM59 , SU01ECC,CRM
11Test the RFC connectivity with ECC using the RFC user and check the Authorizations

SM59,SU01

ECC,CRM
12Change Site for OLTPSMOEACCRM
13Creating Subscriptions for OLTPSMOEACCRMNot required all the times
14Setting for Trusted Systems (SMT1)SMT1ECC
15Correct RFC destinationR3AC4CRMFor delta download activation
16Check ECC  table, Table TBE31ECC
17Define Profiles for ERP Sales Transactions --> Change/correct RFC destinationsCRM
RFC destination setup
SPRO->CRM->Transactions->Setting for Service Transactions->Integration->Set up Time Sheet and  Controlling Integration
18Maintain Logical System Mapping for Transaction Launcher (BD97)BD97CRM
19Define URL and Parameters for ITS on Target ECC System (CRMS_IC_CROSS_SYS)CRMS_IC_CROSS_SYSCRM

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

Headaches with BP role consistency?

$
0
0

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.

Sales Order Custom Field Mapping from CRM to ECC

$
0
0

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

Sales Order Container

Structure of the table

Header

BAPE_VBAK

Item

BAPE_VBAP

Line Item

BAPE_VBEP

 

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 

Sales Order Container

Structure of the table

Update Structure of the table

Header

VBAKOZ

VBAKOZX

Item

VBAPOZ

VBAPOZX

Line Item

VBEPOZ

VBEPOZX


           
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.



Useful tables for CRM Middleware

$
0
0

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:

 

Table nameSystemDescription

SMOFPARSFA

CRM

General middleware parameters

SMOF_ERPSH

CRM

ERP-Site Header table

CRMPAROLTP

ERP

CRM OLTP Parameters

CRMCONSUM

ERP

CRM consumer

CRMRFCPAR

ERP

Definitions for RFC Connections

 

Adapter Object related tables:

 

Table nameSystemDescription
SMOFTABLESCRMFinding the Adapter Object Involved

SMOFOBJECT

CRM

Download Objects

SMOFINICONCRMFlow Contexts in Initial Download depending on Site Types
CRMOBJECTERPDownload Objects
CRMSUBTABERP

Generic Extractor for Objects

CRMATABERPTables Permitted for Customizing Download
CRMOBJTABERPTables Belonging to One Object
CRMMAPTABERPRelationship Between Table Names in CRMOBJTAB and BAPIMTCS
CRMINTBAPERPAssignment of Internal and External Table Fields

 

 

Filter related tables:

 

Table nameSystemDescription

SMOFFILFLD

CRM

The predefined fields for filter

SMOFFILTAB

CRM

Filter settings

CRMFILTAB

ERP

Filter settings

 

 

Queue Name tables:

 

Table nameSystemDescription
SMOFQFINDCRMQueue Name setting

CRMQNAMES

ERP

Queue Name setting

 

 

Bdoc Type Flow related tables:

 

Table nameSystemDescription

SMW3BDOCIF

CRM

BDoc Type Specific Flow Attributes (Validation service)

SMW3FDSTD

CRM

Flow: Standard Configuration

SMW3FDBDOC

CRM

BDoc Type Specific Flow

SMW3FDCUSTCRMCustomer-Specific Flow

 

 

Bdoc message related tables:

 

Table nameSystemDescription
SMW3_BDOCCRM

BDoc Message Store: Header

SMW3_BDOC1

CRM

BDoc Message Store: Message Body (classic  part)

SMW3_BDOC2

CRMBDoc Message Store: Message Body (extension part)
SMW3_BDOC4CRMBDoc: Validation Errors
SMW3_BDOC5CRMBDoc: Receivers with state
SMW3_BDOC6CRMBDoc: Receiver specific error segments
SMW3_BDOC7CRMBDoc: Receiver Root IDs
SMW3_BDOCQCRMqRFC Queues in use by BDoc Message

 

 

Load status related tables:

 

Table nameSystemDescription

SMOFDSTAT

CRM

Initial load monitoring - Current Download Status of Objects

SMOFRSTAT

CRM

Request load monitoring - Current Download Status of Objects

SDIMASTAT

CRM

Dima load monitoring - Current Download Status of Objects

 

 

RFC related tables:

 

Table nameSystemDescription

ARFCSSTATE

CRM,ERP

Description of ARFC Call Status (Send)

ARFCSDATA

CRM,ERP

ARFC Call Data (Callers)

TRFCQSTATE

CRM,ERP

Description of qRFC Call Conditions (Inbound Queue)

TRFCQDATACRM,ERPqRFC Call Data (Inbound Queue)
TRFCQOUTCRM,ERPtRFC Queue Description (Outbound Queue)
TRFCQINCRM,ERPtRFC Queue Description (Inbound Queue)


DIMA related tables:

 

Table nameSystemDescription

SDIMABASIC

CRM

Basic Information for DIMA

SDIMAHEAD

CRM

Header Data of Dima

SDIMASTAT

CRM

Dima load monitoring - Current Download Status of Objects

SDIMAMESSCRMMessages for DIMA
SDIMADETCRMDIMA Filter conditions
SDIMAFILTCRMAllowed Filters for DIMA

 

I will try to add more in the future.

Hope this helps.

BP- CUSTOMER MASTER DATA REPLICATION FROM ECC TO CRM

$
0
0

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)

1.PNG

Click on MORE data…

2.PNG

3.PNG

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.

4.PNG

Step 2:

In CRM- SMQ2 ( Tcode)

Open the inbound Quee –

5.PNG

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

6.PNG

Just double click on it..

7.PNG

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

Place the breakpoint in the INBOUND Quee FM

8.PNG

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

9.PNG

In DATA field-

10.PNG

In DATAX field-

11.PNG

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

 

12.PNG

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’.

 

 

13.PNG

 

Step 2:

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

14.PNG 

Step 3:

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

15.PNG

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).


16.PNG

In ECC

17.PNG

In CRM

18.PNG

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:

19.PNG

In CRM:

20.PNG

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


21.PNG

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.

Useful parameters to parallelize queue processing

$
0
0

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.

 

 

Load typeParameterNote
Initial load

Maintain the parameter in table CRMPAROLTP of ERP system via SM30:

 

Parameter name:    CRM_MAX_QUEUE_NUMBER_INITIAL

Parameter name 2:  <object name>

Parameter name 3:

Consumer/user:          CRM,  CDB or EXT (R/3 backend or external system)

Parval1:           <the number of the parallel processing queues>

Parval2:

Note 350176
Request load

Maintain the parameter in table CRMPAROLTP of ERP system via SM30:

 

Parameter name:    CRM_MAX_NO_QUEUES_PER_REQUEST

Parameter name 2:  <object name>

Parameter name 3:

Consumer/user:          CRM,  CDB or EXT (R/3 backend or external system)

Parval1:           <the number of the parallel processing queues>

Parval2:

Note 426159
Delta load

Maintain the following parameter and the parameter CRM_MAX_QUEUE_NUMBER_DELTAin table CRMPAROLTP simultaneously.

 

Parameter name:    CRM_IN_EQUAL_OUT_QUEUE

Parameter name 2:  <object name>

Parameter name 3:

Consumer/user:          CRM,  CDB or EXT (R/3 backend or external system)

Parval1:                    X

Parval2:

 

For a serialization of the delta load of an R/3 back end to the CRM server, the parameter is entered in the R/3 back end. For a serialization of the delta load from the CRM server, the parameter is entered in the CRM server.

Note 624436
Dima

Maintain the following parameter and the parameter

CRM_MAX_QUEUE_NUMBER_DIMA in table CRMPAROLTP of ECC system simultaneously.


Parameter name:    CRM_IN_EQUAL_OUT_QUEUE

Parameter name 2:  <object name>

Parameter name 3:

Consumer/user:          CRM,  CDB or EXT (R/3 backend or external system)

Parval1:                    X

Parval2:

Note 628949

 

 

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.

No need to implement own coding when merging accounts enhanced with the Application Enhancement Tool (AET)

$
0
0

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.

View accounts in search result list on a map

$
0
0

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.

Viewing all 62 articles
Browse latest View live