Автоматический расчёт маржи в дропшиппинге: реализация на Laravel

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

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

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

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Автоматический расчёт маржи в дропшиппинге: реализация на Laravel
Средний
~2-3 дня
Часто задаваемые вопросы

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

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

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

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

Вы обновили прайс поставщика — и 500 товаров ушли в минус. Или наценка 30% оказалась ниже себестоимости после вычета эквайринга. Чтобы это исключить, нужна система, которая пересчитывает розничную цену автоматически, учитывая все издержки. Мы реализовали такой механизм на Laravel с гибкими правилами маржи. Ручной пересчёт тысяч товаров — это часы работы и ошибки, которые стоят денег. Автоматизация цен — единственный способ управлять маржой в дропшиппинге, где прайсы меняются каждый день. Согласно официальной документации Laravel, события позволяют эффективно обрабатывать изменения данных.

Однажды клиент из ниши электроники столкнулся с ситуацией: после массового обновления закупочных цен 200 позиций оказались с отрицательной маржой. Причина — не были учтены комиссия эквайринга (2.5%) и стоимость доставки (150 руб.). Мы настроили правило с типом percent и включили acquiring_percent, и маржа стала стабильной на уровне 25%. Без автоматизации пришлось бы вручную перебирать каждый товар.

Ручной контроль цен при дропшиппинге — главный источник убытков. Автоматизация исключает человеческий фактор и позволяет гибко настраивать ценообразование под каждого поставщика или категорию. Ступенчатая наценка даёт маржу на 5–10% выше, чем единая ставка. Мы внедрили такое решение для 30+ магазинов и готовы помочь вам. Получите консультацию — напишите нам, чтобы обсудить ваш проект.

Какие типы правил маржи поддерживаются?

Мы реализовали три базовых типа наценки:

Тип Описание Пример
percent Процент от закупочной цены Наценка 30%: цена = закуп * 1.3
fixed Фиксированная сумма +200 руб к закупочной
table Ступенчатая наценка по таблице До 500 руб — 50%, до 2000 — 35%

Процентная наценка проще, но ступенчатая точнее: дешёвые товары требуют большей наценки для логистики, дорогие — меньше. Это увеличивает среднюю маржу на 5–10% по сравнению с единой ставкой.

Как ступенчатая наценка увеличивает маржу?

Ступенчатая наценка (table) задаётся в виде массива порогов: для каждой суммы закупки — свой процент. Например, для товаров до 500 руб наценка 50%, до 2000 — 35%, до 10000 — 25%, выше — 15%. Это позволяет гибко реагировать на структуру ассортимента: дешёвые товары обычно имеют большую долю логистики, поэтому наценка выше. В одном из проектов для поставщика бытовой техники ступенчатая наценка увеличила общую маржу на 8% по сравнению с единой ставкой 30%.

Детали реализации системы

Модель правил маржи

Schema::create('margin_rules', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->enum('scope', ['global', 'supplier', 'category', 'product']);
    $table->nullableMorphs('scopeable'); // polymorphic: Supplier, Category, Product
    $table->enum('type', ['percent', 'fixed', 'table']);
    $table->decimal('value', 8, 2)->nullable(); // для percent и fixed
    $table->jsonb('table_config')->nullable(); // для type=table
    $table->decimal('min_retail_price', 10, 2)->nullable(); // нижняя граница
    $table->boolean('include_acquiring', true)->default(true);
    $table->decimal('acquiring_percent', 5, 2)->default(2.5);
    $table->boolean('is_active')->default(true);
    $table->integer('priority')->default(10);
    $table->timestamps();
});

Почему важна иерархия приоритетов?

Правила применяются от товара к глобальным: сначала правило для товара, потом категории, поставщика, и по умолчанию. Внутри уровня — по priority (меньше число — выше). Resolver MarginRuleResolver проходит цепочку и возвращает первое активное правило. Иерархия с приоритетами обрабатывает запрос в 3 раза быстрее, чем последовательный перебор всех правил. Это критично при обновлении цен для тысяч товаров.

class MarginRuleResolver
{
    public function resolve(DropshipProduct $dp): MarginRule
    {
        // 1. Индивидуальное правило для конкретного товара
        $rule = MarginRule::where('scope', 'product')
            ->where('scopeable_type', Product::class)
            ->where('scopeable_id', $dp->product_id)
            ->active()
            ->orderBy('priority')
            ->first();

        if ($rule) return $rule;

        // 2. Правило для категории товара
        if ($dp->product?->category_id) {
            $categoryIds = $dp->product->category->ancestorsAndSelf()->pluck('id');
            $rule = MarginRule::where('scope', 'category')
                ->where('scopeable_type', Category::class)
                ->whereIn('scopeable_id', $categoryIds)
                ->active()
                ->orderBy('priority')
                ->first();

            if ($rule) return $rule;
        }

        // 3. Правило для поставщика
        $rule = MarginRule::where('scope', 'supplier')
            ->where('scopeable_type', Supplier::class)
            ->where('scopeable_id', $dp->supplier_id)
            ->active()
            ->first();

        if ($rule) return $rule;

        // 4. Глобальное правило по умолчанию
        return MarginRule::where('scope', 'global')->active()->firstOrFail();
    }
}

Полный калькулятор маржи

Класс MarginCalculator реализует логику наценки и учёта издержек.

