40 прайс-листов в единый каталог: AI-извлечение данных для дистрибьютора автозапчастей

Самое дорогое в устаревшем прайсе — не ошибка в цене. Самое дорогое — клиент, который ушёл к конкуренту, потому что нужной позиции не оказалось в каталоге. Она была у поставщика, лежала в свежем прайс-листе, присланном два дня назад. Но менеджер ещё не дошёл до этого файла.

Этот кейс — про дистрибьютора автозапчастей, у которого обновление каталога превратилось в узкое место бизнеса. И про то, почему Excel-макросы и регулярные выражения оказались тупиком, а AI — нет.

Про бизнес и масштаб задачи

К нам обратилась компания, которая торгует автозапчастями оптом и в розницу. Более 40 поставщиков, каталог на 120 000+ позиций. Основные продажи — через собственный сайт и менеджеров.

Каждый поставщик присылает обновлённый прайс-лист по-своему. Кто-то шлёт Excel с аккуратными колонками. Кто-то — PDF с таблицей, которая выглядит по-разному от месяца к месяцу. Третий — архив из нескольких файлов. Четвёртый — прямо в теле письма: «Новые цены на масла, см. приложение + ниже позиции, которые сняты с производства». Пятый — скан бумажного каталога с рукописными пометками.

Сорок поставщиков — сорок форматов. И каждую неделю приходят обновления.

Три дня на одно обновление

Менеджер по закупкам тратил три полных рабочих дня на цикл обновления каталога. Процесс выглядел так:

Открыть почту, скачать все прайсы за неделю.
Для каждого файла — понять структуру: где артикул, где цена, где наименование, где остаток. В каждом прайсе колонки назывались по-разному: «Арт.», «Код», «Артикул поставщика», «Part Number».
Вручную скопировать данные в мастер-таблицу, сопоставив артикулы поставщика с внутренними артикулами каталога.
Обработать спецслучаи: снятые с производства позиции, замены, новые товары без аналогов.
Проверить результат — прогнать выборочно 50-100 позиций.

Три дня — если всё штатно. Если поставщик поменял формат прайса (а это случалось регулярно), добавлялся ещё день на разбор.

Последствия для бизнеса были конкретные:

Каталог устаревал на неделю. Клиент видел цену, которой уже нет. Менеджер звонил поставщику, уточнял, перезванивал клиенту — сделка затягивалась или срывалась.
Новые позиции появлялись с задержкой. Поставщик добавил линейку фильтров, а в каталоге их нет ещё неделю. Клиент ищет — не находит — звонит конкуренту.
Ошибки при ручном переносе. При 120 000 позиций и 40 прайсах ошибки неизбежны. Перепутанная цена, потерянная позиция, неправильный остаток — каждая ошибка стоила денег.

Почему макросы не спасали

До нас компания пробовала автоматизировать процесс макросами в Excel. Для пяти крупнейших поставщиков написали VBA-скрипты: парсинг конкретных столбцов, поиск артикулов, подстановка цен.

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

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

Проблема в том, что прайс-лист — это не база данных. Это документ, созданный человеком для человека. У него есть шапка, комментарии, пустые строки для визуального разделения, объединённые ячейки, примечания в скобках. Человек видит прайс и понимает структуру за секунду. Регулярное выражение — нет.

Что мы построили

Сервис, который принимает прайс-лист в любом формате — Excel, PDF, CSV, текст письма — и возвращает структурированные данные: артикул, наименование, цена, остаток, статус. Без привязки к конкретному формату, без набора правил для каждого поставщика.

Как это работает

Шаг 1. Сбор. Node.js-сервис подключается к почтовому ящику закупок по IMAP. Раз в час проверяет новые письма от поставщиков (список адресов настраивается). Извлекает вложения — Excel, PDF, CSV, изображения. Если данные в теле письма — извлекает и его.

Шаг 2. Извлечение. Каждый файл отправляется в Claude API. Промпт не описывает формат конкретного поставщика — он описывает задачу: «Извлеки из этого документа таблицу товаров. Для каждой позиции определи: артикул, наименование, цену, единицу измерения, остаток (если указан), примечание (если есть). Верни JSON-массив.»

Claude видит документ целиком — с заголовками, комментариями, визуальной структурой — и понимает, что есть данные, а что оформление. Не нужно писать парсер для каждого формата. Модель сама определяет, где столбец с артикулами, даже если он называется «Код», «Part No.» или «Арт/Номенклатура».

Шаг 3. Сопоставление. Извлечённые позиции сопоставляются с внутренним каталогом по артикулу. Здесь тоже помогает AI: артикулы от поставщиков не всегда совпадают символ в символ с каталогом. «MAN 51.12503-0065» и «51125030065» — один и тот же фильтр. Нечёткий матчинг через embedding-модель находит соответствия, которые пропустил бы точный поиск.

