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