Где в 1С хранятся коды маркировок: технический разбор

Вопрос о физическом расположении данных о маркировке в информационной базе 1С возникает не только у программистов, но и у администраторов, занимающихся поддержкой и анализом ошибок. Понимание структуры хранения кодов идентификации критически важно для отладки обмена с оператором ЦРПТ (Честный ЗНАК), поиска потерянных товаров или исправления дублей. В отличие от простых справочников, данные о маркировке распределены между несколькими уровнями хранения: от нормативно-справочной информации до оперативных регистров накопления.

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

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

Нормативно-справочная информация и MASTER-данные

Фундаментом системы маркировки в 1С является блок нормативно-справочной информации (НСИ). Здесь хранятся эталонные данные о том, какие коды вообще существуют в системе и к какой номенклатуре они привязаны. Ключевым объектом здесь выступает справочник КодыМаркировки (или аналогичный в зависимости от конфигурации, например, "Коды маркировки товаров"). Именно в этой таблице содержится уникальный код идентификации в текстовом виде и его криптографический хеш.

Важно понимать, что сам по себе код в справочнике не несет информации о том, где товар находится физически. Он лишь подтверждает легитимность цифрового знака. Связь между кодом и товаром осуществляется через регистры сведений, такие как СоответствиеКодовМаркировкиНоменклатуре. Это позволяет одному и тому же коду (теоретически) быть привязанным к разным карточкам товаров в разных организациях, хотя на практике это скорее исключение.

⚠️ Внимание: Прямое редактирование записей в таблице КодыМаркировки через консоль запросов или внешние обработки категорически запрещено. Это может нарушить целостность хеш-сумм и привести к невозможности выгрузки данных в ЦРПТ.

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

Технические детали таблицы КодыМаркировки

Таблица обычно содержит поля: Ссылка (уникальный идентификатор), Код (строка Data Matrix), ХешКода (бинарные данные для быстрого поиска), СтатусПроверки. Поиск по полю ХешКода работает на порядки быстрее, чем по текстовому полю Код.

Оперативный учет: Регистры накопления и остатки

Когда товар с маркировкой поступает на склад и проводится документ "Поступление товаров", данные перетекают из справочников в регистры накопления. Именно здесь формируется картина реальных остатков. Основной регистр, где хранятся текущие коды в наличии, обычно называется ТоварыНаСкладах (с измерением "КодМаркировки") или специализированный регистр ОстаткиТоваровВРазрезеКодовМаркировки.

В отличие от обычных остатков по количеству, здесь каждая запись уникальна. Вы не увидите строки "Футболка — 10 штук", вы увидите 10 строк с разными кодами Data Matrix. Это накладывает ограничения на производительность базы при больших объемах, поэтому разработчики 1С используют специальные индексы. При поиске потерянного товара на складе необходимо делать выборку именно из этого регистра, фильтруя по складу и номенклатуре.

• 🔍 Регистр накопления хранит текущее состояние: на каком складе, в какой ячейке и в чьей собственности находится конкретный экземпляр.
• 📦 Агрегация учитывается через отдельные измерения, позволяя знать, что код внутри коробки находится в коробке с другим кодом.
• 🔄 Движения записываются при каждом проведении документа: поступление, перемещение, продажа, списание.

Если товар был продан, запись из регистра остатков уходит, но сохраняется история в регистрах оборотов. Для анализа истории перемещений конкретного Data Matrix кода следует использовать отчеты по регистру накопления "ПродажиТоваров" или "ДвижениеТоваров", где в качестве измерения выступает код маркировки. Это позволяет отследить весь путь товара от приемки до отгрузки клиенту.

Работа с агрегированными упаковками и иерархией

Одной из самых сложных задач является хранение информации об агрегации. В 1С для этого используются специальные регистры сведений, например, СоставАгрегированныхЕдиниц. Здесь хранится связь между кодом транспортной упаковки (коробки, паллеты) и кодами единиц товара, вложенных внутрь. Это позволяет при отгрузке паллеты автоматически списывать десятки вложенных кодов без их индивидуального сканирования.

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

Тип объекта	Регистр хранения	Ключевое измерение	Статус данных
Единица товара	ТоварыНаСкладах	КодМаркировки	В наличии / В резерве
Агрегат (Коробка)	СоставАгрегированныхЕдиниц	КодАгрегата	Сформирован / Расформирован
Выбывший товар	ВыбытиеТоваров	КодМаркировки	Продан / Списан
Код в пути	ТоварыВПути	КодМаркировки	В процессе передачи

