Реализация региональных складов и доставки на сайте

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация региональных складов и доставки на сайте
Сложный
~5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1252
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    948

Представьте: интернет-магазин с 5 складами по России. Без правильного распределения заказов доставка в Новосибирск может уйти из Москвы, хотя товар есть в Красноярске. Клиент платит больше и ждёт дольше. В результате — рост возвратов и падение конверсии. Наша система автоматически находит ближайший склад, резервирует товар там и рассчитывает доставку от фактического города отправления. В среднем это сокращает время доставки на 40% для региональных клиентов и снижает операционные затраты на 25% за счёт оптимизации маршрутов. Решение построено на Laravel 11 и React 18, с использованием паттернов Repository и BFF.

Какие проблемы решаем

  • Ошибки резерва. Система всегда выбирает склад, ближайший к покупателю, и резервирует товар именно там. Клиент получает заказ быстрее и дешевле.
  • Некорректный расчёт доставки. Доставка считается от фактического склада, а не от центрального. Это снижает стоимость для региональных покупателей в среднем на 15–20%.
  • Разрозненные остатки. На карточке товара показывается суммарное наличие по всем складам, а также детализация по городам — клиент видит, где товар есть точно.

В отличие от простого показа «есть/нет», мы отображаем точное количество по каждому складу и предлагаем самовывоз из ближайшего. Это снижает число возвратов на 15–20%.

Как выбрать склад для покупателя?

Основной алгоритм реализован в классе WarehouseSelector на Laravel. Он получает ID товара, нужное количество и город назначения, затем выполняет два шага:

  1. Находит склады, где available >= quantity, сортируя по приоритету (можно настроить в админке).
  2. Если геокодирование города успешно — сортирует по расстоянию до покупателя по формуле гаверсинуса. Если нет — выбирает первый по приоритету.
class WarehouseSelector
{
    public function selectForDelivery(
        int    $productId,
        int    $quantity,
        string $destinationCity,
    ): ?WarehouseSelectionResult {
        // Склады, где есть нужное количество
        $available = WarehouseStock::where('product_id', $productId)
            ->where('available', '>=', $quantity)
            ->with('warehouse')
            ->orderByDesc('warehouse.priority')
            ->get();

        if ($available->isEmpty()) {
            // Попробовать split — взять с нескольких складов
            return $this->splitWarehouseSelection($productId, $quantity);
        }

        // Сортировка по близости к покупателю
        $coords = $this->geocoder->getCoords($destinationCity);

        if ($coords) {
            $sorted = $available->sortBy(function ($stock) use ($coords) {
                return $this->haversineDistance(
                    $coords['lat'], $coords['lng'],
                    $stock->warehouse->lat, $stock->warehouse->lng,
                );
            });

            return new WarehouseSelectionResult(
                warehouse:   $sorted->first()->warehouse,
                isSplit:     false,
            );
        }

        // Геокодирование не удалось — берём по приоритету
        return new WarehouseSelectionResult(
            warehouse: $available->first()->warehouse,
            isSplit:   false,
        );
    }

    private function haversineDistance(float $lat1, float $lng1, float $lat2, float $lng2): float
    {
        $R   = 6371; // km
        $dLat = deg2rad($lat2 - $lat1);
        $dLng = deg2rad($lng2 - $lng1);

        $a = sin($dLat / 2) ** 2
           + cos(deg2rad($lat1)) * cos(deg2rad($lat2)) * sin($dLng / 2) ** 2;

        return $R * 2 * atan2(sqrt($a), sqrt(1 - $a));
    }
}

Почему важно резервировать сток при заказе?

Без резервирования возникает race condition: два покупателя могут одновременно оформить заказ на последнюю единицу товара. Наш StockReservationService использует блокировки lockForUpdate в транзакции, чтобы избежать двойного резерва. Резерв живёт 30 минут, после чего автоматически отменяется.

