При настройке двустороннего обмена данными между конфигурациями «1С:Управление торговлей» (УТ 11) и «1С:Бухгалтерия предприятия» (БП 3.0) пользователи часто сталкиваются с неприятным поведением системы. Бухгалтер вносит незначительные изменения в документ поступления на стороне БП (например, корректирует способ зачета авансов в договоре или меняет входящий номер накладной), а после очередной синхронизации в УТ у этого документа автоматически меняется хозяйственная операция (например, сбрасывается на «Импорт» или «Закупка у поставщика»).
В этой статье мы подробно разберем, почему возникает данная проблема с точки зрения архитектуры платформы «1С:Предприятие 8», и рассмотрим несколько практических вариантов ее решения — от изменения административных регламентов до программной доработки системы.
---
Основная причина изменения хозяйственной операции кроется в логике работы универсального формата обмена EnterpriseData, реализованного через общий модуль МенеджерОбменаЧерезУниверсальныйФормат. Здесь срабатывают два ключевых фактора:
ПриобретениеТоваровУслуг имеет детальное разделение по хозяйственным операциям (например: Закупка у поставщика, Импорт, Ввоз из ЕАЭС, Закупка через подотчетника). В БП 3.0 этот документ конвертируется в более простой вид — Поступление (акт, накладная, УПД). В бухгалтерской программе нет столь глубокого деления хоз. операций, из-за чего при выгрузке из УТ в БП происходит свертка данных «многие-к-одному». Когда бухгалтер меняет что-либо в БП, измененный документ регистрируется к обмену. При обратной загрузке в УТ алгоритмы импорта пытаются «восстановить» хоз. операцию по косвенным признакам, так как в БП этой информации изначально не было. Система часто подставляет значение по умолчанию, которое не совпадает с исходным.Закупка (импорт)). После перезаписи договора документ приобретения, ссылающийся на него, при обновлении из БП сверяет свою хоз. операцию с целью договора в УТ и принудительно меняет её на «Импорт».Разберем подробнее варианты решения этой проблемы, начиная с организационных и заканчивая техническими решениями.
---
Самый надежный способ избежать порчи оперативных данных в торговой базе — сделать обмен односторонним (только из УТ в БП). В такой схеме УТ выступает в роли единственного первоисточника документов поступления и продаж, а БП — получателем готовых данных для регламентированного учета.
Часто препятствием для этого становится необходимость загрузки банковских выписок. Бухгалтеры привыкли загружать банк напрямую в БП и затем перегружать платежные документы в УТ через двусторонний обмен. Рассмотрим аргументы, которые помогут убедить бухгалтера изменить этот подход и загружать банк напрямую в УТ:
После переноса загрузки банка в УТ обмен можно безболезненно перевести в односторонний режим (только выгрузка из УТ в БП).
---
Если полностью отказаться от двустороннего обмена невозможно, мы можем настроить правила регистрации так, чтобы документы поступления из БП никогда не регистрировались к отправке обратно в УТ. Это позволит бухгалтеру вносить изменения в БП без риска перезаписать документы в УТ.
Проанализируем, как это сделать по шагам:
Поступление (акт, накладная, УПД).
Отказ = Истина;
Этот код полностью заблокирует автоматическую регистрацию изменений для документов поступления на стороне БП. При этом сам документ Поступление не будет выгружаться в УТ, сохраняя там исходные оперативные данные и хозяйственные операции.
---
Если ситуация требует разового решения проблемы без изменения конфигураций и правил регистрации, можно использовать стандартные инструменты выборочной синхронизации в БП 3.0:
Поступление (акты, накладные, УПД).---
Если двусторонний обмен документами поступления строго необходим (например, для синхронизации номеров входящих документов, дат или статусов оригиналов), эту проблему можно решить программным путем с помощью расширения конфигурации на стороне УТ 11.
Идея решения заключается в том, чтобы при импорте данных из БП проверять, существует ли уже данный документ в УТ. Если документ существует и он уже проведен, мы запрещаем обновлять его ключевые реквизиты (такие как ХозяйственнаяОперация и Договор.ЦельДоговора).
Рассмотрим пример реализации такого алгоритма в расширении для общего модуля, отвечающего за загрузку данных через универсальный формат:
&Вместо("ПередЗаписьюПолученныхДанных")
Процедура Расш_ПередЗаписьюПолученныхДанных(ДанныеИмпорта, ПолученныеДанные, Отказ)
// Проверяем тип загружаемого объекта
Если ТипЗнч(ПолученныеДанные) = Тип("ДокументОбъект.ПриобретениеТоваровУслуг") Тогда
// Попытаемся найти существующий документ в базе УТ по ссылке
СсылкаНаДокумент = ПолученныеДанные.Ссылка;
Если ЗначениеЗаполнено(СсылкаНаДокумент) Тогда
// Получаем текущие значения из базы данных без транзакционного кэша
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПриобретениеТоваровУслуг.Проведен КАК Проведен,
| ПриобретениеТоваровУслуг.ХозяйственнаяОперация КАК ХозяйственнаяОперация
|ИЗ
| Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслуг
|ГДЕ
| ПриобретениеТоваровУслуг.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", СсылкаНаДокумент);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
// Если документ в УТ уже проведен, сохраняем его исходную хозяйственную операцию
Если Выборка.Проведен Тогда
ПолученныеДанные.ХозяйственнаяОперация = Выборка.ХозяйственнаяОперация;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Данный код, внедренный через расширение, гарантирует, что любые изменения, пришедшие из бухгалтерии, обновят только разрешенные поля (например, номера входящих документов или комментарии), но не затронут критически важную управленческую аналитику — хозяйственную операцию документа в торговой базе.
Используя приведенные методики и технические решения, вы сможете полностью исключить порчу данных в «1С:Управление торговлей» при синхронизации с «1С:Бухгалтерией предприятия».