Сертификаты в товарном каталоге: как связать документы с SKU без ложных совпадений

В товарном каталоге документ часто записывают прямо в карточку: номер сертификата, ссылка или PDF. Такой способ кажется достаточным, пока один сертификат не начинает относиться к сотням моделей, один SKU не меняет поставщика, а в приложении не обнаруживается отдельный перечень изделий. После этого невозможно понять, почему ссылка появилась в карточке и к какой версии товара она относилась.

Храните документ один раз, а для каждого товара указывайте, почему он к нему отнесён: например, модель найдена на определённой странице приложения и совпал изготовитель. Так сотрудник сможет проверить связь, а при смене документа будет видно, какие карточки затронуты. Статья объясняет порядок такой проверки и структуру данных для её автоматизации.

С чего начать

1. Соберите заводские модели, изготовителей и полные приложения к документам.
2. Сравните товары с документами и сохраните основание каждого совпадения.
3. Отделите предложения алгоритма от связей, подтверждённых сотрудником.
4. Передавайте на сайт утверждённые сведения.
5. При изменениях сохраняйте историю и повторно проверяйте затронутые товары.

Учебный пример: в каталоге 80 SKU одного бренда и три декларации. SKU здесь означает отдельную товарную позицию в вашей системе. Если сопоставлять только бренд, получится 240 возможных комбинаций «товар - документ». Из этого ещё не следует, что хоть одна связь подходит для публикации.

В условном наборе заводская модель заполнена у 75 позиций. Для 60 находится точная строка приложения и совпадает изготовитель. Ещё 15 требуют проверки дефисов и соответствия артикулов поставщика. Пять карточек без модели остаются в списке запросов данных. Все 80 товаров сохраняются, и по каждому видно следующее действие. Это учебный набор для проверки алгоритма, а не результат проекта «Пятого фактора».

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

1. Не смешивайте SKU, артикул, модель, GTIN и штрихкод

Один товар имеет несколько идентификаторов, и каждый отвечает на свой вопрос. Внутренний SKU различает позиции в вашей системе. Артикул поставщика помогает связаться с его прайсом. Заводская модель используется изготовителем. GTIN идентифицирует торговую единицу в системе GS1. Штрихкод - способ представить идентификатор в машиночитаемой форме, а не самостоятельное доказательство документа.

GS1 определяет GTIN как ключ для уникальной идентификации торговых единиц - продуктов или услуг, которые оцениваются, заказываются либо учитываются в расчётах в цепочке поставок. Правила назначения нового GTIN при изменениях продукта раскрыты в GTIN Management Standard. Из этих правил следует полезный принцип управления вариантами, но не следует, что GTIN обязательно присутствует в записи сертификата или автоматически доказывает её связь с товаром.

Храните идентификаторы раздельно:

Поле	Пример нейтрального значения	Правило
product_id	P-10482	Устойчивый внутренний ключ, не меняется при переименовании
sku	SKU-BLACK-M	Ключ позиции конкретного каталога
supplier_article	A-784/2	Всегда вместе с идентификатором поставщика
manufacturer_model	MX-200	Сохраняется как на изделии и в документах
brand	Brand A	Слабый признак без модели и изготовителя
gtin	Строка цифр	Текстовый тип, проверка формата и источника назначения
variant	Цвет/размер/комплект	Не смешивается с базовой моделью
manufacturer_id	Внутренний ключ изготовителя	Связан с юридическим лицом и площадкой

Храните артикул вместе с указанием поставщика. Значение 1001 может встречаться у нескольких поставщиков. Не делайте GTIN числовым полем: ведущие нули и длинные значения должны сохраняться без преобразования. Не пытайтесь расшифровать из цифр GTIN производителя или страну выпуска без подтверждённых справочных данных; ключ служит идентификации, а сведения о товаре получают из согласованного источника.

Если один SKU объединяет цветовые или размерные варианты, проверьте, допустимо ли это для каталога и документа. Варианты могут иметь разные GTIN, модели, состав или назначение. Поле «одна карточка на витрине» не должно принудительно создавать одну документальную связь на все варианты.

2. Соберите исходные данные и назначьте владельцев

Автоматическое сопоставление не исправит каталог, в котором отсутствуют заводские модели и изготовители. До загрузки документов проверьте заполненность полей. Укажите, кто и когда передал значение. Исходное написание храните отдельно от нормализованного, то есть приведённого к единому формату для поиска.