Разрыв связей агрегации — частая причина ошибок при инвентаризации. Если в базе записано, что код А лежит в коробке Б, а физически коробка Б уже открыта и коды разложены по полкам, но в 1С не проведен документ "Расформирование агрегата", система будет считать коды недоступными для отгрузки поштучно. Проверка таблицы состава агрегатов помогает выявить такие логические тупики.

Архивы и история выбытия кодов

Коды маркировки не удаляются из базы данных после продажи или списания. Они перемещаются в архивные срезы регистров или в специализированные таблицы истории. В типовых конфигурациях (ЕРП, УТ 11, КА 2) существует механизм очистки или архивирования старых данных, но по умолчанию история хранится долго. Это необходимо для формирования отчетов в контролирующие органы и проведения ретроспективного анализа.

Таблицы, хранящие историю выбытия, часто имеют префиксы, указывающие на их назначение, например, ИсторияКодовМаркировки или срезы периодических регистров. При проведении документа "Честный ЗНАК: Выбытие" или при закрытии месяца система фиксирует финальный статус кода. Если вам нужно доказать, что товар был продан полгода назад, искать его в текущих остатках бесполезно — необходимо обращаться к истории движений.

⚠️ Внимание: Регламентные задания по очистке истории могут удалять старые записи о выбывших кодах для экономии места. Перед глубоким аудитом убедитесь, что настройки хранения истории в НСИ и Администрирование позволяют хранить данные за требуемый период.

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

Технические таблицы и кэширование обмена

В процессе обмена с внешней системой "Честный ЗНАК" 1С использует ряд служебных таблиц для буферизации данных. Перед тем как код попадет в основные регистры, он часто проходит через таблицы типа КэшиКодовМаркировки или временные хранилища в рамках сеанса. Это сделано для оптимизации производительности при массовой загрузке тысяч кодов.

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

• ⚙️ Таблицы кэша используются для временного хранения кодов перед массовой записью в базу.
• 📡 Очереди обмена хранят XML-пакеты, отправляемые или полученные от оператора фискальных данных и ЦРПТ.
• 🗑️ Таблицы удаленных элементов могут содержать ссылки на коды, которые были помечены на удаление, но еще не вытеснены из базы.

Для администраторов баз данных полезно знать, что таблицы с кодами маркировки часто занимают значительный объем места. Индексация полей с хеш-кодами является обязательным условием быстрой работы. Отсутствие индексов на полях, участвующих в соединениях (JOIN) при формировании отчетов по маркировке, приводит к_full scan_ таблиц и зависанию системы при попытке открыть журнал документов.

Поиск и анализ через консоль запросов

Для профессионального поиска места хранения конкретного кода наиболее эффективным инструментом является консоль запросов или внешняя обработка анализа базы. Прямой SQL-запрос (для SQL Server) или запрос на языке 1С позволяет точно определить, в какой физической таблице лежит интересующая запись. Однако важно помнить о блокировках: чтение больших таблиц во время активной работы пользователей может замедлить работу системы.

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

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

При работе с базами данных на PostgreSQL или MS SQL следует учитывать особенности хранения строк большой длины. Коды Data Matrix могут быть достаточно длинными, и в некоторых версиях платформ они могут храниться в выносных таблицах (LOBS), что усложняет прямой поиск через SQL без использования специальных функций платформы 1С.

⚠️ Внимание: Интерфейсы и названия таблиц могут отличаться в зависимости от версии платформы (8.3.20+) и конфигурации (УТ 11.5, ЕРП 2.5). Всегда сверяйте имена регистров в конфигураторе или через объект "Метаданные" перед выполнением прямых запросов.

Часто задаваемые вопросы (FAQ)

Можно ли удалить код маркировки из базы 1С, если он был введен ошибочно?

Физическое удаление записей из таблиц маркировки стандартными средствами невозможно и опасно. Если код введен ошибочно, его необходимо "нейтрализовать" через документы корректировки или списания, чтобы он не влиял на остатки. Прямое удаление через SQL нарушит целостность ссылок и может привести к краху базы.

Почему код виден в справочнике, но не подбирается в документ реализации?

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

Где хранятся коды агрегации (коробок и паллет)?

Информация о составе агрегированных единиц хранится в регистрах сведений, обычно называемых СоставАгрегированныхЕдиниц или аналогично. Там фиксируется связь: Код Агрегата -> Список вложенных Кодов Товаров. Без записи в этом регистре система не знает, что находится внутри коробки.

Как найти все коды, по которым не пришел ответ от Честного Знака?

Для этого следует использовать отчет "Состояние обмена с ИС МП" или аналогичный в вашей конфигурации. Технически эти данные хранятся в таблицах очереди сообщений и временных хранилищах статусов, куда записывается результат асинхронного обмена с оператором.

Влияет ли длина кода Data Matrix на производительность базы?

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