При использовании связки конфигураций 1С:Управление торговлей 11 (УТ) и 1С:Бухгалтерия предприятия 3.0 (БП) одной из самых острых проблем является синхронизация договорных отношений. Часто возникает ситуация, когда в УТ используются «Соглашения с поставщиками», а в БП они должны превращаться в «Договоры контрагентов». Если процессы в компаниях не регламентированы, это приводит к появлению дублей, «разъезду» взаиморасчетов и недовольству бухгалтерии. Рассмотрим подробно, как работает этот механизм и как исправить ошибки обмена.
Для начала разберем, как именно данные из УТ попадают в БП. Современный обмен работает через универсальный формат (Enterprise Data). В этом формате нет разделения на соглашения и договоры в том виде, в котором мы видим их в интерфейсе УТ. Существует единый объект обмена — Справочник.ДоговорыКонтрагентов.
Проанализируем работу конфигурации УТ. Весь программный код, отвечающий за преобразование, сосредоточен в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Если мы откроем этот модуль, нам нужно найти процедуру ПКО_Справочник_ДоговорыКонтрагентов_Отправка. Именно здесь система решает: взять ли данные из справочника ДоговорыМеждуОрганизациями или из СоглашенияСПоставщиками (в зависимости от настроек использования договоров в УТ).
Если в УТ включена функциональная опция «Договоры с поставщиками», то приоритет отдается им. Если же снабжение работает только через соглашения, система «собирает» виртуальный объект для файла обмена на основе реквизитов соглашения. Важно понимать: для БП нет разницы, что было источником — договор или соглашение. Она получает XML-пакет с данными договора.
В процессе отладки обмена часто всплывает свойство ВиртуальныйДоговор. Разберемся, зачем оно нужно. В 1С:Бухгалтерии договор является обязательным разрезом учета (субконто) на счетах расчетов с контрагентами (60, 62). Если из УТ прилетает документ (например, «Поступление товаров и услуг»), в котором пользователь не указал соглашение, обмен не может оставить поле пустым — документ просто не проведется в БП.
В этом случае механизмы синхронизации создают так называемую «заглушку» — технический договор. В модуле МенеджерОбменаЧерезУниверсальныйФормат в УТ есть специальная проверка. Если система видит договор с пометкой «виртуальный», она может игнорировать его обратную загрузку, чтобы не засорять справочники в УТ техническим мусором из БП.
Что касается «Основного договора», то в БП это значение хранится не в самом справочнике, а в регистре сведений ОсновныеДоговорыКонтрагентов. При первой загрузке соглашения из УТ, если у контрагента в БП еще нет ни одного договора, система автоматически назначает созданный договор основным.
Рассмотрим ситуацию из практики: бухгалтер в БП создает договор вручную (назовем его «Первый»), чтобы разнести банковскую выписку. Позже из УТ прилетает соглашение («Второй»). Несмотря на то, что контрагент один и тот же, система создает новый объект. Почему так происходит?
Синхронизация через универсальный формат использует следующие поля поиска (в порядке приоритета):
Поскольку бухгалтер в БП создал договор вручную, его GUID не совпадает с GUID соглашения из УТ. Если при этом номер или дата договора в БП отличаются от тех, что ввел снабженец в УТ (или если они вообще не заполнены), поиск по реквизитам проваливается. Результат — дубль договора и «разъезд» сальдо.
Чтобы избежать хаоса, необходимо принудительно заставить пользователей УТ заполнять аналитику. Если административные меры не помогают, используем расширение конфигурации. Нам нужно перехватить событие проведения документов, которые инициируют оплату или поступление (например, ЗаявкаНаРасходованиеДенежныхСредств или ПриобретениеТоваровУслуг).
Проанализируем пример кода для расширения, который проверяет заполнение соглашения перед записью документа:
&НаСервере
Процедура ПроверкаЗаполненияСоглашения_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем только при проведении
Если РежимПроведения = РежимПроведенияДанных.Проведение Тогда
// Если это документ приобретения и соглашение не заполнено
Если ЭтотОбъект.Метаданные().Имя = "ПриобретениеТоваровУслуг" Тогда
Если НЕ ЗначениеЗаполнено(ЭтотОбъект.Соглашение) Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Необходимо заполнить соглашение с поставщиком для корректного обмена с бухгалтерией!";
Сообщение.Поле = "Соглашение";
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует, что в БП не полетят документы с «пустой» аналитикой, которые провоцируют бухгалтеров на ручное творчество.
Типовой обмен Enterprise Data часто настроен в одну сторону для справочников договоров (из торговой базы в бухгалтерскую). Если вам необходимо, чтобы договоры, заведенные в БП, превращались в соглашения в УТ, потребуется серьезная кастомизация модуля МенеджерОбменаЧерезУниверсальныйФормат на стороне УТ.
Выясним причину, по которой это не сделано «из коробки»: соглашение в УТ содержит гораздо больше управленческих реквизитов (графики оплаты, ценовые условия, склады), которых просто нет в БП. При загрузке договора из БП в УТ система должна инициализировать эти реквизиты значениями по умолчанию.
Для реализации такой логики нужно найти в менеджере обмена процедуру ПКО_Справочник_ДоговорыКонтрагентов_Получение. В ней описывается алгоритм создания объекта в УТ на основе входящих данных. Вам придется прописать создание объекта Справочники.СоглашенияСПоставщиками.СоздатьОбъект() и заполнение его минимально необходимых полей (Статус = Действует, ХозяйственнаяОперация = ЗакупкаУПоставщика и т.д.).
Для стабильной работы обмена рекомендуем придерживаться следующих правил:
Разберем еще один важный момент: если вы все же решили использовать и соглашения, и договоры в УТ одновременно, помните, что в БП они могут «склеиваться» или, наоборот, разделяться в зависимости от настроек «Детализация расчетов» в соглашении. Если выбрана детализация «По заказам» или «По накладным», БП может вести себя иначе, чем при детализации «По договорам».
Подводя итог, можно сказать, что корректный обмен между УТ 11 и БП 3.0 — это на 30% техническая настройка правил и на 70% жесткий регламент работы пользователей. Использование программных запретов в УТ является самым эффективным способом поддержания порядка в учете.