Как организовать структуру хранения алкогольных марок в 1С при переходе на поштучный учет

Переход на поштучный учет алкогольной продукции (помарочный учет ЕГАИС) требует сохранения и обработки сотен тысяч уникальных кодов маркировки. Если на предприятии используется файловый вариант информационной базы, разработчик сталкивается с жесткими архитектурными ограничениями, главным из которых является лимит на максимальный размер одной таблицы (4 ГБ в формате 1CD). Рассмотрим, как правильно спроектировать структуру данных в конфигурации 1С, чтобы база не разрасталась до критических объемов и обеспечивала высокую скорость чтения и записи.

Ограничения файлового режима и специфика алкогольных марок

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

1. Формат кодов маркировки. В системе ЕГАИС используются марки старого образца (PDF417 — 68 символов) и нового образца (DataMatrix — 150 символов). При сохранении длинных строк типа Строка(150) в измерениях регистров создаются крупные индексы, которые растут быстрее тела самой таблицы.
2. Ограничение таблиц 1CD. В файловом режиме лимит в 4 ГБ распространяется на совокупность данных таблицы, полей переменной длины и индексов. При обороте 100 000 марок в месяц таблица с некорректно выбранными типами данных и индексацией исчерпает лимит за 1–2 года.
3. Табличные блокировки. При многопользовательской работе запись в регистры в файловом режиме блокирует всю таблицу, что вызывает задержки при одновременном сканировании марок с нескольких рабочих мест.

Оптимальная структура: связка справочника и регистра сведений

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

1. Справочник «ШтрихкодыУпаковокИТоваров» (или «Алкомарки»):

   Справочник выступает хранилищем уникальных марок и упаковок. Он содержит:

   1. Реквизит ЗначениеШтрихкода (тип Строка, переменная длина, без индексации всей строки).
   2. Реквизит ХешСумма (тип Строка(32) или Число, с индексацией) — для быстрого поиска марки.
   3. Реквизиты связи: Номенклатура, Характеристика, СерияНоменклатуры / Партия, Справка2 (РФУ-2).
2. Регистр сведений «ОстаткиАлкогольныхМарок» (непериодический, независимый):

   Регистр хранит только текущее состояние и местоположение конкретной марки на складе:

   1. Измерения: Марка (тип СправочникСсылка.ШтрихкодыУпаковокИТоваров).
   2. Ресурсы: Статус (перечисление: ВНаличии, ВРезерве, Отгружен, Списан), Склад, Ячейка.
   3. Реквизиты: ДокументРезерва, ДатаИзменения.

Принцип хранения только актуальных остатков

Чтобы оперативная таблица не росла бесконечно при обороте 100 000 марок в месяц, используем принцип очистки оперативного регистра. Рассмотрим логику его работы:

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

Оптимизация поиска по марке с помощью хэширования

Поиск строки из 150 символов без индекса замедляет сканирование, а создание индекса по длинной строке раздувает файл БД. Решим эту проблему через вычисление хэша (например, MD5 или контрольной суммы) при записи марки. Разберем пример реализации поиска марки по хэш-сумме:

// Пример поиска марки по предварительно рассчитанному хэшу
Функция НайтиМаркуПоШтрихкоду(Знач ТекстМарки, Знач ХешМарки) Экспорт
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ ПЕРВЫЕ 1
        |	Марки.Ссылка КАК МаркаСсылка
        |ИЗ
        |	Справочник.ШтрихкодыУпаковокИТоваров КАК Марки
        |ГДЕ
        |	Марки.ХешСумма = &ХешСумма
        |	И Марки.ЗначениеШтрихкода = &ЗначениеШтрихкода";
        
    Запрос.УстановитьПараметр("ХешСумма", ХешМарки);
    Запрос.УстановитьПараметр("ЗначениеШтрихкода", ТекстМарки);
    
    Выборка = Запрос.Выполнить().Выбрать();
    Если Выборка.Следующий() Тогда
        Возврат Выборка.МаркаСсылка;
    КонецЕсли;
    
    Возврат Справочники.ШтрихкодыУпаковокИТоваров.ПустаяСсылка();
    
КонецФункции

Агрегация марок в групповые упаковки (SSCC)

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

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

Альтернативные технические решения

Если объем оборота превышает возможности файлового режима, рассмотрим следующие практические варианты перехода:

1. Бесплатный сервер PostgreSQL: платформа 1С штатно поддерживает работу с PostgreSQL. Для снятия файловых ограничений и табличных блокировок достаточно перевести базу на клиент-серверный режим, использовав бесплатную СУБД и лицензию на сервер 1С (включая компактные лицензии «1С:Сервер МИНИ»).
2. Вынесение оперативной проверки на ТСД: валидация марок при сборке и приемке переносится в программное обеспечение терминала сбора данных (ТСД). В 1С загружаются уже готовые проверенные пакеты документов, что существенно сокращает число обращений к центральной информационной базе.