Кастомные статусы заказов WooCommerce: как добавить свои этапы и уведомления

Стандартные статусы WooCommerce закрывают базовый цикл заказа: ожидание оплаты, обработка, выполнение, отмена и возврат. Но реальный бизнес-процесс часто длиннее. Магазину могут понадобиться отдельные этапы «На сборке», «Проверка качества», «Готов к самовывозу», «Передан в доставку» или «Ждём документы».

Добавлять такие статусы нужно не как декоративные подписи в админке, а как часть архитектуры заказа. От них могут зависеть email-уведомления, списание остатков, CRM, склад, отчёты, webhooks и действия менеджеров. Поэтому сначала проектируют workflow, а уже затем пишут код.

Какие статусы уже есть в WooCommerce

WooCommerce документирует стандартные состояния заказа: Pending payment, Processing, On hold, Completed, Failed, Canceled и Refunded. Их смысл связан не только с интерфейсом, но и с внутренней логикой магазина. Например, Processing обычно означает, что оплата получена и заказ требует дальнейшего выполнения.

Официальное описание статусов: WooCommerce Managing Orders — Order Statuses.

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

Сначала нарисуйте цепочку обработки заказа

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

• кто переводит заказ в этот статус — сотрудник, платёжная система, склад или интеграция;
• какие действия должны выполняться при входе в статус;
• кому отправляется уведомление;
• какие переходы из этого состояния допустимы.

Например, цепочка может выглядеть так: Processing → На сборке → Проверка → Готов к отправке → Completed. Для самовывоза ветка будет другой: Processing → На сборке → Готов к самовывозу → Completed.

Такой подход предотвращает хаотичное появление десятков статусов, которые отличаются только формулировкой.

Как зарегистрировать кастомный статус

Для простого решения статус можно зарегистрировать через WordPress API register_post_status(), а затем добавить его в список WooCommerce фильтром wc_order_statuses. Префикс статуса должен соответствовать формату WooCommerce wc-....

add_action( 'init', function () {
    register_post_status( 'wc-picking', [
        'label'                     => 'На сборке',
        'public'                    => true,
        'exclude_from_search'       => false,
        'show_in_admin_all_list'    => true,
        'show_in_admin_status_list' => true,
        'label_count'               => _n_noop( 'На сборке <span class="count">(%s)</span>', 'На сборке <span class="count">(%s)</span>' ),
    ] );
} );

add_filter( 'wc_order_statuses', function ( $statuses ) {
    $result = [];
    foreach ( $statuses as $key => $label ) {
        $result[ $key ] = $label;
        if ( 'wc-processing' === $key ) {
            $result['wc-picking'] = 'На сборке';
        }
    }
    return $result;
} );

На production лучше вынести это в отдельный мини-плагин или проектный плагин, а не добавлять критичную логику в functions.php темы. Тогда смена темы не отключит бизнес-процесс.

Меняйте статус через WC_Order, а не SQL

Ключевое правило современных доработок WooCommerce — работать через CRUD API. Для смены состояния используйте объект заказа:

$order = wc_get_order( $order_id );
if ( $order ) {
    $order->update_status( 'picking', 'Заказ передан на сборку.' );
}

Это важнее, чем кажется. Прямой UPDATE в wp_posts или wp_postmeta обходит хуки, заметки заказа, кэш и современное хранилище HPOS. Код, написанный через WC_Order, значительно проще поддерживать при обновлениях WooCommerce.

Если магазин уже использует HPOS, особенно важно не привязывать кастомизацию к старой структуре таблиц заказов.

Какие хуки использовать для автоматизации

WooCommerce предоставляет события при смене статуса. Для конкретного перехода удобно использовать динамические хуки вида woocommerce_order_status_{from}_to_{to}, а для входа в определённый статус — woocommerce_order_status_{status}.

add_action( 'woocommerce_order_status_picking', function ( $order_id ) {
    $order = wc_get_order( $order_id );
    if ( ! $order ) {
        return;
    }

    // Передача задачи на склад, запись служебной метки или webhook.
} );

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

Email-уведомления для собственного этапа

Регистрация статуса сама по себе не создаёт полноценное письмо WooCommerce. Если нужен отдельный шаблон, обычно создают класс email-уведомления на базе WC_Email, подключают его через woocommerce_email_classes и запускают на нужном событии.

Для простых внутренних уведомлений допустимо использовать отдельный обработчик, но если письмо должно настраиваться в WooCommerce → Settings → Emails, правильнее интегрировать его в стандартную email-систему магазина.

Перед отправкой стоит разделить письма покупателю и сотрудникам. Например, внутренний статус «Проверка антифрода» не обязательно показывать клиенту, а «Готов к самовывозу» — наоборот, должен инициировать понятное клиентское уведомление.

Статусы и платёжные шлюзы

Нельзя подменять кастомным статусом технические состояния оплаты без понимания логики шлюза. Платёжный модуль может ожидать Pending, Processing или Failed и сам переводить заказ после webhook от банка.

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

Интеграция с CRM и складом

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

Если передача идёт через webhooks, фиксируйте идентификатор заказа, старый и новый статус, время события и idempotency key. Подход к надёжной доставке событий мы отдельно разбирали в статье Webhook WooCommerce: как не терять события при передаче заказов в CRM.

Отчёты и аналитика могут потребовать доработки

Новый статус не всегда автоматически попадает в выборки, где WooCommerce или сторонний плагин ожидает только стандартные оплаченные состояния. После внедрения проверьте:

• попадает ли заказ в нужные отчёты;
• считается ли он оплаченной продажей там, где это требуется;
• видит ли его экспорт бухгалтерии;
• не исключает ли статус интеграция доставки;
• правильно ли считаются заказы в CRM и BI.

Статус должен описывать этап процесса, а финансовое состояние лучше хранить и проверять отдельно, если интеграции чувствительны к оплате.

Что проверить на staging

1. Создать тестовый заказ каждым основным способом оплаты.
2. Проверить все допустимые переходы между статусами.
3. Убедиться, что недопустимый переход не запускается автоматически.
4. Проверить письма покупателю и менеджеру.
5. Проверить webhooks, CRM и склад.
6. Проверить заказ в HPOS и без прямых обращений к старым таблицам.
7. Проверить возврат, отмену и повторную оплату.
8. Проверить отчёты и экспорты.

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

Когда лучше использовать готовое расширение

Если нужны только несколько статусов и стандартные уведомления, готовое расширение может быть дешевле поддержки собственного кода. У WooCommerce Marketplace есть Order Status Manager, который добавляет управление статусами и связанными действиями.

Кастомная разработка оправдана, когда статус должен запускать специфическую интеграцию, обращаться к API, учитывать роли сотрудников, автоматически выбирать ветку процесса или синхронизироваться со складом/CRM.

Практическая схема внедрения

• описать существующий процесс заказов;
• оставить стандартные статусы там, где их смысл подходит;
• добавить только действительно новые бизнес-состояния;
• реализовать статусы в отдельном плагине;
• работать с заказами через WooCommerce CRUD;
• сделать автоматизации идемпотентными;
• протестировать оплату, email, CRM, склад и отчёты;
• включать на production только после staging-проверки.

Если стандартной логики уже недостаточно, A.S Groups может выполнить доработку WooCommerce: добавить статусы, автоматические переходы, уведомления и интеграции под конкретный процесс магазина. Для разбора существующей схемы можно описать задачу и текущие этапы заказа.