B2B-заказ по артикулу и файлу: как настроить массовый заказ и проверить результат

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

Что входит в задачу B2B-заказа по артикулу и файлу

Оптовый покупатель редко собирает заказ кликами по каталогу. Ему привычнее работать со своим списком: выгрузка из учётной системы, таблица от снабженца, письмо с номерами позиций. Поэтому B2B-заказ по артикулу — это не «ещё одна кнопка», а отдельный сценарий, где магазин принимает чужой список и превращает его в корректную корзину.

В границы задачи входит:

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

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

Важно заранее договориться, что считается результатом. Результат — не «поле для вставки артикулов», а предсказуемое поведение: клиент вставил список, увидел, какие строки распознаны, какие нет, исправил спорные и оформил заказ. Если после загрузки файла менеджер всё равно перепроверяет каждую позицию вручную, задача не решена.

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

Какие форматы загрузки заказать и когда их выбирать

Формат загрузки — это компромисс между удобством клиента и предсказуемостью обработки. Чем свободнее формат, тем больше вариантов ввода придётся разбирать и тем выше шанс ошибки. Ниже — сравнение основных способов, которое помогает выбрать, что делать в первую очередь.

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

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

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

Как устроено распознавание артикулов и единиц измерения

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

Артикул, код поставщика и внутренний код

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

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

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

Единицы измерения и кратность упаковки

Оптовая торговля почти всегда работает с упаковками: коробка, паллета, комплект. Клиент пишет «2», имея в виду две коробки, а магазин хранит остаток в штуках. Если не развести эти понятия, заказ уедет в неверном количестве.

Что нужно определить:

• в каких единицах клиент указывает количество;
• как единица из файла соотносится с единицей хранения;
• что показывать, если единица в строке не указана;
• как пересчитывать цену — за штуку или за упаковку.

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

Цена под клиента

Цена в B2B-заказе зависит от клиента, а не только от товара. В каталоге может быть несколько типов цен, и доступ к каждому типу настраивается по группам пользователей — так устроено в популярных CMS, где типы цен и права на них задаются в настройках торгового каталога. Это значит, что при распознавании строки нужно сразу подставлять ту цену, на которую у клиента есть право, а не показывать ему все колонки.

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

Ошибки строк: как их находить и что делать с заменами

Ошибки в списке — норма, а не исключение. Задача магазина — не предотвратить их полностью, а сделать так, чтобы клиент быстро понял, что не так, и исправил.

Основные типы ошибок

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

Для каждого типа ошибки нужен свой текст. Формулировка «ошибка в строке 14» бесполезна: клиенту нужно понимать суть проблемы и действие. Хорошее сообщение указывает строку, показывает исходные данные и предлагает решение.

Полезно разделить ошибки на те, что клиент может исправить сам, и те, что требуют участия магазина. Опечатку в коде клиент поправит за секунду. А вот недоступность товара или неоднозначное совпадение — повод для уточнения с менеджером. Если смешать всё в один список «ошибок», клиент не поймёт, где он может действовать сам.

Замены и аналоги

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

Разумный порядок действий:

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

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

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

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

Входные условия. Клиент «Условная компания» заказывает крепёж. У него два юрлица, действует свой тип цен. Снабженец выгружает файл с колонками: код, количество, единица. В файле 40 строк. Часть кодов — старые артикулы или коды поставщика. В трёх строках количество указано в коробках, в остальных — в штуках, но колонка единиц заполнена не везде.

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

Наблюдаемый результат. Из 40 строк распознаны 33. Пять не найдены: три кода устарели, два содержат опечатку. Две строки требуют уточнения единицы измерения (колонка пуста, товар продаётся упаковками). Клиент видит проблемные строки, исправляет опечатки, выбирает единицу из подсказки, устаревшие коды заменяет или убирает. Корзина собирается из 38 подтверждённых позиций, заказ уходит в оформление.

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

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

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

Как проверить результат и принять работу

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

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

Если по какому-то пункту результат неоднозначен, это повод не «принять с замечаниями», а вернуться к формулировке требований. Массовый заказ — сценарий, где мелочь в обработке строк превращается в систематическую ошибку в заказах.

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

Типичные ошибки и ограничения

Ошибки в таких проектах повторяются. Стоит проверить, не заложены ли они в вашем сценарии.

• Поиск только по одному полю. Если система ищет лишь по внутреннему коду, клиентские артикулы и коды поставщика не распознаются.
• Молчаливая подстановка при неоднозначности. Когда коду соответствует несколько товаров, выбор наугад приводит к неверным заказам.
• Игнорирование единиц измерения. Количество в коробках и в штуках смешивается, и заказ уезжает не в том объёме.
• Единая цена для всех. Если цена не привязана к правам клиента, оптовик видит не свои условия.
• Отказ всего заказа из-за одной строки. Клиент с большим списком не должен переделывать всё из-за одной опечатки.
• Неинформативные сообщения об ошибках. Без номера строки и исходных данных клиент не понимает, что исправлять.
• Отсутствие истории изменений. Если замены и правки не фиксируются, менеджер не может разобрать спорный заказ.

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

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

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

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

Чтобы оценить объём работ, разработчику нужны не пожелания, а конкретика. Соберите следующее.

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

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

Следующий шаг

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

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