Как реализовать признак «Выгружено в Бухгалтерию» при обмене данными между УТ и БП?

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

Варианты реализации хранения признака выгрузки

Существует несколько архитектурных подходов к хранению статуса выгрузки объектов. Проанализируем самые популярные решения, которые обсуждаются в сообществе разработчиков:

1. Добавление булевого реквизита в сам документ. Это самое очевидное решение, когда в структуру документа добавляется новый реквизит с типом Булево (например, ЗагруженВБухгалтерию). После успешной загрузки в БП, обработка обращается к УТ и проставляет эту галочку.
2. Использование дополнительных сведений и реквизитов. Чтобы не снимать типовую конфигурацию с поддержки ради одной галочки, добавим признак через стандартный механизм подсистемы БСП «Дополнительные реквизиты и сведения». Это позволит вывести нужный флаг на форму без вмешательства в метаданные.
3. Создание отдельного регистра сведений. Можно организовать один или два непериодических регистра сведений. В первом регистре фиксируем объекты, зарегистрированные к выгрузке, во втором — успешно выгруженные. Этот подход схож с механикой работы типовых планов обмена.

Рассмотрим подробнее реализацию через запись реквизита объекта по COM-соединению и выясним причину потенциальных ошибок.

Практическая реализация и безопасность записи объекта

Посмотрим на пример кода, который часто пишут начинающие разработчики для простановки флага в базе УТ через COM-объект:

ОбъектУТРеализация = РеализацияУТ.GetObject;
ОбъектУТРеализация.АМ_ЗагруженВБухгалтерию = Истина;
ОбъектУТРеализация.Записать;

С первого взгляда код рабочий, но давайте проанализируем ситуацию глубже. Метод Записать в таком виде является крайне ресурсоемким. При вызове записи на стороне УТ будут срабатывать абсолютно все обработчики проведения, проверки заполнения и контроля остатков. Это не только сильно замедлит процесс обмена, но и может привести к ошибке записи (например, если в УТ уже закрыт период редактирования или изменились остатки товаров).

Правильная практика: перед записью объекта (особенно по COM) необходимо отключать лишние бизнес-логические проверки. Для этого мы установим свойство загрузки обмена данными. Перепишем наш код правильно:

ОбъектУТРеализация = РеализацияУТ.GetObject;
ОбъектУТРеализация.АМ_ЗагруженВБухгалтерию = Истина;

// Отключаем проверки и контроль при записи
ОбъектУТРеализация.ОбменДанными.Загрузка = Истина;

ОбъектУТРеализация.Записать;

Современные подходы: Расширения и Статусная модель

Если мы решаем добавлять реквизиты физически, то современным стандартом разработки в 1С является использование Расширений конфигурации. Вместо добавления реквизита в основную конфигурацию, создадим расширение, добавим в него наш реквизит и выведем его на формы документа и списка. База при этом останется на полной поддержке.

Кроме того, использование простой «галочки» (типа Булево) ограничивает возможности контроля. Гораздо эффективнее внедрить статусную модель, используя реквизит с типом Перечисление или строковым справочником статусов. Рассмотрим примеры возможных статусов:

1. К выгрузке — документ готов к отправке.
2. Выгружено — успешная передача.
3. Ошибка выгрузки — обмен прервался или данные не прошли валидацию.
4. Изменено после выгрузки — пользователь отредактировал документ задним числом.

Такая модель позволит бухгалтерам легко фильтровать проблемные документы.

Альтернативы самописному COM-обмену

Часто программисты пишут свои обмены по COM, обосновывая это сложными требованиями заказчика (например, отбирать документы по конкретным складам, подменять контрагентов и договоры «на лету», менять даты). Однако технология COM официально признана устаревшей и имеет массу недостатков: она не работает на Linux-серверах, требует жесткого совпадения релизов платформы и часто зависает, блокируя рабочие процессы.

Рассмотрим лучшие альтернативы:

1. HTTP-сервисы и REST API (или OData). Вы можете опубликовать свой HTTP-сервис на стороне УТ. База БП будет отправлять GET-запросы для получения списка нужных документов в легком формате JSON, а затем отправлять POST-запросы об успешной загрузке для простановки тех самых статусов выгрузки. Это работает быстро, стабильно и кроссплатформенно.
2. Типовые планы обмена и Конвертация Данных. Всю сложную логику (фильтрацию складов, замену контрагентов) можно реализовать в штатных механизмах обмена 1С. В Конвертации Данных существуют Обработчики событий (такие как Перед выгрузкой или При выгрузке), куда можно вставить небольшие фрагменты кода (ПКО и ПКС), сохранив при этом производительность и надежность типовой синхронизации (использующей подсистему регистрации изменений через планы обмена).

Используя типовые планы обмена совместно с правилами конвертации, мы избавляем себя от необходимости изобретать механизмы регистрации измененных объектов и простановки флагов выгрузки — платформа сделает это за нас максимально оптимально.