class StockReservationService
{
    public function reserve(Order $order): ReservationResult
    {
        $reservations = [];

        DB::transaction(function () use ($order, &$reservations) {
            foreach ($order->items as $item) {
                // Найти склад с нужным количеством
                $stock = WarehouseStock::where('product_id', $item->product_id)
                    ->where('available', '>=', $item->quantity)
                    ->where('warehouse_id', $item->preferred_warehouse_id
                        ?? $this->getNearestWarehouse($order->delivery_city, $item->product_id)->id
                    )
                    ->lockForUpdate()
                    ->first();

                if (!$stock) {
                    throw new InsufficientStockException(
                        "Недостаточно товара на складе: SKU {$item->product->sku}"
                    );
                }

                // Увеличить зарезервированное
                $stock->increment('reserved', $item->quantity);

                $reservations[] = StockReservation::create([
                    'order_id'     => $order->id,
                    'order_item_id' => $item->id,
                    'warehouse_id' => $stock->warehouse_id,
                    'product_id'   => $item->product_id,
                    'quantity'     => $item->quantity,
                    'expires_at'   => now()->addMinutes(30),
                ]);
            }
        });

        return new ReservationResult(reservations: $reservations);
    }

    public function cancelExpiredReservations(): int
    {
        $expired = StockReservation::where('status', 'reserved')
            ->where('expires_at', '<', now())
            ->get();

        foreach ($expired as $reservation) {
            DB::transaction(function () use ($reservation) {
                WarehouseStock::where([
                    'product_id'  => $reservation->product_id,
                    'warehouse_id' => $reservation->warehouse_id,
                ])->decrement('reserved', $reservation->quantity);

                $reservation->update(['status' => 'cancelled']);
            });
        }

        return $expired->count();
    }
}

Как рассчитывается доставка с учётом склада?

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

class RegionalDeliveryCalculator
{
    public function calculate(
        array  $cartItems,
        string $destination,
    ): DeliveryResult {
        // Сгруппировать товары по складу
        $warehouseGroups = $this->groupByWarehouse($cartItems, $destination);

        $allOptions = collect();

        foreach ($warehouseGroups as $warehouseId => $items) {
            $warehouse = Warehouse::find($warehouseId);

            // Считать доставку от конкретного склада
            $request = new DeliveryRequest(
                fromCity:    $warehouse->city,
                fromLat:     $warehouse->lat,
                fromLng:     $warehouse->lng,
                destination: $destination,
                items:       $items,
            );

            $options = $this->carrierCalculator->calculate($request);

            // Если несколько складов — суммировать стоимость
            if (count($warehouseGroups) > 1) {
                $allOptions = $allOptions->merge(
                    $options->map(fn($o) => $o->withWarehouseNote($warehouse->city))
                );
            } else {
                $allOptions = $allOptions->merge($options);
            }
        }

        // Дедупликация по методу доставки — выбрать лучший вариант
        return new DeliveryResult(
            options: $allOptions->groupBy('method')
                ->map(fn($g) => $g->sortBy('price')->first())
                ->values(),
        );
    }

    private function groupByWarehouse(array $cartItems, string $destination): array
    {
        $groups = [];

        foreach ($cartItems as $item) {
            $warehouse = $this->selector->selectForDelivery(
                $item->product_id,
                $item->quantity,
                $destination,
            );

            $warehouseId = $warehouse?->warehouse->id ?? $this->defaultWarehouse->id;
            $groups[$warehouseId][] = $item;
        }

        return $groups;
    }
}

Отображение остатков по складам на карточке товара

Фронтенд-компонент на React запрашивает наличие по городам через API и показывает свёрнутый список. Если товара нет ни на одном складе — выводится «Нет в наличии».

