Обмен заказами с 1С: статусы, оплаты и доставка

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

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

Что должно передаваться

Схема обмена заказами

Статусы и их соответствие

Статусы на сайте и в 1С почти никогда не совпадают один к одному. Нужна таблица соответствия: какой статус сайта соответствует какому статусу учётной системы и что видит покупатель.

• Составьте таблицу статусов до разработки.
• Определите, кто меняет статус: сайт, 1С или менеджер.
• Не показывайте покупателю внутренние статусы вроде «ожидает проводки».
• Настройте уведомления на ключевые переходы.
• Обработайте отмены и возвраты отдельно.

Если статус меняется в двух местах, рано или поздно появится расхождение. Выберите источник истины и запретите ручные правки в обход правила.

Оплаты

Платёж — отдельный поток. Сайт может получить подтверждение от платёжной системы раньше, чем 1С, или наоборот. Важно не считать заказ оплаченным только по факту возврата пользователя на сайт.

• Используйте серверное подтверждение платежа, а не только редирект.
• Передавайте идентификатор транзакции и сумму.
• Обрабатывайте повторные уведомления без дублей.
• Сверяйте статусы оплат с платёжной системой.
• Настройте алерты на зависшие платежи.

Доставка

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

• Кэшируйте тарифы и пункты выдачи, но обновляйте их по расписанию.
• Показывайте понятную ошибку, если сервис недоступен.
• Передавайте трек-номер и статус в заказ.
• Не блокируйте checkout из-за недоступности одного перевозчика.

Идемпотентность и повторные попытки

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

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

Мониторинг

• Количество заказов, ожидающих отправки.
• Время обработки и задержка.
• Число ошибок и повторных попыток.
• Заказы без статуса или с зависшим платежом.
• Расхождения между сайтом и 1С.
• Алерты на простой обмена и рост очереди.

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

Тестовый контур

Перед запуском проверьте на копии: новый заказ, оплату, отмену, возврат, повторную отправку, недоступность 1С и восстановление. Только после этого включайте боевой обмен.

Типичные ошибки

• Отправлять заказ синхронно в момент оформления.
• Не хранить идентификаторы и создавать дубли.
• Считать заказ оплаченным по редиректу.
• Игнорировать отмены и возвраты.
• Не мониторить очередь и ошибки.

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

Возвраты и отмены

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

• Отмена до оплаты и после оплаты — разные процессы.
• Возврат денег должен быть связан с платежом.
• Товар возвращается на склад отдельной операцией.
• Пользователь должен видеть понятный статус.
• Все действия фиксируются в журнале.

Сверка данных

Даже при хорошей интеграции нужна регулярная сверка. Она помогает найти расхождения до того, как их заметит клиент.

• Количество заказов на сайте и в 1С.
• Суммы и статусы оплат.
• Статусы доставки и трек-номера.
• Заказы без движения и зависшие платежи.
• Расхождения по возвратам.

Роли и ответственность

У обмена должны быть владельцы с обеих сторон. Если за заказы отвечает только сайт, а 1С «так работает», проблемы решаются медленно.

• Кто отвечает за заказы на сайте.
• Кто отвечает за проведение в 1С.
• Кто разбирает ошибки обмена.
• Кто принимает решение об откате.
• Где хранятся инструкции и контакты.

Что проверить перед запуском

Что делать при сбое 1С

1С может быть недоступна из-за обновления, сети или ошибки. Магазин в этот момент должен продолжать принимать заказы, а не показывать ошибку.

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

Документация

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

• Схема потоков и статусов.
• Форматы и идентификаторы.
• Правила повторных попыток.
• Контакты ответственных.
• Инструкция по ручному запуску.

Очередь и приоритеты

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

• Разделите критичные и фоновые операции.
• Ограничьте параллелизм, чтобы не перегрузить 1С.
• Настройте приоритет для оплаченных заказов.
• Следите за временем ожидания в очереди.

Как выбрать формат обмена

Формат зависит от возможностей 1С и требований к скорости. Для небольших объёмов хватает периодической выгрузки, для оплат и статусов нужен более оперативный канал.

• HTTP API — для быстрых точечных операций.
• Очередь — для надёжности и повторной обработки.
• Файлы — для простых сценариев и больших пакетов.
• Прямое подключение к базе — только при сильной поддержке.

Не все ошибки 1С означают, что интеграция плохая. Иногда проблема в данных: дубли клиентов, неверные статусы или отсутствующие товары. Поэтому в разборе участвуют и техническая команда, и операторы учётной системы.

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

Если в 1С заказ создаётся вручную или требует подтверждения менеджера, это должно быть отражено в статусах. Иначе сайт будет считать заказ принятым, а в учётной системе он ещё не существует.