Как исправить некорректные цены и остатки в магазине после свёртки узла РИБ в «1С:Розница»?

← На главную

Работа в распределенной информационной базе (РИБ) накладывает определенные обязательства на администрирование системы. Одним из наиболее сложных и потенциально опасных процессов является свёртка информационной базы одного из удаленных узлов (магазинов). Часто после проведения этой процедуры технические специалисты сталкиваются с неприятным явлением: в центральном узле (ЦБ) все данные отображаются корректно, а в периферийной базе магазина «плывут» остатки и пропадают или отображаются неверно цены на товары. Ситуация усложняется, если бэкап накатить уже невозможно из-за накопившегося за несколько дней объема новых продаж и документов.

В этой статье мы подробно разберем, почему возникает данная проблема, как функционируют механизмы регистрации изменений в планах обмена и предоставим пошаговую инструкцию по полному восстановлению корректных данных в магазине без потери текущей работы.

Почему происходит сбой остатков и цен после свёртки?

Для того чтобы эффективно решить проблему, нам необходимо понять физику процесса свёртки в контексте РИБ конфигурации «1С:Розница». Рассмотрим ключевые механизмы, которые участвуют в этом процессе:

Формирование остатков на стороне ЦБ: При инициации свёртки конкретного магазина в центральной базе на заданную дату создается специальный документ — ВводНачальныхОстатковУзла. Этот документ призван зафиксировать состояние склада и взаиморасчетов на момент «отсечения» старых данных.
Очистка истории в периферийной базе: Во время очередного сеанса синхронизации этот документ передается в базу магазина. Платформа распознает команду свёртки и автоматически помечает на удаление все документы, созданные ранее даты свёртки. На их место должен встать тот самый документ ввода начальных остатков.
Проблема несовпадения идентификаторов (GUID): Очень часто при создании нового начального образа или после автоматической свёртки документ ВводНачальныхОстатковУзла в периферийной базе оказывается непроведенным. Причиной тому служит битая ссылка в реквизите «Узел» (вместо конкретного узла система видит надпись «Объект не найден...»). Поскольку GUID узла в ЦБ и предопределенного элемента «ЭтотУзел» в подчиненной базе разошлись, документ не может быть автоматически проведен, и магазин остается вообще без остатков.
Удаление документов установки цен: Цены в «1С:Розница» хранятся в периодическом регистре сведений. Документы УстановкаЦенНоменклатуры, созданные до даты свёртки, безвозвратно удаляются в магазине в процессе свёртки. Если в правилах обмена не настроена принудительная обратная выгрузка действующих цен, магазин теряет актуальный прайс-лист.
Очистка информативных остатков: Продавцы в магазинах часто используют функционал просмотра остатков в других торговых точках сети. Эти данные хранятся в регистре ИнформативныеОстаткиТоваровПоМагазинам. После свёртки или пересоздания узла этот регистр полностью очищается и не заполнится до тех пор, пока ЦБ принудительно не выгрузит эти данные заново.

Рассмотрим подробнее, как исправить каждую из этих проблем по шагам.

Шаг 1. Исправление и проведение документа ввода остатков в магазине

Первым делом нам необходимо восстановить собственные остатки магазина. Для этого перейдем непосредственно в информационную базу проблемного магазина.

Выполним следующие действия:

Откроем главное меню программы и перейдем в раздел «Сервис и настройки» — «Функции для технического специалиста» (в старых версиях платформы этот пункт назывался «Все функции»). Если данный пункт не отображается, его необходимо включить в параметрах конфигуратора или в настройках параметров интерфейса под правами администратора.
В открывшемся дереве объектов найдем раздел «Документы» и выберем Ввод начальных остатков узла.
В списке документов найдем тот, который датирован числом проведенной свёртки. Обратим внимание на его пиктограмму: если на ней нет зеленой галочки, документ не проведен.
Откроем этот документ. Если в поле «Узел» или аналогичном реквизите мы видим текстовое представление уникального идентификатора вида <Объект не найден> (832f91a0-...), это подтверждает нашу гипотезу о рассинхронизации GUID.
Для исправления ситуации воспользуемся обработкой ГрупповоеИзменениеРеквизитов. Откроем её, выберем тип данных Ввод начальных остатков узла, найдем наш документ по ссылке или номеру, перейдем в служебные реквизиты и заменим битую ссылку в поле «Узел» на предопределенный элемент Этот узел текущей базы.
Проведем документ вручную. Сразу после этого проверим отчет «Остатки на складах» — данные по собственному магазину должны прийти в норму.