// Компонент наличия по городам
const StockByCity: React.FC<{ productId: number }> = ({ productId }) => {
  const { data } = useQuery(['stock', productId], () => fetchStockByCity(productId));

  if (!data?.length) return <span className="text-red-500">Нет в наличии</span>;

  return (
    <details className="text-sm">
      <summary className="cursor-pointer text-green-600 font-medium">
        В наличии — {data.length} город(а)
      </summary>
      <ul className="mt-1 space-y-1 pl-3">
        {data.map(s => (
          <li key={s.warehouse} className="text-gray-600">
            {s.city} — {s.qty} шт.
          </li>
        ))}
      </ul>
    </details>
  );
};

Процесс внедрения

Внедрение проходит в 5 этапов:

Этап Длительность
Аналитика текущей архитектуры и сбор данных 1-2 дня
Проектирование схемы данных и API 1 день
Реализация backend-классов (WarehouseSelector, RegionalDeliveryCalculator, StockReservationService) 2-3 дня
Интеграция UI-компонентов (карточка товара, корзина) 1-2 дня
Тестирование, деплой и обучение менеджеров 1-2 дня

Общий срок — от 6 до 7 рабочих дней без учёта трансферов между складами. Точный срок рассчитывается после аудита вашей текущей архитектуры.

Что входит в результат

  • Документация схемы данных и API.
  • Рабочие backend-классы (WarehouseSelector, RegionalDeliveryCalculator, StockReservationService).
  • UI-компоненты для карточки товара и корзины.
  • Инструкция для администратора по управлению складами и приоритетами.
  • Обучение менеджеров работе с резервами и трансферами.
  • Поддержка в течение 30 дней после сдачи.

Сравнение с централизованным складом

Характеристика Один склад Региональные склады (наше решение)
Скорость доставки Высокая только в городе склада Минимальная для каждого региона
Стоимость доставки Фиксированная от центра Адаптивная, часто ниже на 15-20%
Остатки на сайте Только общие По складам с детализацией
Риск ошибок резерва Низкий Практически исключён

Закажите внедрение — получите предварительную оценку за 1 день. Наша команда имеет 8+ лет опыта в e-commerce разработке и реализовала более 50 проектов с мультискладской логистикой. Сертифицированные инженеры Laravel и React используют проверенные паттерны, такие как Repository и BFF, чтобы обеспечить отказоустойчивость и простоту поддержки. Получите консультацию инженера — бесплатно.

Что ещё нужно знать?Система корректно обрабатывает кейсы трансферов между складами — когда товар перемещается между складами, остатки пересчитываются в реальном времени. Для этого мы используем очередь фоновых задач (Laravel Horizon) с обработкой событий движения товара.

Разработка интернет-магазинов

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в e-commerce возникает на стыке этих подсистем. Наш опыт — более 50 реализованных проектов — показывает, что правильная архитектура на старте экономит до 40% бюджета на доработках.

Почему производительность каталога деградирует при росте SKU?

Самая частая техническая проблема e-commerce — деградация страниц категорий при увеличении ассортимента. Страница работает хорошо на 500 товарах и начинает тормозить на 10 000. Причины почти всегда одни и те же.

N+1 на атрибутах. Загружаете список товаров — 50 элементов. Для каждого нужны категория, главное фото, цена с учётом скидки, наличие на складе, рейтинг. Без правильного eager loading это 250+ запросов на страницу. В Laravel решается через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) и withAvg('reviews', 'rating'). Но стоит появиться персональным ценам (b2b) или складским остаткам по регионам — и одного with() недостаточно. Нужны Query Object или выделенный ReadModel.

Фасетная фильтрация без индексов. Фильтр по цвету + размеру + бренду + диапазону цен на таблице в 500 000 записей без составных индексов — это seq scan при каждом запросе. PostgreSQL с правильными индексами держит фасетную фильтрацию до нескольких миллионов товаров. Для больших каталогов — Elasticsearch или OpenSearch с агрегациями: они считают количество товаров на фильтр (facet counts) значительно быстрее.

Пагинация через OFFSET. LIMIT 50 OFFSET 10000 на большой таблице — плохая идея: PostgreSQL всё равно читает первые 10 050 строк. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 работает за константное время независимо от страницы. Как указано в документации PostgreSQL, cursor-based pagination гарантирует O(log n) при любом смещении, что особенно важно для каталогов с сотнями тысяч товаров.

