Как настроить обмен между базами 1С для выгрузки только новых контрагентов и договоров?

Стоит задача организовать регулярный обмен данными между двумя конфигурациями «1С:Бухгалтерия 3.0». Важное условие — из базы-источника в базу-приемник должны попадать только новые контрагенты и их договоры. Существующие объекты в базе-приемнике затрагивать не нужно. Кроме того, весь процесс должен запускаться автоматически по расписанию. Разберем, какие технологии для этого существуют и какой подход выбрать для решения этой задачи.

Основная сложность, с которой сталкиваются при такой настройке, — это механизм отслеживания новых объектов. Как системе понять, какой контрагент был создан после последней выгрузки? Для этого в платформе «1С:Предприятие» существует специальный инструмент.

Ключевой механизм: Планы обмена

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

Как это работает:

1. Вы включаете нужные вам объекты (в нашем случае справочники Контрагенты и ДоговорыКонтрагентов) в состав Плана обмена.
2. После этого платформа начинает автоматически регистрировать любые изменения этих объектов: создание нового элемента или изменение существующего.
3. При запуске обмена система обращается к таблице регистрации изменений и формирует пакет данных, включающий только то, что изменилось с момента последней успешной выгрузки.

Таким образом, вам не нужно самостоятельно придумывать, как «отлавливать» новые объекты. План обмена сделает это за вас. Вы можете создать новый план обмена специально для вашей задачи или добавить новый узел в уже существующий, чтобы не нарушать работу действующих обменов.

Теперь, когда мы разобрались с механизмом отслеживания, рассмотрим два основных способа реализации самого обмена.

Решение 1: Современный подход через штатную синхронизацию данных (БСП)

Для обмена между одинаковыми или похожими типовыми конфигурациями, какими являются две «Бухгалтерии 3.0», этот способ является предпочтительным. Он основан на встроенной в конфигурацию Библиотеке стандартных подсистем (БСП) и технологии «Конвертация данных 3.0».

Преимущества:

• Это штатный, поддерживаемый фирмой «1С» механизм.
• Простая первоначальная настройка через пользовательский интерфейс.
• Наглядное представление сопоставленных и несопоставленных объектов.

Проанализируем шаги настройки и доработки для нашей конкретной задачи.

Шаг 1. Настройка синхронизации.

В разделе Администрирование – Синхронизация данных нужно создать новую настройку, выбрав в качестве корреспондента такую же конфигурацию «Бухгалтерия предприятия, ред. 3.0». Мастер настройки проведет вас по основным этапам подключения.

Шаг 2. Ограничение выгружаемых данных.

По умолчанию синхронизация будет пытаться выгрузить много данных, включая документы. Нам это не нужно. Чтобы ограничить состав выгрузки, необходимо изменить правила регистрации объектов. Вы можете указать, чтобы документы не выгружались совсем, или даже более тонко настроить выгрузку, добавив в правила регистрации условие Отказ = Истина; для всех объектов, кроме контрагентов и договоров.

Шаг 3. Запрет на обновление существующих объектов в приемнике.

Это ключевой момент нашей задачи. Нам нужно, чтобы при загрузке данных создавались только новые контрагенты, а если контрагент с таким же уникальным идентификатором уже есть в базе-приемнике, он не обновлялся. Для этого потребуется небольшая доработка конфигурации-приемника, которую лучше всего выполнять через расширение, чтобы не снимать конфигурацию с поддержки.

В правилах обмена, которые используются при синхронизации, есть специальные обработчики событий. Нам нужен обработчик ПередЗаписьюПолученныхДанных для правила конвертации объекта (ПКО) Справочник_Контрагенты.

Добавим в расширение следующий код:

