Как настроить односторонний обмен данными из 1С:Бухгалтерия 3.0 в 1С:CRM 3.0 и решить проблемы с созданием документов

← На главную

Настройка интеграции между конфигурациями «1С:Бухгалтерия предприятия 3.0» (БП) и «1С:CRM 3.0» — частая задача при автоматизации бизнес-процессов. Однако при реализации одностороннего обмена в направлении БП -> CRM разработчики часто сталкиваются с тем, что новые документы (например, счета на оплату покупателям) упорно отказываются создаваться на стороне CRM-системы. При этом связанные справочники переносятся некорректно, а единицы измерения номенклатуры остаются пустыми.

В этой статье мы подробно разберем, почему возникает подобное поведение систем, проанализируем логику работы типового механизма обмена на базе EnterpriseData (КД 3.0) и найдем решения для каждой проблемы по шагам.

Выясняем причину: почему новые «Счета на оплату» не создаются в CRM

Рассмотрим ситуацию из практики. При попытке перенести новый документ «Счет на оплату покупателю» из БП в CRM документ не появляется в базе-приемнике, хотя сам сеанс обмена завершается без критических ошибок. Выясним, почему это происходит.

В архитектуре совместного использования решений 1С:CRM и 1С:Бухгалтерия разработчики вендора заложили жесткую концептуальную логику: первичным источником («мастером») для выставления счетов является CRM-система. Предполагается следующая схема:

Менеджер создает счет в CRM.
Документ мигрирует в БП для отражения в учете.
Из БП обратно в CRM возвращаются только изменения (например, статус оплаты или корректировки реквизитов).

Чтобы исключить хаос и дублирование документов, на стороне CRM по умолчанию заблокировано создание новых документов «Счет на оплату», если они изначально пришли из БП. Проанализируем программный код в модуле менеджера обмена CRM. За обработку загрузки отвечает процедура:


Процедура ПОД_Документ_СчетНаОплатуПокупателю_Получение_ПриОбработке(ДанныеXDTO, ИспользованиеПКО, КомпонентыОбмена)
    
    ИспользованиеПКО.Документ_СчетНаОплатуПокупателю_Получение = Истина;
    
    СсылкаНаСчет = ОбменДаннымиXDTOСервер.СсылкаОбъектаПоУИДОбъектаXDTO(
        ДанныеXDTO.Ссылка.Значение, 
        Тип("ДокументСсылка.CRM_СчетНаОплатуПокупателю"),
        КомпонентыОбмена
    );
    
    // Типовой код вендора, блокирующий создание нового документа:
    ИспользованиеПКО.Документ_СчетНаОплатуПокупателю_Получение = ОбъектСуществуетВБазе(СсылкаНаСчет);

КонецПроцедуры

Обратите внимание на последнюю строку. Функция ОбъектСуществуетВБазе(СсылкаНаСчет) проверяет, зарегистрирован ли уже такой документ в CRM. Если документа нет (это новый счет, созданный в БП), функция возвращает Ложь. В результате свойству ИспользованиеПКО присваивается значение Ложь, и загрузка объекта полностью игнорируется.

Решение проблемы: Если перед нами стоит задача настроить полноценный односторонний обмен БП -> CRM с возможностью создания новых документов в приемнике, эту логику необходимо переопределить. Напрямую редактировать типовую конфигурацию крайне не рекомендуется, чтобы не усложнять последующие обновления системы. Правильнее всего использовать механизм расширений конфигурации.

Создадим расширение для CRM и переопределим процедуру получения документа, принудительно устанавливая признак использования ПКО в значение Истина:


&Вместо("ПОД_Документ_СчетНаОплатуПокупателю_Получение_ПриОбработке")
Процедура Расш_ПОД_Документ_СчетНаОплатуПокупателю_Получение_ПриОбработке(ДанныеXDTO, ИспользованиеПКО, КомпонентыОбмена)
    
    // Вызываем оригинальную логику определения ссылки
    СсылкаНаСчет = ОбменДаннымиXDTOСервер.СсылкаОбъектаПоУИДОбъектаXDTO(
        ДанныеXDTO.Ссылка.Значение, 
        Тип("ДокументСсылка.CRM_СчетНаОплатуПокупателю"),
        КомпонентыОбмена
    );
    
    // Принудительно разрешаем загрузку новых документов
    ИспользованиеПКО.Документ_СчетНаОплатуПокупателю_Получение = Истина;

КонецПроцедуры

После применения данного расширения новые документы начнут успешно создаваться в CRM.

Решаем проблему пустых Единиц Измерения (ЕИ) в документах

После обхода блокировки создания документов вы можете столкнуться со следующей проблемой: новые счета создаются, но табличная часть «Товары» переносится некорректно — реквизит ЕдиницаИзмерения (ЕИ) у номенклатурных позиций остается пустым.

При использовании универсального формата обмена EnterpriseData (КД 3.0) сопоставление таких базовых справочников, как «Классификатор единиц измерения» (ОКЕИ), происходит по уникальным идентификаторам (GUID). Если базы БП и CRM велись независимо, GUID аналогичных записей (например, штуки с кодом «796») в них гарантированно различаются. В таких случаях система ищет соответствие в специальном регистре сведений «Публичные идентификаторы синхронизируемых объектов».

Выясним по шагам, как исправить сопоставление Единиц Измерения:

Заполнение классификаторов: Убедитесь, что в обеих базах (БП и CRM) справочник «Классификатор единиц измерения» заполнен стандартными значениями из общего классификатора ОКЕИ. Коды ЕИ должны строго совпадать (например, для штук код должен быть «796»).
Синхронизация базовых справочников: Перед началом выгрузки документов необходимо выполнить первоначальную синхронизацию самих классификаторов. При обмене система сопоставит их по полям поиска (Код, Наименование) и сделает соответствующие записи сопоставления GUID в регистре «Публичные идентификаторы синхронизируемых объектов».
Проверка обработчиков поиска: Если автоматическое сопоставление не отработало, в модуле менеджера обмена CRM для ПКО Справочник_КлассификаторЕдиницИзмерения_Получение в обработчике событий ПоляПоиска следует явно указать поиск по коду ОКЕИ, если поиск по уникальному идентификатору вернул пустую ссылку.

Разбираем нюансы выгрузки связанных объектов через EnterpriseData

Часто программисты пытаются выполнить перенос документов с помощью стандартной обработки «Выгрузка загрузка EnterpriseData». При этом возникает путаница: пользователь выбирает конкретный документ «Счет на оплату», настраивает отбор, выполняет выгрузку, но в CRM документ не появляется. Выгрузка документа вместе со справочником контрагентов также не дает результата.

Посмотрим на ситуацию изнутри. Стандартная обработка «Выгрузка загрузка EnterpriseData» работает по принципу «прямого действия»: она выгружает исключительно те объекты, которые явно указаны в настройках отбора. Она не выполняет автоматическую рекурсивную выгрузку всей цепочки связанных ссылок.

Если в файле выгрузки присутствует документ, ссылающийся на контрагента, договор, банковский счет и номенклатуру, но сами эти объекты целиком (со всеми их реквизитами) в XML-пакет не попали, то на стороне приемника (CRM) возникнут проблемы:

Документ не сможет записаться из-за отсутствия обязательных реквизитов.
Объекты запишутся с битыми ссылками (вида «Объект не найден»).
Сработает логика контроля целостности данных, и транзакция по созданию документа будет отменена.

Для решения этой проблемы рассмотрим два возможных сценария:

Сценарий 1. Поэтапный перенос данных. При использовании стандартной обработки вам необходимо строго соблюдать последовательность выгрузки данных. Сначала выгружаются и загружаются базовые нормативно-справочные данные, а затем — сами документы:

Выгрузите классификаторы (ЕИ, валюты, страны).
Выгрузите справочник Номенклатура (с установкой необходимых отборов).
Выгрузите справочник Контрагенты совместно со связанными справочниками ДоговорыКонтрагентов и БанковскиеСчета.
И только после успешного импорта НСД в базу CRM производите выгрузку самих документов СчетНаОплатуПокупателю.

Сценарий 2. Использование модифицированной обработки. На профессиональных ресурсах сообщества 1С доступны доработанные версии обработки «Выгрузка загрузка EnterpriseData». Главное их преимущество — встроенный алгоритм автоматического анализа ссылочных реквизитов. При выборе документа такая обработка сама находит все связанные справочники (номенклатуру, договоры, контрагентов, склады) и автоматически включает их в XML-выгрузку, обеспечивая ссылочную целостность на стороне приемника.

Выбор технологии обмена: Конвертация данных 2.0 или 3.0?

Проанализируем архитектурный вопрос: на каком инструменте лучше реализовывать и поддерживать правила обмена между БП и CRM — на классической «Конвертации данных 2.0» (КД 2) или на современной «Конвертации данных 3.0» (КД 3), использующей формат EnterpriseData?

Рассмотрим плюсы и минусы обоих подходов:

Преимущества использования КД 3.0 (EnterpriseData):

Независимость от обновлений: Это главное преимущество. Правила обмена для БП 3.0 уже встроены в саму конфигурацию и поддерживаются фирмой «1С». При частых обновлениях бухгалтерии вам не придется каждый раз переписывать правила. Достаточно один раз настроить правила приема данных на стороне CRM.
Стандартизация: Формат обмена стандартизирован. Если в будущем в ландшафт интеграции добавится новая база (например, «1С:Управление нашей фирмой»), ее будет намного проще подключить к общему контуру обмена.

Преимущества использования КД 2.0:

Простота разработки «здесь и сейчас»: Если у разработчика есть опыт работы в КД 2.0, написать правила переноса напрямую из БП в CRM под конкретные релизы можно значительно быстрее. Не нужно разбираться в сложной схеме формата EnterpriseData.
Гибкость при работе со специфичными реквизитами: Отраслевые реквизиты CRM-системы легче мапить напрямую, минуя промежуточный формат XDTO.

Однако стоит учитывать долгосрочную перспективу. При использовании КД 2.0 любое крупное обновление «1С:Бухгалтерии» (в которой часто меняется структура метаданных) может полностью сломать обмен, что потребует оперативного вмешательства программиста. В случае с КД 3.0 вы защищены от таких рисков стандартом обмена.

Важно отметить, что для точечной доработки обмена на КД 3.0 разворачивать тяжелую конфигурацию «Конвертация данных 3» не всегда обязательно. Вся логика работы универсального формата сосредоточена в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Любые правила конвертации свойств или обработчики событий (ПОД/ПКО) можно оперативно переопределить прямо в коде этого модуля через механизм расширений, что делает поддержку обмена максимально удобной и быстрой.