Загрузка оптового заказа из таблицы: как проверить позиции до добавления

Работа покупателя начинается раньше сайта

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

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

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

Самая важная колонка — та, по которой узнают товар

Код магазина, артикул производителя и штрихкод могут стоять рядом в одной таблице. Подпись «Артикул» не объясняет, какой из них принимает импорт. Если загрузчик ожидает код магазина, а покупатель вставил артикул поставщика, внешне корректная строка останется нераспознанной.

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

Вторая обязательная колонка — количество. Остальные могут быть полезны человеку: название помогает заметить ошибочное сопоставление, комментарий объясняет назначение строки. Необязательно требовать от покупателя удалять всё лишнее. Проще дать ему назначить две нужные колонки в предварительном просмотре.

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

Два одинаковых кода — это не обязательно ошибка

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

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

Такое поведение нужно назвать в интерфейсе. Покупатель может ожидать замену количества, особенно если он загрузил обновлённую версию того же списка. Кнопка «Добавить количества из файла» объясняет действие точнее, чем просто «Импортировать».

С упаковками возникает следующий выбор. Если товар отгружается по шесть штук, запрос на восемь можно отклонить, округлить или предложить исправить. В любом случае покупатель должен увидеть изменение. Молча превратить восемь в двенадцать — значит изменить его заказ без понятного объяснения.

Разберите небольшой заказ прямо здесь

В примере ниже три условных товара. Код 1042 уже есть в заказе в количестве четырёх штук; товар 2050 продаётся по шесть. Две строки с кодом 1042 объединяются, а ошибки остаются видны вместе с причиной.

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

Предварительный просмотр должен объяснять изменения

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

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

С дробными количествами нужно принимать предметное решение. Для штучного товара значение 2,5, скорее всего, ошибка. Для товара в метрах это может быть нормальный заказ. Приведение любого числа к целому без объяснения слишком легко меняет намерение покупателя.

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

Между анализом и добавлением что-то может измениться

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

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

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

Цена товара при импорте берётся из условий покупателя в системе. Колонка «Цена» в произвольной таблице не должна сама менять эти условия. Если нужно загружать согласованное коммерческое предложение, стоит выделить для него отдельный сценарий.

Что проверить на нескольких файлах до запуска

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

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

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

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