При работе в современных конфигурациях на базе 1С:Предприятие 8 (таких как Бухгалтерия предприятия 3.0, Зарплата и управление персоналом 3.1, Комплексная автоматизация 2.5 или ERP) пользователи часто сталкиваются с досадной ошибкой. При попытке создать новое физическое лицо система выдает сообщение о невозможности записи данных в «запрещенный период», указывая на странную дату — 31.12.1899. В этой статье мы подробно разберем природу этого «глюка», проанализируем, почему он возникает спустя десятилетия разработки, и исправим ошибку вывода даты 31.12.1899 в кадровых документах, рассмотрев несколько методов решения: от простых административных настроек до профессиональной разработки расширения.
Для начала проанализируем техническую составляющую. В платформе 1С дата 31.12.1899 является системным минимумом, своего рода «пустой» датой для периодических регистров сведений. Когда мы создаем новую карточку физического лица, система автоматически инициирует запись в сопутствующие регистры, такие как ГражданствоФизическихЛиц, ФИОФизическихЛиц или ВоинскийУчет. Чтобы эти сведения считались актуальными «с начала времен», программа записывает их с периодом 31.12.1899.
Конфликт происходит в тот момент, когда в информационной базе включена Дата запрета изменения данных. Механизм проверки дат воспринимает 1899 год как глубокое прошлое. Если у вас установлена общая дата запрета (например, по конец прошлого года или квартала), система видит, что запись в регистр сведений попадает в закрытый период, и блокирует транзакцию. Это классическая архитектурная коллизия Библиотеки стандартных подсистем (БСП), которая кочует из релиза в релиз.
Рассмотрим, какие именно данные чаще всего вызывают остановку работы при попытке регистрации нового сотрудника или контрагента-физлица. В некоторых случаях администратору может потребоваться прямое редактирование движений в регистре кадровая история (удобно через редактор записей регистров сведений и накопления для 1С) или корректировка данных в регистрах документа перенос данных, чтобы устранить последствия некорректных записей:
Ниже мы разберем по шагам, как можно обойти это ограничение, не снимая дату запрета полностью.
Если нам необходимо решить проблему «здесь и сейчас» без изменения кода, проанализируем возможности стандартных настроек. Этот метод подойдет бухгалтерам и кадровикам, имеющим права администратора.
Разберем алгоритм временного обхода:
01.01.1899.Важно: Этот метод неудобен при частом вводе новых сотрудников, но он является самым безопасным с точки зрения целостности данных, так как не требует вмешательства в конфигурацию — решить проблему поможет расширение для настройки запретов записи и условий редактирования объектов.
Проанализируем еще один вариант настройки. В настройках даты запрета есть возможность установить исключение: «Не применять дату запрета для пользователей с полными правами». Если вы доверяете пользователю, который вводит данные, можно временно включить эту опцию. Однако помните, что это открывает возможность случайного редактирования документов в закрытых периодах.
Для более гибкого управления доступом и защиты данных рекомендуем использовать расширение для блокировки и отслеживания изменений объектов с формы. Кроме того, при работе со сложными структурами прав может быть полезно развитие RLS на уровне групп доступа физического лица, что позволит автоматизировать выдачу прав кадровикам при оформлении совместителей.
Если вы готовы к минимальной правке кода в основной конфигурации (или через расширение с заменой метода), рассмотрим вариант корректировки бизнес-логики. Нам необходимо найти место, где система проверяет корректность записи регистра по умолчанию.
В общем модуле ЗарплатаКадрыСобытия найдем процедуру ПроверитьЗаписьПоУмолчаниюРегистраСведений. Мы можем принудительно отключить отказ в записи, добавив строку Отказ = Ложь;. Это позволит системе игнорировать ошибку даты запрета конкретно для этого механизма.
Пример кода:
Процедура ПроверитьЗаписьПоУмолчаниюРегистраСведений(Источник, Отказ, Замещение) Экспорт
Если ЗарплатаКадры.ОтключитьБизнесЛогикуПриЗаписи(Источник) Тогда
Возврат;
КонецЕсли;
// Добавляем принудительный сброс отказа для обхода ошибки даты запрета
Отказ = Ложь;
Для каждого Запись Из Источник Цикл
// Стандартная логика проверки
КонецЦикла;
КонецПроцедуры
Самым правильным и современным методом решения является использование расширения конфигурации. Это позволит нам сохранить поддержку программы и не изменять типовой код. Мы перехватим проверку даты запрета и добавим условие: если дата равна технической (1899 год), то проверку выполнять не нужно.
Создадим расширение и добавим в него процедуру из модуля ДатыЗапретаИзменения. Разберем программную реализацию:
&ИзменениеИКонтроль("ПроверитьДатуЗапретаИзмененияПередЗаписьюНабораЗаписей")
Процедура Запр_ПроверитьДатуЗапретаИзмененияПередЗаписьюНабораЗаписей(Источник, Отказ, Замещение)
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Источник.ДополнительныеСвойства.Вставить("Замещение", Замещение);
// ВСТАВКА: Проверяем, является ли дата технической (пустой)
флДатаПустая = Ложь;
Попытка
ДатаЗаписи = Источник.Отбор.Период.Значение;
Если ДатаЗаписи = ЗарплатаКадрыКлиентСервер.ДатаОтсчетаПериодическихСведений
ИЛИ ДатаЗаписи = '00010101' Тогда
флДатаПустая = Истина;
КонецЕсли;
Исключение
флДатаПустая = Ложь;
КонецПопытки;
Если флДатаПустая Тогда
// Пропускаем проверку запрета для даты 1899 года
Возврат;
КонецЕсли;
// КОНЕЦ ВСТАВКИ
ПроверитьДатыЗапретаИзмененияДанных(Источник, Отказ, Истина, Замещение);
КонецПроцедуры
Разберем, что делает этот код. Функция ЗарплатаКадрыКлиентСервер.ДатаОтсчетаПериодическихСведений возвращает ту самую злополучную дату 31.12.1899. Если период записи в регистр совпадает с этой датой, наше расширение просто прерывает выполнение процедуры проверки (Возврат), не вызывая стандартный механизм ПроверитьДатыЗапретаИзмененияДанных.
Применяя способ с расширением, проанализируйте риски обновления. Процедура ПроверитьДатуЗапретаИзмененияПередЗаписьюНабораЗаписей является частью БСП. При обновлении конфигурации на новый релиз 1С может изменить количество параметров этой процедуры. В таких случаях, чтобы избежать критических ошибок, полезно внедрить универсальное расширение для блокировки записи объекта по условию (удобно через расширение контроля ввода и управления доступом к объектам в 1С), которое позволяет настраивать бизнес-правила без жесткой привязки к коду БСП.
Ситуация с датой 31.12.1899 — это типичный пример того, как универсальные механизмы платформы (Дата запрета) конфликтуют с внутренними соглашениями разработки типовых конфигураций (хранение истории с начала времен). Мы рассмотрели несколько путей решения:
Выбор метода зависит от ваших полномочий и регулярности возникновения задачи. Для стабильной работы крупного предприятия наиболее предпочтительным выглядит создание небольшого расширения, которое раз и навсегда снимет этот вопрос с повестки дня.