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.

Scenario Message Description Message 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 performa 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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Rupesh Kumar

    Hi Very helpful Blog , I wish more blogs from you in Future Specially about Master Data download also and Sales Order replication from CRM to ECC

    (0) 
  2. Dinesh Sachdeva

    Hi shanthala,

    A very helpful blog written by you again. Both of parts are very informative.

    I would appreciate your time and effort you invested in making these blogs.

    Best regards,

    Dinesh

    (0) 
  3. Kish Kumar

    Hi Shanthala,

    Very useful information. Your 2 blogs are very good and expecting more for you like this.. 🙂

    Regards

    Kishor Kumar

    (0) 
  4. Dnyanesh Joshi

    Hi Shanthala, 

    Very nice compilation.  I am also doing the initial load of CNDALL… but getting errors in SLG1. Please help on how to rectify these errors.

    SLG1 error.png

    (0) 
  5. Michael Jaeger

    Dear Shanthala,

    thank you for your excellent documentation! We have already set up the synchronization of condition records from ERP to CRM and everything is working fine. Now, we would like to start archiving condition records. Since the ERP system is the master system, we start here using the archiving object SD_COND. However, after running the deletion Job on ERP, the respective condition data is still available on the CRM System. When we now try to archive the same data on CRM side using archiving object CND_RECORD, we obtain the error message “No archiving – lack of maintenance authorization”. We opened a case at SAP but did not receive a helpful answer yet.

    Do you have any experience with archiving condition records in a setup like this?

    Many thanks,

    Michael

    (0) 
    1. Shanthala Kudva

      Hello Michael,

      Not sure whether you already found the solution for this 🙂

      To be honest, I have moved out of CRM now. What I can understand is that since condition records were maintained in ECC and downloaded later to CRM, you are getting authorisation issue while archiving in CRM.

      How about shifting the maintainence of table to CRM, if you are talking about specific table to be archived and not used/maintained in ECC?

      This requires detailed investigation in the system.

      Please share the solution, if you have already resolved this.

      Thanks and BR,

      Shanthala.

      (0) 

Leave a Reply