Как организовать сканирование алкогольной продукции при приемке и оптимизировать базу 1С под миллионы марок ЕГАИС?

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

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

Стратегии приемки алкоголя: какую схему выбрать?

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

1. Тотальное (побутылочное) сканирование. Применяется преимущественно в розничных точках и небольших сетях при объемах поставок до 500–1000 бутылок в одной накладной. Каждая бутылка физически извлекается из коробки и сканируется терминалом сбора данных (ТСД). Это позволяет полностью исключить расхождения фактического наличия марок с данными ЕГАИС. Если выявляется пересорт, поставщику сразу же оформляется акт расхождений, что избавляет розницу от риска получить штраф по статье 14.19 КоАП РФ.
2. Доверительная приемка (по коробам и паллетам). Используется крупными дистрибьюторами и оптовиками при «вагонных» поставках. При этом сканируются только штрихкоды групповой тары (коробок или паллет с кодами SSCC). Информационная система автоматически сопоставляет код упаковки со вложенными в нее марками, переданными поставщиком по ЕГАИС. Важный нюанс: этот метод полностью зависит от корректности агрегации на заводе-производителе. Если на линии произошел сбой, вы получите «грязную» агрегацию и внутренний пересорт марок, который вскроется только при инвентаризации или продаже.
3. Комбинированный (выборочный) контроль. Оптимальный компромисс между скоростью и безопасностью. На складе сканируют, например, по одной случайной бутылке с каждой паллеты или коробки, чтобы убедиться в отсутствии явного пересорта и подтвердить легальность партии. Дополнительно на тотальный контроль могут отправляться дорогие позиции элитного алкоголя или поставки от ненадежных контрагентов.

Организация процесса сканирования с ТСД и интеграция с WMS

Для мобильной работы на складе традиционно используются терминалы сбора данных (например, марки семейства Urovo, Honeywell, Zebra). Программное обеспечение ТСД работает в связке с WMS (системой управления складом) через web-сервисы в режиме реального времени (онлайн-обмен). Рассмотрим типичный сценарий проверки:

В момент сканирования штрихкода на складе мобильное приложение не обращается к глобальной системе ЕГАИС напрямую. ТСД отправляет запрос во внутреннюю WMS, где проверяется:

• Соответствие считанного штрихкода номенклатуре из приходной накладной;
• Физическое нахождение марки в сканируемой коробке (в соответствии с данными агрегации поставщика);
• Отсутствие дублей марок внутри текущей поставки.

Если проверка проходит успешно, марка привязывается к документу поступления во внутренней базе данных 1С для последующей отправки подтверждения в ЕГАИС.

Оптимизация 1С при работе с миллионными объемами марок

Когда оптовая или розничная компания работает с алкоголем длительное время, объем регистра сведений, хранящего статусы и движения акцизных марок, лавинообразно растет. Накопление 10–50 миллионов записей в периодическом регистре сведений может привести к драматическому падению производительности систем на платформе 1С:Предприятие 8.3.

Выясним причину замедления. Как правило, разработчики по умолчанию используют виртуальную таблицу СрезПоследних для проверки текущего состояния марки перед ее отгрузкой или продажей. При объемах базы в десятки миллионов записей СУБД (например, MS SQL Server или PostgreSQL) при обращении к СрезПоследних часто строит неоптимальный план запроса, генерируя тяжелые операции типа Table Spool (создание временных таблиц на диске), что приводит к зависанию проведения документов.

Разберем по шагам, как решить эту проблему и добиться проведения документов на 15 000–20 000 марок всего за несколько секунд:

Шаг 1. Отказ от стандартного среза последних в запросах

Вместо использования виртуальной таблицы СрезПоследних для периодического регистра сведений рекомендуется применять соединение с временной таблицей максимальных дат (периодов), отобранных по конкретному списку марок. Это позволяет СУБД использовать наиболее эффективные индексы.

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

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

Этот подход гарантирует стабильно высокую скорость работы запроса вне зависимости от общего количества записей в регистре (хоть 5 миллионов, хоть 100 миллионов), так как поиск осуществляется строго по индексу ключевого поля марки.

Шаг 2. Разделение регистра на оперативный и архивный

Еще один проверенный метод оптимизации — разделение данных. Для оперативной проверки статусов марок при продаже и перемещении нам нужны только актуальные записи (те марки, которые сейчас физически находятся на остатках).

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

Шаг 3. Локальные проверки на кассовом узле (Фронт-офис)

В розничной сети крайне важно, чтобы кассир мог пробить чек мгновенно. Задержка даже в 2 секунды на проверку марки в центральной базе 1С по сети в час-пик создаст огромные очереди.

Для оптимизации этого процесса рекомендуется выгружать плоский список («белый список») разрешенных к продаже марок напрямую в локальную базу кассового софта (например, Frontol или специализированную локальную базу на СУБД SQLite/PostgreSQL). Касса моментально валидирует марку локально перед отправкой чека в ЕГАИС, минимизируя нагрузку на центральный сервер 1С.

Резюме

Автоматизация приемки алкоголя — это всегда баланс между скоростью работы склада и минимизацией рисков получения штрафов. Комбинирование выборочного и тотального сканирования с помощью ТСД закрывает бизнес-риски пересорта. С технической стороны, грамотная работа с СУБД, отказ от стандартного использования СрезПоследних в пользу временных таблиц и разделение оперативного контура от архивного позволяют системе на базе 1С стабильно функционировать на базах любого масштаба.