В процессе оперативной работы пользователи нередко совершают банальные опечатки при вводе дат в документах товародвижения или расчетов. Наиболее распространенный сценарий — ввод текущего дня и месяца, но с ошибочным указанием года (например, 0018 или 2081 год вместо текущего 2024). Несмотря на то, что пользователи могут быстро заметить ошибку и исправить ее, система 1С:Комплексная автоматизация 2 или 1С:ERP успевает зафиксировать первичные данные в базе.
Это мгновенно приводит к тяжелым последствиям для производительности: регламентное задание по распределению взаиморасчетов начинает пересчитывать временные периоды длиной в тысячи лет. Программа перегружает процессор сервера, транзакции блокируют таблицы базы данных, а остальные пользователи сталкиваются с зависанием системы. В этой статье мы подробно разберем причины этой проблемы, проанализируем архитектурные особенности работы распределения расчетов и рассмотрим несколько эффективных методов решения данной проблемы.
Для того чтобы понять природу сбоя, проанализируем логику работы классического механизма распределения взаиморасчетов (так называемой «офлайн»-архитектуры). При проведении любого документа, влияющего на состояние расчетов с контрагентами (накладные, платежные поручения, корректировки долга), система не производит мгновенный расчет авансов и курсовых разниц в режиме реального времени. Вместо этого программа делает записи в специальные регистры сведений:
ЗаданияКРаспределениюРасчетовСКлиентамиЗаданияКРаспределениюРасчетовСПоставщикамиВ этих регистрах фиксируется минимальная дата, начиная с которой необходимо актуализировать расчеты. Если пользователь ошибочно проводит документ с датой 01.01.0018, в регистр записывается задание на пересчет с этой экстремально ранней даты. Когда по расписанию (или автоматически при проведении) запускается фоновое регламентное задание «Выполнение отложенных движений по расчетам с клиентами / поставщиками», оно считывает эту запись и пытается последовательно рассчитать распределение долгов за период более чем в две тысячи лет. Алгоритм уходит в бесконечный цикл обработки, потребляя всю свободную оперативную память и ресурсы СУБД, что полностью парализует работу предприятия.
Рассмотрим по шагам основные способы борьбы с этой уязвимостью системы.
Самым простым организационно-техническим методом защиты от ввода некорректных прошлых дат является использование встроенного механизма даты запрета редактирования.
Для включения этого функционала выполним следующие действия:
Важное ограничение метода: Дата запрета редактирования отлично защищает базу от ввода документов за прошлые периоды (например, она заблокирует проведение документа за 0018 год). Однако она окажется абсолютно бесполезной, если пользователь опечатается в большую сторону — например, укажет дату из далекого будущего (скажем, 2085 год). Будущие периоды в системе, как правило, открыты для редактирования, поэтому задание на распределение расчетов запишется в регистр с датой текущего дня, но при попытке закрыть этот "будущий" месяц фоновое задание также может зависнуть.
Для того чтобы гарантированно исключить попадание некорректных дат в базу данных (как глубокого прошлого, так и далекого будущего), напишем небольшое расширение конфигурации. В расширении мы создадим подписку на событие для проверки даты документа перед его записью.
Создадим общую процедуру-обработчик в серверном модуле расширения и подключим ее к событию ПередЗаписью проводкообразующих документов. Код валидации даты будет выглядеть следующим образом:
Процедура ПередЗаписьюДокументаПроверкаДаты(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Если документ уже помечен на удаление или отменяется его проведение, проверку можно пропустить
Если Отказ Или Источник.ПометкаУдаления Тогда
Возврат;
КонецЕсли;
ТекущийГод = Год(ТекущаяДата());
ГодДокумента = Год(Источник.Дата);
// Определяем границы допустимого диапазона дат (например, текущий год минус 1 и плюс 1)
МинимальноДопустимыйГод = ТекущийГод - 1;
МаксимальноДопустимыйГод = ТекущийГод + 1;
Если ГодДокумента < МинимальноДопустимыйГод Или ГодДокумента > МаксимальноДопустимыйГод Тогда
Отказ = Истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Внимание! Год в дате документа (" + Формат(ГодДокумента, "ЧГ=0") + ") указан некорректно! "
+ "Допустим ввод документов только за период с " + Формат(МинимальноДопустимыйГод, "ЧГ=0") + " по " + Формат(МаксимальноДопустимыйГод, "ЧГ=0") + " гг. "
+ "Пожалуйста, исправьте опечатку.";
Сообщение.Поле = "Дата";
Сообщение.УстановитьДанные(Источник);
Сообщение.Сообщить();
КонецЕсли;
КонецПроцедуры
Данный программный код перехватывает попытку записи документа на самой ранней стадии. Если год даты документа выходит за рамки разумного диапазона, транзакция отменяется (Отказ = Истина), пользователю выводится понятное предупреждение, а некорректные данные не попадают в базу и не порождают ошибочные записи в регистрах заданий к распределению.
Начиная с версии ERP/КА 2.4.6, фирма 1С добавила принципиально новый режим работы — Онлайн-взаиморасчеты. В версии 2.5 этот режим стал основным и стандартным. Переход на онлайн-расчеты кардинально меняет логику распределения.
Рассмотрим ключевые преимущества перехода на онлайн-расчеты в контексте нашей проблемы:
Для включения этого режима в Комплексной автоматизации 2 выполним переход по пути: НСИ и администрирование – Настройки разделов – Взаиморасчеты, где переведем флаг архитектуры взаиморасчетов в положение Онлайн. Перед переходом обязательно завершим все процедуры закрытия прошлых месяцев и выполним все текущие отложенные расчеты.
Если профилактические меры не были настроены вовремя, и пользователь уже провел документ с некорректной датой (например, 0018 годом), система начнет сильно тормозить. Разберем алгоритм экстренного восстановления работоспособности базы данных.
Шаг 1. Остановка зависшего фонового процесса. Нам необходимо экстренно завершить расчет. Для этого запустим консоль администрирования кластера серверов 1С:Предприятия, найдем сеанс фонового задания «Выполнение отложенных движений по расчетам...» и принудительно завершим его. Если консоли под рукой нет, то в режиме «1С:Предприятие» перейдем в НСИ и администрирование – Обслуживание – Активные пользователи (или Фоновые задания), найдем соответствующее задание и нажмем кнопку Отменить/Завершить.
Шаг 2. Исправление даты в документе-первоисточнике. Найдем документ, в котором была допущена ошибка. Изменим его дату на корректную и проведем заново.
Шаг 3. Очистка битых записей в регистрах сведений. Даже после исправления самого документа, ошибочная запись в регистре заданий к распределению с датой 0018 года может остаться. Перейдем в меню «Функции для технического специалиста» (ранее «Все функции») и найдем регистры сведений:
Задания к распределению расчетов с клиентамиЗадания к распределению расчетов с поставщикамиОтфильтруем записи по колонке даты, найдем строку, содержащую некорректный год (0018), и удалим эту запись вручную. Если запись заблокирована или не удаляется стандартным списком, воспользуемся внешней обработкой очистки записей регистров.
Важное примечание администратору: Иногда в результате сбоев в этих регистрах сведений могут появляться «битые» записи с незаполненными ключевыми измерениями (например, пустое поле Организация). В таком случае регламентное задание будет аварийно завершаться с системной ошибкой: «Запись не верна! Значение поля "Организация" не может быть пустым». При обнаружении подобных строк в указанных регистрах сведений их также необходимо полностью вычистить.
Применение рассмотренных методик позволит вам надежно защитить информационную систему от критических зависаний, вызванных человеческим фактором при вводе дат.