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

[luis_riveragallego]

In CRM systems connected to an ERP backend, pricing must usually be executed in both systems and give the same results. For this purpose, the condition tables that already exist in the ERP system must be mapped to CRM condition tables, which will usually have different names for the variable key fields but for which there must be a one to one correspondence between ERP and CRM fields. The steps to be performed for the mapping of condition tables are explained in note :

514952  Download of customer-specific tables

The steps in the note must be performed for all customer fields present in condition tables – given that we need the condition tables for CRM pricing – and also for some ERP standard fields for which there is no standard mapping ( as we will see in our example with field KUNAG).

The steps in note 514952 are pretty clear but.. what happens in case you have made a mistake in one of the steps of the note? In case you forget to map a certain field of the table in view V_CND_MAP_CNVFLD it would not be a big problem as the table will not be generated in CRM. You add the mapping, execute the download of adapter object DNL_CUST_CNDALL again and, given that all the steps of the note are fulfilled, the condition table will be generated

However the problem is more complex in case you have fulfilled all the steps in the note, but you have entered a wrong condition table field name in V_CND_MAP_CNVFLD or a wrong data element for a condition table field in the CRM field catalogue.

What can you do if you detect this kind of mistake after the condition table has been generated?

How can you delete the table? And what about other tables that could have been generated too because of that mapping? This is what this blog is about. For this purpose I add here a sample case. I do not intend to cover all the possibilities, but the case is complex enough to give you ideas for similar situations.

After a description of the problem, I add an overview of the steps to solve it, which could be enough for some of you in case you face a similar issue. However if you encounter problems while implementing the steps, you may find some useful hints in the following section which contains the detailed steps.

Description of the problem

In the sample case explained here, a wrong data element had been introduced in the CRM field catalogue, and the condition table had been generated, but it contained a Z field with a wrong data element

The initial situation was:

a) Mappings from note 514952 had been done in CRM between R3 field KUNAG and CRM field ZZ_SOLD_TO_PARTY, which should enable the generation of the condition table that corresponds to ERP condition table A386  

b) After initial download of condition customizing, DNL_CUST_CNDALL, condition table CNCCRMPRSAP386 had been generated in CRM.

c) Condition table CNCCRMPRSAP386 was created but field ZZ_SOLD_TO_PARTY had a wrong data element  ( the data element that was selected when the field was created in the product catalog)

 

The data element could not be changed in the field catalog, as the input for it was disabled for the saved fields.

 

d) Several access sequences existed in ERP which contain one access to the condition table A386 . The access sequences had been downloaded to CRM

Sample access sequence

 

e) No condition records had been downloaded to the table CNCCRMPRSAP386 , as I had detected the problem before downloading adapter object DNL_COND_A386.

Main issues encountered in the process and solutions

The data element could not be changed directly in the field catalogue. Therefore it was necessary to delete field ZZ_SOLD_TO_PARTY from the field catalogue. However for the deletion of the field I had to previously delete the condition tables that contain this field and delete the field from the access sequences that had been generated in the download.

-- For the deletion of the condition tables, I had to use report /SAPCND/RV12N001 

-- For the deletion of the field from the access sequences, I had to delete the field mapping for field ZZ_SOLD_TO_PARTY and execute the initial download of condition customizing

Overview of the steps

STEP 1)

I checked in CRM table /SAPCND/T681E all the active tables that had been

generated with field ZZ_SOLD_TO_PARTY  . For this I filtered with FIELDNAME_ID = ZZ_SOLD_TO_PARTY) and field AS4LOCAL = A ( active)

STEP 2)

In this case all of the condition tables seen before did not contain any condition records. If this had not been the case, then all the master data would need to be deleted from the condition tables before going to the next step. However for this particular example this was not necessary.

If master data is present in the condition table, you must consider that the data must be deleted from the CNCCRMPR* table and all dependent tables, including supplementary tables and the entries in table CND_MAPM_CNV_REC that are linked to our condition table  

STEP 3)

I deleted all the condition tables that I  had seen before as active

(AS4LOCAL = A) . For this I executed report /SAPCND/RV12N001, once for each table