Процедура ПКО_Справочник_Контрагенты_Получение_ПередЗаписьюПолученныхДанных(ПолученныеДанные, ДанныеИБ, Отказ)

    // Если объект в базе-приемнике уже найден (ДанныеИБ не пустое),
    // то мы отменяем его запись.
    // Таким образом, будут создаваться только новые объекты.
    Если НЕ ДанныеИБ = Неопределено Тогда
        Отказ = Истина;
    КонецЕсли;

Этот код проверяет, был ли найден соответствующий объект в информационной базе-приемнике (ДанныеИБ). Если да, то он устанавливает параметр Отказ в значение Истина, что отменяет запись полученного объекта. В результате обновлений существующих контрагентов не произойдет.

Решение 2: Гибкий подход через «Конвертацию данных 2.1»

«Конвертация данных 2.1» (КД 2.1) — это более старая, но все еще очень мощная и гибкая технология. Она отлично подходит для сложных обменов, обменов с нетиповыми конфигурациями или когда требуется полный контроль над каждым полем.

Преимущества:

• Полный контроль. Можно детально настроить, какое поле откуда и куда переносится, по каким полям искать существующие объекты.
• Гибкость поиска. Можно настроить поиск контрагентов не по внутреннему идентификатору, а по связке полей, например ИНН + КПП, что является более надежным способом избежать дублей.
• Быстрая доработка правил. Для опытного разработчика внести изменения в правила КД 2.1 часто быстрее, чем разбираться с доработкой правил на БСП.

Рассмотрим шаги для этого решения:

1. Создание правил в КД 2.1. Запускаем отдельную конфигурацию «Конвертация данных 2.1», загружаем в нее структуру метаданных из обеих баз (источника и приемника).
2. Настройка правил конвертации. Создаем Правила конвертации объектов (ПКО) для справочников Контрагенты и ДоговорыКонтрагентов.
3. Настройка поиска. В ПКО для контрагентов на закладке «Настройки» указываем поля поиска: ставим галочки напротив полей ИНН и КПП. Это гарантирует, что система будет искать существующего контрагента по этим реквизитам.
4. Настройка поведения при нахождении. Устанавливаем флаг «Не замещать существующие объекты в приемнике при загрузке», чтобы данные не обновлялись.
5. Создание правил выгрузки. Создаем Правила выгрузки данных (ПВД), указывая, что выгрузка будет производиться на основании данных из Плана обмена.
6. Сохранение и загрузка правил. Сохраняем готовые правила в XML-файл и загружаем их в универсальную обработку обмена данными в базе-источнике.

Хотя этот метод требует больше ручной работы в конфигураторе «Конвертация данных», он дает непревзойденную гибкость в настройке логики обмена.

Автоматизация обмена по расписанию

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

• При использовании штатной синхронизации (БСП), сценарий для автоматического запуска настраивается прямо в форме настройки синхронизации. Вы создаете новый сценарий, указываете расписание (например, каждый день в 3:00) и система автоматически создаст нужное регламентное задание.
• При использовании КД 2.1, вам нужно будет создать регламентное задание вручную (Администрирование – Обслуживание – Регламентные операции). В этом задании нужно будет прописать вызов обработки универсального обмена с нужными параметрами (путь к файлу правил, узел обмена и т.д.).

Итоги: что выбрать?

Проанализируем оба варианта в контексте нашей задачи:

• Для обмена между двумя одинаковыми конфигурациями «Бухгалтерия 3.0», когда требуется лишь незначительная кастомизация (как в нашем случае — не обновлять существующие), рекомендуется использовать штатную синхронизацию данных на БСП. Это современный, поддерживаемый и более простой в первоначальной настройке путь.
• «Конвертация данных 2.1» остается вашим выбором, если в будущем планируется усложнение правил, интеграция с сильно измененной или нетиповой конфигурацией, или если вам нужен более надежный поиск дублей по ключевым реквизитам (ИНН+КПП), а не по внутренним идентификаторам.

Оба подхода решают поставленную задачу, но выбор зависит от ваших долгосрочных планов по поддержке и развитию этого обмена.