При обновлении крупных конфигураций, таких как 1С:ERP или 1С:Комплексная автоматизация, часто возникают ситуации, когда внешние обработки и расширения перестают корректно работать. Особенно чувствительны к обновлениям механизмы, выводящие оперативные данные, такие как свободные остатки, резервы и доступность товаров.
В этой статье мы подробно разберем проблему, с которой сталкиваются разработчики и администраторы после обновления 1С:ERP до версий 2.5.13 и выше. Речь пойдет о ситуации, когда колонка "В наличии" или "Доступно" в списках номенклатуры (например, на начальной странице или в подборе) перестает заполняться или показывает данные лишь частично.
Рассмотрим типичный сценарий. До обновления системы у нас работало расширение, которое выводило информацию о номенклатуре на начальную страницу. Код этого расширения использовал вызовы процедур общих модулей типовой конфигурации для получения остатков. После обновления платформы и конфигурации пользователи заметили следующее:
Если мы попытаемся отладить этот процесс, то можем столкнуться с тем, что отладка уходит глубоко в общие модули и теряется в бесконечных вложенных вызовах. Чтобы понять причину, нам нужно обратиться к архитектурным изменениям самой конфигурации.
Главная причина описанного поведения кроется в изменениях, внедренных в версии 1С:ERP 2.5.13. Разработчики 1С перевели механизм обеспечения потребностей и распределения запасов на так называемый производительный режим (или новую архитектуру).
Разберем ключевые технические изменения:
РаспределениеЗапасовДвижения. Многие функции общих модулей и динамические списки строили свои запросы именно к нему.ЗапасыИПотребности.Таким образом, если код вашего расширения (или запрос динамического списка, который модифицируется расширением) пытается получить данные из регистра РаспределениеЗапасовДвижения (или связанных с ним таблиц), он получает пустой результат, так как новые движения туда просто не пишутся.
Почему данные заполняются частично (на 10%)?
Это может быть связано с тем, что в базе остались "хвосты" старых записей, либо система находится в гибридном состоянии, когда часть движений еще видна по старым алгоритмам, но актуальные данные уже пишутся в новые структуры.
Прежде чем приступать к правке кода, убедимся, что в вашей базе действительно включен новый режим. Проверим настройки:
В версиях 2.5.13+ распределение запасов по умолчанию переводится на производительный режим. Это подтверждает, что старые методы работы с данными больше не актуальны.
Чтобы восстановить работоспособность расширения, нам необходимо найти место, где формируется запрос к данным или вызывается устаревшая функция, и изменить его с учетом новой структуры хранения данных.
Если ваше расширение выводит данные в динамический список (таблицу на форме), скорее всего, текст запроса этого списка был изменен. В типовых конфигурациях запросы списков часто меняются от релиза к релизу.
Поступим следующим образом:
Вы увидите, что в новом запросе обращение идет к другим таблицам. Например, вместо:
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РаспределениеЗапасовДвижения.Остатки КАК Остатки
ДоступныеОстаткиПланируемыеПоступления или к регистру накопления ЗапасыИПотребности.
Если в модуле формы вашего расширения используется программное получение остатков, проанализируем вызываемые методы. Часто разработчики используют функции общего модуля СкладскоеОбеспечение или прямые запросы.
Если вы использовали прямой запрос к регистру РаспределениеЗапасовДвижения, его необходимо переписать на использование регистра ЗапасыИПотребности. Однако, структура измерений и ресурсов у них отличается, поэтому "простая замена имени" не сработает.
Более надежный способ — использовать актуальные экспортные процедуры БСП или прикладного решения. Найдем в конфигурации модуль, отвечающий за запасы. Обычно это модули РаспределениеЗапасов, ЗапасыСервер или СкладскоеОбеспечениеСервер.
В новой архитектуре для получения данных о доступности рекомендуется использовать методы, которые учитывают режим работы системы. Примерный подход к поиску нужного метода:
Рассмотрим пример того, как логика могла измениться концептуально. Раньше мы считали:
Доступно = (ОстатокНаСкладе - Резерв);
Теперь понятие "Резерв" в регистре ЗапасыИПотребности трансформировалось, и расчет доступного остатка может требовать анализа графы "Отложено" или "Зарезервировано" в разрезе назначений.
Поскольку проблема вызвана глобальным изменением механизма, универсального "патча" в одну строку не существует. Мы рекомендуем действовать по следующему алгоритму:
РаспределениеЗапасовДвижения, он бесполезен.Подводя итог: проблема не в ошибках кода (как предполагали некоторые участники обсуждения), а в использовании устаревших источников данных. Для решения необходимо актуализировать запросы в вашем расширении, направив их к регистру ЗапасыИПотребности или используя актуальные методы API конфигурации ERP 2.5.