entering

Application                       CRM

Usage                               PR

Table Number                  SAPXXX    ( or CUSXXX for customer tables)

Selection of objects to be generated   > Do NOT mark anything in this

section

Selection of objects to be deleted    Mark everything in this section

In the result of the report execution not all the errors are relevant. However errors are specially relevant if they indicate that there are condition records in the table. As mentioned before, if the table contains condition records it cannot be deleted.

 As a double-check I went to transaction SE11 to verify if the tables existed or not.

Names of the condition tables to be entered there must be in the format CNCCRMPRSAPXXX or CNCCRMPRCUSXXX, where XXX is the table number.

The tables had been properly deleted by the report

STEP 4)

  I deleted the field mapping for the relevant field, ZZ_SOLD_TO_PARTY, in view

V_CND_MAP_CNVFLD.

 This was necessary so that field ZZ_SOLD_TO_PARTY could get deleted from the access sequences in the next customizing download ( and also to avoid a regeneration of the condition tables with wrong(old) data) . See next step

STEP 5)

 I executed the initial download of DNL_CUST_CNDALL.

Asthe relevant field ZZ_SOLD_TO_PARTY was not mapped anymore, this customizing download deleted the field from the accesses in CRM ( access sequence customizing)

STEP 6)

 At this point I could delete the field ZZ_SOLD_TO_PARTY from the field catalog. There were no

errors related to access sequences or condition tables using such field

 In the field catalog I had to press button generate to ensure the deletion of field ZZ_SOLD_TO_PARTY from the access structures

STEP 7)

   At this point I could go over the steps in note 514952  and redo again everything:

I created a new field ZZ_SOLD_TO_PARTY in the catalog with the correct data element

I added the mapping in V_CND_MAP_CNVFLD

I kept the old value in structure CND_MAPT_ACS_REM_CUST

I executed initial download of DNL_CUST_CNDALL.

I checked in SE11 that Condition table CNCCRMPRSAP386 had been  generated with the correct data element for ZZ_SOLD_TO_PARTY, as expected

NOTE

The sample case explained here refers to pricing condition tables. If we have other usages different from pricing, the condition table names would be different and we would need to select another usage while deleting the condition table, but the main concepts would be the same.

Detailed steps

STEP 1)

I checked all the active tables that had been generated with field ZZ_SOLD_TO_PARTY . For this purpose I went to CRM table /SAPCND/T681E and filtered with FIELDNAME_ID = ZZ_SOLD_TO_PARTY) and field AS4LOCAL = A ( active)

 The tables in this sample case were:

SAP386 

CUS901

CUS907

CUS909

STEP 2)

In this case all of the condition tables seen before did not contain any condition records, because I detected the problem of the data element as soon as the table was generated and I did not perform the initial download of the condition table master data ( objects DNL_COND_XXXX or corresponding Z objects ). If this had not been the case, then all the master data would need to be deleted from the condition tables before going to the next step. However for this particular example this was not necessary.

STEP 3)

I deleted all the condition tables that I had seen before as active

(AS4LOCAL = A) . For this I executed report /SAPCND/RV12N001  ,once for each table

entering

Application                       CRM

Usage                               PR

Table Number                  SAPXXX    ( or CUSXXX for customer tables)

Selection of objects to be generated   > Do NOT mark anything in this

section

Selection of objects to be deleted    Mark everything in this section

Example for table CNCCRMPRSAP386

 

 

 After the previous steps table CNCCRMPRSAP386 was not active in the data dictionary any more

 

In my first approach to the problem I attempted to delete the field ZZ_SOLD_TO_PARTY just after the deletion of condition table CNCCRMPRSAP386 ( before deleting any other condition table). But there was an error while trying to delete the field:

 “ZZ_SOLD_TO_PARTY condition tables already exist for field 3”

 

The reason for the previous error in the field catalogue is that there were still 3 active tables containing field ZZ_SOLD_TO_PARTY. As explained before I could find those tables in table /SAPCND/T681E, by filtering with FIELDNAME_ID = ZZ_SOLD_TO_PARTY and AS4LOCAL = A ( active tables)

 