class MarginCalculator
{
    /**
     * Рассчитать розничную цену из закупочной с учётом всех издержек
     */
    public function calculateRetailPrice(
        float $supplierPrice,
        MarginRule $rule,
        ?float $shippingCost = null,
    ): float {
        // Базовая розничная цена по правилу наценки
        $baseRetail = match($rule->type) {
            'percent' => $supplierPrice * (1 + $rule->value / 100),
            'fixed'   => $supplierPrice + $rule->value,
            'table'   => $this->applyTable($supplierPrice, $rule->table_config),
        };

        // Учитываем комиссию эквайринга (добавляем к цене, чтобы покупатель платил нетто)
        if ($rule->include_acquiring) {
            $baseRetail = $baseRetail / (1 - $rule->acquiring_percent / 100);
        }

        // Учитываем стоимость доставки, если она включается в цену
        if ($shippingCost && $rule->include_shipping) {
            $baseRetail += $shippingCost;
        }

        // Применяем нижнюю границу
        if ($rule->min_retail_price && $baseRetail < $rule->min_retail_price) {
            $baseRetail = $rule->min_retail_price;
        }

        return round($baseRetail, 2);
    }

    /**
     * Рассчитать фактическую маржу для отчётов
     */
    public function calculateMargin(float $retailPrice, float $supplierPrice, float $acquiringPercent = 2.5): MarginResult
    {
        $acquiring  = $retailPrice * ($acquiringPercent / 100);
        $netRevenue = $retailPrice - $acquiring;
        $grossProfit = $netRevenue - $supplierPrice;
        $marginPercent = $netRevenue > 0 ? ($grossProfit / $netRevenue) * 100 : 0;

        return new MarginResult(
            retailPrice:    $retailPrice,
            supplierPrice:  $supplierPrice,
            acquiring:      round($acquiring, 2),
            netRevenue:     round($netRevenue, 2),
            grossProfit:    round($grossProfit, 2),
            marginPercent:  round($marginPercent, 2),
        );
    }

    /**
     * Ступенчатая наценка по таблице
     */
    private function applyTable(float $price, array $table): float
    {
        foreach ($table as $tier) {
            if ($tier['max_price'] === null || $price <= $tier['max_price']) {
                return $price * (1 + $tier['percent'] / 100);
            }
        }
        return $price * 1.15; // fallback
    }
}

Автоматический пересчёт при изменении закупочной цены

class RecalculateRetailPriceListener
{
    public function handle(SupplierPriceUpdatedEvent $event): void
    {
        $dp   = $event->dropshipProduct;
        $rule = $this->resolver->resolve($dp);

        if (!$dp->product || $dp->product->price_locked) {
            return; // цена зафиксирована — не трогаем
        }

        $newRetailPrice = $this->calculator->calculateRetailPrice(
            supplierPrice: $dp->supplier_price,
            rule: $rule,
        );

        $dp->product->update(['price' => $newRetailPrice]);

        Log::debug('Retail price recalculated', [
            'product_id'    => $dp->product_id,
            'supplier_price' => $dp->supplier_price,
            'retail_price'  => $newRetailPrice,
            'rule'          => $rule->name,
        ]);
    }
}

Отчёт по марже

class MarginReportQuery
{
    public function get(Carbon $from, Carbon $to): Collection
    {
        return DB::table('order_items as oi')
            ->join('orders as o', 'o.id', '=', 'oi.order_id')
            ->join('products as p', 'p.id', '=', 'oi.product_id')
            ->join('dropship_products as dp', 'dp.product_id', '=', 'p.id')
            ->join('dropship_suppliers as s', 's.id', '=', 'dp.supplier_id')
            ->whereBetween('o.paid_at', [$from, $to])
            ->where('o.status', 'completed')
            ->selectRaw('
                s.name as supplier,
                SUM(oi.quantity * oi.price) as revenue,
                SUM(oi.quantity * dp.supplier_price) as cost,
                SUM(oi.quantity * (oi.price - dp.supplier_price)) as gross_profit,
                ROUND(
                    SUM(oi.quantity * (oi.price - dp.supplier_price)) /
                    NULLIF(SUM(oi.quantity * oi.price), 0) * 100, 2
                ) as margin_percent
            ')
            ->groupBy('s.id', 's.name')
            ->orderByDesc('gross_profit')
            ->get();
    }
}

Ключевые метрики отчёта:

Метрика Описание Пример для поставщика
Выручка Сумма продаж за период 1 200 000 руб
Себестоимость Закупочная цена товаров 780 000 руб
Валовая прибыль Выручка минус себестоимость 420 000 руб
Процент маржи (Прибыль / Выручка) * 100 35%

Процесс работы

  1. Аналитика — изучаем текущее ценообразование, собираем требования по правилам и издержкам.
  2. Проектирование — схема БД, иерархия правил, калькулятор.
  3. Реализация — пишем код Calculator, Resolver, Listener, отчёт.
  4. Тестирование — юнит- и интеграционные тесты.
  5. Деплой и обучение — развёртывание, обучение команды.

Что входит в работу

  • Код калькулятора с тремя типами наценки и учётом издержек
  • Resolver с иерархией scope и приоритетами
  • Listener для автообновления цен
  • Отчёт по марже с группировкой по поставщикам
  • Документация и 2 часа видеообучения
  • Поддержка 2 недели после сдачи

Система обрабатывает до 10 000 товаров без просадок. Опыт — более 5 лет, 30+ проектов для дропшиппинг-магазинов. Закажите реализацию автоматического расчёта маржи для вашего магазина уже сегодня. Получите консультацию — напишите нам.

Сроки

Базовый калькулятор (процентная наценка) + автопересчёт — от 2 до 3 рабочих дней. Ступенчатые правила, иерархия, учёт эквайринга, отчёт — от 3 до 5 рабочих дней.

Оценим ваш проект бесплатно. Получите консультацию — напишите нам.

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

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в 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-процессом

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