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