Почему исправление обмена начинается с правил
Покупатель видит на сайте двенадцать упаковок, оформляет заказ и получает звонок: доступно только семь. Менеджер объясняет расхождение задержкой синхронизации. Разработчик сокращает интервал обновления, но ситуация повторяется: часть товара зарезервировал другой отдел, а сайт получил физический остаток без вычета резервов.
Интеграция — это согласованное изменение данных и состояний в нескольких системах. Передача файла с товарами решает только часть задачи. Нужно определить, какое значение сайт показывает, какая система имеет право его изменить и когда обещание покупателю считается подтверждённым.
При этом 1С — название семейства решений, а не описание единственного способа обмена. В проекте важны конкретная конфигурация, её доработки, правила учёта и используемый сайт. Сначала составляют карту процесса, затем выбирают механизм подключения.
Разделите остаток, доступность и резерв
Физический остаток показывает, сколько товара находится на складе. Доступность для продажи определяется правилами компании: из остатка могут исключаться выделенные заказы, карантин и другие ограничения. Резерв связывает определённое количество с конкретным заказом на согласованных условиях.
Не складывайте ограничения автоматически. Если карантин уже исключён из передаваемого остатка, повторный вычет занизит доступность. Для каждого показателя зафиксируйте состав и единицу измерения.
Условный поставщик продаёт фильтры упаковками по десять штук. В системе учёта хранится 120 штук, 30 выделено подтверждённым заказам, 20 находится в отдельном недоступном запасе. Если все ограничения независимы, свободно 120 − 30 − 20 = 70 штук, или семь полных упаковок. Сайт, показывающий двенадцать упаковок, передаёт физический запас вместо доступного.
Для первой версии полезно согласовать карточку показателя:
- Название: доступно для заказа через сайт.
- Источник: определённый регистр или подготовленный показатель учётной системы.
- Разрез: товар, характеристика, склад, единица продажи.
- Ограничения: какие категории исключены и на каком этапе.
- Обновление: событие либо расписание с согласованным допустимым возрастом.
- Поведение при задержке: показывать необходимость подтверждения вместо неподтверждённого обещания.
Назначьте владельца каждому изменению
Цена каталога, персональная скидка, количество в корзине и резерв могут принадлежать разным процессам. Для каждого поля нужен один понятный источник решения. Иначе сайт и учётная система начнут исправлять друг друга.
Например, базовая цена приходит из учёта, договорная цена рассчитывается по условиям покупателя, а контакт получателя заполняется на сайте. Смена телефона не должна перезаписывать коммерческие условия. Ответ обмена должен различать принятую информацию и отклонённое изменение.
Отдельно согласуйте момент фиксации цены. Это может быть подтверждение заказа уполномоченным сотрудником либо другой утверждённый этап. Статья не задаёт коммерческие правила за компанию: задача разработки — явно реализовать выбранное правило и показать покупателю его результат.
Старый заказ нельзя пересчитывать незаметно после обновления прайс-листа. Сохраните исходные условия и отдельное предложение изменений. Разбор общей устойчивости обмена дополняет статья о надёжных интеграциях.
Проверьте гонку за последний товар
Продолжим условный пример. На выбранном складе осталось пять насосов. Два покупателя почти одновременно отправляют заказы по четыре насоса. Оба видели корректный снимок каталога, но удовлетворить оба заказа невозможно.
Проверка доступности и фиксация резерва должны выполняться как единая защищённая операция: другой заказ не может занять то же количество между этими действиями. После первого подтверждения остаётся одна единица. Второй заказ получает отказ на четыре единицы либо предложение допустимого частичного исполнения.
Ключевой вопрос: кто принимает окончательное решение? Если сайт сам уменьшает локальный остаток, а офис параллельно резервирует товар в учёте, единого контроля нет. Отдельный механизм распределения возможен, но его границы нужно проектировать сознательно.
Покупателю не следует показывать «товар зарезервирован», пока подтверждение не получено. Промежуточное состояние может называться «заказ получен, проверяем наличие». Формулировка должна соответствовать реальному процессу, а не скрывать его неопределённость.
Сделайте повторную отправку безопасной
Ответ может потеряться после успешного создания резерва. Сайт видит задержку и отправляет запрос повторно. Без защиты возникает второй резерв для того же заказа.
Для операции создают устойчивый идентификатор. Повтор с тем же идентификатором должен возвращать прежний результат либо позволять проверить состояние исходной операции. Это правило называют идемпотентностью: повторение обращения не умножает бизнес-результат.
В техническом задании опишите три разных случая:
- запрос не был принят и его можно повторить;
- запрос принят, но результат пока неизвестен;
- операция завершена, а ответ не дошёл до отправителя.
Во втором случае нельзя сразу создавать новый резерв с новым номером. Сначала нужна проверка исходного. Аналогичное правило требуется для отмены: повторное снятие резерва не должно дополнительно увеличивать свободный остаток.
Как обрабатывать отмены и просроченные резервы
Резерву необходим жизненный цикл: запрошен, подтверждён, частично исполнен, снят либо завершён отгрузкой. Эти состояния не обязательно показывать покупателю дословно, но их должен понимать оператор.
Условная компания держит резерв до установленного менеджером срока. По завершении срока система проверяет условия снятия. Если отгрузка уже началась, автоматическая отмена может быть недопустима по внутреннему процессу. Такой заказ направляется ответственному.
Отмена на сайте означает сначала запрос отмены. Только после подтверждения учёта можно сообщать, что товар освобождён. Если часть заказа отгружена, отменяется оставшаяся часть, а история исполнения сохраняется.
Что включить в первую версию
Начните с одной категории товаров, одного склада и понятного типа покупателей. Проверьте полный цикл: обновление каталога, оформление, подтверждение, изменение количества и отмена. Рабочий путь важнее большого количества подключённых справочников.
Минимальный операционный экран должен помогать разбирать исключения. Сотруднику нужны номер заказа, время последнего обмена, источник ошибки, последняя подтверждённая версия и допустимое следующее действие. Сообщение «ошибка сервера» не объясняет, можно ли повторять резерв.
До запуска подготовьте заполненный сценарий проверки: заказ на четыре единицы при остатке пять, второй такой же заказ, потеря ответа первого запроса, повторная отправка, затем отмена одной единицы. Ожидаемый итог после подтверждённой отмены: первый резерв три, свободно две, второй полный заказ по-прежнему не подтверждён.
Готовый модуль или собственная разработка
Готовый обмен стоит проверять первым, если он поддерживает вашу конфигурацию, номенклатуру и правила заказов. Попросите показать не только загрузку каталога, но и конкурирующие резервы, персональные цены, повтор после сбоя и отмену.
Собственная разработка обоснована, когда существующий механизм не выражает существенные правила: распределение между складами, сложные единицы продажи, последовательность согласований или особые условия покупателей. Иногда достаточно ограниченной доработки вокруг стандартного обмена.
Перед выбором зафиксируйте критерии приёмки:
- цена показывается с правильными условиями покупателя;
- недоступный запас не обещается повторно;
- повтор запроса не создаёт второй заказ;
- отмена освобождает только подтверждённое количество;
- задержка обмена видна ответственному;
- расхождение можно восстановить по истории операций.
С чего начать обсуждение с ExtentLab
Подготовьте один реальный, обезличенный заказ, описание конфигурации 1С и три примера расхождений. Для каждого укажите, что видел покупатель, что было в учёте и какое решение принял менеджер.
С ExtentLab можно обсудить правила обмена и объём необходимой доработки. Результатом такого обсуждения должен стать конкретный сценарий проверки, позволяющий оценить готовый модуль и заказную реализацию по одинаковым требованиям.