Шаг 2. Восстановление цен номенклатуры через принудительную регистрацию

Теперь разберем, как вернуть актуальные цены в периферийную базу. Поскольку документы установки цен были удалены при свёртке, нам нужно принудительно заставить центральную базу отправить текущие записи регистра цен в магазин. Для этого мы воспользуемся механизмом планов обмена.

Выполним процедуру в Центральной Базе (ЦБ):

Перейдем в раздел «Администрирование» — «Синхронизация данных» — «Настройки синхронизации».
Выберем настройку обмена с нашим проблемным магазином и нажмем кнопку «Состав отправляемых данных» (иконка с изображением синей шестеренки или таблицы с карандашом).
Перед нами откроется дерево всех объектов метаданных, которые входят в состав этого плана обмена. Нам необходимо найти регистр сведений, отвечающий за цены. Обычно это Цены номенклатуры или Действующие цены номенклатуры.
Нажмем на кнопку «Зарегистрировать изменения объектов» (или выберем аналогичный пункт в контекстном меню) и укажем команду «Зарегистрировать все объекты выбранного типа».

Проанализируем, что произошло на программном уровне. В СУБД к таблице регистрации изменений данного плана обмена добавились записи для всех цен. Программно этот процесс выглядит эквивалентно следующему коду:


ВыборкаУзлов = ПланыОбмена.ПоМагазинам.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
    Если ВыборкаУзлов.Ссылка = УзелПроблемногоМагазина Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(ВыборкаУзлов.Ссылка, Метаданные.РегистрыСведений.ЦеныНоменклатуры);
    КонецЕсли;
КонецЦикла;

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

Шаг 3. Восстановление информативных остатков других магазинов

Чтобы продавцы снова могли консультировать покупателей о наличии товаров в соседних точках сети, восстановим работу регистра информативных остатков. Этот шаг также выполняется в Центральной базе.

Перейдем в меню «Администрирование» — «Обслуживание» — «Регламентные операции» — «Регламентные и фоновые задания».
Найдем в списке регламентных заданий задачу с наименованием Обновление информативных остатков по магазинам.
Выделим её и нажмем кнопку «Выполнить сейчас». Дождемся завершения работы фонового процесса. Система пересчитает текущие остатки по всей торговой сети и запишет их в соответствующий регистр.
Снова откроем обработку «Состав отправляемых данных» для узла нашего магазина в ЦБ.
Найдем в списке регистров сведений объект Информативные остатки товаров по магазинам.
Нажмем кнопку «Зарегистрировать изменения» — «Зарегистрировать все объекты выбранного типа».
Запустим выгрузку данных из ЦБ и загрузим их в периферийном магазине.

Полезные советы по работе с планами обмена и авторегистрацией

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

Авторегистрация: Если у объекта метаданных в плане обмена свойство «Авторегистрация» установлено в значение Разрешить, то при любом интерактивном или программном изменении (записи, проведении) этого объекта платформа автоматически добавляет его в таблицу регистрации для всех узлов этого плана обмена.
Отключенная авторегистрация: Если авторегистрация установлена в Запретить, объект попадет в обмен только в том случае, если разработчик прописал регистрацию вручную в коде (например, в модуле объекта при записи) или если администратор зарегистрировал его принудительно через обработку «Состав отправляемых данных».
Очистка регистрации: Если вы по ошибке зарегистрировали огромный объем данных (например, миллионы записей движений регистров), обмен может «зависнуть». В таком случае откройте «Состав отправляемых данных», выберите нужный объект и нажмите кнопку «Отменить регистрацию изменений объектов». Это уберет их из очереди отправки без удаления самих данных из базы.

Таким образом, мы детально разобрали механизм возникновения сбоя данных после свёртки узла РИБ в «1С:Розница 2.3» и изучили надежный способ исправления ситуации без полной перезаливки базы и без остановки текущих продаж магазина.