Что запросить о товаре

• внутренний ID и SKU;
• наименование без маркетинговых сокращений;
• назначение и существенные характеристики;
• бренд, модель, модификацию и вариант;
• GTIN и источник его получения, если он есть;
• фактического изготовителя и производственную площадку;
• поставщика и его артикул;
• серию, партию и даты, когда это важно;
• фотографии маркировки и упаковки для спорных позиций.

Что запросить о документе

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

Заявитель обязан указывать сведения о документе в сопроводительной документации и предъявлять документ или его регистрационный номер заинтересованным лицам в предусмотренных законом случаях. Обязанности и действия при изменении состояния документа описаны в статье 28 Федерального закона № 184-ФЗ. Эта норма не превращает любой переданный поставщиком номер в подтверждённую связь с вашим SKU: реквизиты всё равно сопоставляются с продукцией и поставкой.

Назначьте ответственных: команда каталога ведёт SKU и публикацию, закупки уточняют поставщика и заказанную модель, служба качества определяет правила проверки, IT следит за передачей данных. Если за поле manufacturer_model никто не отвечает, алгоритм будет снова отправлять товары без модели на ручную проверку.

Поле	Основной источник	Кто подтверждает	Что делать при конфликте
SKU	Система управления товарными данными (PIM) или учётная система (ERP)	Владелец каталога	Не менять из файла поставщика
Заводская модель	Маркировка и спецификация	Закупки/качество	Сопоставить версии и запросить уточнение
GTIN	Владелец идентификатора и товарные данные	Владелец каталога	Не генерировать замену автоматически
Изготовитель	Документы и фактическая маркировка	Ответственный специалист	Разделить бренд и юридическое лицо
Номер документа	Официальная запись	Ответственный за документы	Сохранить исходный и нормализованный варианты
Строка приложения	Полный официальный/полученный комплект	Проверяющий	Хранить страницу, цитату-поле и файл

3. Храните товар, документ и основание связи отдельно

SKU - внутренний идентификатор позиции каталога. Сертификат или декларация - документ с собственными реквизитами, объектом, заявителем, изготовителем, сроком, статусом и областью продукции. Даже если сегодня один документ относится к одному SKU, это не повод объединять их в одну запись: завтра у товара может появиться новый поставщик, а документ может охватывать ещё несколько моделей.

Для реализации понадобятся три отдельные таблицы:

1. Products - товарные позиции и варианты.
2. Documents - сертификаты, декларации и их проверенные реквизиты.
3. ProductDocumentLinks - связи товаров с документами и доказательства этих связей.

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

Запись	На какой вопрос отвечает	Чего в ней не должно быть
Товар	Что продаётся в конкретной карточке	Случайной копии реквизитов без основания
Документ	Что сообщает реестровая запись	Решения «подходит всем товарам бренда»
Строка приложения	Какая модель, артикул или группа упомянуты	Интерпретации без ссылки на страницу
Связь	Почему документ отнесён к SKU	Одного поля «сертификат есть» (has_certificate) без пояснения
Проверка	Когда и из какого источника получены сведения	Перезаписи прошлых результатов без истории
Событие	Что изменилось и какие позиции затронуты	Автоматического юридического вердикта

Такое разделение защищает от двух противоположных ошибок. Первая - один документ копируется во все товары по бренду. Вторая - один и тот же документ хранится сотни раз, поэтому его статус и ссылка обновляются неравномерно. Общий справочник помогает обновлять документ в одном месте. Для каждого товара всё равно нужно отдельное основание связи.

Обязательное подтверждение соответствия проводится в случаях и формах, установленных применимым техническим регламентом. Сертификат и декларация не выбираются продавцом как взаимозаменяемые файлы. Базовая рамка дана в статье 23 Федерального закона № 184-ФЗ. Каталог должен хранить фактический вид документа, а не приводить всё к разговорному полю «сертификат».

4. Постройте модель данных, в которой связь имеет доказательство

В записи связи укажите документ и основание, по которому он отнесён к товару. Техническая структура такой записи:

