Как исправить ошибку «Запись не верна! Период не может быть пустым!» при обмене РИБ в 1С?

При выполнении обмена данными в распределенной информационной базе (РИБ) в момент загрузки сообщения методом ПрочитатьИзменения() может возникнуть исключение: «Запись не верна! Период не может быть пустым! (Регистр накопления: [ИмяРегистра]; Номер строки: N)». Выясним причину этой ошибки и подробно разберем все способы её поиска и устранения.

Рассмотрим, почему это происходит. При загрузке данных в РИБ платформа устанавливает флаг ОбменДанными.Загрузка = Истина. Это отключает пользовательские и прикладные проверки в коде конфигурации, но системные платформенные ограничения СУБД продолжают действовать. Для любого регистра накопления и периодического регистра сведений поле Период входит в состав системного первичного ключа. Попытка записать набор движений с незаполненной датой (значение 0001-01-01) безусловно блокируется платформой «1С:Предприятие».

Чаще всего источник проблемы находится в узле-отправителе: В специализированных и отраслевых решениях при формировании движений по партионным регистрам дата в Период может подставляться не из даты самого документа, а из реквизита табличной части (например, «Дата партии» или «Дата входящего документа»). Если пользователь не заполнил это поле, в регистр попадает пустая дата. Также причиной могут быть «битые» или осиротевшие записи (движения без документа-регистратора) либо сбои при программном формировании наборов записей.

Способ 1. Поиск проблемной записи через файл обмена XML

Разберем самый точный и быстрый способ локализовать проблемный документ без изменения конфигурации — анализ XML-сообщения обмена.

1. Откроем сформированный файл обмена (имеющий имя вида Message_*.xml) в текстовом редакторе (например, Notepad++ или VS Code).
2. Выполним поиск узла набора записей, указанного в ошибке. Ищем тег с именем регистра, например: <AccumulationRegisterRecordSet.ПартииТоваровНаСкладахУправленческийУчет>.
3. В тексте ошибки система указывает точный номер строки: Номер строки: 4. Отсчитаем внутри найденного блока четвертый вложенный тег <Record>.
4. Посмотрим на содержимое тега <Period> — в нем будет содержаться значение 0001-01-01T00:00:00.
5. В заголовке набора или в теге <Recorder> найдем уникальный идентификатор (GUID) документа-регистратора. Скопировав этот GUID, мы сможем легко найти исходный документ в информационной базе с помощью стандартной обработки поиска объектов по ссылке/идентификатору или через консоль запросов.

Способ 2. Поиск записей с пустым периодом в базе-источнике через консоль запросов

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

Напишем запрос к регистру накопления, отфильтровав пустые даты:

ВЫБРАТЬ
    Партии.Регистратор КАК ДокументРегистратор,
    Партии.НомерСтроки КАК НомерСтроки,
    Партии.Период КАК Период
ИЗ
    РегистрНакопления.ПартииТоваровНаСкладахУправленческийУчет КАК Партии
ГДЕ
    Партии.Период = ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)

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

ВЫБРАТЬ
    Док.Ссылка КАК ДокументСсылка
ИЗ
    Документ.ПоступлениеТоваровУслуг КАК Док
ГДЕ
    Док.Дата = ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)

Способ 3. Варианты исправления ситуации

После того как проблемный регистратор определен, разберем возможные пути решения:

1. Корректировка в узле-источнике (основной вариант): Откроем найденный документ в узле-отправителе, заполним недостающие реквизиты дат в шапке или табличной части, затем перепроведем документ. После этого сформируем файл обмена заново и повторим чтение изменений в базе-приемнике.
2. Снятие с регистрации изменений: Если документ не должен передаваться или требует длительного согласования, откроем в подчиненном узле обработку «Регистрация изменений для обмена данными». Найдем ошибочный набор записей или сам документ и удалим его регистрацию по узлу обмена. Сообщение будет сформировано уже без проблемного блока данных.
3. Экстренная ручная правка XML-файла: Если обмен требуется выполнить срочно, а доступа к подчиненному узлу временно нет, откроем XML-файл обмена и в теге <Period> четвертой строки укажем корректную дату документа (например, 2024-03-15T12:00:00) либо полностью удалим ошибочную запись <Record>...</Record>. Сохраним файл и повторно запустим чтение в узле-приемнике.
4. Тестирование и исправление: Если запрос показал, что поле Регистратор содержит «Объект не найден» (фантомные или осиротевшие движения), в конфигураторе подчиненного узла выполним процедуру Тестирование и исправление информационной базы. Обязательно включим опции «Проверка логической целостности» и «Проверка ссылочной целостности», выбрав действие «Очищать ссылки» или «Удалять записи». Это удалит остатки некорректных наборов из таблиц регистра.