Почему разделение заказов вызывает сложности?
Представьте интернет-магазин, где продают товары разных категорий: например, крупную бытовую технику и мелкие аксессуары. Клиент добавляет в корзину холодильник (требующий спецдоставки) и набор посуды (обычная почта). В текущей версии PrestaShop такие товары автоматически разделяются на два заказа с разными службами доставки.
Для покупателя это:
- Путаница: «Почему я получил два номера заказа? Как отслеживать посылки?»
- Недовольство: «Я оплатил всё сразу, но почему сумма раздробилась?»
Для продавца:
- Сложности с синхронизацией данных в ERP (система управления ресурсами компании, которая объединяет финансы, логистику, склад и другие процессы).
- Дополнительная работа: два заказа — дважды проверять статусы, общаться с клиентом, учитывать в отчетности.
Главная проблема текущей системы PrestaShop — не в самой доставке, а в том, как платформа «ломает» заказ на части, чтобы удовлетворить разным условиям доставки. Это устаревший подход, который давно не отвечает запросам рынка. Но команда PrestaShop уже работает над улучшениями.
Текущая система: Почему 1 заказ ≠ 1 доставка?
Сейчас PrestaShop автоматически разделяет корзину, если товары требуют разных служб доставки. Например:
- Товар А (крупногабаритный) → Доставка грузовиком.
- Товар Б (мелкий) → Курьерская служба.
Что происходит за кулисами:
- Система создает два независимых заказа.
- Каждый заказ имеет свой ID, трекер и статус оплаты.
- Для клиента это выглядит как две отдельные покупки.
Почему это неудобно?
- Для покупателя: Невозможно отследить весь заказ в одном месте. Возврат части товаров превращается в квест.
- Для продавца: В ERP-системе данные дробятся. Приходится вручную связывать заказы, что ведет к ошибкам.
- Для маркетинга: Скидки применяются к каждому «мини-заказу», а не к общей сумме. Клиент может потерять выгоду.
Будущее PrestaShop: Один заказ — множество доставок
Команда PrestaShop рассматривает новую концепцию: единый заказ с гибкими «единицами выполнения» (Fulfillment Units).
Как это может работать?
- Клиент видит один заказ.
- В корзине: холодильник (грузовой перевозчик) + набор посуды (почта).
- На этапе оформления система показывает два варианта доставки, но не разбивает заказ.
- После оплаты покупатель получает один номер заказа с двумя трекерами в личном кабинете.
- Новая логика: От заказов — к «логистическим группам».
- Fulfillment Unit — это группа товаров с одинаковыми условиями доставки.
Пример:
- Группа 1: Крупная техника → Доставка грузовиком (DPD).
- Группа 2: Мелкие товары → Курьер (UPS).
- Carrier Rules — правила, которые автоматически распределяют товары по группам на основе веса, габаритов, зоны доставки.
- Технические изменения:
- Новая сущность в базе данных —
Fulfillment, связанная с заказом, но независимая от него. - Единая финансовая модель: скидки, налоги, оплата рассчитываются для всего заказа, а не для его частей.
- API для интеграции с ERP/WMS (Warehouse Management System): данные по разным доставкам передаются в рамках одного объекта заказа.
Пример: Магазин «HomeComfort» и его борьба с хаосом
Ситуация до изменений:
- Клиент заказывает холодильник (150 кг) и набор посуды.
- PrestaShop создает два заказа:
- Заказ №45: Холодильник → Грузовая доставка (трекер 1XQ).
- Заказ №46: Набор посуды → Почта (трекер Z9R).
- Клиент в панике: «Я оплатил всё вместе! Куда пропали мои деньги?»
- Менеджер «HomeComfort» тратит час на объяснения и ручное объединение заказов в ERP.
Ситуация после внедрения новой системы:
- Заказ №45 содержит две «единицы выполнения»:
- Fulfillment Unit 1: Холодильник → Грузовик (DPD). Статус: В пути.
- Fulfillment Unit 2: Набор посуды → Почта (UPS). Статус: Доставлено.
- В ERP заказ отображается как единая сущность с подразделами.
- Клиент доволен: все данные в одном окне, нет путаницы с оплатой.
Почему это важно?
- Для клиентов:
- Прозрачность: Один номер заказа, несколько трекеров — всё в личном кабинете.
- Упрощение возвратов: Можно вернуть часть заказа без аннулирования всего платежа.
- Для бизнеса:
- Снижение нагрузки на поддержку: Больше не нужно объяснять, почему заказ «разделился».
- ERP-дружелюбность: Данные по разным доставкам привязаны к одному ID — интеграция становится предсказуемой.
- Маркетинговые возможности: Скидки на общую сумму заказа (например, «-20% при покупке от 500€») работают корректно.
- Для разработчиков:
- Упрощение платежных модулей: Одна транзакция вместо нескольких.
- Гибкость API: Внешние системы (например, TMS — Transport Management System) получают детализированные данные без парсинга множества заказов.
Сложности и перспективы
Идея кажется логичной, но её реализация потребует:
- Тщательной проработки архитектуры. Нужно учесть, как новая логика повлияет на существующие модули и интеграции.
- Тестирования. Важно убедиться, что изменения не нарушат работу магазинов, особенно крупных.
- Обучения сообщества. Мерчанты и разработчики привыкли к старой логике — им понадобятся понятные руководства и документация.
Альтернатива: Можно было бы улучшить текущую систему, «залатав» её недостатки. Но это похоже на бесконечный ремонт старого дома. Новый подход предлагает более устойчивое решение для будущего.
Зачем это нужно рынку?
По данным Salesforce, 80% покупателей считают, что опыт доставки так же важен, как и качество товара. Новая концепция PrestaShop — это шаг к клиентоцентричной коммерции, где сложные логистические сценарии не становятся головной болью для всех участников.
«PrestaShop, как open-source платформа, всегда балансировала между гибкостью и простотой. Новый подход — это не революция, а эволюция, которая отвечает запросам современного рынка. Да, изменения потребуют времени и усилий, но они помогут платформе оставаться конкурентоспособной в мире, где клиенты ценят удобство и прозрачность».
Какой подход кажется вам более жизнеспособным: переход на «единый заказ» или постепенное улучшение старой системы? Делитесь мнениями в комментариях.