Поле связи	Содержание
link_id	Устойчивый идентификатор связи
product_id	Товар или вариант каталога
document_id	Запись в справочнике документов
scope_item_id	Строка приложения или области продукции, если есть
basis_type	Точное совпадение модели, диапазон, партия, экспертное решение и т. п.
matched_fields	Какие признаки совпали и с какими исходными значениями
confidence	Технический уровень уверенности по утверждённой шкале
review_state	Кандидат, на проверке, подтверждено, отклонено, историческое
reviewed_by	Ответственный сотрудник или роль
reviewed_at	Дата решения
source_checked_at	Дата последнего получения сведений источника
valid_from / valid_to	Интервал использования связи в каталоге, не срок документа
comment	Причина исключения или контекст решения

Не объединяйте confidence и review_state. Высокая техническая уверенность означает, что алгоритм нашёл сильное совпадение, но ещё не обязательно, что человек его утвердил. И наоборот, специалист может подтвердить связь при неполных машинных признаках, указав документированное основание.

Справочник документов должен хранить исходные поля реестра отдельно от внутренних производных. Например, source_status - точное значение источника, а attention_state - внутреннее правило «требует проверки». Если внешний запрос завершился ошибкой, нельзя записывать новый source_status = не действует. Техническая ошибка и юридический статус - разные данные.

Положение о формировании и ведении реестров сертификатов и деклараций задаёт состав реестровых сведений и порядок работы с записями; перед проектированием импорта сверяйтесь с действующей редакцией Постановления Правительства РФ № 1856. Каталог не должен обещать наличие любого удобного поля: часть моделей или приложений может быть представлена иначе, а доступность сведений зависит от официального источника.

Рекомендуемая структура события

event_id
document_id
event_type
observed_value
source_url
source_observed_at
system_received_at
affected_link_ids
decision_owner
decision_state
decision_basis

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

5. Извлекайте приложение построчно и сохраняйте контекст

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

Для каждой позиции приложения сохраняйте:

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

Распознавание текста в сканах (OCR) может разбить дефис, перепутать кириллицу и латиницу, потерять верхний индекс или объединить соседние ячейки. Поэтому нормализованное значение хранится рядом с исходным. Если MX-200 распознано как МХ—200, система может предложить кандидата, но не должна молча переписывать оригинал.

Диапазоны требуют явного правила. Запись вида «A100–A199» не всегда означает числовой диапазон всех промежуточных моделей; дефис может быть частью обозначения или редакционным сокращением. До автоматического перечисления моделей выясните, что означает диапазон в этом документе. Аналогично слова «серия», «тип», «модификации» и «в том числе» должны интерпретироваться с учётом всей строки и применимого документа.

Контроль качества извлечения

1. Выберите страницы с таблицей, многострочным текстом, сноской и переносом на следующую страницу.
2. Сравните число визуальных строк с числом структурированных записей.
3. Проверьте модели с дефисами, пробелами, косыми чертами и похожими буквами.
4. Убедитесь, что заголовок и изготовитель не потерялись при разрыве страницы.
5. Для каждого извлечённого значения сохраните обратную ссылку на страницу.
6. Отметьте строки, которые человек не подтвердил.
7. Повторите тест после изменения распознавания или шаблона импорта.

Распознанный текст используйте для поиска возможных совпадений. Официальное приложение он не заменяет. При споре проверяющий открывает оригинальную страницу и сравнивает её с товаром.

6. Как выбирать документы для проверки

Для каждого предложенного совпадения алгоритм должен показывать причину. Такое предложение будем называть кандидатом: сотрудник ещё должен проверить его. Совпадения по бренду достаточно для поиска вариантов, но недостаточно для публикации связи.

Сильные признаки

• точная заводская модель или артикул изготовителя;
• точный GTIN, если он действительно указан в проверяемом контексте;
• совпадение изготовителя и производственной площадки;
• точная партия или серия выпуска;
• строка приложения с однозначным включением товара;
• идентификатор документа, уже подтверждённый для этой версии модели.

Средние признаки

• нормализованная модель после контролируемого преобразования;
• совпадение нескольких характеристик и назначения;
• подтверждённая таблица соответствия артикулов поставщика заводским моделям;
• бренд вместе с изготовителем и узкой группой продукции.

Слабые признаки

• только бренд;
• общее товарное наименование;
• один код классификации;
• только заявитель или поставщик;
• совпавшее слово из описания;
• изображение похожего изделия;
• соседний SKU в одной категории.

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

Вместо непрозрачного балла храните объяснение:

Кандидат D-204 для SKU-815:
+ точная модель MX-200 в строке приложения, страница 4
+ совпал изготовитель
+ совпала площадка
- GTIN в документе отсутствует
? поставщик использует внутренний артикул A-784/2

