Почему в УПД выводится код упаковки вместо кода единицы измерения по ОКЕИ и как это исправить?

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

Рассмотрим достаточно распространенную и неочевидную ситуацию, с которой сталкиваются пользователи современных конфигураций на базе 1С:ERP 2, 1С:Управление торговлей 11 и 1С:Комплексная автоматизация 2. Суть проблемы заключается в следующем: при формировании печатной формы Универсального передаточного документа (УПД) в графе кода единицы измерения выводится непонятное значение (например, 999), хотя в карточке номенклатуры мы визуально видим корректный код по ОКЕИ (например, 778 для упаковок или 796 для штук).

Разберем по шагам, почему возникает эта путаница, как устроена архитектура справочников в 1С и какие существуют надежные способы устранения этой ошибки.

Архитектура справочников единиц измерения в 1С

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

  1. Справочник Классификатор единиц измерения (ОКЕИ). Это глобальный классификатор, в котором хранятся стандартизированные коды. Именно здесь живут правильные значения: 796 для шт, 778 для упак и так далее.
  2. Справочник Упаковки единиц измерения. Это подчиненный справочник, который непосредственно подставляется в табличные части документов и в карточку номенклатуры. Реквизит ЕдиницаИзмерения в справочнике Номенклатура ссылается именно на него.

Таким образом, в справочнике упаковок есть собственный реквизит ЕдиницаИзмерения, который и является ссылкой на элемент классификатора ОКЕИ. В базе данных каждая упаковка имеет свой собственный сгенерированный код, который никак не связан с классификатором. Именно поэтому код упаковки может оказаться равным 999 или любому другому числу.

Почему в запросе мы получаем 999, а на форме видим 778?

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


ВЫБРАТЬ 
    Номенклатура.ЕдиницаИзмерения КАК ЕдиницаИзмерения, 
    Номенклатура.ЕдиницаИзмерения.Код КАК ЕдиницаИзмеренияКод 
ИЗ 
    Справочник.Номенклатура КАК Номенклатура 
ГДЕ 
    Номенклатура.Ссылка = &Ссылка

В данном запросе мы обращаемся к полю Номенклатура.ЕдиницаИзмерения.Код. Как мы выяснили ранее, этот путь ведет к внутреннему коду элемента справочника упаковок. Система честно возвращает нам сгенерированный код упаковки — 999.

Однако, когда мы открываем форму элемента справочника в пользовательском режиме, интерфейс платформы настроен таким образом, чтобы для удобства подменять внутренний код упаковки на реальный код из связанного элемента классификатора ОКЕИ. Поэтому на форме мы видим корректное значение 778. Чтобы получить правильный код по ОКЕИ программно, наш запрос должен обращаться через два уровня вложенности:


ВЫБРАТЬ
    Номенклатура.ЕдиницаИзмерения.ЕдиницаИзмерения.Код КАК КодОКЕИ
ИЗ
    Справочник.Номенклатура КАК Номенклатура

Причина ошибки в печатной форме УПД

Выясним причину, почему в УПД попадает неверный код. Если у вас конфигурация определенного релиза (например, 1С:КА 2.4.12.91), то вы столкнулись с явной ошибкой разработчиков типового решения. При формировании макета УПД, в программном коде 1С, собирающем данные для печати, ошибочно используется обращение к коду упаковки (наше значение 999), а не к классификатору ОКЕИ.

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

Варианты решения проблемы

Рассмотрим подробнее способы, которыми можно исправить этот недочет и вернуть корректные коды в печатные документы.

  1. Установка официального исправления (патча)

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

  2. Обновление релиза конфигурации

    Наиболее фундаментальный подход. Разработчики 1С исправляют подобные баги в последующих релизах. Если есть техническая возможность, рекомендуется обновить конфигурацию до актуального стабильного релиза, где ошибка выборки кода ЕдиницаИзмерения в УПД уже устранена.

  3. Создание расширения конфигурации

    Если база доработана и оперативное обновление невозможно, разработчик может решить проблему за 15-20 минут с помощью механизма расширений. Для этого потребуется:

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

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

← На главную