При настройке обмена данными между конфигурациями 1С:Бухгалтерия предприятия 3.0 (БП) и 1С:Управление нашей фирмой 3.0 (УНФ) пользователи часто сталкиваются с ситуацией, когда справочники и кассовые документы мигрируют успешно, но документы Счет на оплату покупателю, созданные в БП, упорно не появляются в УНФ. Рассмотрим подробно, почему это происходит, как устроена логика обмена и что можно сделать в этой ситуации.
Для начала проанализируем ситуацию: в обеих программах настроена стандартная синхронизация через Универсальный формат (EnterpriseData). Пользователь видит, что счета в БП регистрируются к обмену, пакеты данных уходят, но в УНФ список документов остается пустым. При этом ошибки в журнале регистрации могут отсутствовать. Чтобы не пропустить момент, когда данные перестают поступать, полезно использовать отправку оповещений на почту при остановке обмена для УНФ 3.0.
Выясним причину такого поведения. Основная концепция разработчиков 1С при создании интеграций между управленческими и регламентированными системами строится на принципе «единой точки ввода». В связке БП и УНФ именно УНФ выступает ведущей системой для оперативного учета. Это означает, что все первичные события продаж, включая выставление счетов и фиксацию заказов, должны происходить в управленческой базе.
Разберем, как движутся документы в стандартном обмене:
Таким образом, правила обмена в типовой конфигурации просто не содержат алгоритмов для создания документа Счет на оплату в УНФ на основании данных, пришедших из БП. Программа-приемник получает данные, видит незнакомый тип объекта для данного направления и игнорирует его.
Рассмотрим технический нюанс, который часто вводит в заблуждение администраторов 1С. В плане обмена СинхронизацияДанныхЧерезУниверсальныйФормат объект ДокументСсылка.СчетНаОплатуПокупателю включен в состав метаданных. Это позволяет платформе регистрировать изменения документа. Для управления этим процессом в нестандартных ситуациях может потребоваться регистрация объектов для обмена по организации с помощью внешних инструментов.
Однако регистрация — это лишь первый этап. Вторым этапом выступают правила выгрузки (XSLT-преобразования), которые определяют, какие из зарегистрированных данных реально попадут в XML-пакет EnterpriseData. В типовом коде БП для направления «в УНФ» эти правила могут быть опущены. Но даже если данные ушли, на стороне УНФ правила загрузки настроены только на прием оплат и реализаций. В некоторых случаях требуется доработка синхронизации данных через универсальный формат, чтобы система корректно обрабатывала специфические версии формата или новые реквизиты объектов.
Проанализируем пример того, как технически может выглядеть регистрация, которая в итоге никуда не приведет:
// Пример кода, который программно регистрирует изменения,
// но не гарантирует прием на той стороне
ПланыОбмена.ЗарегистрироватьИзменения(УзелИнформационнойБазы, Метаданные.Документы.СчетНаОплатуПокупателю);
Система видит изменения, помещает их в очередь, но при попытке сопоставить объект с правилами EnterpriseData для целевой конфигурации УНФ, механизм понимает, что соответствия нет.
Важно отметить, что переход с редакции 1.6 на 3.0 в «Управлении нашей фирмой» не изменил логику синхронизации. Версия 3.0 является развитием 1.6 с обновленным интерфейсом и унифицированной нумерацией, но механизмы обмена данными остались прежними. Если вы используете описание обмена для версии 1.6, оно будет актуально и для 3.0.
Если бизнес-процесс вашей компании жестко требует выставления счетов именно в Бухгалтерии, существует несколько путей решения задачи. Рассмотрим их подробнее.
Вариант 1: Изменение бизнес-процесса (рекомендуемый)
Перенесите выставление счетов в УНФ. Это позволит вам использовать весь потенциал программы: контроль остатков, резервирование товаров, анализ воронки продаж. После выставления счета в УНФ он автоматически попадет в БП при следующей синхронизации. Для этого в настройках синхронизации на стороне УНФ проверьте положение флага Переносить заказы покупателей как счета на оплату. Если он включен, то Заказ покупателя из УНФ превратится в Счет на оплату в БП.
Вариант 2: Доработка правил обмена
Поскольку обмен идет через универсальный формат, вы можете изменить правила преобразования данных. Для этого потребуется:
СчетНаОплатуПокупателю (БП) в объект СчетНаОплату или ЗаказПокупателя (УНФ) в формате EnterpriseData.Вариант 3: Использование сторонних обработок
Рассмотрим вариант использования внешних инструментов. Существуют настройки выгрузки документов из БП 3.0, которые позволяют принудительно включить передачу первичных документов в УНФ. Это позволяет избежать прямого редактирования правил в «Конвертации данных», что значительно упрощает поддержку систем в будущем.
Проанализируем текущие настройки вашей синхронизации, чтобы убедиться, что проблема именно в архитектуре, а не в случайной галочке. Выполните следующие действия:
Подводя итог, можно утверждать: отсутствие счетов из БП в УНФ — это не ошибка, а штатное поведение программы. Система «охраняет» управленческий учет от ввода данных из бухгалтерии, которые могут не содержать необходимых аналитик (склады, проекты, подразделения, спецификации номенклатуры). Для корректной работы совместного использования БП 3.0 и УНФ 3.0 старайтесь придерживаться правила: «Сделка начинается в УНФ, а заканчивается в БП».