Такой результат можно проверить по приложению и сведениям о товаре. Число score = 0.92 без перечня признаков не объясняет, почему алгоритм предложил документ. Порог автоматизации выбирают только после контрольной выборки и анализа ошибок; единый процент для всех категорий не существует.

7. Определите, какие связи можно публиковать

Для каждого результата назначьте следующее действие:

Уровень	Что установлено	Действие каталога
Подтверждено	Ответственный проверил сильные признаки и основание	Разрешить вывод по утверждённому правилу
Точный кандидат	Алгоритм нашёл сильное совпадение, решения человека нет	Отправить в быструю проверку
Вероятный кандидат	Совпало несколько признаков, остаётся неоднозначность	Открыть приложение и запросить данные
Конфликт	Сильные признаки противоречат друг другу	Заблокировать автоматическую публикацию
Нет данных	Не хватает модели, изготовителя, приложения или источника	Сформировать адресный запрос поставщику

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

Закрепите правила публикации:

• карточка не получает документ только по бренду;
• конфликт изготовителя всегда требует решения;
• отсутствие приложения не заменяется предположением по общему названию;
• новый поставщик не наследует старую связь без проверки фактического товара;
• новая модель или значимое изменение создаёт новую версию;
• техническая ошибка источника не удаляет последний успешный результат, но показывает его давность;
• снятие публикации и юридические действия выполняются по утверждённой процедуре, а не по одному машинному событию.

Начните с пробного режима: система предлагает совпадения и показывает конфликты, а карточки остаются без изменений. Ответственные сравнивают предложения с ручной проверкой. После разбора ошибок можно разрешить ограниченные автоматические действия для проверенных категорий.

8. Что показывать покупателю и что оставлять сотруднику

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

Внутренний интерфейс должен быть подробнее. Сотруднику нужны:

• источник и дата последней успешной проверки;
• товарная версия и изготовитель;
• страница или строка приложения;
• совпавшие и конфликтующие признаки;
• состояние ручной проверки;
• история замен и решений;
• технические ошибки обмена;
• список карточек, использующих документ.

Не показывайте посетителю слово «проверено» без расшифровки. Оно может означать, что ссылка открылась, номер найден, статус прочитан или применимость подтверждена специалистом. Используйте конкретную подпись: «сведения получены из источника тогда-то», «связь с моделью подтверждена ответственным тогда-то». Юридически значимую формулировку согласует профильный специалист.

Если файл хранится на сайте, не делайте его единственным источником. PDF может устареть, а реестровая запись - измениться. Ссылка на первоисточник и дата проверки должны оставаться доступными. При этом отсутствие публичной скан-копии само по себе не означает отсутствия документа: правила предоставления открытых сведений и выписки следует проверять по пунктам 24–28 Положения № 1856.

Для разных каналов создавайте представления из одного справочника, а не отдельные копии. Сайт, маркетплейс, B2B-портал и выгрузка дилеру могут требовать разные поля, но используют один document_id и утверждённую связь. Так исправление не расходится по четырём системам.

9. Обновляйте статусы и связи как события, а не полной перезаписью

Состояние документа может меняться, поставщик - заменяться, а товар - выпускаться на новой площадке. Простая ночная перезапись текущего поля уничтожает контекст. Событийная история позволяет определить, какие SKU были связаны с документом в конкретный момент и что компания сделала после изменения.

При каждом обновлении сохраните:

1. источник и время запроса;
2. технический результат получения данных;
3. сырое значение статуса и связанные даты;
4. различие с предыдущим успешным результатом;
5. список активных и исторических связей;
6. затронутые товары, поставщиков и каналы;
7. назначенного владельца решения;
8. действия и основание закрытия события.

Не выводите одинаковое последствие для окончания срока, приостановления, прекращения действия или признания записи недействительной. Эти состояния различаются, а решение по конкретной партии зависит от применимых норм и фактов выпуска и поставки. Статья 28 № 184-ФЗ отдельно затрагивает обязанности заявителя и продукцию, выпущенную в обращение во время действия документа; применять норму следует к установленным обстоятельствам, а не ко всему каталогу по дате в карточке.

Постройте обратный индекс:

document_id
  → scope_item_id
  → active product links
  → historical product links
  → suppliers and manufacturer sites
  → sales channels
  → unresolved orders or batches, если они ведутся в системе

