Последний насос положили в корзину два покупателя. Сайт обоим сообщил, что товар есть на складе. Через несколько минут менеджер звонит одному из них и предлагает ждать поставку. Остаток на странице был правильным в момент загрузки, но к оформлению заказа ситуация изменилась.
Обмен остатками становится надёжнее, когда команда различает физическое наличие, доступное количество и резерв. Эти значения связаны, однако каждое отвечает на свой вопрос. Для продажи последней единицы нужна проверка в момент, когда компания принимает обязательство перед покупателем.
Разберём пять правил на учебном примере интернет-магазина оборудования. У него один склад, сайт и менеджеры, которые принимают заказы по телефону. Все количества и сроки в примере условные. По ним удобно обсудить требования с разработчиком и проверить поведение готовой системы.
1. Назовите величину, которую сайт показывает покупателю
На складе лежит десять насосов. Три уже обещаны клиентам, один отложен для проверки качества. Если в каталог выгрузить физическое количество, посетитель увидит десять доступных единиц. Для оформления новых заказов пригодны только шесть.
Сначала согласуйте словарь. Физическое наличие описывает то, что хранится на складе по данным учёта. Резерв закрепляет часть количества за заказом или другой операцией. Доступный остаток рассчитывается по правилам компании и показывает, сколько можно предложить новому покупателю.
Правила расчёта зависят от бизнеса. Например, магазин может хранить страховой запас для гарантийных замен. Тогда эти товары существуют физически, но сайт их не продаёт. Решение принимает владелец процесса, а разработчик отражает его в обмене.
На странице необязательно показывать точное число. Для части каталогов достаточно «Есть на складе» и возможности запросить крупную партию. Однако внутренний расчёт доступного количества всё равно нужен. Иначе покупатель закажет двадцать единиц, хотя система подтверждает только шесть.
Проверьте, что сайт получает нужный вид остатка для нужного склада. Ошибка возникает и при корректной цифре: десять насосов лежат в другом регионе, откуда компания сейчас не доставляет. Для многоскладской схемы дополнительно задают правила выбора склада, перемещения и расчёта срока.
Описание данных стоит включить в план интеграции 1С и сайта. Запись «передавать остатки» слишком общая. В ней должны появиться конкретные поля, источники и исключения, понятные складу и отделу продаж.
2. Выберите момент постановки в резерв
Добавление в корзину ещё не обязательно означает резервирование. Человек может закрыть вкладку и забыть о покупке. Если сайт удерживает товар бесконечно, реальные покупатели получат сообщение об отсутствии при полном складе.
Компания может резервировать товар после оформления заказа, после подтверждения менеджером или при начале оплаты. Каждый вариант меняет пользовательский сценарий. Выберите правило и объясните его на сайте там, где посетитель принимает решение.
В учебной схеме магазин удерживает последнюю единицу после отправки формы заказа. У резерва есть срок действия, который согласует бизнес. Если оплата или подтверждение не пришли вовремя, система освобождает товар по установленному порядку. Длительность зависит от способа оплаты и работы команды.
Покупателю нужна понятная обратная связь. Например, после оформления он видит, что заказ принят на проверку, а наличие будет подтверждено менеджером. Если система уже закрепила товар, текст может сообщить о резерве и сроке следующего действия. Обещание в интерфейсе должно соответствовать реальной операции.
Для телефонных заказов требуется тот же источник доступности. Менеджер, который продал последний насос в обход общей системы резервов, создаст конфликт даже при исправной интеграции сайта. Поэтому правила охватывают все каналы продажи, включая ручные операции.
До разработки восстановите путь нескольких прошлых заказов. Посмотрите, когда сотрудник фактически переставал предлагать товар другим клиентам. Этот момент часто лучше описывает действующий процесс, чем формальная инструкция. Расхождения нужно обсудить и устранить до автоматизации.
3. Проверяйте последнюю единицу при подтверждении
Обновление каталога раз в несколько минут не защищает от двух одновременных заказов. Оба посетителя могут открыть страницу до следующего обмена. Поэтому в момент резервирования система должна ещё раз проверить доступность и закрепить количество как одну согласованную операцию.
Технический способ зависит от используемой базы и учётной системы. Для заказчика полезно сформулировать проверяемое условие: два параллельных запроса на последнюю единицу приводят к одному подтверждённому резерву. Второй запрос получает понятный ответ о недоступности или иной согласованный вариант.
Идентификатор запроса нужен для повторов. Если соединение оборвалось после создания резерва, сайт может не получить ответ и отправить ту же просьбу ещё раз. Обработчик должен распознать повтор и вернуть результат существующей операции. Иначе один заказ удержит товар дважды.
Простое отключение кнопки после нажатия не решает эту задачу целиком. Пользователь способен открыть вторую вкладку, а сетевой сбой возникает независимо от интерфейса. Проверка выполняется там, где система изменяет доступное количество.
У такого подхода есть практическое следствие для текста ошибки. Сообщение «Что-то пошло не так» скрывает разницу между отсутствием товара и неизвестным результатом запроса. При неизвестном результате сначала нужно выяснить судьбу операции. Предложение немедленно оформить новый заказ может создать ещё один резерв.
Поведение повторных сообщений обсуждается в материале о передаче событий через вебхуки. Вебхук означает уведомление, которое одна программа отправляет другой при событии. Для резервов важна та же дисциплина: повторное сообщение должно сохранять смысл исходной операции.
В Feature IT можно заказать автоматизацию обмена заказами и остатками. Начать обсуждение удобно с двух спорных заказов на один товар и журналов их появления. По времени записей видно, где система перестала согласовывать действия разных каналов.
4. Определите судьбу резерва после отмены
Создать резерв недостаточно. Его нужно уменьшить при изменении количества, освободить при отмене и корректно закрыть после отгрузки. Каждое действие должно быть связано с конкретным заказом и его текущей версией.
В учебном заказе покупатель сначала выбрал три насоса, затем оставил два. Система освобождает одну единицу после подтверждённого изменения. Если старое сообщение о количестве три придёт позже нового сообщения о количестве два, обработчик должен понять порядок изменений. Иначе освобождённый насос снова окажется занят.
Для этого участники обмена согласуют версию заказа или другую проверяемую последовательность событий. Время отправки само по себе может быть недостаточным: часы разных систем расходятся, а сообщения задерживаются. Конкретный механизм выбирает разработчик с учётом возможностей источника данных.
Отмена оплаты и отмена заказа тоже могут быть разными событиями. Неудачная попытка платежа не всегда означает отказ клиента: человек может выбрать другую карту. Если освобождать резерв после каждой ошибки оплаты, товар уйдёт другому покупателю во время повторной попытки.
Опишите таблицу переходов. Для каждого события укажите действие с резервом и допустимое состояние заказа. Например, запрос отмены от клиента требует подтверждения менеджером, если товар уже передали на сборку. Автоматическое освобождение в такой ситуации должно учитывать складскую операцию.
Отдельная проверка нужна для частичной отгрузки. После выдачи двух единиц из трёх система должна правильно учесть оставшуюся. Двойное уменьшение физического наличия и резерва способно создать отрицательные или завышенные значения. Сверяйте результат с правилами вашей учётной системы.
5. Заведите сверку и очередь спорных операций
Даже при аккуратной передаче событий полезно периодически сравнивать данные систем. Сверка проверяет, какие активные резервы есть в учёте и какие заказы считает открытыми сайт. Она помогает найти пропущенную отмену или операцию, завершившуюся только на одной стороне.
Сравнивайте по устойчивому идентификатору заказа и позиции. Используйте постоянный код позиции. Название товара могут отредактировать; к тому же одинаковые названия встречаются у разных моделей. Если у систем разные идентификаторы, храните таблицу соответствий и проверяйте её заполнение.
Найденное расхождение должно попасть к ответственному сотруднику с понятным описанием. В записи нужны заказ, товар, ожидаемое количество и наблюдаемое значение. Полезно добавить последнее успешное событие, чтобы сотрудник начал проверку с конкретного места.
Автоматическое исправление всех расхождений рискованно, если система не знает причины. Например, ручной резерв менеджера может быть законным и ещё не связанным с заказом сайта. Сначала выделите типы расхождений, для которых правило исправления однозначно. Остальные отправляйте на разбор.
Для сбоя обмена установите понятное поведение каталога. Компания может временно принимать заявки без обещания наличия, ограничить продажу дефицитных товаров или остановить оформление. Выбор зависит от цены ошибки и возможностей команды. Сообщение посетителю должно соответствовать принятому решению.
Причины подобных задержек разобраны в статье о сбоях обмена сайта с 1С. В рабочем журнале полезно хранить время последнего подтверждённого обновления, чтобы менеджер видел, насколько свежими данными он располагает.
Как проверить схему до первой продажи
Подготовьте отдельный тестовый товар и согласуйте проведение проверки со складом. Лучше использовать безопасную тестовую среду, в которой операции не затронут реальных покупателей. Зафиксируйте исходное количество и очистите старые тестовые резервы по принятой процедуре.
Первый сценарий проверяет конкуренцию. Два пользователя почти одновременно оформляют последнюю единицу. Один заказ должен получить подтверждение, второй обрабатывается по согласованному правилу. После этого сравните записи сайта и учётной системы.
Во втором сценарии оборвите получение ответа после отправки запроса и повторите его. Разработчик может воспроизвести такую ситуацию в тестовой среде управляемым способом. Проверьте, что товар зарезервирован только один раз и у заказа сохранился один результат операции.
Третий сценарий посвящён отмене. Измените количество, затем отмените заказ и повторно отправьте уведомление об отмене. Доступный остаток должен вернуться к ожидаемому значению. Повторное уведомление не должно прибавить лишний товар.
Четвёртая проверка касается позднего сообщения. После уменьшения количества доставьте старую версию заказа. Посмотрите, сохранит ли система актуальное состояние. Зафиксируйте результат вместе с версиями сообщений: это полезный пример для проверки после будущих обновлений.
Наконец, остановите обмен на согласованное время и оформите заказ через второй канал. После восстановления передачи данных выполните сверку. Она должна обнаружить нужные изменения и показать спорные операции сотруднику. Одного зелёного статуса соединения для приёмки недостаточно.
Сохраните сценарии в рабочей инструкции. При добавлении нового склада или канала продаж их можно повторить с другими входными данными. Правила резервов остаются понятными, пока команда проверяет их на конкретных заказах.
Если последнюю единицу регулярно обещают двум клиентам, обсудите обмен остатками с Feature IT. Подготовьте описание момента резервирования, список каналов продажи и пример расхождения. Это даст основу для решения, которое учитывает работу сайта и склада.
Читайте также
