Автоматическое обновление остатков товаров от поставщиков на Laravel

Покупатель добавил товар в корзину, оформил заказ, а через час менеджер сообщает: «Этого товара нет на складе». Или наоборот: товар есть, но скрыт из-за нулевого остатка в устаревшем фиде. По статистике, до 30% заказов отменяются именно из-за неверных остатков, а менеджеры тратят до 2 часов в день на ручную сверку CSV-файлов. Это типичная ситуация при ручной синхронизации остатков.

Мы решаем её автоматической синхронизацией stock-данных от поставщиков. Наши инженеры имеют 6+ лет опыта в интеграциях с поставщиками — от 1С до маркетплейсов. После внедрения вы забудете о ручной синхронизации. Бюджет на интеграцию многократно перекрывается сокращением времени менеджеров (до 90%) и снижением числа отменённых заказов в 2–3 раза. Синхронизация с поставщиками — это вложение, которое окупается за счёт повышения точности остатков и роста конверсии.

Какие данные нужно синхронизировать?

Полная картина остатка включает:

• qty — количество единиц на складе поставщика
• warehouse — на каком складе (особенно важно при региональных складах)
• available_date — дата ожидаемого прихода, если сейчас 0
• reserved — зарезервировано под чужие заказы
• status — снят с продажи, под заказ, только опт

Минимальный набор для большинства магазинов: sku, qty, warehouse_id.

Способы получения данных от поставщиков

CSV/Excel по расписанию

Самый распространённый вариант — поставщик кладёт обновлённый файл на FTP раз в час. Реализуем интерфейс StockSourceInterface и парсер под конкретный формат:

class FtpStockSource implements StockSourceInterface
{
    public function fetch(): array
    {
        $ftp = ftp_connect($this->host);
        ftp_login($ftp, $this->user, $this->pass);
        $tmpFile = tempnam(sys_get_temp_dir(), 'stock_');
        ftp_get($ftp, $tmpFile, $this->remotePath, FTP_BINARY);
        ftp_close($ftp);
        $reader = \PhpOffice\PhpSpreadsheet\IOFactory::load($tmpFile);
        $rows = $reader->getActiveSheet()->toArray();
        unlink($tmpFile);
        $stocks = [];
        foreach (array_slice($rows, 1) as $row) { // пропустить заголовок
            $stocks[] = [
                'sku' => (string) $row[0],
                'qty' => (int) $row[2],
            ];
        }
        return $stocks;
    }
}

REST API с delta-обновлениями

Современные поставщики предоставляют endpoint для инкрементальных изменений. Запрашиваем только те SKU, остатки которых изменились с последнего опроса. Это экономит трафик и время обработки.

Webhook от поставщика

Если поставщик умеет пушить изменения, принимаем POST-запрос и ставим задачу в очередь. Эндпоинт отвечает за <200 мс. Webhook — наиболее оперативный метод.

class StockWebhookController {
    public function __invoke(Request $request, string $source): JsonResponse {
        $payload = $request->validated();
        ProcessStockWebhookJob::dispatch($source, $payload);
        return response()->json(['status' => 'queued']);
    }
}

Сравнение методов

Как агрегировать остатки из нескольких складов?

Итоговый остаток на сайте — сумма по всем активным складам или с учётом приоритета. Например, склад «Москва» считается основным: если на нём qty > 0, показываем его; иначе — остальные. Мы реализуем это через view или computed-поле. Пример SQL-представления:

CREATE VIEW product_available_stock AS 
SELECT product_id, SUM(qty) AS total_qty, MAX(updated_at) AS last_synced_at 
FROM product_stocks 
WHERE source_active = true 
GROUP BY product_id;

Обработка и применение данных

Bulk upsert

Используем upsert для массового обновления — один запрос на 500 строк вместо N отдельных UPDATE. Laravel upsert работает через INSERT ... ON CONFLICT DO UPDATE в PostgreSQL.

class StockUpdater {
    public function apply(array $stocks, int $sourceId): StockUpdateResult {
        $updated = $skipped = 0;
        $chunks = array_chunk($stocks, 500);
        foreach ($chunks as $chunk) {
            $rows = [];
            foreach ($chunk as $item) {
                $productId = $this->skuMap[$item['sku']] ?? null;
                if (!$productId) {
                    $skipped++;
                    continue;
                }
                $rows[] = [
                    'product_id' => $productId,
                    'source_id' => $sourceId,
                    'qty' => max(0, $item['qty']),
                    'updated_at' => now(),
                ];
                $updated++;
            }
            if ($rows) {
                DB::table('product_stocks')->upsert(
                    $rows,
                    ['product_id', 'source_id'],
                    ['qty', 'updated_at']
                );
            }
        }
        return new StockUpdateResult($updated, $skipped);
    }
}

Автоматическое управление видимостью

После обновления остатков пересчитываем, доступен ли товар для заказа. Используем Observer или database trigger:

class StockVisibilityObserver {
    public function updated(ProductStock $stock): void {
        $totalQty = ProductStock::where('product_id', $stock->product_id)->sum('qty');
        Product::where('id', $stock->product_id)->update([
            'in_stock' => $totalQty > 0,
            'stock_count' => $totalQty,
        ]);
    }
}

Как выбрать частоту обновления?

При частом обновлении важно не перегрузить БД. Bulk upsert по 500 строк за один запрос оптимален. Webhook обрабатывает изменения в десять раз быстрее, чем CSV-опрос, но требует более сложной инфраструктуры.

Обработка ошибок и TTL

Типичная проблема: поставщик не ответил. Не обнуляем остатки. Используем TTL: если данные от источника старше max_age (например, 4 часов), помечаем товары как «устаревшие» и показываем предупреждение в админке, но не трогаем qty на витрине.

Что входит в реализацию

1. Определение списка поставщиков и форматов данных.
2. Разработка парсеров для каждого источника с реализацией StockSourceInterface.
3. Настройка scheduler для периодического опроса CSV/API или webhook-эндпоинта.
4. Реализация StockUpdater с bulk upsert и маппингом SKU → product_id.
5. Добавление StockVisibilityObserver для автоматического управления видимостью.
6. Настройка TTL и мониторинга ошибок.
7. Тестирование на копии базы с реальными данными.

Сроки реализации

• Один источник (CSV/FTP), scheduler, bulk upsert, пересчёт видимости — от 2 дней.
• Несколько источников + агрегация по складам — от 3 до 4 дней.
• Webhook-приём + дашборд мониторинга синхронизации — от 5 дней.

Точные сроки называем после аудита вашего проекта.

Документация и поддержка

• Документация: описание архитектуры, схема данных, инструкция для администратора.
• Доступы: настройка FTP, API-ключей, webhook-эндпоинта.
• Обучение: показываем, как добавлять нового поставщика и мониторить синхронизацию.
• Поддержка: исправляем ошибки в течение гарантийного срока.

Свяжитесь с нами для аудита вашего проекта. Закажите внедрение — и ваши остатки всегда будут актуальны.