Заказ в Битриксе: жизненный цикл от корзины до выгрузки в 1С

Заказ в Битриксе не появляется в 1С сам по себе, между кликом «Оформить заказ» и записью в бухгалтерской базе проходит несколько шагов: корзина превращается в объект заказа, у него меняются статусы, приходит оплата, подключается доставка, и только потом данные уезжают дальше по обмену. Я занимаюсь доработкой интернет-магазинов на 1С-Битрикс несколько лет, и большинство вопросов от клиентов сводится к одному: почему заказ повис между статусами или почему он не долетел до 1С. Разберу весь путь по шагам, от корзины до выгрузки, и покажу, где обычно ломается цепочка.

Как устроен заказ в Битрикс: от корзины до объекта в базе

Корзина в Битриксе это промежуточное состояние, а не заказ: товары лежат в таблице b_sale_basket, привязаны к пользователю или сессии, и живут отдельно от любого заказа, пока покупатель не нажмёт кнопку оформления. В момент оформления система создаёт объект заказа, в актуальном API это \Bitrix\Sale\Order из модуля sale (D7), а данные ложатся в таблицу b_sale_order. Вместе с заказом создаются связанные сущности: позиции корзины копируются в таблицу с привязкой к ORDER_ID, платежи попадают в b_sale_payment, отгрузки в b_sale_shipment, а адрес и контакты покупателя сохраняются как свойства заказа.

На старых магазинах, которые обновлялись годами, часто встречается смесь: часть кастомных обработчиков написана под старый API модуля sale, часть уже переведена на объектную модель \Bitrix\Sale\Order. Перед тем как трогать логику заказа на конкретном проекте, я всегда смотрю, каким API написаны существующие обработчики, иначе новый код может задублировать то, что уже делает старый, и заказ начнёт менять статус дважды за одно событие.

Статусы заказа и переходы между ними

Статусы заказа настраиваются в админке, в разделе «Магазин» -> «Настройки» -> «Статусы заказов». У каждого статуса свой код, сортировка и список групп пользователей, которым можно переводить заказ именно в этот статус, это защищает от ситуации, когда менеджер по ошибке переводит оплаченный заказ обратно в «новый». По умолчанию в комплекте статусы вроде «Принимается», «Оплачен», «Передан в службу доставки», «Выполнен» и «Отменён», но в реальных проектах я почти всегда добавляю свои: «Ждёт подтверждения по телефону», «Собран на складе», «Возврат» - под конкретный процесс обработки заказов у клиента.

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

AddEventHandler('sale', 'OnSaleStatusOrderChange', ['OrderEvents', 'onStatusChange']);

class OrderEvents
{
    public static function onStatusChange($orderId, $value)
    {
        $order = \Bitrix\Sale\Order::load($orderId);
        if ($order && $value === 'F') {
            $order->setField('REASON_MARKED', '');
            $order->save();
        }
    }
}

Обработчик регистрируется в init.php модуля или через install-скрипт компонента, если логика должна пережить обновление шаблона.

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

Компонент оформления заказа на финальном шаге запускает создание заказа: копирует состав корзины, применяет скидки и промокоды, привязывает выбранные способ оплаты и доставки, сохраняет объект через save(). Именно на этом шаге стоит вешать проверку остатков и любую валидацию, которая должна остановить оформление, а не подчищать заказ постфактум.

Для точечных проверок обычно используют событие OnSaleOrderBeforeSaved у объекта заказа: там уже видно состав корзины и свойства, но заказ ещё не записан в базу, и можно вернуть ошибку прямо в чекаут. Программно менять готовый заказ, например донасчитать бонусы после оплаты, удобнее через тот же \Bitrix\Sale\Order::load(), это стабильно работает и в консольных скриптах, и в cron-обработчиках, и внутри REST-обработчиков.

Оплата и доставка: как статус заказа меняется через Т‑Банк и СДЭК

Оплата заказа почти всегда меняет его статус автоматически, а не руками менеджера. При подключении эквайринга Т‑Банк оплата подтверждается через notification-запрос на сторону сайта: банк присылает уведомление об успешном платеже, обработчик находит заказ по номеру, проверяет подпись запроса и переводит заказ в статус «Оплачен» тем же методом setField(‘STATUS_ID’, ‘P’) с последующим save(). Похожая механика у большинства платёжных систем, разница в основном в формате уведомления и способе проверки подлинности запроса.

