Обработка и сопоставление прайс-листов

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

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

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

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

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

На Discovery команда замеряет не только длительность операции. В расчёт входят ожидание между этапами, повторная работа, исправление ошибок и цена задержки для следующего участника процесса.

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

Рабочие правила формулируются явно: поиск SKU, единиц, валюты, цен, сроков и даты актуальности. Если правило нельзя объяснить владельцу процесса или проверить на примере, оно не должно незаметно управлять production-потоком.

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

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

Результат возвращается как единый реестр цен и очередь изменений. Это важнее отдельного AI-чата: команда продолжает работу в знакомой системе, а руководитель видит статус без дополнительной ручной сводки.

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

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