Когда приходит событие, сначала проверяют первоисточник, затем выясняют, какие товары затронуты. Например, документ связан со 120 SKU, но 70 связей исторические, 30 относятся к другому изготовителю после подтверждённой замены, а 20 активны. Система должна показать эти группы отдельно и передать их ответственному для решения.

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

10. Что проверить перед запуском

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

Контрольные сценарии

Сценарий	Ожидаемый результат
Точная модель и изготовитель совпали	Кандидат с высоким техническим уровнем и ссылкой на строку
Совпал бренд, модель другая	Автоматическая связь запрещена
Модель совпала, изготовитель другой	Конфликт и ручная проверка
GTIN совпал, но источник GTIN неизвестен	Кандидат с вопросом об идентификаторе
Приложение отсутствует	Запрос комплекта, не подтверждение по общему тексту
Один SKU имеет двух поставщиков	Отдельные версии или связи с происхождением данных
Изменился статус документа	Событие и обратный список затронутых связей
Источник временно недоступен	Техническая ошибка и дата последнего успеха
Поставщик заменил модель «аналогом»	Новая проверка, без наследования старой связи
OCR перепутал символы	Кандидат остаётся непроверенным до просмотра страницы

Приёмочный чек-лист каталога

• ☐ количество товаров до и после импорта совпадает;
• ☐ каждый SKU имеет устойчивый внутренний ключ;
• ☐ исходные и нормализованные значения хранятся раздельно;
• ☐ документы не дублируются по карточкам;
• ☐ каждая активная связь имеет основание;
• ☐ приложение открывается на нужной странице;
• ☐ конфликт изготовителя нельзя утвердить автоматически;
• ☐ пять позиций без модели остаются видимыми в очереди;
• ☐ техническая ошибка не превращается в статус документа;
• ☐ повторная загрузка не создаёт дубли связей;
• ☐ изменение модели создаёт новую проверку;
• ☐ история решений доступна для аудита.

Проверьте также спорные и неполные данные. Добавьте одинаковые артикулы разных поставщиков, ведущий ноль в GTIN, кириллическую С и латинскую C, документ на партию, несколько производственных площадок и модель, указанную только в приложении. Ошибки на этих строках показывают реальную надёжность правил.

11. Как внедрить проверку и чем может помочь «Пятый фактор»

Работы удобно выполнять в таком порядке:

1. Описать системы, поля и ответственных; проверить заполненность моделей, GTIN и изготовителей.
2. Создать отдельные справочники товаров, документов, поставщиков, изготовителей и строк приложений.
3. Настроить приведение значений к единому формату и поиск кандидатов. Публикацию пока оставить ручной.
4. В интерфейсе проверки показать оригинал, строку приложения и причины предложенного совпадения.
5. Передавать утверждённые связи на сайт, в 1С и другие системы.
6. Настроить повторную проверку источников и журнал изменений с перечнем затронутых товаров.

На первом этапе измеряйте не «процент сертификатов», а полноту исходных данных: сколько SKU имеют модель, изготовителя, GTIN с источником и документ с приложением. На втором - долю связей с воспроизводимым основанием. Эти показатели помогают планировать работу, но не являются публичной гарантией точности или юридической пригодности.

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

Автоматическая привязка к SKU и проверка модели, изготовителя, приложения, серии или партии в бесплатный поиск не входят. Поиск по ИНН, обработку списков и файлов Excel, обмен с 1С, историю замен, уведомления, OCR и массовое сопоставление обсуждают отдельно.

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

Если источником карточек служит учётная система, отдельная услуга - передача сертификатов и деклараций из 1С на сайт. До оценки проекта нужны конфигурация и версия 1С, система управления сайтом (CMS) или PIM, пример номенклатуры, место хранения файлов, правила вариантов и владельцы данных. Интеграция передаёт утверждённые связи; она не должна создавать их по одному общему названию.

Три углубляющих материала:

1. Сертификаты номенклатуры в 1С: проверка статуса и модель хранения - о разделении справочников, связей и результатов проверки в учётной системе.
2. Массовая проверка сертификатов и деклараций из Excel - о подготовке исходных ключей, уникальных документов и возврате результатов ко всем SKU.
3. Как скачать декларацию и получить ссылку на реестр - о полном комплекте файла, приложения, официальной ссылки и даты проверки.