Реализация автоматического обновления остатков товаров от поставщиков

Реализация автоматического обновления остатков товаров от поставщиков

Остатки — самые волатильные данные в интернет-магазине. Покупатель оформляет заказ, а товара нет на складе. Или наоборот: товар есть, но он скрыт из-за нулевого остатка в устаревшем фиде. Автоматическое обновление stock-данных от поставщиков решает эту проблему системно, а не патчами.

Что именно нужно синхронизировать

Остаток — это не только количество. Полная картина включает:

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

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

Источники и форматы остатков

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

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

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, остатки которых изменились с последнего запроса:

$response = $client->get('/stocks/delta', [
    'query' => ['since' => $this->lastSyncAt->toIso8601String()],
    'headers' => ['X-API-Key' => $this->apiKey],
]);
// Возвращает только изменённые позиции — экономит трафик и время обработки

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

Если поставщик умеет пушить изменения:

// routes/api.php
Route::post('/webhooks/stock/{source}', StockWebhookController::class)
    ->middleware('webhook.signature');

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

Webhook-эндпоинт должен отвечать за <200 мс и сразу ставить задачу в очередь.

Логика применения остатков

class StockUpdater
{
    public function apply(array $stocks, int $sourceId): StockUpdateResult
    {
        $updated = $skipped = 0;

        // Bulk upsert через один запрос вместо N отдельных UPDATE
        $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);
    }
}

Метод upsert в Laravel поддерживается начиная с версии 8 и работает через INSERT ... ON CONFLICT DO UPDATE в PostgreSQL.

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

Если поставщик ведёт несколько складов, итоговый остаток на сайте — сумма по всем или выборочно:

-- Представление для витрины: суммарный доступный остаток
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;

Если один склад «Москва» считается приоритетным — можно хранить warehouse_priority и брать максимальный приоритет при qty > 0.

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

После обновления остатков запускать пересчёт видимости товара:

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,
        ]);
    }
}

Вместо Observer можно использовать database trigger — быстрее, но сложнее тестировать.

Частота обновлений и нагрузка

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

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

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

Обработка ошибок синхронизации

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