Разработка решений под WooCommerce — коннекторы с amoCRM, МойСклад и 1С

WooCommerce — это витрина: каталог, корзина, оформление заказа. Но продажи и учёт обычно живут в других системах — в CRM и товароучёте. Я соединяю их так, чтобы заказ из магазина сразу попадал туда, где с ним работают, а остатки и цены не приходилось вести в магазине руками.

Пишу коннекторы под REST API WooCommerce — прослойку с очередью, повторными попытками и логированием. Что именно связывать, решаем под задачу: насколько хватит фантазии и насколько это окупается. Сам сайт на WordPress при этом не переделываю — работаю на стыке магазина и ваших систем.

Типовые связки, которые собираю под WooCommerce:

• Заказы из магазина → в amoCRM как сделки, со статусами и составом заказа.
• Остатки и цены из МойСклад или 1С → на витрину, чтобы не продавать то, чего нет.
• Статусы и оплаты → обратно в магазин, чтобы клиент видел актуальное состояние заказа.
• Несколько каналов (сайт, маркетплейсы) в один контур учёта без двойного ввода.

Первое — планировщик WordPress. Штатный wp-cron запускается посетителями сайта, поэтому обмен «раз в час» на магазине с редким трафиком проходит раз в сутки, и остатки на витрине отстают. Расписание я выношу за пределы WordPress: обмен идёт по системному планировщику на стороне коннектора и от посещаемости не зависит.

Второе — вариации товаров. У родительской карточки артикул есть, у размеров и цветов его часто нет, и остаток ложится на товар целиком. Перед запуском привожу вариации к артикулам учёта, иначе витрина продолжает продавать размер, которого на складе нет.

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

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

Логика обмена живёт вне WordPress — отдельным сервисом, который ходит в магазин по REST API с ключами, ограниченными нужными правами. Ядро, тему и плагины я не правлю, поэтому обновление WooCommerce или версии PHP не откатывает мои изменения и не ломает интеграцию.

Там, где без кода на стороне магазина не обойтись — например, при передаче собственных полей заказа, — оформляю его отдельным плагином с понятным именем и версией. Он не смешивается с темой, его видно в списке расширений, и при передаче проекта команда понимает, что именно у неё стоит.

Перед обновлением магазина прогоняю набор проверок на тестовой копии: создание заказа, смена статуса, выгрузка остатка, возврат оплаты. Расхождения видно до выката. В поддержке эта проверка входит в месячный цикл — WooCommerce обновляется часто, и структура полей в его API время от времени меняется.