Sometimes is a little confusing how to customize the Sales Area templates assigned to the Account. Here you have a quick configuration description:

1^st Step:

Template Types: Working with accounts, the relevant template type is CRM_SALES, assigned to BUPA object.

IMG: “Define Template Types for Business Partner”

2^nd Step:

IMG: “Assign Mini-Template Types to Template Types”: The sales-area-dependent mini-templates types to be used in the Template Type:

These sales-area-dependent mini-templates types are defined in customizing entry:

IMG: “Define Mini-Template Types for Business Partner” as 

3^rd Step:

After this you should maintain the sales-area-independent mini-templates (attributes) and sales-area-dependent mini-templates (sales area):

IMG “Maintain Mini-Templates”.

4^th Step:

Now, with the sales-area-independent mini-templates  (ex: ZBELSHATT) and sales-area-dependent mini-templates (ZBELSHSA) created, the template to be assigned when maintaining an account can be created in the following customizing:

IMG: “Assign Mini-Templates to Templates”

1º Create the template name:

2º Assign the sales-area-dependent mini-template created

RESULT:

Maintaining sales area data in accounts in the WebUI can be done using the templates: “New from Template”

==>

==>

This is a summary about how to debug  a customer delta download from an ECC system to a CRM system. The main places for setting the breakpoints are indicated here.

Modify any data in the ECC system with transaction XD02 and activate the debugging mode with /h in the command field. Then save the data.

 1.- Data is collected in PI_BP_CUSTOMER_BTE_1321 (EVENT 132 Tx BF31). This is the first place to set an external breakpoint. Then, navigate into the following code:

      1.1.- PERFORM START_DOWNLOAD (filters are checked)

                    Loop AT gt_kunnr into ls_kunnr

              1.1.1.- PERFORM CHECK_FILTER_COMPLETE

                        (lv_filter_ok = X ) checking if customer can be downloaded according to the filtering. 

              1.1.2.- PI_BP_MAP_CUST_TO_BUPA (generates the data to be send to    CRM systems --> BAPIMTCS: structures that contain the modified data in the customer) Go inside this function....

                       1.1.2.1.- PERFORM GET_BUPA

                                    -PERFORM MAP_KNA1 (F8) (create the Complex Structure)

                                        LS_CENTRAL_DATA contains what has been changed

                                  In this point, when data is set in the Complex Structure, before creating the BAPIMTCS structure to send the data to CRM, the following user exit is call:

                                       Call User Exit DE_EIOUT (tx: bf34)

                                       FM: OPEN_FI_PERFORM_DE_EIOUT_E

                                              (lt_main_extern)

                                   -FM: PI_BP_MAIN_TO_BAPIMTCS (creates the lineal structure)

            At the end of FM PI_BP_MAP_CUST_TO_BUPA we have the BAPIMTCS structures to be sent to CRM (lt_bapimtcs). In case of number of rows sent from here are different than the number of rows received by CRM, this means that a problem happens in MW!)

2.- Up here, the debugging has been done in R/3.

      In this moment data are collected in the Inbound Queue in CRM (SMQR)      

      R3A* queue should be deregistered, then the R/3 Adapter in CRM is debugged.

      2.1.- BUPA_MWX_BDOC_DOWNLOAD_R3A. Mapping BAPIMTCS structures into   mbdocs (complex structure)

     In the previous FM MAP_BAPIMTCS_AND_PROCESS we should have the same number of rows in the BAPIMTCS structure (ti_bapimtcs) that we saw in R/3

     2.2.- Validation FM:        CRM_BUPA_MAIN_VAL

     In this FM, the relevant FM’s of table CRMC_BUT_CALL_FU are executed  for event  CRMIN and object BUPA.

     For instance:  --> BUPA_INBOUND_MAIN_CENTRAL (takes care of the mapping of the central data)

                         --> CRM_BUPA_INBOUND_MAIN_MD (CRM specific data )       

  At this point, data are in the Complex Structure that is the only way that CRM is able to understand the information (LS_BP)

                      (loop AT message_ext_partners INTO ls_bp)

From here , different BAPI’s are called for saving the data in the CRM system.

PS:

In case we need to debug an initial or request download, the starting point should be PI_BP_CUSTOMER_MAIN_EXTRACT for CUSTOMER_MAIN  and PI_BP_CUSTOMER_REL_EXTRACT for CUSTOMER_REL.  These are the extractor modules for a Customer and its Relation/Partner Functions in the ECC system. After extracting the data, these modules call the subroutine START_DOWNLOAD which does the filtering and mapping of data to complex structure and forward it to the middleware to be sent to the CRM system.

Hello Experts,

Couple of positions are deleted from the org structure in live system, is there any program or method is there to re-store the same positions once again in the org structure.

Please help me to resolve the above the issue.
Thanks in advance for your support.

Regards

Sathish

Middleware is a tool which is inbuilt within SAP CRM that enables the SAP CRM system to interact with various other SAP (R/3, BW, APO etc.) and non SAP systems (3rd party web channel etc.)

Using middleware we can control what data should flow in and out of the CRM system and also monitor the same.

The data exchange between the CRM Middleware and external systems is performed via adapters. The adapters map and convert data between various formats.

Load objects can be exchanged between a source and target system, for example, between an SAP R/3 Backend and the CRM server. For Example: Business partner master data and product master data.

They are grouped as follows:

Business objects; transaction R3AC1
Customizing objects; transaction R3AC3
Condition objects; transaction R3AC5

The objects are stored in the table SMOFOBJECT.
R3AS is used to trigger an initial load.

The following are a few t-codes which are commonly used within Middleware:

