Почему в 1С:ERP нет общего журнала документов и как решать задачи администрирования без него?

← На главную

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

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

Технические причины: почему общий журнал — это тупиковый путь

Для того чтобы понять, почему создание общего журнала документов в 1С:ERP противопоказано, заглянем на уровень СУБД (MS SQL Server, PostgreSQL или Oracle). Проанализируем, как устроена структура метаданных системы:

Огромное количество физических таблиц. В конфигурации 1С:ERP насчитывается более 300 самостоятельных видов документов. Для каждого вида документов в СУБД создается отдельная физическая таблица (а также отдельные таблицы для их табличных частей).
Принцип работы динамического списка. Когда пользователь открывает журнал документов, платформа формирует SQL-запрос для заполнения динамического списка. Чтобы вывести «все документы», СУБД вынуждена объединить данные из сотен таблиц с помощью тяжелых конструкций UNION ALL или выполнять множественные левые соединения (LEFT JOIN).
Ограничения оптимизатора СУБД. Попытка обработать запрос, содержащий сотни объединений, перегружает оптимизатор запросов СУБД. Он физически не может построить оптимальный план выполнения такого запроса за разумное время. В СУБД MS SQL Server существуют жесткие ограничения на максимальное количество таблиц в одном запросе (в некоторых версиях это лимит в 256 таблиц), при превышении которых запрос просто аварийно завершается.
Влияние ограничений прав на уровне записей (RLS). В крупных корпоративных базах практически всегда внедрена политика разграничения прав доступа на уровне записей (по организациям, подразделениям или партнерам). При использовании RLS платформа 1С автоматически добавляет условия фильтрации к каждой из сотен таблиц в запросе. Это приводит к колоссальному росту нагрузки на процессор (CPU) сервера СУБД и переполнению базы временных таблиц (tempdb). Даже при работе одного пользователя система начнет зависать, а при массовой работе пользователей база данных может полностью заблокироваться.

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

Разбор сценария: поиск ошибок и массовые манипуляции с документами

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

Для решения этой задачи в типовой конфигурации 1С:ERP предусмотрен целый арсенал штатных инструментов. Разберем их по шагам.

Инструмент 1. Журнал документов регламентированного учета

Мало кто знает, но в ERP существует скрытый по умолчанию, но чрезвычайно полезный инструмент — Журнал документов регламентированного учета. В этот журнал автоматически попадают абсолютно все хозяйственные операции оперативного контура, которые делают или в перспективе могут делать проводки в бухгалтерском и налоговом учете.

Чтобы открыть его, выполним следующие действия:

Перейдем в раздел Регламентированный учет.
В группе переходов См. также найдем и откроем пункт Журнал документов (если пункт скрыт, его можно добавить через настройку навигации панели раздела).

Этот журнал работает оптимально, поскольку его структура спроектирована под задачи бухгалтера и содержит ограниченный, оптимизированный состав реквизитов, позволяющий быстро фильтровать документы по периоду, организации и статусу отражения в учете.

Инструмент 2. Стандартная обработка «Проведение документов»

Если наша цель — пакетное изменение статуса проведения документов определенного типа за период, использовать журналы вообще не требуется. В платформу встроен мощный низкоуровневый инструмент:

Откроем меню Сервис и настройки (в правом верхнем углу экрана) -> Функции для технического специалиста (ранее — «Все функции»).
Раскроем ветку Стандартные и выберем обработку Проведение документов.
В открывшемся окне на вкладке Настройка укажем интересующий нас период.
В списке документов отметим флагами только те виды документов, которые нас интересуют.
Нажмем кнопку Отменить проведение или Провести.

Этот метод работает напрямую с объектной техникой платформы 1С, минуя сложные запросы к интерфейсным спискам, что гарантирует максимальную скорость выполнения операции.

Инструмент 3. Универсальная обработка «Групповое изменение реквизитов»

