Розробка модуля управління складами 1С-Бітрікс

Розроблення модуля керування складами для 1С-Bitrix

У Bitrix вбудований облік складських залишків через модуль catalog: таблиці b_catalog_store (склади), b_catalog_store_product (залишки за складами та товарами). Для простих сайтів цього достатньо. Але коли з'являються кілька реальних складів з різною логікою резервування, пріоритетами відпускання, переміщенням між складами та інтеграцією з 1С — стандартний функціонал потребує суттєвого розширення.

Обмеження стандартного Bitrix

• Немає поняття «зарезервовано» у розрізі замовлення — залишок або є, або немає
• Немає логіки вибору складу для відпускання при оформленні замовлення
• Немає обліку переміщень між складами з історією
• Немає аналітики за оборотністю та дефіцитом

Розширення схеми даних

Модуль додає кілька таблиць поверх стандартних:

Таблиця b_catalog_store_reservation — резервування під замовлення:

Таблиця b_catalog_store_movement — переміщення між складами:

Резервування при оформленні замовлення

При створенні замовлення товари потребують резервування. Логіка підключається через обробник подіі OnSaleOrderSaved:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderSaved',
    [ReservationService::class, 'onOrderSaved']
);

Метод onOrderSaved перевіряє, що статус замовлення передбачає резерв (наприклад, N — новий, P — оплачено). Для кожної позиції замовлення визначає склад-джерело та створює запис у b_catalog_store_reservation.

Вибір складу для відпускання

Стратегія вибору складу налаштовується в конфігурації модуля:

• FIFO за датою приходу — спочатку відпускається більш старий товар
• Найближчий склад — за геолокацією покупця (вимагає координат складів)
• Пріоритет складу — поле SORT у b_catalog_store, менше = вищий пріоритет
• Мінімальний залишок — спочатку спустошувати склади з найменшим запасом

Якщо на одному складі немає потрібної кількості, система автоматично розбиває відпускання по кількох складах.

Розрахунок доступного залишку

Доступний залишок = фізичний залишок мінус активні резерви:

public static function getAvailable(int $storeId, int $productId): float
{
    $physical = \Bitrix\Catalog\StoreProductTable::getList([
        'filter' => ['=STORE_ID' => $storeId, '=PRODUCT_ID' => $productId],
        'select' => ['AMOUNT'],
    ])->fetch()['AMOUNT'] ?? 0;

    $reserved = \Bitrix\Main\Application::getConnection()->query(
        "SELECT COALESCE(SUM(QUANTITY), 0) as RES
         FROM b_catalog_store_reservation
         WHERE STORE_ID = {$storeId}
           AND PRODUCT_ID = {$productId}
           AND RELEASED_AT IS NULL"
    )->fetch()['RES'] ?? 0;

    return max(0, (float)$physical - (float)$reserved);
}

На карточці товару та в корзині відображається саме доступний залишок, а не фізичний.

Адміністративний інтерфейс

В адміністративній частині (/bitrix/admin/) додаються розділи:

• Залишки за складами — матриця товар × склад з фізичним та доступним залишком, фільтрація за категорією та складом
• Переміщення — створення документа переміщення, підтвердження приходу на склад-приймач
• Резерви — список активних резервів з можливістю ручного зняття

Інтеграція з 1С

Якщо на проекті працює інтеграція з 1С через стандартний механізм (/bitrix/admin/1c_exchange.php), залишки з модуля синхронізуються через обробник подіі OnSuccessCatalogImport1C. Резерви при цьому не затираються — залишки з 1С інтерпретуються як фізичні, доступний залишок перераховується.

Терміни розроблення