Статусы заказа семян, СЗР и техники: от заявки до документов
Сайты и порталы · практическая схема B2B-заказа, сентябрь 2026 года
Заявка на семена или запчасти принята. Через день покупатель получает счёт, затем уточняет срок, потом выясняет, что часть товара уже приехала, а часть ждёт поставки. У менеджера при этом одно слово — «заказ». Для закупщика оно слишком грубое: ему нужно понимать, какой состав согласован, за какую часть получена оплата, что зарезервировано, что отгружено и какие документы закрыты.
Ранее мы разобрали, почему промышленная B2B-покупка редко укладывается в кнопку «Купить». Теперь посмотрим на следующий отрезок: от заявки до исполнения. Это проектная карта процесса, составленная по открытым правилам платёжных сервисов и учётной логике заказа. Реальных заказов агропоставщика и временных меток у нас нет. Поэтому здесь нет заявлений, что автоматизация сократила срок или ошибки на какой-либо процент.
Показать данные текстом
| Контур | Вопрос покупателя | Подтверждающее событие |
|---|---|---|
| Согласование | Что именно и по какой версии условий мы покупаем? | Датированное согласие по артикулам, количеству, цене, сроку и замене. |
| Деньги | Какая сумма поступила и к какому обязательству её отнесли? | Банковское зачисление и отдельная запись распределения платежа по счёту или партиям. |
| Резерв | Сколько единиц удерживается, где и до какой даты? | Запись склада по строке и партии с количеством и сроком резерва. |
| Исполнение | Что собрано, передано перевозчику и принято? | Отдельные даты комплектации, отгрузки, доставки и приёмки каждой партии. |
| Документы | По какой отгрузке документы отправлены и урегулированы? | Документ привязан к партии; отправка, получение, подпись или разногласие различаются. |
Показать картинку
Схема и данные к статье
Один заказ, две партии и несколько разных «готово»
Возьмём условный пример. Хозяйство запрашивает 100 мешков семян. После уточнения партии и условий поставщик подтверждает 60 мешков со склада сейчас и 40 через две недели. Суммы, даты и правила оплаты здесь намеренно не назначены: они определяются договором конкретной сделки.
В этой ситуации слово «заказ оплачен» не отвечает сразу на четыре вопроса. Оплачен ли весь согласованный объём или только первая партия? Сопоставила ли бухгалтерия поступление с нужным счётом? Действует ли резерв на 60 мешков? Отгружены ли они, а документы по ним получены? Если статусы этих событий хранить одной строкой, частичная поставка почти неизбежно будет выглядеть либо завершённой раньше времени, либо зависшей без объяснения.
Заказу нужен постоянный номер, а каждому изменению состава — своя версия. Строка товара связывает артикул, количество и цену; партия поставки связывает свою дату, резерв, отгрузку и документы. Счёт и платёж имеют собственные номера и явные связи с версией заказа. Когда покупатель согласует замену семян или меняет объём, старые условия остаются в истории, а действующей становится новая версия.
Пять статусов, которые нельзя слить в один
Покупатель может видеть эти сведения в кабинете, письме или документе. Сам носитель не принципиален; важно, чтобы статус был проверяемым и относился к нужной версии заказа. Для менеджера та же модель показывает исключения: изменённый артикул, истёкший резерв, недоплату, спор по приёмке. Без связи событий вопрос покупателя превращается в ручной поиск по переписке, банку, складу и ЭДО.
Оплата пришла — можно ли отгружать?
Быстрый платёж сам по себе не является разрешением складу. Сначала надо установить, что деньги зачислены; затем сопоставить их с плательщиком, счётом и действующей версией заказа; после этого проверить условия конкретной партии — сумму предоплаты или одобренную отсрочку, резерв, совместимость и согласованный срок. Один платёж может покрывать несколько счетов, а несколько платежей — один счёт. Совпадение суммы или текст в назначении не заменяют учётную запись распределения.
как отдельный сценарий для юридических лиц и ИП. В её рекомендациях одноразовая ссылка может относиться к конкретному счёту или заказу, а уровень связи с сайтом и учётной системой зависит от банковского продукта и интеграции. Платёж по ссылке и розничный QR для физического лица не стоит смешивать с корпоративным расчётом. Доступность нужного способа и сообщений о статусе надо проверять у банков обеих сторон на конкретном сценарии. Публичная страница платёжного сервиса не доказывает, что платёж автоматически разнесётся в ERP поставщика.
И даже успешное распределение денег не даёт права обещать дату, если резерв уже истёк. В условном заказе на 100 мешков первая партия может быть полностью оплачена, а для второй ещё не наступило условие оплаты. Так и следует показывать: «60 мешков: платёж распределён, резерв до даты, готовится к отгрузке; 40 мешков: согласованная поставка позже, ожидается условие оплаты или поступление». Вариант отсрочки требует отдельного одобрения лимита и даты денежного требования; он не должен выглядеть как «неоплаченный, значит ошибочный» заказ.
Что происходит при изменении условий
В агрозакупке нередко меняются объём, партия семян, упаковка препарата, код детали или склад. Система должна сохранять исходное предложение и ответ на вопрос кто, когда и что согласовал. Для замены детали нужен результат проверки применяемости; для СЗР — проверка точного препарата и актуальных документов; для семян — согласование партии и требуемых свойств. Эти решения нельзя вывести из технического факта, что в системе появился новый SKU.
Если поставщик нашёл только 60 из 100 мешков, корректный статус — «частично зарезервировано» с количеством и следующим действием, а не просто «в работе». Если после оплаты резерв пропал, нужно новое обещание по сроку или пересогласование; банк не решает за продавца вопрос наличия. Если покупатель вернул часть партии, отгрузка в истории остаётся состоявшейся, а рядом появляются приём возврата, корректировка документов и отдельный статус возврата или зачёта денег.
С документами та же логика. , но применяемый набор документов и момент их юридического закрытия зависят от сделки и выбранного процесса. «УПД создан», «направлен» и «разногласие урегулировано» — разные события. Статус «отгружено» не означает, что покупатель принял товар или что расчёты завершены.
С чего начать проверку у себя
Не обязательно начинать с нового кабинета. Сначала можно разобрать 20 обезличенных завершённых и незавершённых заказов из одного товарного направления и ответить на шесть вопросов:
- Можно ли связать заявку, действующую версию предложения, счёт, платёж и каждую отгрузку по устойчивым идентификаторам?
- Сохраняются ли прежние версии при замене артикула, количества, цены или даты?
- Видно ли, когда деньги зачислены и когда они распределены по нужному счёту?
- Есть ли по каждой партии подтверждённый резерв с количеством и сроком действия?
- Разделены ли факты передачи перевозчику, доставки, приёмки и закрытия документов?
- Какой из этих статусов доступен покупателю без звонка менеджеру?
Если история есть, из неё можно измерять время согласования заявки, задержку распределения платежа, долю партий с резервом к контрольному моменту, отгрузку к обещанному сроку и время закрытия документов. Без журналов событий и исходных сроков эти показатели считать нельзя. Особенно опасно брать только последний статус: он скрывает ожидания, исправления и частичные поставки.
Рабочий результат первого этапа — таблица событий для одного заказа и трёх вариантов условий: предоплата, оплата по этапам, отсрочка. Для каждого события назначают владельца, первичное подтверждение и видимый покупателю статус. Каждый показатель получает определение и источник данных. Затем проверяют несколько реальных заказов вручную и только после этого решают, что автоматизировать.
Граница этой схемы
Здесь нет замера скорости банков, выгоды СБП, сокращения ручной работы или успешного внедрения у агропоставщика. Последовательность резерва, счёта и допуска к отгрузке задают договор и внутренние правила компании. Текущие тарифы и возможность конкретного B2B-платежа нужно проверять по банку и способу расчёта; нельзя автоматически считать комиссией конечного клиента.
Но карта позволяет сформулировать требование к процессу без общих слов. Покупателю нужна актуальная версия заказа и статус каждой партии. Поставщику — надёжная связь между заказом, деньгами, складом и документами. Когда эта связь есть, автоматизация может ускорить рутинные проверки; насколько именно — покажет только журнал реальных заказов до и после изменения.
Данные и источники
Основа схемы — приложенный исходный пакет Карта_B2B_агрозаказа_полный_отчет_2026-09-25.zip; методическая карта включена в этот комплект: состояния, события, три сценария допуска к отгрузке, определения показателей и состав обезличенной выгрузки. Внешние первичные источники: , , . Дополнительная методическая работа — AXENIX, «Ai-driven подход к созданию дата-продуктов» (файл исследования предоставлен редакции); измерений агросектора она не содержит.
10 мин
12 августа 2026 
