Ошибки ввода дат пользователями — частая проблема при активном документообороте. Достаточно пропустить точку-разделитель при быстром наборе (например, ввести 02.20 вместо 02.2024), как платформа 1С интерпретирует число как 220 год нашей эры. В результате в информационной базе появляются документы времен Римской империи или эпохи Средневековья, а также записи из далекого будущего (например, 3999 год).
Проанализируем, к каким техническим последствиям приводят такие ошибки и какими способами можно исключить появление некорректных дат в конфигурации 1С:Управление торговлей 11.
Попадание документов с некорректной датой в базу влечет за собой не только путаницу в аналитических отчетах, но и серьезную деградацию производительности платформы и СУБД:
Рассмотрим самый быстрый административный вариант, не требующий изменения конфигурации или разработки кода. В типовую конфигурацию «1С:Управление торговлей» встроен механизм дат запрета изменения данных из Библиотеки стандартных подсистем (БСП).
Конец прошлого месяца или Конец прошлой недели.Этот механизм полностью заблокирует возможность создания или проведения документов задним числом. Однако типовой механизм дат запрета изменения по умолчанию контролирует только прошлое время и не защищает базу от ввода документов в будущем (например, 3999 года). Для комплексной двусторонней защиты разберем программное решение.
Чтобы не модифицировать типовую конфигурацию и сохранить ее на полной поддержке, создадим отдельное расширение конфигурации. Нет необходимости создавать десятки подписок под каждый отдельный документ — в 1С можно назначить один общий обработчик для всех документов сразу.
Разберем по шагам алгоритм создания проверки:
Адаптация или Дополнение).ДокументОбъект (это охватит абсолютно все документы базы).ПередЗаписью.Посмотрим на пример кода обработчика, который проверяет дату документа на попадание в допустимый диапазон:
Процедура ПроверитьДатуДокументаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Пропускаем проверку, если дата не заполнена (проверяется стандартными механизмами)
Если Не ЗначениеЗаполнено(Источник.Дата) Тогда
Возврат;
КонецЕсли;
// Определяем допустимые границы
ГраницаПрошлого = '20150101000000'; // Дата начала ведения реального учета в базе
КоличествоДнейВперед = 30; // Допустимый сдвиг вперед для будущих отгрузок/заказов
ГраницаБудущего = КонецДня(ТекущаяДатаСеанса() + (КоличествоДнейВперед * 86400));
// Проверяем попадание даты в допустимый интервал
Если Источник.Дата < ГраницаПрошлого Или Источник.Дата > ГраницаБудущего Тогда
Отказ = Истина;
ТекстОшибки = СтрШаблон(
"Недопустимая дата документа: %1. Дата должна быть в диапазоне от %2 до %3.",
Формат(Источник.Дата, "ДФ=dd.MM.yyyy HH:mm:ss"),
Формат(ГраницаПрошлого, "ДФ=dd.MM.yyyy"),
Формат(ГраницаБудущего, "ДФ=dd.MM.yyyy")
);
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
ТекстОшибки,
Источник,
"Дата"
);
КонецЕсли;
КонецПроцедуры
Важное замечание: не следует автоматически приравнивать ошибочную дату к ТекущаяДатаСеанса() без уведомления пользователя. Если документ проводится текущим днем вместо целевой даты, это нарушит хронологию взаиморасчетов, списание партий по ФИФО и нумерацию связанных счетов-фактур. Установка Отказ = Истина с информативным сообщением принуждает пользователя осознанно ввести корректное значение.
Если документы попадают в базу через внешние интеграции (ЭДО, файлы Excel, веб-сервисы или универсальный формат EnterpriseData), человеческий фактор дополняется ошибками некорректного парсинга форматов дат.
Проанализируем контрольные точки для интеграций:
yy) следует явно приводить к четырехзначным с учетом текущего века.Если в рабочей базе уже накопились документы с датами прошлых веков, выполним следующие действия по восстановлению базы: