НКТ в УПП и УТП: типового помощника там не появится, и это официально

Если вы работаете на Управлении производственным предприятием или на Управлении торговлей для Казахстана, у вас сейчас интересное положение. Код Национального каталога обязателен с 1 января 2026 года наравне со всеми. Типового механизма, который его получает, в вашей конфигурации нет.

Это не задержка релиза. Это объявленное решение, и планировать надо исходя из него. С маркировкой картина та же: сервис 1С:Маркировка с интеграцией в ИС МПТ есть в свежих Бухгалтерии и Управлении торговлей для Казахстана, а в УПП и УТП его нет, и маркировку в таких базах закрывают доработкой.

Что именно объявил вендор

Интеграция с сервисом Национального каталога вышла в пяти конфигурациях: Бухгалтерия для Казахстана с релиза 3.0.68.1, Розница для Казахстана с 2.3.10.4, Управление торговлей для Казахстана с 3.4.5.16, ERP и Комплексная автоматизация для Казахстана с 2.4.5.16.

По УПП для Казахстана позиция другая: обновления и поддержка текущего законодательства выпускаются до конца 2026 года, а развитие функциональности идёт только в современных конфигурациях.

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

Проще говоря: ждать бессмысленно. Ждать нечего.

Три пути, и у каждого своя цена

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

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

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

Почему расширение здесь помогает хуже, чем кажется

Первая мысль обычно такая: сделаем расширение конфигурации, там и место для нового функционала. В обычном приложении эта мысль ломается о платформу.

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

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

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

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

Что придётся добавить в номенклатуру в любом случае

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

• Наименование на казахском. Обязательный атрибут заявки. Взять его неоткуда, кроме как из базы, поэтому реквизит заводится и заполняется.
• Товарный знак отдельным полем. В базе он обычно живёт внутри наименования или в свойстве, а каталогу нужен отдельно.

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

Что ломается в УПП конкретно

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

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

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

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

Сроки, из которых стоит исходить

Поддержку УПП для Казахстана вендор ведёт до конца 2026 года. Это верхняя граница для решения о переходе, и она ближе, чем кажется в сентябре.

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

С чего начать

• Проверить, какая у вас конфигурация и релиз, и убедиться, что помощника каталога в ней действительно нет.
• Прогнать штрихкоды через поиск каталога и понять, скольким товарам карточки нужны, а скольким достаточно проставить готовый код.
• Завести в номенклатуре реквизиты под наименование на казахском и товарный знак.
• Отдельно посчитать позиции с внутренними штрихкодами: им нужен GTIN от GS1 Казахстан, и это самый долгий из сроков.

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