SMW01 – Display BDoc Messages.
SMW03 – Display Unprocessed BDoc Messages.
SMQ1 – Monitor Outbound Queue.
SMQ2 – Monitor Inbound Queue.
SMWP – Middleware Monitoring Cockpit.

This will help you to check if your customizing is properly set when you use the new Customer Vendor Integration (CVI), which is delivered with the enhanced functions as of Release ERP 6.0, to synchronize the business partner with the customer and/or vendor.

The report CVI_FS_CHECK_CUSTOMIZING is provided in the SAP Note 1623677 is used to display and check the Customizing for the customer vendor integration. Please keep in mind that the SAP Note 956054 is required for the correct synchronization.

The best choice to get the report is upgrade to the corresponding SP:

SAP_APPL    600      SAPKH60021

SAP_APPL    602      SAPKH60211

SAP_APPL    603      SAPKH60310

SAP_APPL    604      SAPKH60411

SAP_APPL    605      SAPKH60507

SAP_APPL    606      SAPKH60602

Start the report:

1. General Settings:

In this part you can check if the general settings for CVI are correctly customized.

In the above screen, the CVI is activate for all the directions however the PPO has not been activated.

Also, in this screen we can see the table CRMC_BUT_CALL_FU, in this table the mainly/relevant FM for synchronization has to be called. These FMs are the following:

BPOUT          BUPX 1000000          MDS_BUPA_OUTBOUND  X

CRMOU         BUPA 1000000          BUPA_OUTBOUND_BPS_FILL_CENTRAL        X

CRMOU         BUPR 1000000          BUPA_OUTBOUND_BPR_FILL_CENTRAL        X

MERGE          BUPA 1000000          MERGE_BUPA_CENTRAL X

MERGE          BUPA 2000000          MERGE_BUPA_FINSERV  X

MERGE          BUPR 1000000          MERGE_BUPR_CENTRAL X

We can check the first error showed in the output of the General settings

Customer/Vendor Settings

Here you can find all the settings for the CVI and also a log appears with the errors. These include role assignments for the synchronization directions "business partner -> customer/vendor" and "vendor/customer -> business". In this transaction you can go directly to the customizng in SPRO. It is very important to check that all the settings are set properly according to the note 956054.

Anything can happen in the world of middleware. No matter how good you are at configuring the system word-to-word following the best practices and ensuring all the pre-requisites are met, there is always the surprise factor that SAP will have in store for you.

I was configuring the system to set up a Controlling Integration scenario and was wondering what went wrong right from the first step. Not a single bdoc was getting generated for the service orders that were created in CRM.

Went through innumerable blogs and sources on SDN. Went through best practices. No luck. My search results didn't get me what I needed.

Started re-checking all the middleware config from scratch. I knew the sites and subscriptions were working fine as the BP replication and the Product Master replication was working correctly. So whats up with the service orders ? Some object specific settings? This SDN forum gave some really good tips:

http://scn.sap.com/thread/3149675 . But they were only for the master data.

Alas, with great determination in mind, and armed with the skills of a technical consultant, I decided to debug two separate CRM systems in parallel to find out. (This was only after I checked all the configs in both the CRM sandbox systems and was satisfied that they matched each other correctly. In the latter system, I could see a bdoc getting generated for any save to the Service Order).

This was the main difference:

