При обновлении конфигурации 1С:Управление нашей фирмой (УНФ) до версии 1.6.23.117 и выше многие разработчики и администраторы систем заметили существенное изменение в архитектуре метаданных. В частности, в регистре сведений ШтрихкодыНоменклатуры произошла «миграция» ключевых полей: если раньше измерением был только Штрихкод, а такие поля как Номенклатура, Характеристика, Партия и ЕдиницаИзмерения являлись ресурсами, то в новых версиях все они стали измерениями. Разберем подробно, какая логика стоит за этим решением и какие преимущества это дает для бизнеса и производительности системы.
Для начала вспомним базовые принципы работы платформы «1С:Предприятие 8». Измерения регистра сведений определяют уникальность записи. В старой модели, где только Штрихкод был измерением, система гарантировала, что один и тот же штрихкод не может встретиться в таблице дважды. Это логично для классической розницы, где один код EAN-13 жестко привязан к одной позиции номенклатуры. Однако такая структура накладывала серьезные ограничения при усложнении бизнес-процессов.
Рассмотрим ситуацию, когда мы переводим аналитику в измерения. Теперь уникальность записи определяется комбинацией всех полей. Это позволяет хранить в системе более сложные связки, которые ранее требовали либо программных «костылей», либо создания дополнительных регистров. Выясним основные причины такого архитектурного маневра.
Проанализируем современные требования к учету маркированной продукции. В системе маркировки (ИС МП) один и тот же GTIN (международный код товара) может быть привязан к разным потребительским упаковкам или вариантам исполнения товара. Более того, при работе с транспортными упаковками и групповыми кодами агрегации возникает необходимость жесткой связки идентификатора с конкретной партией или характеристикой.
Сделав Номенклатуру, Характеристику и Партию измерениями, разработчики обеспечили соответствие структуры базы данных логике запросов в ИС МП. Теперь связка «Товар + Характеристика + Код» является атомарным идентификатором, что упрощает сопоставление данных при сканировании кодов маркировки и проверке их статусов в ГИС Маркировка.
Посмотрим на техническую сторону вопроса со стороны базы данных (SQL). В платформе 1С поля, входящие в состав измерений, автоматически включаются в индексы таблицы регистра. В старой архитектуре, когда нам нужно было найти все штрихкоды конкретной номенклатуры (например, при печати этикеток из карточки товара), системе приходилось либо выполнять полное сканирование таблицы (Full Scan), либо опираться на дополнительные индексы, если они были созданы вручную.
После переноса аналитики в измерения, поиск по полям Номенклатура или Характеристика стал максимально быстрым на уровне СУБД, так как эти поля теперь являются частью кластерного (или основного) индекса. Рассмотрим пример типичного запроса, который стал работать быстрее:
ВЫБРАТЬ
Штрихкоды.Штрихкод КАК Штрихкод,
Штрихкоды.ЕдиницаИзмерения КАК Единица
ИЗ
РегистрСведений.ШтрихкодыНоменклатуры КАК Штрихкоды
ГДЕ
Штрихкоды.Номенклатура = &Номенклатура
И Штрихкоды.Характеристика = &Характеристика
В новой структуре этот запрос отрабатывает мгновенно даже в базах с миллионами записей, так как поиск идет по индексированным измерениям, а не по неиндексированным (в общем случае) ресурсам.
Разберем ситуацию с весовым товаром или товаром, продаваемым как поштучно, так и упаковками. Часто производители присваивают разные штрихкоды штуке товара и заводскому коробу (паллете). При этом для системы учета это может быть одна и та же номенклатурная позиция, но разные единицы измерения.
В старой логике (где Штрихкод — единственное измерение) мы могли записать штрихкод короба, но поиск по номенклатуре был затруднен. В новой структуре мы можем создавать уникальные записи для каждой комбинации. Это критично для логистических цепочек, где один и тот же код может использоваться в разных контекстах, и нам важно сохранять историю или вариативность этих связей.
Проанализируем экосистему программных продуктов 1С. В таких конфигурациях, как «1С:Управление торговлей» (ред. 11), «1С:Комплексная автоматизация» и «1С:ERP Управление предприятием», структура регистра штрихкодов уже давно построена по принципу «аналитика в измерениях».
Приведение 1С:УНФ к единому стандарту упрощает:
Современная УНФ активно используется вместе с мобильными приложениями и терминалами сбора данных (ТСД). При синхронизации данных с мобильным устройством (через механизмы Data Exchange) гораздо надежнее оперировать записями, уникальность которых определена набором ключевых полей. Это минимизирует риск возникновения дублей при двустороннем обмене, когда один и тот же товар со штрихкодом может быть изменен или добавлен одновременно на мобильном устройстве и в центральной базе.
Выясним, на что следует обратить внимание при работе с обновленным регистром. Если в ваших кастомных обработках или отчетах использовались прямые запросы или методы СоздатьМенеджерЗаписи(), необходимо убедиться, что вы передаете значения для всех измерений.
Например, при записи нового штрихкода теперь недостаточно установить только Штрихкод. Рассмотрим правильный подход:
МенеджерЗаписи = РегистрыСведений.ШтрихкодыНоменклатуры.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Штрихкод = "2000000000015";
МенеджерЗаписи.Номенклатура = СсылкаНаТовар;
МенеджерЗаписи.Характеристика = СсылкаНаХарактеристику;
МенеджерЗаписи.ЕдиницаИзмерения = СсылкаНаУпаковку;
// Теперь записываем, так как все ключевые поля (измерения) заполнены
МенеджерЗаписи.Записать();
Важный момент: если вы оставите измерения (например, Характеристика) пустыми, платформа воспримет это как Справочники.ХарактеристикиНоменклатуры.ПустаяСсылка(). Это допустимо, но важно понимать, что это будет уже другая уникальная комбинация в регистре.
Подводя итог, можно утверждать, что изменение структуры регистра ШтрихкодыНоменклатуры — это не случайное решение, а необходимый шаг для эволюции программы. Мы получаем высокую скорость поиска, готовность к тотальной маркировке товаров и совместимость с более мощными учетными системами семейства 1С. Несмотря на то, что это потребовало от разработчиков пересмотра некоторых алгоритмов, долгосрочный положительный эффект для стабильности и масштабируемости системы очевиден.