Для более гибкой выборки документов и изменения их состояния (например, пометки на удаление или отмены проведения по сложным критериям) воспользуемся стандартной обработкой из состава БСП (Библиотеки стандартных подсистем):

Перейдем в раздел НСИ и администрирование -> Обслуживание -> Корректировка данных -> Групповое изменение реквизитов.
В поле «Выбирать элементы» укажем необходимые типы документов. Мы можем выбрать как один, так и сразу несколько десятков видов документов.
С помощью ссылки «Все элементы» настроим отбор (например, по дате вхождения в период или по конкретной организации).
Внизу формы нажмем кнопку Дополнительные параметры и установим флаг Показывать служебные реквизиты.
В списке реквизитов найдем служебные поля (такие как проведение или пометка удаления) или воспользуемся встроенными алгоритмами обработки для изменения состояния проведения.

Инструмент 4. Анализ действий пользователей через специализированные отчеты

Если перед нами стоит задача понять: «Что именно пользователи занесли в систему за этот период?», наиболее правильным решением будет использование административных отчетов:

Перейдем в раздел НСИ и администрирование -> Обслуживание -> Отчеты администратора.
Сформируем отчет Активность пользователя. Он позволяет детально проанализировать историю создания и изменения документов конкретными сотрудниками за выбранный интервал времени.
Для детального расследования воспользуемся механизмами Журнала регистрации и встроенного Версионирования объектов, которые покажут точное состояние реквизитов документа до и после совершения ошибки.

Как разработать безопасный аналог общего журнала (если он действительно необходим)

Бывают ситуации, когда специфика бизнес-процессов или отладочные работы на копии базы требуют наличия единого рабочего места для просмотра разнородных документов. Рассмотрим два профессиональных архитектурных подхода, как реализовать такую задачу без ущерба для производительности СУБД.

Вариант А. Создание реестра документов на СКД

Вместо использования динамического списка на управляемой форме, создадим внешний отчет или обработку с использованием Системы компоновки данных (СКД). Основная идея заключается в том, что запрос выполняется разово (по кнопке «Сформировать») за жестко ограниченный период времени, а результат выводится в обычную таблицу значений.

Проанализируем пример построения пакетного запроса для СКД, выбирающего только ключевые торговые документы за период. Такой подход не блокирует СУБД, так как не производит постоянное считывание порций данных при скроллинге:


ВЫБРАТЬ
    Ссылка КАК ДокументСсылка,
    Дата КАК ДатаДокумента,
    Проведен КАК СтатусПроведения,
    Организация КАК Организация,
    "Реализация товаров услуг" КАК ТипДокумента
ИЗ
    Документ.РеализацияТоваровУслуг КАК Реализация
ГДЕ
    Реализация.Дата МЕЖДУ &НачалоПериода И &КонецПериода

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Ссылка,
    Дата,
    Проведен,
    Организация,
    "Приобретение товаров услуг"
ИЗ
    Документ.ПриобретениеТоваровУслуг КАК Приобретение
ГДЕ
    Приобретение.Дата МЕЖДУ &НачалоПериода И &КонецПериода

Использование параметров &НачалоПериода и &КонецПериода является обязательным. Это позволяет СУБД использовать индексы по полям дат документов и мгновенно возвращать результат выборки.

Вариант Б. Проектирование вспомогательного регистра-индекса

Если пользователям необходим именно динамический список, работающий в реальном времени с возможностью быстрого поиска и сортировки по всей базе, применим паттерн проектирования «Индексный регистр». Этот паттерн часто используется разработчиками в высоконагруженных системах.

Разберем этот метод по шагам:

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

Напишем обработчик подписки на событие для регистрации метаданных:


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

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

Таким образом, мы выяснили, почему классический общий журнал документов отсутствует в 1С:ERP, научились использовать мощные штатные инструменты для анализа данных и перепроведения, а также разобрали безопасные с точки зрения производительности способы проектирования кастомных решений.