To identify SRM system by MM system and MM system by SRM system we need to define the

source and destination sites. We define source and destination sites in the T-Code SMOEAC.
SMOEAC SRM Side
In transaction SMOEAC by default it was CRM (Destination Site). CRM is maintained as
destination site, USER=CRM, basing on the RFC user CRM will replicate material master data. If Im using
CRM in SMOEAC, I need to maintain this CRM in the backend system to inform CRM is the user who is
consuming information.
If I maintained SRM in SMOEAC, same should be maintained in the backend system in the MM
table CRMCONSUM
In the site attributes we need to define SRM Destination, and when we click on Get Details R/3
release and logical system will be updated. [This means somewhere (Define System Landscape) we need
to define our system version and the version of the system with we are communicating]
Now based on the version (R/3 System with which it is communicating) it will decide which
programs/functional modules has to be used.
Note: 1-ECC can talk with 3-SRM, 1-ECC can talk with 1-SRM and 1-CRM systems.
Next goto ECC table CRMCONSUM
CRMCONSUM
In CRMCONSUM table we maintain user who consumes the data, say we give entry as SRM This is
not a RFC user.
In the program BBP_Product_Settings_MW program execution we give the name as SRM to
deactivate CRM objects and activate SRM objects. That SRM user we use in SMOFPARSFA and
CRMCONSUM tables.
In CRMCONSUM table we specify which user consumes data SRM
In CRMCONSUM, CRM user is already there and if we want SRM user along with CRM user then
we have to maintain SRM user (through SM30 tcode)
Entries: Consumer =SRM
Activity =X
Text =SRM
Check whether necessary entries maintained in the table CRMSUBTAB, if required copy the
following entries into the table in the OLTP system (MM)
CUSTOMIZING_OBJECTS
MATERIALS
SERVICES
We need to maintain the information who is consuming the data in CRMSUBTAB. Of course we
already defined that in CRMSUBTAB but currently who is consuming but currently who is
consuming is important. In CRMCONSUM we have both CRM and SRM users, but who
consumes now is maintained in CRMSUBTAB.
In CRMCONSUM table we also specify Qprefix because in transformation/replication process
if something is stuck we go to SM12 and delete the queue. In SM12 we can find many other
queues; we should delete only our queue, to identify our queues we use Qprefix name.
CRMRFCPAR:
To which destination we are taking the data we maintain here. We give the destination logical
system name here say ECCCLNT200. Along with logical system we maintained download
types (Initial/Delta) for materials and services
Q) Difference between Initial Download and Delta Download in master data replication?
Sol) If any changes happened to the master data that should be replicated to SRM this is
called Delta Download
If we want the master data for no.of times then we select Initial Download option.
Some case OnRequest is there which is nothing but Delta Download.
CRMPAROLTP:
We activate filters for business objects in this table. We cannot filter customizing objects. I we
want filter for customizing objects we can do that from R3AC3 (SRM Side)
In this we activate filter for Material and SERVICE_MASTER (Filter names will not be
changed)
Next maintain the entries in TBE11 table.
BC_MID and NDI should be maintained in the table. There were already maintained just check
they are active or not.
SMOFPARSFA (SRM Side): Likewise in ECC we need to active this table for material replication.
We need to check MCRM_CONSUM entry is active or not.