Физическое хранение кодов маркировки в базе данных 1С

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

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

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

Архитектура хранения данных в подсистеме маркировки

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

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

⚠️ Внимание: Прямое изменение данных в таблицах регистра сведений через SQL-запросы (UPDATE/DELETE) категорически запрещено без остановки работы системы и создания полной резервной копии. Это может привести к рассинхронизации данных между оперативным учетом и данными, отправленными в ЦРПТ (Честный ЗНАК).

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

Основные таблицы регистров сведений и накопления

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

Параллельно с регистром сведений работают регистры накопления, отвечающие за историю движений. Таблицы РегистрНакопления.ТоварыНаСкладах и специализированные регистры маркировки фиксируют каждое перемещение. При проведении документа «Приемка товаров» код записывается в приходную часть регистра, а при документе «Реализация» — в расходную. Это позволяет строить детальные отчеты о пути конкретной единицы товара от производителя до кассы.

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

Ниже приведена таблица основных сущностей, участвующих в хранении данных:

Хранение параметров выбытия товаров

Объект 1С	Примерное имя таблицы (SQL)	Назначение
Справочник.КодыМаркировки	_Reference..Codes	Хранение уникальных идентификаторов кодов
РегистрСведений.КодыМаркировкиВОбороте	_InfoRg..Turnover	Текущий статус и привязка к номенклатуре
РегистрНакопления.ТоварыНаСкладах	_AccRg..Goods	Количественный учет с разрезом по кодам
Документ.ЧестныйЗНАК.ОтчетОВыбытии	_Document..Disposal

Технические детали именования таблиц

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

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

Для безопасного поиска информации о том, где хранится код маркировки в 1С, наиболее эффективным инструментом является встроенная консоль запросов или обработка «Универсальный отчет». Использование этих средств позволяет получить данные в том виде, в котором их видит сама платформа, учитывая все права доступа и механизмы блокировок. Это исключает риск повреждения данных, который существует при работе напрямую с SQL.

Чтобы найти конкретный код, необходимо сформировать запрос к регистру сведений. Запрос должен выбирать поля «КодМаркировки», «Номенклатура» и «Статус». Пример логики такого запроса подразумевает обращение к виртуальной таблице регистра. Платформа 1С сама транслирует этот запрос на язык SQL, оптимизируя его под конкретную СУБД.

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

• 🔍 Используйте режим «Текст запроса» в консоли, чтобы увидеть сгенерированный SQL-код и понять, к каким физическим таблицам идет обращение.
• 📊 Для массового анализа применяйте обработку «Анализ состояния учета по маркировке», которая автоматически проверяет целостность данных в регистрах.
• ⚡ При поиске дублей обязательно учитывайте регистр символов, так как в некоторых конфигурациях коды могут храниться в верхнем регистре.

Особенности хранения в файловом и клиент-серверном варианте

Механизм физического хранения данных существенно различается в зависимости от типа базы данных. В файловом варианте 1С все данные, включая таблицы с кодами маркировки, упакованы в единый файл расширения .1CD. Доступ к этим данным извне возможен только через COM-соединение или ODBC-драйверы, что накладывает ограничения на производительность при выборке больших объемов данных о маркировке.

В клиент-серверном варианте (на базе MS SQL Server, PostgreSQL или Oracle) данные распределены по множеству таблиц. Здесь администратор имеет возможность использовать мощные средства СУБД для индексации и поиска. Правильная настройка индексов по полям, содержащим коды маркировки, является критически важной задачей для обеспечения быстродействия системы при сканировании товаров на кассе.

⚠️ Внимание: В клиент-серверном варианте не создавайте собственные индексы на таблицы 1С без согласования с разработчиками конфигурации. Неправильный индекс может замедлить проведение документов или вызвать блокировки (deadlocks) в момент пиковой нагрузки.

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

Проблемы дублирования и целостности данных

Одной из самых распространенных проблем при работе с маркировкой является появление дублей кодов в базе данных. Это может произойти из-за некорректного импорта данных из файлов Excel, ошибок при ручном вводе или сбоев в работе сканеров штрихкода. Дублирование приводит к тому, что система не может однозначно идентифицировать товар при продаже, что блокирует пробитие чека.

Для выявления таких ситуаций необходимо проводить регулярную сверку данных в регистре «КодыМаркировкиВОбороте». Алгоритм проверки должен искать записи с одинаковым значением поля «КодМаркировки», но разными ссылками на документы поступления или разные статусы. Наличие таких записей сигнализирует о нарушении бизнес-логики учета.

Устранение дублей требует аккуратности. Часто проблема кроется не в самой базе 1С, а в том, что один и тот же код был введен в оборот дважды разными пользователями или через разные каналы (например, импорт из ЭДО и ручной ввод). Перед удалением лишних записей необходимо убедиться, что товар физически присутствует на складе и не был продан.

• 🛑 Никогда не удаляйте дубли кодов маркировки напрямую через SQL, не проанализировав документы-основания их появления.
• ✅ Используйте обработку «Поиск и устранение дублей кодов маркировки», если она предусмотрена вашей конфигурацией.
• 🔄 При обнаружении дублей проведите инвентаризацию по проблемной номенклатуре для сверки фактического наличия с учетными данными.

Взаимодействие с ЦРПТ и выгрузка данных

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

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

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

⚠️ Внимание: Правила обмена данными с ЦРПТ и форматы файлов могут изменяться. Всегда проверяйте актуальность версий обработок обмена в официальном источнике или в разделе «Поддержка» вашей конфигурации 1С перед массовой выгрузкой данных.

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

Можно ли увидеть код маркировки в печатной форме документа?

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

Что делать, если код маркировки не находится в базе при сканировании?

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

Хранятся ли коды маркировки в исторических данных после продажи?

Да, после продажи код маркировки перемещается из регистра «В обороте» в регистры истории выбытия. Это позволяет формировать ретроспективные отчеты и отслеживать историю движения конкретной единицы товара за любой период.

Как очистить базу от тестовых кодов маркировки?

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