Коллги,
хотелось бы высказаться по поводу сабж и услышать (увидеть ваше мнение, может быть кто-то уже имел дело с подобными вещами.
На первоначальном этапе внедрения crm мы импортировали из r/3 сбытовую оргструктуру, завели сотрудников как ДП в роли "Сотрудник" и присвоили их сбытовым оргединицам. Настроили правила определения оргданных для сбытовых заказов, контактов и т.д по присвоенным сбытовым оргединицам сотрудникам . Все замечательно!
1. После выполнения тестовой интеграции с hr появилась новая hr-ная оргструктура в crm. И как следствие, все сотрудники переприсваиваются в crm новым оргединицам. Соотвественно, все правила определения оргданных в заказах НЕ работают. Никакой связи hr-ная структура к сбытовой не имеет и в этой свзяи вcтает вопрос как определять рынок сбыта в заголовках заказов, контактов и т.д.?
2. Реальным плюсом от интеграции является то, что нет необходимости дважды заводить сотрудника в r/3 & crm, но и это не факт. Если планировать фоновое задание по синхроницации данных сотрудников (pfal), то реально данные попадут в crm с задержкой. Т.е. выполнение полного цикла заведения сотрудника в обеих системах затягивается. Кроме того, например, у нас есть случаи когда имя пользователя в системах crm & r/3 у одного пользователя разные - опять проблемы. Есть подозрение, что проще дважды завести сотрудника.
3. Может быть вы знаете еще какие-нибудь практические позитивные моменты от hr-интеграции?

С наилучшими пожеланиями,
Алексей

Тогда уж лучше в Excel-е всё делать - ещё проще

Как не имеет а в орг. структуре - в подробных свойствах Орг. Единиц - функции - есть присвоение сбытовым организациям, отделам сбыта, группам сбыта

По 2му пункту согласен.

3ий пункт - в случае существования орг. структуры возможно присвоение профилей центра взаимодействия WinClient отдельным орг. единицам, да и не только. многое можно узнать про присвоение в тр. ppomw.

Не хочется ставить перед собой трудности, а потом героически их преодолевать. Интеграция ради интеграции - это не наш метод

Естественно можно сделать подобные присвоения, но какой в этом смысл? Для чего hr-ная оргединица должна ссылаться на сбытовую (что делать со старой структурой)? Я сейчас говорю про ситуацию, когда hr-интеграция выполняется после продуктивного старта. Может быть у кого-то была такая ситуация. Хотелось узнать мнение коллег. В любом случае спасибо за ответ!

Уход от "трудностей" очень часто означает низкий уровень компетенции Трудностей с интеграцией HR-CRM не очень много при достаточном умении

как какой смысл:
http://help.sap.com/saphelp_crm31/helpd ... ameset.htm

Организационные единицы R/3 (например, сбытовая организация, канал сбыта, сектор, завод с обработкой ТОРО) отображаются в CRM в качестве атрибутов, присваиваемых организационным единицам. Это позволяет оценить значимость той или иной организационной единицы.

Перечисленные атрибуты не являются обязательными для планирования организационной структуры. Однако, они необходимы для автоматического определения организационных данных в документах.

2 Vodoley
Ок. Проблема еще в том, что после hr-интеграции у меня сотрудники переприсвоились другим штатным должностям и hr-ным оргединицам. Если использовать hr-ные оргединицы для сценария продаж (например в качестве отдела сбыта), то встает вопрос что делать со старым оделом сбыта, который ссылается на соотвествующий отдел сбыта r/3. Да и после обновления оргструктуры из r/3 (pfal), в crm все присвоенные атрибуты введенные руками в crm затираются.
А как у вас выстроена оргмодель? Используются ли hr-ные оргединицы для сенария продаж и сервиса?

Посмотрите транзакцию WE05. Посмотрите этот документ, он хоть и старый, но тем не менее... Проверьте как настроены фильтры.

In R/3 you use HR or the HR mini-master to create employee records to be used as partners on the customer master and in sales processing. If you want to have these partner functions in CRM you need to have business partners in CRM that represent the employee records. Business partners in CRM that are maintained in the role ‘Employee’ can be created in one of two ways, manually in CRM or via the ALE method described in this document. There is no middleware object available to download employee records. Only one method can be used, once you enable the ALE method it is no longer possible to manually maintain business partners as employees.

If you decide to manually maintain business partners in the role employee in CRM it is possible to download partner functions that use HR master records. In the central data view of the role employee you can maintain the field ‘personnel number’, this is the number of the HR record in R/3. After you have maintained the personnel number for your employee business partners you need to download CUSTOMER_REL again to be able to view the partner functions and corresponding relationship in CRM. Dual maintenance of these master records is also now required.

If you want to integrate R/3 HR master records with CRM 3.0 via ALE, this document details the steps required.


Steps

The steps detailed below should be undertaken before you run the initial download for object CUSTOMER_REL. If you have already run this initial download you should run the download again after employee records have been downloaded to CRM. Once the employee records are in CRM the delta downloads will

In R/3
• Setup the ALE distribution model (OSS note #312090 provides a good reference for this step). Create distribution model via transaction BD64 (e.g. “Employee Distribution to CRM”)
o Specify your source and target systems
o Use the filters specified in note #312090
• Save model, distribute model
• Environment-->Generate partner profiles for the model; edit partner profiles:
o WE20 Maintain the Sending and Receiving Partner parameters for IDOC’s via ALE.
Type LS for CRM logical system name (e.g. CFS_100)
Outbound Parameters (this is generated automatically)
Message Type: HRMD_ABA
Receiver Port: A000000004
Packet Size: 100
Idoc Type: HRMD_ABA01
Syntax Check : ON
Output Mode: Transfer Idoc immediately

Message Type: SYNCH (this is generated automatically)
Receiver Port: A000000004
Packet Size: 100
Idoc Type: SYNCHRON
Syntax Check : ON
Output Mode: Transfer Idoc immediately
• Activate change pointers for message type HRMD_ABA. IMG: ALE  Modeling & Implementing Business Processes  Master Data Distribution  Activate Change Pointers for Message Type. By activating change pointers it is possible to send deltas to CRM. Without this setting it would be necessary to send all records when you want to update CRM.

In CRM
• Verify distribution model received from R/3 via transaction BD64
• Environment-->Generate partner profiles; edit partner profiles:
o WE20 Maintain the Sending and Receiving Partner parameters for IDOC’s via ALE.
Type LS for R/3 logical system name (e.g. SES_130)
Inbound Parameters (this is generated automatically)
Message Type: HRMD_ABA
Syntax Check : ON
Output Mode: Transfer Idoc immediately

Outbound Parameters (this is generated automatically)
Message Type: SYNCH
Receiver Port: A000000001
Packet Size: 100
Idoc Type: SYNCHRON
Syntax Check : ON
Output Mode: Transfer Idoc immediately

Note: In all of the above partner profiles, there is an "agent" notified in the event of an error processing the IDOCs. This agent type can be a user, position, work center, job, organization, or person. We used agent type "user" and put in a user id. Choose a method that best suits your implementation.

• In CRM configuration setup integration with HR. IMG: CRM  Master Data  Business Partner  Integration Business Partner with HR  Setup Integration With HR. In the entry for ‘CPERS’, ‘EEALE’ enter an ‘X’ in the value field. Also see IMG help for this configuration.
• Create and assign ‘Name format’ value ‘00’ to country US in CRM. Use transactions OY07 and SA13. This step may be needed to avoid errors in CRM inbound IDOC processing if R/3 is country US with ‘Name Format’ value ‘ ’ but the IDOC contains ‘00’.
• Configuration of Partner Function ZM (German for partner function ER). Done via tcode sm30 for table CRMV_PARTNER_MP2 or tcode CRMC_PARTNER_MAP2CRM. This is needed in order for CRM to build partner relationships between Employee and Sold-To, etc.
• If certain employee data is considered sensitive you can use conversion rules to suppress certain data being passed across. To create a conversion rule use transaction BD62. Create a conversion rule e.g. ‘HIDE_EMP_DATA1’ for IDOC segment E1P0002 and ‘HIDE_EMP_DATA2’ for segment E1P0006.
• Create the conversion details for the rules you just created in transaction BD79. For segment E1P0002 you may need to suppress the fields;
o NAME2 – Name at birth – use constant ‘suppressed’ or similar
o RUFNM – Known as – use constant ‘suppressed’ or similar
o GESCH – Gender – use constant ‘0’ for unknown
o GBDAT – Birth date – setting a constant for this field did not work so we mapped field ENDDA (end date) to this field
o GBORT – Birthplace – use constant ‘suppressed’ or similar
o The fields for religion and marital status do not get transferred, no conversion rule is needed.
• For segment E1P0006 you may need to suppress the fields;
o NAME2 – c/o – use constant ‘suppressed’ or similar
o STRAS – House no/street – use constant ‘suppressed’ or similar
o ORT01 – City – use constant ‘suppressed’ or similar
o ORT02 – District – use constant ‘suppressed’ or similar
o PSTLZ – P.Code/city – use constant ‘11111’ or similar
o TELNR – Telephone no. – use constant ‘suppressed’ or similar
o LOCAT – 2nd add Line – use constant ‘suppressed’ or similar
o HSNMR – House number – use constant ‘0 or similar
o POSTA – Apartment ID – use constant ‘suppressed’ or similar
o STRAS_40 – No description – use constant ‘suppressed’ or similar
o ORT01_40 – No description – use constant ‘suppressed’ or similar
o ORT02_40 – No description – use constant ‘suppressed’ or similar
o LOCAT_40 – No description – use constant ‘suppressed’ or similar
o HSNMR_40 – No description – use constant ‘suppressed’ or similar
• Assign the rules to the segment types in transaction BD55. Enter message type HRMD_ABA. Assign the conversion rules segment type E1P0002 and E1P0006 for the appropriate sending and receiving systems.

In R/3
• Run program RHALEINI in R/3 with the following parameters, Object type = O, transfer mode = update, info type = 1000, Receiver partner no = CRM logical system name. This will download HR organizations
• Run program RHALEINI in R/3 with the following parameters, Object type = C, transfer mode = update, info type = 1000, Receiver partner no = CRM logical system name. This will download the jobs.
• Run program RHALEINI in R/3 with the following parameters, Object type = S, transfer mode = update, info type = 1000, Receiver partner no = CRM logical system name. This will download positions.

In CRM
• Run program CRM_COM_ORGMAN_BUPA_INTEGRATE in CRM to create business partners for the downloaded HR org structure. This program should be run periodically in the background – daily or weekly depending on how often your HR org structure changes.

In R/3
• Run program RHALEINI in R/3 with the following parameters, Object type = P, transfer mode = insert, Receiver partner no = CRM logical system name. This will download employees. This program should be run once as part of the initial data load. It should be run before you download customer relationships.

In CRM
• Run program CRMHRALE_CENTRAL_PERSON in CRM to check the consistency of employee data downloaded from R/3. This program should be run periodically – daily or weekly.

In R/3
• Run Change pointer program RHALESMD to create and dispatch the IDOCs based upon the change pointers for changes HR data. This program should be run at least daily.

Additional documentation

OSS notes 363187 & 312090 provide detailed information on the setup of ALE and the parameters to use when running RHALEINI.

The program documentation for RHALEINI also provides additional detailed documentation.

To create a HR master records use transaction PA30. When creating a new employee record do so by creating an ‘Action’ of type ‘Hiring’. Once this is created and saved it is possible to maintain other info types (views) as required. Info type 0105 contains the communication information, if you maintain subtype 0001 (user ID) the user ID should be the same as in CRM. Ideally this would be achieved with CUA. The user ID is expect for some CRM functionality the utilizes responsible employees. If the info type 0006 (address) is to be transferred only subtype 1 (permanent address) can be used by CRM. If subtype 1 is not found an error is posted for the idoc.

Документ действительно очень полезный, спасибо, взял себе на заметку!
P.S. Из личного опыта могу лишь добавить в этот документ следующее: что если вы в r/3 не ведете адреса hr-ных оргединиц, а в crm они обязательны, то при переносе осн. данных персонала (type P), присвоенных этим оргединицам, система прверяет адреса и возникают проблемы. Для отмены проверки адресных данных (нота 503329) необходимо в таблице t77s0 'BUPA' 'ADDR' switch to the initial value ' '.