Therefore I should follow similar steps to delete condition tables

CUS901

CUS907

CUS909

 

STEP 4)

After I had deleted all the active condition tables that contained field ZZ_SOLD_TO_PARTY I tried to delete the field from the field catalogue

There were no errors related to the condition tables but there was an error:

/SAPCND/CUSTOMIZING414
“Field ZZ_SOLD_TO_PARTY is already used in 8 access sequences.”

 

Just for your information, If you want to find the access sequences that contain a certain table field you can do the following:
 -- In table /SAPCND/T681E we can check the condition tables that contain a certain field
-- In table /SAPCND/T682I  we can check the access sequences that contain a certain condition table

Then  I deleted the field mapping for the relevant field, ZZ_SOLD_TO_PARTY, in view

V_CND_MAP_CNVFLD.

 This was necessary so that field ZZ_SOLD_TO_PARTY gets deleted from the access sequences in the next customizing download   
(Furthermore, if we do not delete the mapping the condition tables would be regenerated in the next customizing download with the wrong(old) data element again !!) .

View V_CND_MAP_CNVFLD before deletion of ZZ_SOLD_TO_PARTY:

 

View V_CND_MAP_CNVFLD after deletion of ZZ_SOLD_TO_PARTY:

  

STEP 5)

 I executed the initial download of DNL_CUST_CNDALL. There were no errors related to this field in SLG1 log (object object COND_EXCHANGE, subobject COND_EXCHANGE) 

As the relevant field ZZ_SOLD_TO_PARTY was not mapped anymore, this customizing download deleted the field from the accesses in CRM ( access sequence customizing)

After initial download of DNL_CUST_CNDALL I could see that field did not appear in the accesses in CRM.

In the figure we see a sample access sequence

I also checked that the condition tables that contained ZZ_SOLD_TO_PARTY remained inactive, as expected. We can see that in table /SAPCND/T681, where we can see that the inactive tables have field AS4LOCAL = blank. Or alternatively, we can go to the data dictionary and see that the tables with names CNCCRMPRSAPXXX or CNCCRMPRCUSXXX do not exist

  

STEP 6)

 At this point I could delete the field ZZ_SOLD_TO_PARTY from the field catalog. There were no

errors related to access sequences or condition tables using such field

Before deletion

 

After deletion

 

However even after deletion of the field in the field catalogue, the structure used in the access to the header fields in access sequence customizing, CRMT_ACS_H_SEL, still contained the field ZZ_SOLD_TO_PARTY.

 

Then I pressed button "Generate" ( button displayed as red and white ball) in the field catalogue. This step deleted field ZZ_SOLD_TO_PARTY from structure CRMT_ACS_H_SEL and also from other condition technique tables, as we can see in the log of the generation.

 

As we can see in the next screenshot at this point ZZ_SOLD_TO_PARTY had been deleted from structure CRMT_ACS_H_SEL too.

  

STEP 7)

   Then I could go over the steps in note 514952  and redo again everything:

I created a new field ZZ_SOLD_TO_PARTY in the catalog with the correct data element

In this case the generation was executed automatically after saving (no need to press the generation button)

 

 I  checked that the field ZZ_SOLD_TO_PARTY had been added to the structure CRMT_ACS_H_SEL with the new data element, as expected

 

I added the mapping in V_CND_MAP_CNVFLD

 (For this particular case implementation of BADI CND_MAP_CNV_FIELD was necessary for the field conversion but this is not relevant here)

 

 I kept the same value for the R3 field (KUNAG ) in structure CND_MAPT_ACS_REM_CUST ( no changes here)

 

I executed initial download of DNL_CUST_CNDALL.

After the initial download I check in SE11 that the table I was interested on CNCCRMPRSAP386, had been generated with the correct data element

 

The access sequences containing ZZ_SOLD_TO_PARTY were correct, too.

Finally I created adapter object DNL_COND_A386 and executed the initial download to ensure that there was no problem with master data download. I checked the records in CNCCRMPRSAP386