На небольшом WooCommerce-магазине счёт иногда делают вручную: открывают заказ, копируют реквизиты, собирают PDF и отправляют клиенту. Пока заказов пять в неделю, это терпимо. Когда их десятки или сотни, ручная схема начинает давать типичные ошибки: забытый документ, неверный номер, старый адрес клиента, повторная отправка или PDF, который не соответствует фактическому состоянию заказа.
Автоматизация PDF-инвойсов решает эту рутину, но только если документ связан с жизненным циклом заказа. Важно заранее определить, когда именно появляется счёт, какой номер считается официальным, что происходит при отмене или возврате и должен ли PDF генерироваться заново после изменения заказа.
Сначала отделяем заказ от счёта
Order ID или order number WooCommerce — это идентификатор заказа. Invoice number — номер финансового документа. В простом магазине они могут выглядеть одинаково, но архитектурно лучше считать их разными сущностями.
Причина простая: заказ может существовать до оплаты, менять статус, получать возврат или редактироваться менеджером. Счёт при этом может выпускаться только на определённом этапе и иметь собственную последовательную нумерацию. Если использовать ID заказа как единственный источник номера, позже сложно внедрить отдельный префикс, нумерацию по году, credit note или правила бухгалтерии.
На каком статусе генерировать PDF
WooCommerce использует статусы для отражения состояния заказа. Официальная документация Order Statuses описывает, среди прочего, Pending payment, Processing, Completed, On hold, Failed, Cancelled и Refunded.
Не существует одного правильного триггера для всех магазинов. Для оплачиваемых онлайн-заказов документ часто логично формировать после подтверждения оплаты или перехода в Processing. Для B2B-сценария счёт на оплату, наоборот, может понадобиться раньше. Поэтому сначала фиксируется бизнес-правило, а уже потом выбирается hook или событие.
Почему генерация «при каждом открытии PDF» опасна
Инвойс должен быть детерминированным документом. Если при каждом скачивании код создаёт новый номер или пересчитывает данные по текущему состоянию заказа, один и тот же заказ способен породить несколько разных документов.
Надёжнее при первом допустимом событии:
- проверить, есть ли у заказа invoice number;
- если нет — атомарно получить следующий номер;
- сохранить номер и дату в order meta или отдельной структуре;
- сформировать PDF из зафиксированных данных;
- сохранить путь или идентификатор файла;
- при повторной отправке использовать тот же документ, если бизнес-правило не требует новой версии.
Последовательная нумерация без дублей
Самая чувствительная часть — выдача следующего номера. Простой алгоритм «прочитал последний номер + 1 + сохранил» может сломаться при двух одновременных заказах: оба процесса увидят одно значение.
На нагруженном магазине счётчик должен обновляться атомарно или защищаться транзакцией/lock-механизмом. Дополнительно полезно хранить связь invoice_number → order_id и проверять уникальность до финального сохранения.
Если используется готовое расширение, нужно убедиться, как именно оно решает concurrency и что произойдёт после миграции базы или восстановления backup.
Что умеют готовые расширения WooCommerce
В WooCommerce Marketplace есть расширение PDF Invoices, которое умеет автоматически прикладывать PDF к письмам, использовать последовательную нумерацию, добавлять юридическую информацию компании и позволять клиенту скачивать прошлые счета из аккаунта.
Есть и другие Marketplace-решения, например PDF Invoice, Packing Slips & Credit Notes, где вместе со счетами предусмотрены packing slips и credit notes. Это полезно, если документный процесс шире одного invoice.
Выбор плагина лучше делать не по количеству настроек, а по конкретным требованиям: нужные поля, формат номера, налоги, возвраты, мультиязычность, HPOS, хранение PDF и возможность кастомизации шаблона.
Как связать PDF с email WooCommerce
WooCommerce имеет встроенный набор email-уведомлений. В официальной документации Email Settings перечислены New order, Completed order, Refunded order, Order Details и другие сообщения.
Для PDF важно выбрать конкретные письма, а не цеплять документ ко всем подряд. Например, покупателю можно прикладывать счёт к Processing/Completed, а администратору — к New order только если внутреннему процессу действительно нужен документ на этом этапе.
Отдельно проверяется повторная отправка email из админки. Она не должна выдавать новый invoice number, если счёт уже существует.
Order Details — не то же самое, что PDF invoice
WooCommerce умеет вручную отправлять клиенту письмо Order Details с деталями заказа и ссылкой на оплату. Это полезный штатный механизм, но он не заменяет отдельный PDF-документ, если бизнесу нужна собственная нумерация, печатный шаблон или архив.
Поэтому при проектировании стоит разделять коммуникацию о заказе и финансовый документ, даже если они приходят клиенту одним письмом.
Какие данные фиксировать в счёте
Типовой PDF может содержать:
- invoice number и дату;
- номер заказа как связанный идентификатор;
- реквизиты продавца;
- billing-данные клиента;
- позиции, количество и цены;
- скидки;
- доставку;
- налоги, если они используются;
- валюту и итог;
- дополнительные юридические поля конкретного бизнеса.
Состав документа зависит от страны и бухгалтерских требований. WooCommerce или PDF-плагин не заменяет консультацию бухгалтера по обязательным реквизитам — техническая реализация должна следовать уже определённым правилам бизнеса.
Что происходит после редактирования заказа
Представим, менеджер выпустил счёт, а затем изменил количество товара. Есть два подхода: запрещать тихое изменение документа после выпуска либо создавать новую версию/корректирующий документ.
Главное — не пересобирать старый PDF незаметно. Иначе клиент мог получить одну сумму, а через неделю скачать из My Account другой файл под тем же номером.
Для значимых сценариев полезно хранить snapshot данных, на основании которых был создан конкретный invoice.
Возвраты и credit notes
Статус Refunded в WooCommerce отражает возврат заказа, а частичный refund может существовать без полного перевода заказа в Refunded. Поэтому документный процесс должен различать полный и частичный возврат.
Если бухгалтерский процесс требует credit note, его лучше моделировать отдельным документом со своей серией/номером и связью с исходным invoice, а не просто перегенерировать старый PDF с меньшей суммой.
Совместимость с HPOS
Современный WooCommerce использует High-Performance Order Storage. Кастомный код для заказов должен работать через WooCommerce CRUD API, а не полагаться на прямые запросы к старой структуре wp_posts/wp_postmeta. WooCommerce отдельно описывал этот подход в материалах по HPOS compatibility.
Это особенно важно для invoice-плагина, который читает адрес, позиции, налоги и order meta. Перед обновлением магазина стоит проверить, что расширение официально совместимо с HPOS и не использует устаревшие обходные способы чтения заказов.
Где хранить PDF
Варианты зависят от объёма и требований:
- локально внутри защищённой директории WordPress;
- в object storage с приватным доступом;
- генерировать по запросу из immutable snapshot и кешировать готовый документ.
Публичный URL без авторизации для счёта с персональными данными — плохая идея. Если клиент скачивает документ из My Account, доступ должен проверять владельца заказа или роль сотрудника.
PDF не нужно прикладывать к каждому письму
Большие вложения увеличивают объём email и могут влиять на доставляемость. Если PDF нужен только после оплаты, нет смысла отправлять его вместе с Failed или Pending уведомлениями.
Иногда лучше дать авторизованную ссылку на скачивание, а не повторно прикладывать один и тот же файл во все сообщения. Решение зависит от требований бизнеса и привычек клиентов.
Шаблон: что можно кастомизировать
Практически всегда требуется хотя бы логотип, адрес компании, реквизиты, формат таблицы и подписи полей. В B2B могут понадобиться ИНН/регистрационные номера, PO number, договор или отдельный блок оплаты.
Если стандартного шаблона плагина недостаточно, лучше переопределить template через предусмотренный API/override, а не править файлы самого плагина: иначе обновление сотрёт изменения.
Как тестировать автоматизацию
Перед production-запуском я прогоняю несколько сценариев:
- новый оплаченный заказ;
- неоплаченный Pending/On hold;
- повторная отправка письма;
- изменение заказа до выпуска invoice;
- полный refund;
- частичный refund;
- guest checkout и заказ зарегистрированного пользователя;
- два заказа почти одновременно — проверка уникальности номеров;
- скачивание PDF из аккаунта;
- обновление WooCommerce/плагина на staging.
Частые ошибки
- Invoice number равен order ID без возможности отделить серии. Пока бизнес простой — работает, позже мешает миграции.
- Новый номер при каждом скачивании. Один заказ создаёт несколько документов.
- PDF прикладывается до нужного статуса. Клиент получает документ раньше оплаты.
- Повторный email создаёт новый счёт. Нужна идемпотентность.
- Refund перезаписывает исходный invoice. Теряется история.
- Документ лежит по публичной угадываемой ссылке. Риск раскрытия персональных данных.
- Код читает заказы напрямую из wp_posts. После HPOS интеграция ломается.
Когда нужен кастом, а когда достаточно плагина
Готовое Marketplace-расширение подходит, когда требования стандартные: один тип счёта, шаблон, нумерация, вложение в письма и скачивание в My Account. Кастомная разработка оправдана, если документы зависят от юридического лица, склада, валюты, метода оплаты, CRM/ERP, внешней бухгалтерии или нестандартных статусов.
Часто оптимальный вариант — не писать PDF engine с нуля, а взять стабильное расширение и добавить небольшой слой бизнес-логики: поля, API-синхронизацию, условия отправки и контроль статусов.
Нужна автоматизация счетов в WooCommerce?
В A.S Groups могу проверить текущий процесс заказов, подобрать или доработать PDF-решение, настроить нумерацию, шаблон, вложения в email, возвраты и интеграцию с CRM или учётной системой. Если магазин уже работает, можно начать с доработки WooCommerce; для нового проекта — с разработки WooCommerce-магазина.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.