Налаштування оновлення залишків за розкладом із зовнішніх джерел 1С-Бітрікс

Налаштування оновлення остатків по розписанню з зовнішніх джерел 1С-Бітрікс

Покупець оформляє замовлення, сплачує, чекає доставку — а товара на складі немає. Остатки на сайті не оновлювалися два дні, й за цей час позиція пішла. Повернення коштів, негативний відзив, втрата клієнта. Автоматичне оновлення остатків по розписанню розв'язує цю проблему — за умови, що налаштовано правильно.

Як Бітрікс зберігає остатки

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

• b_catalog_product — основна таблиця товарів каталогу. Поле QUANTITY — загальний остаток, QUANTITY_TRACE — увімкнено гей облік кількості, CAN_BUY_ZERO — можна гей купувати при нулі.
• b_catalog_store_product — остатки по складам. Поле AMOUNT — кількість на конкретному складі (STORE_ID).
• b_catalog_store — справочник складів.

Якщо на сайті один склад — достатньо оновлювати QUANTITY у b_catalog_product. Якщо увімкнений складській облік (кілька складів, адресне зберігання) — оновлюйте b_catalog_store_product, а Бітрікс пересчитає загальний остаток автоматично.

Оновлення через API

Простий варіант — один склад:

\Bitrix\Catalog\ProductTable::update($productId, [
    'QUANTITY' => $newQuantity,
]);

Складській облік — кілька складів:

$existing = \Bitrix\Catalog\StoreProductTable::getList([
    'filter' => ['PRODUCT_ID' => $productId, 'STORE_ID' => $storeId],
])->fetch();

if ($existing) {
    \Bitrix\Catalog\StoreProductTable::update($existing['ID'], ['AMOUNT' => $newQuantity]);
} else {
    \Bitrix\Catalog\StoreProductTable::add([
        'PRODUCT_ID' => $productId,
        'STORE_ID'   => $storeId,
        'AMOUNT'     => $newQuantity,
    ]);
}

Після оновлення остатків по складам викличте пересчет загальної кількості:

CCatalogProduct::QuantityTracer($productId);

Формати даних від поставщиків

Маппінг товарів

Ключева задача — сопоставити ідентифікатор товара у прайсі поставщика з елементом каталогу Бітрікс. Варіанти:

• По артикулу — властивість PROPERTY_ARTICLE або PROPERTY_SUPPLIER_SKU. Найнадійніший при умові, що артикули унікальні.
• По XML_ID — якщо каталог спочатку імпортований з того же джерела.
• По штрихкоду — таблиця b_catalog_product_barcode. Надійно, але штрихкоди є не у всіх товарів.

Для маппінгу створіть індексовану таблицю відповідностей:

CREATE TABLE parser_product_map (
    supplier_sku VARCHAR(100) NOT NULL,
    product_id   INT NOT NULL,
    store_id     INT DEFAULT 1,
    PRIMARY KEY (supplier_sku, store_id),
    INDEX idx_product (product_id)
);

Запит через цю таблицю у 10–50 разів швидший, ніж пошук по властивостях інфоблоку на кожен товар.

Обробка нульових остатків

Коли товар закінчується, існує три стратегії поведінки:

• Деактивація (ACTIVE = 'N') — товар зникає з сайту. Погано для SEO: сторінка перестає індексуватися, позиції втрачаються.
• Показ з позначкою «Немає в наявності» — QUANTITY = 0, CAN_BUY_ZERO = 'N'. Кнопка «Купити» замінюється на «Сповіщити про поступлення». Оптимальний варіант.
• Передзамовлення — CAN_BUY_ZERO = 'Y'. Покупець може оформити замовлення, товар прийде з найближчою поставкою. Підходить для товарів з передбачуваним терміном поставки.

Стратегія задається глобально в налаштуваннях модуля catalog та може бути переопреділена для конкретного товара.

Cron та розписання

Частота оновлення залежить від оборачиваємості товара:

# Оновлення остатків кожні 30 хвилин
*/30 * * * * /usr/bin/php /home/bitrix/scripts/update_stock.php >> /var/log/stock_update.log 2>&1

Продуктивність

При оновленні 50 000+ позицій поелементне оновлення через API занадто повільне — 3–5 секунд на товар через обробники подій та пересчет кешів. Оптимізація:

• Батчевий UPDATE — прямий SQL-запит для оновлення b_catalog_store_product пакетами по 500–1000 рядків.
• Вимикання подій — \Bitrix\Catalog\ProductTable::disableEvents() на час масового оновлення.
• Відстрочений пересчет — оновити всі остатки, затім однократно пересчитати доступність та сбросити кеш.

Мониторинг

Оновлення остатків — критичний процес. Якщо скрипт упав або поставщик не відав файл — каталог показує застарілі дані. Мінімальний мониторинг:

• Перевірка часу останнього успішного оновлення. Якщо пройшло більше двох інтервалів — алерт.
• Логування кількості оновлених, пропущених (не знайдено у маппінгу) та помилкових позицій.
• Контроль аномалій: якщо разом обнулилися остатки по 80% каталогу — скоріше за все, помилка у файлі поставщика, а не реальна розпродажу.