Почему после обновления ERP система требует оформить приходные ордера на старые поступления и как это исправить?

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

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

Причина проблемы: появление нового измерения «Отправитель»

Проанализируем изменения в структуре метаданных. Начиная с релиза ERP 2.2.3 (и аналогичного релиза УТ 11.3.3), фирма «1С» пересмотрела логику сквозного контроля ордерных складов и добавила новое измерение Отправитель в регистр накопления ТоварыКПоступлению, а также одноименный реквизит в документ ПриходныйОрдерНаТовары.

Механика движений регистра работает по принципу балансировки:

1. Финансовый документ-распоряжение (например, ПриобретениеТоваровУслуг или ПеремещениеТоваров) делает движение с видом Приход в регистр ТоварыКПоступлению со знаком «плюс».
2. Фактический складской документ ПриходныйОрдерНаТовары формирует движение с видом Расход со знаком «минус», закрывая потребность в приемке.

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

Шаг 1. Контроль выполнения дополнительных процедур обработки данных

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

Для проверки состояния процедур обновления выполним следующие действия:

1. Перейдем в раздел НСИ и администрирование → Обслуживание → Результаты обновления программы.
2. Откроем список невыполненных или завершившихся с ошибкой отложенных процедур.
3. Найдем обработчики, связанные с регистром ТоварыКПоступлению и ордерным учетом.
4. Если обработчик находится в статусе «Ошибка» или «Ожидает выполнения», запустим его вручную.

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

Шаг 2. Диагностика расхождений через консоль запросов

Посмотрим на пример запроса, с помощью которого можно быстро выявить зависшие остатки по новому измерению. Откроем консоль запросов и обратимся к виртуальной таблице остатков регистра:

ВЫБРАТЬ
	ТоварыКПоступлениюОстатки.Склад КАК Склад,
	ТоварыКПоступлениюОстатки.ДокументПоступления КАК ДокументПоступления,
	ТоварыКПоступлениюОстатки.Отправитель КАК Отправитель,
	ТоварыКПоступлениюОстатки.Номенклатура КАК Номенклатура,
	ТоварыКПоступлениюОстатки.КПоступлениюОстаток КАК КПоступлениюОстаток
ИЗ
	РегистрНакопления.ТоварыКПоступлению.Остатки(&Период, ) КАК ТоварыКПоступлениюОстатки
ГДЕ
	ТоварыКПоступлениюОстатки.КПоступлениюОстаток <> 0

Если в результате выполнения запроса мы видим по одной и той же накладной две строки — например, +10 с заполненным полем Отправитель и -10 с пустым полем Отправитель — это однозначно свидетельствует о несоответствии аналитики между накладными и складскими ордерами.

Шаг 3. Пересчет итогов регистра

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

1. Запустим информационную базу в режиме Конфигуратор монопольно.
2. Откроем меню Администрирование → Тестирование и исправление....
3. Установим флаг Пересчет итогов.
4. Нажмем кнопку Выполнить и дождемся завершения операции.

Шаг 4. Методы выравнивания остатков

Если фоновые обновления успешно завершены, пересчет итогов выполнен, но расхождения в регистре сохраняются, разберем два пути решения задачи:

Способ 1. Последовательное групповое перепроведение документов

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

Способ 2. Использование документа «Корректировка регистров»

Если документы относятся к закрытым периодам и повторное проведение категорически запрещено политикой учета, воспользуемся документом КорректировкаРегистров. В нем выбирается регистр ТоварыКПоступлению, после чего вносятся две компенсирующие записи: расход по пустой аналитике отправителя и приход (либо сторно) по заполненной. В результате сальдо регистра по закрытым поставкам обнуляется, и рабочее место приемщика очищается от фиктивных требований оформления.