При внедрении поэкземплярного учета товаров (маркировки) в крупных оптовых компаниях основной проблемой становится лавинообразный рост объема данных. Если ежегодный оборот составляет десятки миллионов единиц продукции (например, молочная продукция или упакованная вода), стандартные механизмы хранения кодов в справочниках 1С могут привести к деградации производительности системы. В рамках данной статьи мы разберем архитектурные подходы, которые позволяют эффективно обрабатывать огромные массивы кодов маркировки (КМ), минимизировать размер базы данных и обеспечить быструю интеграцию с ГИС МТ (Честный Знак).
Рассмотрим стандартный подход типовых конфигураций 1С, где каждая марка хранится как элемент справочника. При объемах в 50 миллионов записей справочник начинает потреблять значительные ресурсы из-за наличия уникальных идентификаторов (GUID), ссылочной целостности и накладных расходов на объектную модель 1С. Проанализируем альтернативный вариант — хранение в независимых регистрах сведений.
Преимущества регистра сведений (РС):
ВерсияДанных, Предопределенный и других, характерных для справочников.НаборЗаписей для массовой вставки данных, что на порядки быстрее, чем запись отдельных элементов справочника в цикле.Разберем пример кода для быстрой записи кодов в независимый регистр сведений:
НЗ = РегистрыСведений.КэшКодовМаркировки.СоздатьНаборЗаписей();
// Устанавливаем отбор, если нужно перезаписать блок данных
// НЗ.Отбор.ДокументОснование.Установить(СсылкаНаДокумент);
Для Каждого СтрокаКода Из ТаблицаКодов Цикл
НоваяЗапись = НЗ.Добавить();
НоваяЗапись.КодМаркировки = СтрокаКода.ПолныйКод;
НоваяЗапись.GTIN = СтрокаКода.GTIN;
НоваяЗапись.СерийныйНомер = СтрокаКода.Серия;
НоваяЗапись.ДатаПолучения = ТекущаяДата();
КонецЦикла;
// Параметр Ложь в методе Записать(Ложь) означает, что мы не замещаем существующие записи по отбору,
// а добавляем новые (если РС не подчинен регистратору)
НЗ.Записать(Ложь);
Когда объем таблицы с кодами превышает критическую отметку (десятки миллионов строк), стандартных индексов 1С может стать недостаточно. Выясним, как ускорить работу базы на уровне СУБД. Проанализируем ситуацию: при поиске статуса марки система часто выполняет полное сканирование таблицы. Чтобы этого избежать, опытные администраторы баз данных рекомендуют создавать покрывающие индексы или индексы с включенными столбцами непосредственно в SQL Server Management Studio.
Например, если вам часто нужно получать остатки марок в разрезе организаций и справок, создайте индекс, который включает эти измерения. Помните, что при реструктуризации базы через конфигуратор эти индексы могут удалиться, поэтому процедуру их создания стоит автоматизировать или выполнять после каждого обновления конфигурации.
Если бизнес-логика позволяет, рассмотрим стратегию "1С как прокладка". В этом случае полные коды маркировки (включая криптохвосты) хранятся во внешней базе данных (например, PostgreSQL или MS SQL), а в 1С остаются только ссылки или короткие идентификаторы.
Почему это выгодно:
В самой 1С в документах реализации можно хранить только КлючСвязи (например, GUID документа + Номенклатура), по которому при выгрузке данных в ЭДО или ГИС МТ система будет "подтягивать" коды из внешнего источника.
При интеграции с Честным Знаком мы можем столкнуться с выбором между True API и классическим API ГИС МТ. Практика показывает, что True API иногда ведет себя нестабильно при наличии в кодах маркировки спецсимволов (таких как "=", "/", "+").
Рассмотрим проблему пагинации. При запросе больших списков кодов сервер возвращает данные порциями. Если в процессе получения порций в ГИС МТ добавятся новые коды, обычная пагинация по смещению может "перескочить" через записи. Разберем правильный алгоритм получения данных:
limit для ограничения размера выборки (оптимально 500-1000 записей).cache=false, чтобы получать актуальное состояние марок, минуя кэширующие узлы ГИС МТ.Пример анализа ответа при получении списка КМ:
Если выборка "слетает" или возвращает пустой результат на больших объемах, проверьте наличие в кодах символов, требующих экранирования при передаче в строке URL. Всегда используйте методы GET с кодированием параметров в UTF-8.
Один из самых частых вопросов: нужно ли хранить криптохвост? С технической точки зрения, криптохвост (код проверки) необходим для формирования тега 1162 в кассовом чеке и для успешного прохождения проверки в ФН (фискальном накопителе) версии 1.2. Если ваше предприятие осуществляет розничные продажи, хранение полного кода (GTIN + Серия + Криптохвост) обязательно до момента пробития чека.
Для оптовых звеньев, где передача идет через УПД по ЭДО, криптохвост часто не передается, так как ГИС МТ восстанавливает его по своим реестрам. Однако для внутреннего контроля и обеспечения бесперебойности отгрузок рекомендуется сохранять полный код в момент приемки товара от поставщика.
Чтобы база не росла бесконечно, проанализируем стратегию очистки. Коды маркировки товаров, которые выбыли из оборота более 6-12 месяцев назад, можно безболезненно удалять из оперативных таблиц. Перед удалением стоит убедиться, что по данным маркам нет незавершенных претензий или возвратов от покупателей. Сами ссылки в документах можно заменить на текстовое представление или "заглушку", чтобы сохранить целостность печатных форм без хранения тяжелых объектов в базе.
Рассмотрим резюме: для систем с высокой нагрузкой оптимальным решением будет использование независимых регистров сведений с оптимизированными индексами и периодическая очистка данных. Если же объемы превышают возможности 1С по обслуживанию индексов (сотни миллионов записей), необходимо переходить к архитектуре с внешним SQL-хранилищем.