Шаг 4. Обновление. Сопоставленные данные записываются в мастер-таблицу Google Sheets: новые цены, изменённые остатки, снятые позиции. Каждое изменение помечается: дата, поставщик, исходный файл.

Шаг 5. Контроль. Три типа алертов в Telegram:

Аномалии: цена изменилась больше чем на 20% — скорее всего ошибка или нужно перепроверить.
Новые позиции: товар есть в прайсе, но нет в каталоге — менеджер решает, добавлять ли.
Несопоставленные: система не смогла найти соответствие — требуется ручная проверка.

Что происходит, когда AI не уверен

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

Выше 85%. Данные записываются в мастер-каталог автоматически. Это ~92% всех позиций.
Ниже 85%. Позиция попадает в лист «На проверку» в той же таблице. Менеджер видит исходное значение из прайса, предложенное сопоставление и причину низкой уверенности. Решает в один клик: принять, исправить или отклонить.

Это не AI, который «сам всё знает». Это AI, который делает 92% рутины и честно признаётся, когда не уверен.

Что изменилось за три месяца

Было: 3 рабочих дня на полный цикл обновления каталога. Один менеджер, занятый только этим. Каталог актуален с задержкой 5-7 дней.

Стало:

1 час на обработку всех 40 прайсов — это время работы сервиса, не человека. Менеджер тратит 20-30 минут на проверку алертов и спорных позиций.
Каталог обновляется ежедневно, а не раз в неделю. Свежие цены — в день получения прайса.
Ошибки сопоставления: 0.3% вместо ~2.5% при ручном переносе. В абсолютных числах: с 3 000 ошибок в месяц до 360.

Метрика	Было	Стало
Цикл обновления каталога	3 рабочих дня	1 час автоматически + 30 мин проверка
Актуальность цен	Задержка 5-7 дней	В день получения прайса
Ошибки сопоставления	~2.5% (3 000/мес)	0.3% (360/мес)
Форматы без ручной настройки	5 из 40 (макросы)	40 из 40
Время менеджера	24 часа в неделю	2-3 часа в неделю

Окупаемость: разработка — 180 000 руб. Расходы на Claude API — 8 000-12 000 руб./мес (зависит от объёма прайсов). Высвободили 20+ часов в неделю менеджера по закупкам. Окупаемость — менее 3 месяцев.

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

О чём стоит знать заранее

Стоимость API растёт с объёмом. 40 прайсов в неделю — 8 000-12 000 рублей в месяц. Если поставщиков станет 100 и прайсы будут приходить ежедневно — расходы вырастут в 3-4 раза. Пока это кратно дешевле ручной работы, но в бюджете учитывать нужно.

PDF-сканы с плохим качеством — слабое место. Из 40 поставщиков трое присылают сканы бумажных каталогов. Качество распознавания зависит от качества скана. Если документ отсканирован криво или с низким разрешением — AI извлечёт данные с ошибками. Мы попросили этих поставщиков присылать электронные версии. Двое согласились, один по-прежнему шлёт сканы — его прайс проверяется вручную.

Новые поставщики требуют проверки. Когда подключается новый поставщик, первые 2-3 прайса мы рекомендуем проверять полностью. Система адаптируется к формату без настройки, но лучше убедиться, что она правильно «поняла» структуру именно этого документа. После калибровки — переходим на автоматический режим.

Embedding-модель для матчинга нужно обновлять. Каталог растёт, появляются новые бренды и линейки. Раз в квартал мы пересчитываем embeddings для всего каталога. Это занимает 2-3 часа и требует ручного запуска. Не критично, но забывать не стоит.

Технический стек

Компонент	Технология
Платформа	Node.js, TypeScript
Сбор прайсов	IMAP-клиент, парсинг вложений
Извлечение данных	Claude API (мультимодальная модель)
Нечёткий матчинг	Embedding-модель + cosine similarity
Хранение данных	Google Sheets (мастер-каталог)
Очереди	BullMQ, Redis
Уведомления	Telegram Bot API
Деплой	VPS, Docker

Архитектура

Сервис работает как фоновый процесс на VPS. IMAP-клиент проверяет почту раз в час. Каждое новое письмо от поставщика создаёт задачу в очереди BullMQ. Задачи обрабатываются последовательно: извлечение файла → отправка в Claude API → парсинг ответа → сопоставление с каталогом → запись в Google Sheets.

Если Claude API недоступен или вернул ошибку — задача повторяется с нарастающей задержкой (3, 9, 27 секунд). Если после 5 попыток результата нет — задача уходит в dead letter queue, алерт в Telegram. За три месяца работы таких случаев было два, оба — из-за временной недоступности API.