Как автоматизировать обработку прайс-листов без смешения товаров

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

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

Почему объединение файлов ещё не даёт правильный прайс

Название товара не служит надёжным идентификатором. Один поставщик может написать «Кабель X», другой — добавить марку, цвет или длину бухты, а третий — сократить наименование. Совпадение слов ещё не доказывает, что строки можно сравнивать.

Артикулы тоже нельзя смешивать между поставщиками. Код X-100 в двух файлах может обозначать разные позиции: каждый поставщик ведёт собственный справочник. Поэтому артикул нужно хранить вместе с идентификатором поставщика.

Единица меняет смысл цены. Стоимость одной штуки нельзя напрямую сравнить со стоимостью упаковки, пока неизвестно количество внутри. Цена за метр и цена за бухту также несопоставимы без длины. Если условия не указаны, система должна сохранить неопределённость и передать строку человеку.

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

Какие поля сохранить до сопоставления

Сначала определите структуру итоговой таблицы. Для контроля прайс-листов обычно нужны такие поля:

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

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

Как построить обработку прайс-листа

Рабочий маршрут можно описать шестью шагами:

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

Правила сопоставления зависят от данных. Точное совпадение заранее согласованных идентификаторов надёжнее похожего названия. Название можно использовать для поиска кандидатов, но не как единственное основание для автоматического объединения.

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

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

Учебный пример: одинаковое название, разные условия

Условные строки для объяснения, не реальные цены поставщиков.

В этом примере нельзя назвать предложение поставщика Б более выгодным или дорогим. Для сравнения не хватает длины бухты. Правильное действие системы — показать причину остановки и сохранить обе исходные строки.

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

Какие расхождения передавать человеку

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

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

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

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

Где нужны правила, а где может помочь ИИ

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

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

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

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

Как принять пилот до рабочей выгрузки

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

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

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

Пилот можно принять, если выполняются согласованные критерии:

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

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

Что подготовить для обсуждения проекта

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

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

Покажите Switch On AI обезличенные образцы прайсов и нужную итоговую таблицу. Обсудим ваш процесс, правила сопоставления и проверку перед выгрузкой. После разбора можно определить границы прототипа; он проверит ключевой сценарий, но не будет считаться готовым внедрением.

Перед сравнением сведений из файлов настройте обработку документов и извлечение данных: сохраняйте исходный документ и место, откуда получено поле.

Документация и ограничения

Extract From File в n8n помогает преобразовать файл в данные. Правила сопоставления артикула, валюты и единицы измерения нужно задать отдельно от операции чтения файла.

Источники: n8n: Extract From File. Проверено 29 сентября 2026 года.