Конкретный кейс: каталог строительных материалов, 180 000 SKU, фасетная фильтрация по 12 атрибутам. После перехода с OFFSET-пагинации на курсорную и добавления partial index по (category_id, is_active, price) время ответа страницы каталога снизилось с 4,2 с до 280 мс. Экономия на серверных ресурсах составила около 30 000 ₽ в месяц. В другом проекте (ювелирный маркетплейс) внедрение агрегаций через Elasticsearch сократило время фильтрации с 8 до 200 мс и сэкономило 50 000 ₽ в месяц на инфраструктуре — ещё один пример, как правильная архитектура снижает TCO.

Что такое race condition в корзине и как его избежать?

Checkout — место, где деньги либо попадают на счёт, либо нет. Технические проблемы здесь стоят дорого.

Race condition при резервировании товара. Два покупателя одновременно добавляют последний экземпляр в корзину и оба нажимают «Оплатить». Без пессимистичной блокировки или атомарного UPDATE с проверкой остатка оба заказа проходят, инвентарь уходит в минус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Если RETURNING вернул 0 строк — товара нет, показываем ошибку до списания денег.

Идемпотентность платёжных вебхуков. payment.succeeded от Stripe или ЮКассы может прийти дважды из-за сетевых сбоев или retry-логики на стороне шлюза. Без проверки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублирование заказа или двойное зачисление. Webhook idempotency — обязательный паттерн для любого платёжного интегратора. Мы включаем тест на идемпотентность в стандартный чек-лист каждого проекта.

Checkout в несколько шагов. Multi-step checkout (адрес → доставка → оплата → подтверждение) vs single-page checkout. Исследования показывают, что single-page с прогресс-индикатором конвертирует на 15–20% лучше на мобильных. Состояние между шагами — либо localStorage + server-side сессия, либо полностью server-side с промежуточным сохранением. Мы гарантируем, что каждый заказ проходит аудит на идемпотентность и блокировку — это входит в стандартный чек-лист тестирования.

Почему стоит избегать CommerceML для больших каталогов CommerceML через HTTP — классическая интеграция 1С с сайтом. 1С выгружает XML по расписанию, сайт импортирует. Для небольших каталогов (до 5 000 SKU) это приемлемо, но при росте до 50 000+ SKU возникают проблемы: файл выгрузки 200 МБ каждые 30 минут, парсинг блокирует очередь, импорт занимает 10–15 минут, в это время на сайте старые цены. Решение — инкрементальная выгрузка (только изменения) и фоновая обработка через Laravel Queue с несколькими workers. Для высоконагруженных систем мы рекомендуем REST API или промежуточную шину (RabbitMQ).

Интеграции: 1С, склад, доставка

1С — отдельная глава. Три распространённых способа интеграции:

  1. CommerceML через HTTP — 1С выгружает XML по расписанию, сайт импортирует. Работает для небольших каталогов, есть задержка синхронизации.
  2. REST API / OData от 1С — двусторонняя синхронизация в реальном времени. Требует настройки на стороне 1С, капризна к версиям конфигураций.
  3. Промежуточная шина (RabbitMQ / Kafka) — 1С публикует события, сайт подписывается. Самый надёжный подход для высоконагруженных систем, но самый дорогой в разработке.

Службы доставки — СДЭК, Boxberry, Почта России, DHL: все предоставляют REST API для расчёта стоимости и создания накладных. Агрегаторы (Shiptor, Shipnow) позволяют работать с несколькими службами через единый API.

Платёжные шлюзы

Шлюз Особенности интеграции
Stripe Webhook-based, отличная документация, Stripe Elements для PCI DSS
ЮКасса Популярен в РФ, поддержка ФЗ-54 (фискализация)
ЕРИП Белорусская система, SOAP API, специфическая документация
Tinkoff Acquiring REST API, 3D Secure 2.0, webhook-уведомления

