Почему после обновления 1С:ERP не отображаются остатки номенклатуры в расширении?

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет Торговля и дистрибуция
← На главную

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

В этой статье мы подробно разберем проблему, с которой сталкиваются разработчики и администраторы после обновления 1С:ERP до версий 2.5.13 и выше. Речь пойдет о ситуации, когда колонка "В наличии" или "Доступно" в списках номенклатуры (например, на начальной странице или в подборе) перестает заполняться или показывает данные лишь частично.

Анализ ситуации

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

  1. Колонки с данными о наличии товара пусты.
  2. У небольшой части товаров (примерно 10%) данные все же отображаются.
  3. Типовые отчеты (Ведомость по товарам на складах) показывают корректные остатки.

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

Причина: Смена архитектуры распределения запасов

Главная причина описанного поведения кроется в изменениях, внедренных в версии 1С:ERP 2.5.13. Разработчики 1С перевели механизм обеспечения потребностей и распределения запасов на так называемый производительный режим (или новую архитектуру).

Разберем ключевые технические изменения:

  1. Отказ от старого регистра. Ранее основным источником данных для расчета доступности служил регистр накопления РаспределениеЗапасовДвижения. Многие функции общих модулей и динамические списки строили свои запросы именно к нему.
  2. Внедрение нового регистра. В новой версии этот регистр больше не используется для оперативной работы. Вместо него введен оборотный регистр накопления ЗапасыИПотребности.
  3. Изменение логики работы. Теперь система рассчитывает доступность иначе, часто используя фоновые задания для актуализации данных в регистрах сведений (кешах), чтобы ускорить работу списков.

Таким образом, если код вашего расширения (или запрос динамического списка, который модифицируется расширением) пытается получить данные из регистра РаспределениеЗапасовДвижения (или связанных с ним таблиц), он получает пустой результат, так как новые движения туда просто не пишутся.

Почему данные заполняются частично (на 10%)?
Это может быть связано с тем, что в базе остались "хвосты" старых записей, либо система находится в гибридном состоянии, когда часть движений еще видна по старым алгоритмам, но актуальные данные уже пишутся в новые структуры.

Как проверить настройки системы

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

  1. Перейдем в раздел НСИ и администрирование.
  2. Выберите пункт Склад и доставка.
  3. Найдите блок настроек Обеспечение потребностей.

В версиях 2.5.13+ распределение запасов по умолчанию переводится на производительный режим. Это подтверждает, что старые методы работы с данными больше не актуальны.

Решение проблемы: адаптация кода

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

Вариант 1. Если используется Динамический список

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

Поступим следующим образом:

  1. Откроем конфигуратор и найдем типовую форму списка номенклатуры (или форму подбора), где отображение остатков работает корректно в новой версии.
  2. Скопируем текст запроса динамического списка из обновленной типовой формы.
  3. Сравним его с текстом запроса в вашем расширении.

Вы увидите, что в новом запросе обращение идет к другим таблицам. Например, вместо:


ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РаспределениеЗапасовДвижения.Остатки КАК Остатки
Может использоваться обращение к регистру сведений ДоступныеОстаткиПланируемыеПоступления или к регистру накопления ЗапасыИПотребности.

Вариант 2. Если используется программный вызов функций

Если в модуле формы вашего расширения используется программное получение остатков, проанализируем вызываемые методы. Часто разработчики используют функции общего модуля СкладскоеОбеспечение или прямые запросы.

Если вы использовали прямой запрос к регистру РаспределениеЗапасовДвижения, его необходимо переписать на использование регистра ЗапасыИПотребности. Однако, структура измерений и ресурсов у них отличается, поэтому "простая замена имени" не сработает.

Более надежный способ — использовать актуальные экспортные процедуры БСП или прикладного решения. Найдем в конфигурации модуль, отвечающий за запасы. Обычно это модули РаспределениеЗапасов, ЗапасыСервер или СкладскоеОбеспечениеСервер.

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

  1. Поищите глобальным поиском в конфигурации вызовы, содержащие "ПолучитьОстатки".
  2. Обратите внимание на функции, которые принимают в качестве параметров "Склад" и "Номенклатуру".

Рассмотрим пример того, как логика могла измениться концептуально. Раньше мы считали:


Доступно = (ОстатокНаСкладе - Резерв);

Теперь понятие "Резерв" в регистре ЗапасыИПотребности трансформировалось, и расчет доступного остатка может требовать анализа графы "Отложено" или "Зарезервировано" в разрезе назначений.

Рекомендации по доработке

Поскольку проблема вызвана глобальным изменением механизма, универсального "патча" в одну строку не существует. Мы рекомендуем действовать по следующему алгоритму:

  1. Не пытайтесь "починить" старый запрос. Если он обращается к РаспределениеЗапасовДвижения, он бесполезен.
  2. Используйте типовой код как образец. Откройте форму "Подбор товаров" в документах продажи. Там точно реализован механизм показа колонки "В наличии" и "Доступно". Посмотрите в отладчике, какая функция вызывается при активизации строки или при обновлении списка.
  3. Проверьте регламентные задания. Убедитесь, что в базе выполняются фоновые задания по обновлению данных о доступности. В новой архитектуре данные в регистрах для быстрого чтения (регистры сведений) могут обновляться с задержкой, если регламентные задания отключены или зависли.

Подводя итог: проблема не в ошибках кода (как предполагали некоторые участники обсуждения), а в использовании устаревших источников данных. Для решения необходимо актуализировать запросы в вашем расширении, направив их к регистру ЗапасыИПотребности или используя актуальные методы API конфигурации ERP 2.5.

← На главную