Ми розробляємо мультисклад для інтернет-магазинів — архітектуру, де критична точність залишків, швидкість маршрутизації та прозорість для покупця. В одному з проєктів ми впровадили мультисклад для магазину з 5 точками зберігання: центральний склад, три регіональних та один дропшипер. До впровадження менеджери вручну розподіляли замовлення, що призводило до помилок — замовлення йшли на склад без потрібного товару, а покупці отримували скасування. Система автоматично обирала найближчий склад із достатнім залишком та при необхідності розщеплювала замовлення на кілька відвантажень. У результаті час обробки замовлення скоротився на 40%, а кількість спірних ситуацій з клієнтами знизилася на 90%. Наша команда має більше 5 років досвіду в розробці e-commerce рішень та впровадила мультисклад для 20+ магазинів з каталогами до 6000 SKU. Зазвичай така необхідність виникає, коли магазин працює з кількома постачальниками, має регіональні склади, використовує дропшипінг або офлайн-точки для самовивозу (BOPIS).
Схема даних
Розширення односкладової схеми: додається вимір warehouse_id:
CREATE TABLE warehouses ( id BIGSERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, code VARCHAR(50) NOT NULL UNIQUE, address TEXT, is_active BOOLEAN NOT NULL DEFAULT true, priority INTEGER NOT NULL DEFAULT 0, type VARCHAR(50) NOT NULL DEFAULT 'internal' ); CREATE TABLE warehouse_stock ( id BIGSERIAL PRIMARY KEY, warehouse_id BIGINT NOT NULL REFERENCES warehouses(id), variant_id BIGINT NOT NULL REFERENCES product_variants(id), stock_qty INTEGER NOT NULL DEFAULT 0, reserved_qty INTEGER NOT NULL DEFAULT 0, UNIQUE (warehouse_id, variant_id), CHECK (stock_qty >= 0), CHECK (reserved_qty >= 0) ); CREATE MATERIALIZED VIEW product_total_stock AS SELECT variant_id, SUM(stock_qty) AS total_stock, SUM(reserved_qty) AS total_reserved, SUM(stock_qty - reserved_qty) AS available_qty FROM warehouse_stock GROUP BY variant_id; Materialized view оновлюється після кожної зміни через тригер або REFRESH MATERIALIZED VIEW CONCURRENTLY за розкладом (кожну хвилину). Наш досвід показує, що такий підхід у 3 рази швидше за live-запити при кожному замовленні.
Як обрати склад для відвантаження?
Ключова бізнес-логіка мультискладу — алгоритм WarehouseRouter. У нас він конфігурований:
| Стратегія | Опис | Застосування |
|---|---|---|
| Proximity | Найближчий до адреси доставки | Регіональні мережі |
| Priority | За пріоритетом складу | Дропшипінг як запасний |
| Cost | Мінімальна вартість відвантаження | Інтеграція з транспортними API |
| Consolidation | Мінімум джерел у замовленні | Зниження вартості упаковки |
| FIFO по SKU | Перший прийшов — першим пішов | Керування термінами придатності |
Для більшості проєктів достатньо proximity + priority fallback. Якщо сумніваєтеся у виборі стратегії — зв'яжіться з нами, допоможемо підібрати оптимальну.
Приклад реалізації роутера:
class WarehouseRouter { public function resolve(OrderItem $item, Address $destination): Warehouse { $candidates = WarehouseStock::query() ->where('variant_id', $item->variant_id) ->whereRaw('stock_qty - reserved_qty >= ?', [$item->qty]) ->with('warehouse') ->get() ->filter(fn($ws) => $ws->warehouse->is_active) ->sortBy([ fn($a, $b) => $this->byProximity($a->warehouse, $destination) <=> $this->byProximity($b->warehouse, $destination), fn($a, $b) => $a->warehouse->priority <=> $b->warehouse->priority, ]); return $candidates->first()?->warehouse ?? throw new NoWarehouseAvailableException($item->variant_id); } } Керування відвантаженнями та резервування
Якщо товари з одного замовлення є на різних складах — замовлення розщеплюється на кілька відвантажень (Shipment). Покупець бачить єдине замовлення, але всередині система створює різні трек-номери. Статус замовлення агрегується: «виконано» тільки коли всі відвантаження доставлені.
Резервування має бути атомарним — фіксувати конкретний склад, а не лише варіант. Операція резервування: UPDATE warehouse_stock SET reserved_qty = reserved_qty + :qty WHERE variant_id = :vid AND warehouse_id = :wid AND (stock_qty - reserved_qty) >= :qty. Паралельно запис у stock_reservations. Це виключає подвійне резервування одного й того ж товару.
Як синхронізувати залишки із зовнішніми системами?
Кожен склад може мати свій канал оновлення залишків. Для кожного джерела — окремий адаптер, що реалізує інтерфейс WarehouseStockProvider:
- Внутрішній склад: WMS через REST API або файловий обмін (XLSX, CSV).
- Дропшипер: їх API з rate-limit, часто нестандартний формат.
- Офлайн-точка: касова система (1С:Роздріб, iiko).
- МійСклад: REST API з підтримкою вебхуків.
Синхронізація запускається незалежно за розкладом: * * * * * php artisan stock:sync --warehouse=central і т.д. У кожного адаптера свій таймаут та обробка помилок.
BOPIS: самовивіз з магазину
Якщо включений BOPIS, покупець обирає точку самовивозу. Для цього потрібен API, що повертає available_qty по кожному товару на кожному складі. Фронтенд будує список точок та карту (Leaflet, Яндекс.Карти), фільтруючи тільки ті, де є все замовлення.
Звітність по складах
Аналітика, яка реально потрібна операційному менеджеру:
- Залишки по кожному складу в розрізі категорій.
- Оборотність (sold_qty / avg_stock за період).
- Переміщення між складами (transfer orders).
- Прогноз дефіциту по днях продажів.
Приклад запиту оборотності:
SELECT w.name AS warehouse, pv.sku, ws.stock_qty, COALESCE(sales.sold_30d, 0) AS sold_30d, CASE WHEN COALESCE(sales.sold_30d, 0) = 0 THEN NULL ELSE ROUND(ws.stock_qty / (sales.sold_30d / 30.0)) END AS days_of_stock FROM warehouse_stock ws JOIN warehouses w ON ws.warehouse_id = w.id JOIN product_variants pv ON ws.variant_id = pv.id LEFT JOIN ( SELECT variant_id, SUM(qty) AS sold_30d FROM order_items oi JOIN orders o ON oi.order_id = o.id WHERE o.completed_at >= NOW() - INTERVAL '30 days' GROUP BY variant_id ) sales ON sales.variant_id = pv.id; Процес впровадження
| Етап | Що робимо | Результат |
|---|---|---|
| Аналіз | Збираємо вимоги: кількість складів, типи, бізнес-процеси | Технічне завдання |
| Проектування | Схема БД, алгоритми маршрутизації, адаптери інтеграції | Архітектурний документ |
| Реалізація | Код на Laravel, тести, міграції | Репозиторій з кодом |
| Інтеграція | Підключаємо одного-двох зовнішніх провайдерів | Робочі синхронізації |
| Тестування | Навантажувальне, module, integration тести | Звіт про тестування |
| Деплой | Налаштування черг, schedules, моніторинг | Доступи та документація |
| Навчання | Навчання менеджерів роботі з системою | Відеоінструкції та база знань |
Покроковий план впровадження
- Аналіз вимог: Визначаємо кількість складів, їх типи та бізнес-процеси. Збираємо метрики: обсяг замовлень, частоту оновлення залишків, інтеграційні точки.
- Проектування архітектури: Розробляємо схему БД, обираємо алгоритми маршрутизації, проектуємо адаптери для зовнішніх систем.
- Розробка та тестування: Пишемо код, покриваємо unit- та integration-тестами, проводимо навантажувальне тестування.
- Інтеграція та деплой: Підключаємо склади та зовнішніх провайдерів, налаштовуємо моніторинг, документуємо.
- Навчання та передача: Навчаємо менеджерів, передаємо доступи та документацію.
Що входить в роботу
Після впровадження ви отримуєте:
- Архітектурний документ та опис схеми БД.
- Вихідний код репозиторію з коментарями.
- Налаштовані черги та планувальники завдань.
- Документацію по API інтеграцій.
- Доступи до моніторингу (лог-централізація, алерти).
- Навчання команди (відеоінструкції та база знань).
- Гарантію на реалізований функціонал.
Терміни та вартість
- Схема мультискладу + маршрутизація за пріоритетом: 5–7 днів.
- Розщеплення замовлень + керування відвантаженнями: 3–5 днів.
- Інтеграція з одним зовнішнім джерелом (1С, МійСклад): 3–5 днів.
- BOPIS з картою самовивозу: +3–4 дні.
- Аналітичні звіти по складах: +2–3 дні.
Повноцінна мультисклад-система для магазину з 2–5 точками зберігання: 2–4 тижні. Вартість розраховується індивідуально — щоб отримати точну оцінку вашого проєкту, надішліть запит, ми проаналізуємо ваші склади та запропонуємо рішення. Надаємо гарантію на реалізований функціонал.
Замовте впровадження мультискладу під ключ у нас — отримайте консультацію та точну оцінку вашого проєкту. Зв'яжіться з нами.