Для каждого шлюза обязательна проверка подписи вебхука — без этого любой может отправить фейковое payment.succeeded.

CMS vs собственная разработка

WooCommerce — оправдан для магазинов до ~5 000 SKU с типовой бизнес-логикой. Быстрый старт, огромная экосистема плагинов. Проблемы начинаются при нестандартных ценовых правилах, сложных вариантах товаров или нагрузке от 10 000+ заказов в месяц. Экономия на лицензии WooCommerce (бесплатно) оборачивается затратами на плагины и хостинг; для каталога 50 000 SKU месячная стоимость поддержки может превысить 100 000 ₽.

OpenCart, Prestashop — аналогичная история. Хороши для старта, ограничены при росте.

Собственная разработка на Laravel — для:

  • Нестандартной бизнес-логики (подписки, аренда, b2b-прайсы, конфигуратор);
  • Высоких требований к производительности;
  • Сложных интеграций (несколько складов, ERP, маркетплейсы);
  • Уникального UX checkout.

Как мы разрабатываем интернет-магазин: пошаговый процесс

  1. Аналитика и проектирование. Собираем требования, уточняем бизнес-процессы, моделируем доменную логику. На выходе — техническое задание и архитектурная схема.
  2. Backend и API. Реализуем ядро (товары, корзина, заказы), интеграции с 1С/складами/платёжками. Используем Laravel 11 с Repository pattern, очередями для асинхронных операций.
  3. Frontend и checkout. Настраиваем React 18 / Next.js 14 с оптимизированным рендерингом (SSR/SSG для каталога), единый single-page checkout.
  4. Тестирование. Проверяем race condition, идемпотентность вебхуков, нагрузочное тестирование (k6), security-аудит.
  5. Деплой и мониторинг. Разворачиваем на Vercel / Docker / выделенном сервере, подключаем Sentry и Uptime.

SEO для e-commerce

Canonical и дублирование. Фасетная фильтрация генерирует тысячи URL (?color=red&size=M&sort=price). Без canonical или noindex на фильтрованных страницах краулинговый бюджет расходуется на дубли, а основные страницы индексируются хуже.

Structured data. Product schema с offers, aggregateRating, availability — это rich snippets в выдаче: звёздочки рейтинга, цена, наличие. Влияет на CTR.

Core Web Vitals на страницах товаров. Hero image товара — это LCP element. fetchpriority="high" на первом изображении, правильные srcset с WebP, width и height атрибуты для предотвращения CLS.

Что входит в результат работы

После завершения проекта вы получаете:

  • Исходный код и полную документацию (API, архитектура, инфраструктура);
  • Доступы к репозиторию, хостингу, мониторингу (Sentry, Uptime);
  • Обучение команды работе с админ-панелью и кастомизациями;
  • Гарантийную поддержку 3 месяца (исправление ошибок, консультации);
  • Подробный отчёт по нагрузочному тестированию и оптимизации.

Ориентиры по срокам

Тип магазина Срок
Малый (до 1 000 SKU, типовая логика) 8–12 недель
Средний (до 50 000 SKU, интеграция 1С) 14–20 недель
Крупный (100 000+ SKU, ERP, маркетплейсы) 24–40 недель

Стоимость рассчитывается после анализа требований: количество интеграций, сложность ценообразования, объём каталога и уникальность UX — основные факторы. Оценим ваш проект бесплатно — закажите консультацию.

Чек-лист перед запуском

  • Race condition при оплате последнего товара — покрыт тестом
  • Идемпотентность вебхуков платёжного шлюза
  • Rate limiting на эндпоинтах корзины и checkout
  • Canonical на фильтрованных страницах каталога
  • Фискализация чеков (ФЗ-54 для РФ или аналог)
  • Стресс-тест checkout под нагрузкой (k6 или Locust)
  • Мониторинг ошибок (Sentry) и алерты на payment errors
  • Backup базы данных с проверенным restore-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.