Как правильно организовать историю изменений и статистику переадресации задач в 1С

← На главную

При разработке систем учета заявок и поручений часто возникает необходимость не просто хранить текущее состояние документа, но и видеть всю хронологию событий: кто создал задачу, как менялся исполнитель, когда произошла переадресация и кто в итоге ее выполнил. В контексте конфигурации 1С:Документооборот и систем на базе БСП (Библиотека стандартных подсистем) существует несколько подходов к решению этой задачи. Рассмотрим их подробно, проанализируем плюсы и минусы каждого метода и разберем по шагам реализацию.

Метод 1: Стандартное версионирование объектов (БСП)

Если ваша основная цель — аудит изменений реквизитов (например, кто и когда изменил поле Исполнитель или Адресат), самым быстрым решением будет подключение документа к подсистеме Версионирование объектов. Этот механизм уже встроен в большинство современных типовых конфигураций.

Рассмотрим алгоритм подключения самописного документа к версионированию:

Включение функциональной опции: Перейдем в раздел Настройка и администрирование — Общие настройки и убедимся, что установлен флаг Использовать версионирование объектов.
Настройка состава определяемых типов: В конфигураторе нам необходимо найти определяемый тип ВерсионируемыеОбъектыОбъект (название может незначительно отличаться в зависимости от версии БСП) и добавить в его состав наш самописный документ.
Подписки на события: Убедимся, что документ попадает в область действия типовых подписок, таких как ЗаписатьВерсиюОбъекта. Обычно это происходит автоматически при правильной настройке определяемых типов.
Настройка в пользовательском режиме: В справочнике Настройки версионирования объектов выберем наш документ и установим режим Версионировать при записи.

Проанализируем ситуацию: Версионирование отлично подходит для ответа на вопрос "Что изменилось в этом поле?". Однако оно неэффективно для построения статистических отчетов (например, "среднее количество переадресаций в месяц"), так как данные хранятся в сжатом XML-формате в регистре ВерсииОбъектов. Для извлечения данных в отчет системе придется программно распаковывать каждую версию, что крайне медленно.

Метод 2: Архитектурный подход через Бизнес-процессы и Задачи

Если документ по своей сути является заявкой, которая движется между сотрудниками, то правильнее использовать объекты типа БизнесПроцесс и Задача. В 1С:Документообороте это базовый механизм.

Разберем логику работы этого механизма:

Вместо того чтобы менять реквизиты в одном и том же документе, мы запускаем процесс. На каждом этапе процесса система создает объект ЗадачаИсполнителя. Рассмотрим пример жизненного цикла:

Старт процесса: Автор создает документ и запускает бизнес-процесс.
Этап адресации: Создается задача для "Адресата".
Переадресация: Если адресат решает передать задачу, текущая задача помечается как выполненная с результатом "Переадресовано", и система автоматически создает новую задачу на другого исполнителя.

Выясним преимущество: Каждая задача — это отдельная запись в базе со своим временем создания, исполнения и исполнителем. Это позволяет строить любые статистические отчеты запросом к таблице задач, не прибегая к сложным манипуляциям с историей изменений. Вы всегда сможете увидеть цепочку: Задача 1 (Адресат А) -> Задача 2 (Адресат Б) -> Задача 3 (Исполнитель В).

Метод 3: Использование дополнительного регистра сведений (ручное логирование)

Если переход на бизнес-процессы кажется слишком сложным, а версионирование не дает нужной аналитики, проанализируем вариант с созданием собственного регистра истории. Это "золотая середина" для получения быстрой статистики.

Создадим непериодический регистр сведений ИсторияИзмененийЗаявок со следующими измерениями и ресурсами:

Объект: ДокументСсылка.ВашаЗаявка
НомерСтроки: Число (для обеспечения уникальности записей в рамках одной секунды)
ДатаИзменения: Дата и время
АвторИзменений: СправочникСсылка.Пользователи
Событие: Строка или Перечисление (Назначение, Переадресация, Исполнение)
СтароеЗначение / НовоеЗначение: СправочникСсылка.Пользователи

Для записи данных воспользуемся подпиской на событие ПередЗаписью. Проанализируем пример кода, который фиксирует смену исполнителя:


Процедура ПередЗаписьюЗаявкиДляИстории(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    
    // Получаем старые данные из базы для сравнения
    Если Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    Если Источник.ЭтоНовый() Тогда
        // Логируем создание документа
    Иначе
        СтарыйОбъект = Источник.Ссылка.ПолучитьОбъект();
        Если Источник.Исполнитель <> СтарыйОбъект.Исполнитель Тогда
            // Зафиксируем переадресацию
            Запись = РегистрыСведений.ИсторияИзмененийЗаявок.СоздатьМенеджерЗаписи();
            Запись.Объект = Источник.Ссылка;
            Запись.ДатаИзменения = ТекущаяДатаСеанса();
            Запись.АвторИзменений = Пользователи.ТекущийПользователь();
            Запись.Событие = "Переадресация";
            Запись.СтароеЗначение = СтарыйОбъект.Исполнитель;
            Запись.НовоеЗначение = Источник.Исполнитель;
            Запись.Записать();
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Использование ОбменДанными.Загрузка в коде выше критически важно для того, чтобы история не записывалась повторно при обмене данными или выполнении регламентных операций.

Выбор оптимального решения

Подведем итог:

Версионирование БСП — выбираем, когда нужно быстро включить "контроль над пользователями", чтобы они не могли незаметно менять данные. Это инструмент администратора.
Бизнес-процессы — выбираем для полноценной автоматизации документооборота. Это наиболее правильный путь с точки зрения архитектуры 1С, так как он разделяет сущность "Заявка" и сущность "Действие по заявке".
Регистр сведений — выбираем, когда нужен легкий и быстрый отчет по специфическим изменениям в рамках уже существующего самописного функционала без глобальной переработки системы.

Для реализации качественной статистики (как в Сообщении 7 темы форума) мы рекомендуем комбинацию: использование бизнес-процессов для логики работы и стандартных отчетов по задачам для анализа эффективности отделов. Это позволит избежать "велосипедов" и обеспечит высокую производительность системы даже при больших объемах данных.