{ please note: Having two sessions of the debugger open parallely is definitely a pain. I wouldn't recommend it to anyone unless its the only way out. And yes, you would definitely wish you had a extra wide screen }

Ignore the z implementations; they are irrelevant. But note the key missing implementation CRM_BUS20001_UPLOAD. I checked in the system and saw that it was inactive. And it contains the code to invoke the FM 'CRM_UPLOAD_BUS_TRANS_MSG' which ultimately generates the BDOC BUS_TRANS_MSG.

So far I was searching for service order replication, middleware replication, bus_trans_msg etc in the forums. Now it was time to find out if CRM_BUS20001_UPLOAD had anything. And voila! It did.

Came across 1604621 - No Bdoc created for sales transactions

Interestingly, this had the validity from 28.06.2011. So I'm not so far behind!

Anyways, the resolution was simple:

Resolution

1. Transaction SE18 enter badi ORDER_SAVE
2. From the menu bar select Enhancement Implementation and from drop down list Overview.
3. Activate implementation CRM_BUS20001_UPLOAD.

So all is well that ends well! Hopefully any of you guys having such an issue in future would be able to get this blog post in your results list!

I had a requirement for controlling integration where I had to configure the middleware to enable the flow of service transactions from CRM to ECC. I will be trying to post a blog on the details of Controlling Integration soon; however this short blog is for those who are looking for options to debug service order related transactions from CRM to ECC.

(Apologies if any of these are repetitive from any previous posts or forums, I had to struggle a bit to get through to this as I did not find any existing post on this!)

1. First step - very simple and familiar to anyone having experience debugging middleware - deregister the queues.

     If the middleware setup has been done correctly bdocs will be generated for every service order/confirmation that is generated. Hence through transaction SMW01, check the bdocs that are getting generated. Under the queue name, you will find the name of the queues to be deregistered. Depending on the requirement, you can block either the entire CSA_ORDER_* queues or any particular queue corresponding to a single transaction. (Please be careful not to stop the subsequent flow or confirmations that need to flow for an order).

Goto transaction code SMQR to deregister the queue.

Once this is done, the bdoc for transaction 8000000144 will be in wait status when it is generated as the queue is blocked. (Make sure some change is applied to the transaction so that the change triggers the bdoc creation).

2. Goto transaction SMQ2 (Inbound queues) and you will find the queue readily waiting for you to flag it off!

3. Click on the right entry and select debugging icon

4. Hurray! You are within the ABAP debugger - a developer's paradise where everything is within your control

5. Now is the tricky part. Where do I put the right breakpoints so that I can find out what is being done in ECC?

Depending on the bdocs generated, SAP uses certain standard function modules to transfer data to ECC. For example, in this situation, I got confused because the control goes to the function module CRM_R3_SALESDOCUMENT_UPLOAD also, but within in it doesn't transfer to ECC as this transaction type is not a sales related one. Hence it passes through this FM without doing anything.

The right FM to be checked in the service scenario is CRM_R3_SERVICECONF_UPLOAD. (Place a breakpoint in this FM so that the control reaches here).

6. My requirement was to only check what was happening within ECC and hence I only needed to jump to the point where the call to ECC was being made. Hence I went directly to line number 343 in the FM CRM_R3_SERVICECONF_UPLOAD.

Just like in any other middleware debugging scenario, change the value of the parameter GV_SYNCHRONOUS_CALL to 'X'. This will call the BAPI 'BAPI_SERVICECONF_PROXY_UPLOAD' in foreground and you will be able to get into ECC to debug.

There you go! You have the world in your hands to troubleshoot any issues arising out of service order replication to ECC! Happy Debugging!

Some other potential issues that can spoil your day after doing all the above:

- RFC destination is not set-up right with the required authorizations

- Your userid might not have the authorizations to execute this activity of debugging in the external system

>If you search how to replicate custom BP fields from CRM to ERP(ISU) you will see that has possibly complex steps to do. But the truth is different. I can say BP custom fields replication have easy steps but SD replication may have complex steps.

1. First thing is adding custom Z-fields to CRM with AET.

All CRM consultants know easily zfield creation with AET.

2. We will see custom fields in But000 table in CRM. All fields are staying in CI_EEW_BUT000 include.

3.  We should add these fields with Easy Enhancement Workbench, EEWB  transaction to ERP (ISU) system.

There isn't any AET tool in ERP (ISU).We are using a simple wizard that is completing everything for us.

3.1 First Creating Project

As you see here package is assigned! It is not $tmp and if you write $tmp here you will possibly face finding all local objects and assign directory.

3.2 Create Extension in that project

EEW Bus.Object is BUPA  & EEW Extension TYPE: ADD_NEW_Fields

3.3 Start Wizard to define customer fields.

You should define all custom fields with ordered in CRM system. This is important! Because system is matching fields lenght by lenght between CRM-ERP (ISU).  You are not able to give field name, search help definitions in wizard. Field names are generated by system automatically. Descriptions are important because system will add these definitions to all related tables,structures and screens. Possibly you will match descriptions betwwen systems.  Also you are able to check bw relations in system relevance step.

3.4 Wait system to complete changes.

3.5 Check bp transaction /but000 table with new fields.

You will see a new tab (customer fields) in BP transaction.

4. Replication Steps

There are interesting manual oss implementation for replication. If you don't do this you will not see replication of data possibly.

4.1 Add .INCLUDE    CI_EEW_BUT000 to BSS_CENTI structure

Please take care of order! Absolutely you will add only include.

4.2 Add .INCLUDE    CI_EEW_BUT000_X to BSS_CENTIX structure

Please take care of order! Absolutely you will add only include.

5. Check Replication

Create or change any BP data in CRM and have a look to ERP(ISU) BP .

Hope everything perfect.

Possible Errors You May Have while These steps.

- Extension type BUPA - ADD_NEW_FIELDS cannot be combined with package ZCRM  ( OXT_MISC327 )

> If you take this error search already created projects in your system. Possibly you have test or another projects in the system. You should take care about it. I faced this error and debugged many times. At the end i can say put breakfoint OXT_CHECK_DEVLAYER  function and see comparison. You will see there are mismatches between projects. This is cause of copying clients. If anybody created a test data and if it's copied to another client you should login that client and delete or change it.

-BDT-DC is Not Prepared for This Application Object ( DC1101 )

> If you get this message you shoul maintain V_TBZ1_DC , BUPA item as active.

Configuration for vendor master data exchange ECC <---> CRM

if you want to activate the data exchange between ERP vendor master data and CRM business partners than follow below mention step

In transaction SM31, table CRMC_BUT_CALL_FU for the Business Partner Outbound of Business Partner objects, the function VEND_MWX_CREATE_MAIN_BDOC must be active.

In transaction R3AC1 the adapter VENDOR_MAIN must be active.

In transaction SMOEAC shall be a subscription for the publication 'All Vendors' to the ERP system (Site). For example you can specify 'All Vendors (MESG)' as subscription's name.

Within transaction SM31, in the table COM_BUPA_CALL_FU for R/3 object inbound processing (time R3OBI) of vendor records (object VEND), the function PI_BP_PROXY_BAPI_VENDOR must be active, and the function PI_BP_PROXY_BAPI_CUST_VEND must not be active.

In transaction SM31, table CRMSUBTAB for User CRM

The function COM_VEND_MAIN_INBOUND shall be active for object VEND_MAIN of class BUPA for upload

The function PI_BP_VENDOR_MAIN_EXTRACT shall be active for object VENDOR_MAIN of class VEND for download.

Define Number Ranges for Vendor

Tcode BUCF

Note * Identifying Relevant ERP Account Groups & To check which intervals are configured in ERP

Define Grouping and Assign Number Ranges for Vendor

In transaction PIDV please maintain the mapping between the CRM role categories for vendors (usually role category BBP000) and the corresponding ERP account group.

Note: the field 'Grouping' in transaction PIDV (ERP) shall be an existing grouping entry in the CRM-table TB001. The values for TB001 can be checked in CRM within transaction SM31 for the view V_TB001. Be aware that the ERP vendor numbers are in the interval of the grouping range assigned to the grouping ID you have selected from view V_TB001. To check which intervals are configured in ERP, please refer to the IMG activity: Logistics – General → Business Partner → Vendors → Control → Define Number Ranges for Vendor Master Records.

Delta load (ERP→CRM)

the function module PI_BP_VENDOR_BTE_1421 should be registered for the event 00001421 and the application BC-MID in the table TBE31 at the ERP-site. For this purpose, use transaction R3AC4.

Initial load (ERP→CRM)

Start transaction R3AS.

Select VENDOR_MAIN as Adapter Object and press ENTER. Then run the application.

Use transaction SMW01 in order to check the BDoc transfer for BDoc type VEND_MAIN.

Check if the BDoc processing finalized with no errors (status is green) within transaction SMW01 for BDoc type VEND_MAIN. If this did not happen, check if errors have occurred in the inbound or outbound queues (transactions SMQR and SMQS).

A new corresponding entry is filled in table CRMLIFNR (you can get the parameter PARTNER_GUID from transaction CRMM_BUPA_MAP in CRM)

you can see the ERP vendor number
- in table BUT0ID (tab "Identification" of transaction BP in CRM 5.0 or assignment block “Identification Numbers” in CRM 5.1 and subsequent releases)

in table CRMM_BUT_VENDNO.

Test Execution

Start transaction XK01/XK02 (Create/Change Vendor Master)

On the access screen, mark corresponding Data Sets: Address, Control and Payment Transactions and press ENTER

Maintain any data for Address, Control or Payment Transactions

Save

Check bdoc and then Txn BP

In ECC

In CRM

During download of vendor master records from the ERP system to the CRM

system , the BPs need to be differentiated from the customer master BPs

The ECC vendor number, would come across to CRM as the same number prefixed by ‘an identifier’

Example: ECC vendor number 0000500001 --> CRM number V000500001

Reason and Prerequisites

To differentiate easily between the vendor BPs and others in the CRM system

Implement a customer-specific function module for the CRM0_200 middleware user exit in the ERP system that determines the names for the business partners to be created:

     o  In Transaction SE37, create the Z_VENDOR_EXTERNAL_RANGES function group and in it, the Z_VENDOR_EXTERNAL_RANGES function module.

        -  Copy the existing SAMPLE_PROCESS_CRM0_200 example function module to a separate module with the name Z_VENDOR_EXTERNAL_RANGES. Save the module and activate it.

-  Implement the code present in the mention below You can   change it according to your own requirements. The example code suffixes 'V' before the first 9 digits of the vendor number before it is downloaded to CRM.

    -  In the transaction PIDV on the ERP system assign the relevant account group to be replicated into CRM BP with grouping which has the appropriate external number ranges settings.

-  Save the module and activate it.

*******************************************************************
*   System-defined Include-files.                                 *
*******************************************************************  INCLUDE LZ_VENDOR_EXTERNAL_RANGESTOP.      " Global Data  INCLUDE LZ_VENDOR_EXTERNAL_RANGESUXX.      " Function Modules


*******************************************************************
*   User-defined Include-files (if necessary).                    *
*******************************************************************
* INCLUDE LZ_VENDOR_EXTERNAL_RANGESF...      " Subprograms
* INCLUDE LZ_VENDOR_EXTERNAL_RANGESO...      " PBO-Modules
* INCLUDE LZ_VENDOR_EXTERNAL_RANGESI...      " PAI-Modules

FUNCTION z_vendor_external_ranges.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(I_OBJ_NAME) LIKE  BAPICRMOBJ-OBJ_NAME
*"     VALUE(I_BAPICRMDH2) LIKE  BAPICRMDH2 STRUCTURE  BAPICRMDH2
*"  TABLES
*"      T_INT_TABLES STRUCTURE  BAPIMTCS
*"      T_BAPISTRUCT STRUCTURE  BAPIMTCS
*"      T_MESSAGES STRUCTURE  BAPICRMMSG
*"      T_OTHER_INFO STRUCTURE  BAPIEXTC
*"----------------------------------------------------------------------
*======================================================================*
*  Program Name: SAPLZ_VENDOR_EXTERNAL_RANGES                          *
*----------------------------------------------------------------------*
*                                              *
*----------------------------------------------------------------------*
*   Description: To avoid a possible number range overlap between      *
*                Customers and Vendors in the CRM system. We need to   *
*                implement a customer-specific function module to be   *
*                called by middleware during the vendor replication    *
*                process in ECC.                                       *
*===============================REVISIONS==============================*
*             Cut                                                      *
* Programmer  Over                          *
* ----------  ---- -------- ------- -----------------------------------*
*                                                                      *
*                                                                      *
*                                                                      *
*                                                                      *
*======================================================================*  DATA: ls_bapimtcs   TYPE bapimtcs,          ls_v_crm_vend TYPE r3a_vend,          ls_user_exit  TYPE bapibus1006_head,          lt_user_exit  TYPE TABLE OF bapibus1006_head,          ls_r3a_vend   TYPE r3a_vend,          ls_bsc_maini  TYPE bsc_maini,          lv_num(9)     TYPE n.  DATA wa_bapimtcs TYPE bapimtcs .  DATA: lv_index TYPE sy-tabix.  FIELD-SYMBOLS: <fs_v_crm_vend>     TYPE r3a_vend.  CASE i_obj_name.    WHEN 'VEND_MAIN' OR 'VENDOR_MAIN'.      LOOP AT t_bapistruct        WHERE segtype = 'DA' AND tabname = 'R3A_VEND'.        ASSIGN  t_bapistruct-data        TO <fs_v_crm_vend> CASTING.        MOVE-CORRESPONDING <fs_v_crm_vend> TO ls_v_crm_vend.


*   Set the key field, this has to be the WERKS of the PLANT        ls_user_exit-extern_no = ls_v_crm_vend-vendor_no.
******************************************************
*   Set the partner number for external numbering
******************************************************        SHIFT ls_v_crm_vend-vendor_no LEFT  DELETING LEADING '0'.        IF STRLEN( ls_v_crm_vend-vendor_no ) <= 9.          MOVE  ls_v_crm_vend-vendor_no TO lv_num.          CONCATENATE 'V' lv_num INTO ls_user_exit-bpartner.
*    ls_user_exit-bpartner = ls_v_crm_cp-werks.
*   Set the grouping (leave empty for external standard)          ls_user_exit-partn_grp  = 'VEND'.          APPEND ls_user_exit TO lt_user_exit.        ENDIF.      ENDLOOP.


******************************************************
*     Update Vendor Partner Number for external numbering
******************************************************      CLEAR wa_bapimtcs.      LOOP AT t_bapistruct INTO wa_bapimtcs        WHERE segtype = 'DA' AND tabname = 'BSC_MAINI'.        lv_index = sy-tabix.        wa_bapimtcs-data+0(1) = 'V' .        MODIFY t_bapistruct FROM wa_bapimtcs INDEX lv_index TRANSPORTING data. " WHERE tabname = 'BSC_MAINI'.      ENDLOOP .      CLEAR wa_bapimtcs .      LOOP AT t_bapistruct INTO wa_bapimtcs              WHERE segtype = 'DA' AND tabname = 'R3A_VEND'.        lv_index = sy-tabix.        wa_bapimtcs-data+1(1) = 'V' .        MODIFY t_bapistruct FROM wa_bapimtcs INDEX lv_index TRANSPORTING data. " WHERE tabname = 'R3A_VEND'.      ENDLOOP.  ENDCASE.


************************************************************
* Append the BAPIMTCS structures for the external numbering
************************************************************
  ls_bapimtcs-segtype = 'DA'.  ls_bapimtcs-tabname = 'BAPIBUS1006_HEAD'.  LOOP AT lt_user_exit INTO ls_user_exit.    CLEAR ls_bapimtcs-data.    MOVE ls_user_exit TO ls_bapimtcs-data.    APPEND ls_bapimtcs TO t_bapistruct.  ENDLOOP.


ENDFUNCTION.

In ECC

Register this function module for the CRM0_200 exit user in the ERP system.

- Use Transaction SM30, table TPS34, to go to the maintenance of the modules. Here, enter the Z_VENDOR_EXTERNAL_RANGES  module for the CRM0_200 process.

- Use Transaction SM30, table TBE24, to check whether the

application you have selected (Product column in TPS34) is active.

Note:- The vendor account group should not be sent to crm as it is not possible to handle it in CRM and also it is not required in CRM

       classification Tab is not visible for vendor or plant in CRM

Reference

SAP Note 883162 - Configuration guidelines for vendor data exchange

SAP Note 1044637 - Customize Vendor Numbers (above mention code is bit different from SAP code )

SAP Note 942062 - Vendor account group incorrectly filled in R/3

Hi,

We are using ECC and CRM 6.0 .We have completed the initial download for all the customers from ECC to CRM.Whatever we do changes for the customers in ECC, these changes are replicating to CRM by using delta load.But when we update the address in ECC the updated address is not replicated to CRM.Bdoc is generated with the updated address.But the updated address is not posting in the BP.

Ex: When we changed the street name in ECC then the Bdoc is generating with updated street name.But it is not updating in BP in CRM.

Please help me.

Thanks,

Kiran

When you download material from ECC to CRM, the product attribute 'serial number processing' can be transferred if the customizing is set up properly. But the logic of how product attribute 'serial number processing' will be set is not widely known.

In ECC transaction MM01, you can create a material. Under tab 'Sales: General/Plant', in field 'SerialNoProfile', you can assign the serial number profile. This will be downloaded into CRM product as field 'Serial No. Processing', under tab Material.

The serial number profile is maintained in ECC at the following path:

IMG

-- Sales and Distribution

-- Basic Functions

-- Serial Numbers

-- Determine Serial Number Profiles

Under each profile, you can define a series of procedures,

If the material is downloaded for the first time(initial download, or when you create a new material in ECC), the application will evaluate the serial number profile you assigned to this material by the following logic:

Within the serial number profile, it has procedure 'MMSL' (Maintain goods receipt and issue doc). For MMSL procedure,  if its serial number usage is 03 (Obligatory),

the CRM product attribute 'serial number processing' will be set to 4. Otherwsie, the product attribute 'serial number processing' will be 0.

in ECC FM CRS_SERIAL_PROFIL_DETERMINE, line 38,

    LOOP AT IT_MARC_NEW ASSIGNING <fs_marc>.
    CALL FUNCTION 'SERIAL_PROFILE_READ'
      EXPORTING
        PROFILE_R      = <fs_marc>-sernp
        OPERATION_R    = 'MMSL'
      IMPORTING
        T_377          = lt_T377
      EXCEPTIONS
        NO_T377P_ENTRY = 1
        NO_T377_ENTRY  = 2
        OTHERS         = 3.
    IF SY-SUBRC = 0.
      IF lt_T377-SERPFLICHT = '03'.
        EV_SERIALNO_PROCESS_NEW = '4'.
        EXIT.
      ENDIF.
    ENDIF.
  ENDLOOP.

it will read the MMSL procedure in the serial number profile which is assigned to the current material, then it will check if the MMSL procedure usage is 03(Obligatory). If so, the CRM product attribute 'serial number processing' will be set to 4.

When the material is not downloaded for the first time, that is to say, before the download, the product already exists in CRM and it's mapped to the ECC material. When you change the serial number profile in ECC material, the delta download of material works like this:

in FM CRS_SERIAL_PROFIL_DETERMINE

line 19,

   LOOP AT IT_MARC_OLD ASSIGNING <fs_marc>.
    CALL FUNCTION 'SERIAL_PROFILE_READ'
      EXPORTING
        PROFILE_R      = <fs_marc>-sernp
        OPERATION_R    = 'MMSL'
      IMPORTING
        T_377          = lt_T377
      EXCEPTIONS
        NO_T377P_ENTRY = 1
        NO_T377_ENTRY  = 2
        OTHERS         = 3.
    IF SY-SUBRC = 0.
      IF lt_T377-SERPFLICHT = '03'.
        EV_SERIALNO_PROCESS_OLD = '4'.
        EXIT.
      ENDIF.
    ENDIF.
  ENDLOOP.

it reads the MMSL procedure of the old serial number profile and if it has usage 03, it will set EV_SERIALNO_PROCESS_OLD = '4'.

line 38,

   LOOP AT IT_MARC_NEW ASSIGNING <fs_marc>.
    CALL FUNCTION 'SERIAL_PROFILE_READ'
      EXPORTING
        PROFILE_R      = <fs_marc>-sernp
        OPERATION_R    = 'MMSL'
      IMPORTING
        T_377          = lt_T377
      EXCEPTIONS
        NO_T377P_ENTRY = 1
        NO_T377_ENTRY  = 2
        OTHERS         = 3.
    IF SY-SUBRC = 0.
      IF lt_T377-SERPFLICHT = '03'.
        EV_SERIALNO_PROCESS_NEW = '4'.
        EXIT.
      ENDIF.
    ENDIF.
  ENDLOOP.

it reads the MMSL procedure of the new serial number profile and if it has usage 03, it will set EV_SERIALNO_PROCESS_NEW = '4'.

Later, in include LCRM1F11,

FORM get_serialno_processing,

line 30,

    CALL FUNCTION lv_function  "provided by Service
    IMPORTING
      ev_serialno_process_old = ls_mara_ser_old-serialnoprocess
      ev_serialno_process_new = es_mara_ser_new-serialnoprocess
    TABLES
      it_marc_old             = lt_marc_old
      it_marc_new             = lt_marc_new.

  IF es_mara_ser_new-serialnoprocess =
     ls_mara_ser_old-serialnoprocess.
    CLEAR: es_mara_ser_new.           "No changes
  ELSE.
*   es_mara_ser_new-material
    IF es_mara_ser_new-serialnoprocess IS INITIAL.
      es_mara_ser_new-operation = 'D'.
    ELSE.
      es_mara_ser_new-operation = 'I'.
    ENDIF.
  ENDIF.

** here lv_function  = CRS_SERIAL_PROFIL_DETERMINE, so it will call CRS_SERIAL_PROFIL_DETERMINE to get the serial number process of both the old profile and the new profile. It then compare the serial number process of the old profile and serial number process of the new profile, if they are equal, it will clear the es_mara_ser_new. Then the CRM product attribute 'serial number processing' will be set to 0.

Hi,

I am using the MDM tool for extracting data from CRM system to XI system. its successfully extracting records for initial load, now i am trying for the delta changes (Change pointers) where, i am not able to find the way for it.

I followed as per instruction downloaded , i gone to transaction BUPA_IFC_CALL_FU and created new lines BUPA_CREATE_CHANGE_POINTER and BUPR_CREATE_CHANGE_POINTER and activated the same. But while i am executing for delta changes in MDM_CLNT_EXTR is not transferring any changed data to XI.

Note : i am transferring all standard fields only , no custom field and using standard extraction function module.

Please guide me if any other thing i have missed on this,

Regards,

K.Sudhakaran.

     Sometimes we don't want the delta download (replication from ECC to CRM) to happen, what should we do?

     The mechnism that the delta download happens with is by BTE event. Specifically, it's ECC table TBE31. Then how to know which entries are the relevant ones concerning the object I'm going to stop? You can check the transaction R3AC4 in CRM.

     For example, if you want to stop delta download of SD customers, the object class, the object class is BUPA.

Select 'BUPA', then select 'Event by object class' folder, under which you can see all the relevant BTE event function modules.

These function modules are the ones that appear in ECC table TBE31. When an initial download of customers has been done successfully, these entries will be filled in TBE31 table automatically. When you create or change a SD customer in ECC, these function modules will be called to transfer the customer to CRM

     So, to stop delta download, you can delete these FMs from TBE31. But sometimes it is not safe as these FMs can be added back by some programs in ECC. So to make sure the delta download doesn't happen for ever, the safest way is to add an entry in ECC table CRMRFCPAR:

User                        CRM (the consumer)

Object Name           CUSTOMER_MAIN(the adapter object)

Destination              (the RFC destination pointing to CRM)

Load Type                 D ('D' stands for delta download)

Discard Data            X

By setting 'discard data' to X, you can ensure the delta download of CUSTOMER_MAIN is stopped.

• Logical System:
  • A Logical system is pretty much important to be present prior hand because this is important to establish the connection with that system.
  • When data is distributed between different systems, each individual system within a network has to be clearly identifiable.
  • A Logical system is an application system in which the applications work together on a common data context.
  • In SAP terms, logical system is considered to be a CLIENT.
  • Since logical system is the name used to identify a system uniquely within the network, two systems cannot have same name if they are connected to each other.
• RFC Connection:
  • RFC connections are the ones which physically enable the system to share the information over the network.
  • To create a RFC connection, use transaction SM59.

• CRMRFCPAR - Definitions for RFC Connections*

• CRMCONSUM - Possible Users of R/3 Adapter Functionality

• CRMFILTAB - Filter Conditions for Download

When there is a filter defined in R3AC1 transaction and the filters are synchronized, then all the filters will be present in this table in ECC. In CRM it will be  present SMOFFILTAB.

• CRMPAROLTP - CRM OLTP Parameters

When the filters are maintained in CRM system, then there should be an entry with the text CRM_FILTERING_ACTIVE for the correspnding adapter object. Sample screenshot:

• CRMSUBTAB - Subscription Table for Upload and Download Objects

This is the table which will have the function modules for the upload or download objects.

Important tables and transaction in CRM system:

• SMOF_ERPSH - ERP-Site Header table
  • This table fills automatically whenever you create the site in the CRM system by using the administration console (SMOEAC)
  • Site ID is the unique ID provided for the each site created via SMOEAC.
• CRMM_BUT_CRMOBJ - Buffer: Which BPs are in Which Systems
  • This table will carry the partners which are successfully replicated and the SITE ID of the system to which the data is replicated.
• SMOEAC (Transaction for Administraton console)   
  • In CRM server every system which is connected to it are defined as  sites and to enable the data exchange the sites must be define in the CRM system  using the tool SMOEAC.
  • To enable the data exchange between the CRM server and the connected system first we have to create the site for the particular RFC destination in the SMOEAC.
  • Following are the steps to create site:
    • Open transaction smoeac.
    • choose object type SITE.
    • Click on create.
    • Fill all the required fields like name of site , type of site.
    • Click on site attribute button.
    • Enter the RFC destination in our case it should be any ECC system and hit enter the system will automatically fetch all the relevant data for the site like logical system name,release of the system etc.
• After creating the site the screen will look like the below screen.
• Once the site is created, the connected site has to be subscribed for the available publication.
• Publication:
  • Publication is the definition of one or more replication objects with specific criteria for replication means to say that Publication is kind of container which may consist different replication object.
• Subscription:   
  • Subscription is a replication object within the publication which connected site can subscribe to it.
  • Subscription is a means by which the site can subscribe for some particular set of replication objects from publication which he want to get it from the CRM server..
  • For eg. Site can subscribe for the all the business partner to flow to him or only the relationship should be replicated to him. It all depends on the customer requirement that what data he want to replicated to the connected site.         

• In our case most of the time we subscribe for two business objects BUPA_MAIN i.e. all business partner  and BUPA_REL i.e. all business partner relationship means to say that the connected ECC side can accept all BP data and BP relationship data from the CRM system other than this it will discard all other types of data.
• After defining the ECC as a site in the CRM system we must assign subscription to it below are the screenshot which will show how to create and assign subscription to the ECC site.
• Following will be the steps where the subscription will be created and assigned to the site.

• Types of Subscription.

  • Simple Bulk subscription.

    • Simple bulk subscription is the standards subscription which given by the SAP standard SAP delivery and customer are not allowed to make any change in this subscription. General recommendation is to have bulk subscription.

  • Simple intelligent subscription.

    • Simple intelligent subscription is something which customer can create their own subscription with some filter criteria according to their requirement.

Some times when the Master data are to be uploaded from a legacy system or from any other non connected, non SAP systems LSMW will come to the rescue. LSMW can be expanded as Legacy System Migration Workbench. This is to migrate the business entities into the CRM system. This tool actually contains following methods in which we can import data to CRM system:

• Standard Batch / Direct Input
• Batch Input Recording    
• BAPI
• IDOC.

Out of these methods we will have a look into the steps of the importing business partners using Idoc method.

Step 1: Create project using transaction LSMW

Step 2: Select Maintain Attributes Radio Button:

Step 3: Maintain Attributes

Select Idoc Radio button and give "Message Type and Basic Type".

Click on Save.

Step 4: Activate Inbound processing.

The following screenshots explain the activation of Idoc Inbound processing.

Click "Idoc inbound processings" under settings.

Here maintain "Port" and "Partner type" and Partner number here and Press Activate Idoc Inbound processing.

Step 5: Maintain Source attributes

Click on "Maintain source structures" radio button. Click on Source attributes and then click on create.

Step 6: Maintain source fields

Step 7: Maintain structure relations

Click on structure relation and click on relationship as shown above to maintain relationship.

Step 8: Maintain field mapping

And press F8.

Extras ==> Auto field mapping. Press Enter until you get a popup message field mapping completed.

Step 9: Specify files

Click on the Legacy data while taking file from presentation server and click create.

Step 10: Assign files

Step 11: Read data

Step 12: Display Read data

Step 13: Convert Data

Step 14: Start Idoc generation

We will get popup like this:

Click Ok.

Step 15: Create Idoc overview

After this step, idocs will be created which can be viewed in transaction WE05. I hope this might help who try to import the Business objects using Idoc method of LSMW. For illustration purposes i have combined partners and orders in few places. This is a guideline for LSMW Idoc input method.

Hi ,

We are working on SAP CRM 7.0 (EHP1) and our source system is ECC. Customers are created in ECC and they flow to CRM. The payment terms are not flowing accurately to CRM system for some customers. Kindly help me in resolving this issue.

Regards,

JP

After you starting an initial load in R3AS, if you want to abort it before it runs through its end on its own, in most cases, it's not enough to just abort it in R3AM1. Although you have selected the entry in R3AM1 and hit the button 'Abort', when you start the same initial load again in R3AS, you frequently see the popup

This means the abortion of initial load has not been done thouroughly.

To ensure the initial load is aborted properly, firstly you need to abort it in R3AM1. Afterwards, you need to check the CRM outbound queue and inbound queue, in SMQ1 and SMQ2 respectively, to see if there's any relevant queues, if any, delete them manually.

Thirdly you need to check SM50 in both CRM and ECC, to see if there's any relevant work process still running for the initial load. If any, you can select that work process and cancel it as shown in the following figure.

If you still cannot start the initial load because the old initial load is still not aborted, even after you did all the aboves, you can go to table SMOFDSTAT, find the relevant adapter object, and check the field 'DNL_STATUS'. If DNL_STATUS is still running, you can manually delete this entry. This can ensure the initial load is aborted.

You can use adapter objects defined in R3AC3 to download customizing data. When it doesn't work, the most common issue is in ECC table CRMATAB, there's no proper entries. eg. if you're to download DNL_CUST_KTOKD - account group, the relevant table T077D and T077X must exist in CRMATAB on ERP.

If this table is empty or not having the relevant entry for the adapter object you're using, you can run report SMOF_FILL_CRMATAB in CRM to fill this R3 table.

When you run this report, you need to fill in the following parameter:

Source Site Name   --- R3 system site

Objectname            ----- the adapter object

(if table CRMATAB is empty and you want to fill in entries for all the adapter objects, you can also check the checkbox 'All objects'.)

But report SMOF_FILL_CRMATAB requires some special authorization.

Note 1498111 explains the specific authorization required for the initial download of customizing object. Please also note that the authorizations described in this note are not covered by SAP_ALL - so even if your user has authorization SAP_ALL, the additional authorization is required. It must be added to the user defined in SM59 of the CRM that connects to ECC system - this user which is maintianed in SU01 of the ECC. Also, it should be added to the user defined in SM59 of the ECC that connects to the CRM destination (this time in SU01 of the CRM).

In some cases, the report SMOF_FILL_CRMATAB doesn't exist in CRM. In that case, you need to apply note 1501685 to populate this report.

Also, in some ECC systems, there're no function module CRM0_WRITE_CRMATAB. Because report SMOF_FILL_CRMATAB will call ECC FM CRM0_WRITE_CRMATAB remotely, to fill table CRMATAB, when this FM is missing, the report will fail. In that case, you need to apply note 1502607 in ECC to populate FM CRM0_WRITE_CRMATAB.

The above are basically all the issues you will potentially face with table CRMATAB.

CRM product hierarchy is mapped to R3 material master.

In R3 IMG, the following path:

go to 'Define Product Hierarchy', and then choose the 3rd one, press 'Enter'.

there you can maintain the product hierarchy. The product hierarchy node number will indicate the hierarchical relationship between the nodes.

eg. 00230000106 and 00230000105 will both go under the node of 00230.   The field 'Level no' will also tell you the level of each node in the hierarchy.

You must run initial download of DNL_CUST_PROD1 again to load the new product hierarchy category to CRM, because there's no delta load for customizing data.

1. Replication between CRM BP to ERP BP and vice versa.
2. Replication between ERP Customer to CRM BP.
3. Replication is not supported between CRM BP and ERP Customer.

• Card type should be maintained in both the systems.
  • Card Type maintenance in ERP and CRM systems:
    • SPRO
    • Cross Application components
    • Payment cards
    • Basic Settings
    • Maintain Payment card type.

• Card category should be maintained in bot h the systems.
  • Card category maintainenace in ERP and CRM systems
    • SPRO
    • Cross Application components
    • Payment cards
    • Basic Settings
    • Maintain Payment card category

• During replication of the credit card from one system to another every card type should be assigned to a card category. This enables the system to
  understand and check which card type belongs to which card category. For ex the card type VISA belongs to the category Credit card. This can be maintained in following SPRO path in both the systems.
  • SPRO
  • Cross Application components
  • Payment cards
  • Basic Settings
  • Assign Payment card category to Payment card type.

• Some times End user has to block the credit card due to some circumstances for which they have to provide the reason to block it. If there is no reason provided the system will throw an error during the replication of the blocked credit card. This can be maintained in following SPRO path in both the systems.
  • SPRO
  • Cross Application components
  • Payment cards
  • Basic Settings
  • Maintain Card blocks

• During replication of the credit card there are some validations done on the credit card to check whether the credit card is valid or not for which the customer has to provide some checking rules which would be able to validate the credit card. There are some standard checking rules provided by the SAP and following are few of them. If the End user defines the new card type then he has to create the checking rules for that card type otherwise the replication will not be successful.

• Since the credit card is a very critical data which can cause the financial loss to the organization if it is exposed to wrong people. So it is mandatory that whenever the replication of the credit card happens, it should be in a secure way for which card should be encrypted before sending from one system to another and then save it in the encrypted format so that no one will able to understand the card data. To enable the card encryption during defining the card type we should check the encryption checkbox to encrypt the card during replication or saving it in the system. To achieve this we can follow the following IMG path.
  • SPRO
  • Cross Application components
  • Payment cards
  • Basic Settings
  • Maintain Payment card type.

       Here user can check the encryption check box for the card type. To allow the system at the point in which the encryption should happen can be defined in the following SPRO path.

• SPRO
• Cross Application components
• Payment cards
• Basic Settings
• Make security settings for payment cards.

Possible errors during replication:

1. R11 561 - Specify Card type:
   1. Payment card type is not maintained in CRM system.
   2. Payment card category not defined but if defined not assigned to any card type in CRM system.
   3. If there is no checking rule present in the system.
2. R11 345 - Payment card does not exist for BP:
   1. If there is no checking rule maintained.
3. R11 144 - No credit card details found:
   1. Card number or type may not be filled or deleted during the exchange.

Above errors are most common errors. Not necessarily to be created for the reasons mentioned but mostly happen due to the reasons mentioned. In any case of confusion, debugging the flow will be able to spot the error accurately in terms of replication.