С доставкой логика симметричная, но завязана на статус отгрузки, а не заказа целиком: у СДЭК есть встроенный расчёт доставки по зонам через калькулятор, который сразу отдаёт стоимость и сроки в чекауте, а трек-номер и смена статуса «в пути» или «доставлен» обычно приходят по вебхуку от службы доставки и точно так же дописываются в заказ программно. На проектах, где нужна нестандартная логика вроде частичной оплаты или комбинированной доставки в несколько городов, проще заказать точечную доработку и поддержку 1С-Битрикс, чем адаптировать типовой обработчик руками без опыта работы с объектной моделью заказа.

Выгрузка заказов в 1С: как работает обмен по CommerceML

Модуль «1С-Битрикс: Управление сайтом» изначально поставляется с обменом данными с 1С по стандарту CommerceML, настройки лежат в «Магазин» -> «Настройки» -> «Обмен данными с 1С». По каталогу это односторонний поток из 1С на сайт: 1С формирует import.xml и offers.xml с товарами, ценами и остатками, а сайт их принимает. По заказам обмен двусторонний: 1С обращается на сайт по HTTP с логином и паролем пользователя для обмена, забирает orders.xml с новыми и изменёнными заказами, обрабатывает их у себя в базе, а затем отправляет обратно присвоенные номера и, при необходимости, обновлённые статусы.

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

Запускать обмен можно вручную кнопкой в мастере или в автоматическом режиме через агент, задачу по расписанию, которая сама обращается к 1С или ждёт входящего запроса, в зависимости от схемы обмена. На магазинах с суточным объёмом в сотни заказов интервал в 15-20 минут обычно достаточен, слишком частый запуск на обычном хостинге с ограничением по числу процессов PHP может накладываться сам на себя и создавать дубли в очереди обмена.

Частые проблемы при синхронизации заказов с 1С

Дубли заказов. Чаще всего это следствие пересечения нумерации: если у клиента несколько сайтов на одной базе 1С или заказ создаётся и через сайт, и через ручной ввод в 1С, номера могут пересекаться, и обмен принимает один и тот же заказ за новый. Лечится префиксом номера заказа на стороне Битрикса и явной привязкой к внешнему коду заказа при обмене.

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

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

Нужна скорость быстрее, чем интервал обмена. Штатный обмен с 1С работает пачками по расписанию, и для оперативных уведомлений, например менеджеру сразу после оплаты, быстрее и дешевле повесить отдельный обработчик на событие смены статуса, чем ждать выгрузки в 1С. Для несложных сценариев такого рода я обычно собираю цепочку в n8n: вебхук с сайта прилетает в сценарий, а дальше он сам решает, кому и куда отправить сообщение, без правки кода на каждый чих.

1С-Битрикс и 1С регулярно обновляются, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Можно ли добавить свои статусы заказа в Битриксе, кроме стандартных?

Да, статусы заказов настраиваются в админке в разделе «Магазин» -> «Настройки» -> «Статусы заказов», там же задаются права на переход между ними для разных групп пользователей. Единственное, что нужно не забыть, это прописать соответствие нового статуса в таблице обмена на стороне 1С, иначе заказы в этом статусе будут выгружаться, но 1С не будет понимать, что с ними делать.

Как часто заказы синхронизируются с 1С?

Это не фиксированное платформой значение, а настройка обмена: запуск можно делать вручную из мастера обмена или по расписанию через агент. На проектах с несколькими сотнями заказов в сутки я обычно ставлю интервал 15-20 минут, для небольших магазинов хватает и часа.

Почему заказ выгрузился в 1С два раза?

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

Нужен ли отдельный сервер для обмена Битрикса с 1С?

Нет, обмен работает на обычном хостинге, где размещён сайт: 1С обращается к тому же адресу по HTTP, никакой отдельный VPS для этого не нужен. Отдельный сервер имеет смысл обсуждать, только если у самой 1С своя серверная инфраструктура, но это уже вопрос конфигурации бухгалтерской системы, а не сайта на Битриксе.