Налаштування автоматичного замовлення товарів у постачальників 1С-Бітрікс
Уявіть: менеджер витрачає 3 години на день на ручний моніторинг залишків 80 000 позицій. Товар закінчився, а замовлення не зроблено — втрачені продажі та термінові доставки за ваш рахунок. Або навпаки: закупівля «на око» призводить до заморожування обігових коштів. Ми вирішуємо це через автоматичне замовлення на CommerceML та штатні механізми Бітрікс.
Наша архітектура виключає людський фактор: агент перевіряє залишки, порівнює з порогом перезамовлення та створює замовлення. Відправка відбувається по API, email або EDI — залежно від можливостей постачальника. За останні 5 років впроваджень ми скоротили час на закупівлі на 70% у клієнтів з роздрібу та дистрибуції.
Проблеми, які вирішуємо
Типова ситуація: середній час поставки 10 днів, поріг перезамовлення не налаштований — до приходу товару вже дефіцит. Або навпаки: поріг завищений, страховий запас 40% замість 20%. Ручний контроль призводить до помилок:
- Моніторинг тисяч позицій вручну — до 3 годин на день.
- Різні формати відправки (email, API, EDI) для кожного постачальника.
- Дублювання замовлень при збоях інтеграції.
Ми закриваємо кожну проблему архітектурно: порогові значення з прогнозом, агент з захистом NOT EXISTS, гнучкі адаптери відправки.
Як працює агент перезамовлення?
Агент AutoReorderAgent запускається за розкладом (раз на годину або раз на добу) та виконує запит: вибирає товари, у яких поточний залишок нижче порогу, та для яких немає активного замовлення у того ж постачальника. Умова NOT EXISTS ключова — вона блокує дублювання навіть при збоях cron.
function AutoReorderAgent(): string { $db = \Bitrix\Main\Application::getConnection(); $result = $db->query(" SELECT rs.product_id, rs.reorder_qty, rs.supplier_id, SUM(sp.AMOUNT) AS current_stock FROM bl_reorder_settings rs LEFT JOIN b_catalog_store_product sp ON sp.PRODUCT_ID = rs.product_id WHERE rs.active = 1 GROUP BY rs.product_id, rs.reorder_qty, rs.supplier_id HAVING current_stock < rs.reorder_point AND NOT EXISTS ( SELECT 1 FROM bl_supplier_orders so WHERE so.product_id = rs.product_id AND so.status IN ('pending', 'sent', 'confirmed') ) "); while ($row = $result->fetch()) { SupplierOrderService::create( $row['supplier_id'], $row['product_id'], $row['reorder_qty'] ); } return 'AutoReorderAgent();'; } Чому порогові значення краще рахувати з прогнозом?
Просте фіксоване число не враховує сезонність та тренди. Ми використовуємо середні продажі за 90 днів, множимо на час поставки (lead time) та додаємо 20% страхового запасу. Формула перераховується автоматично раз на тиждень через агент. Результат: точність прогнозу 85–90% та зниження страхового запасу на 30%.
Як виключити дублювання замовлень?
Дублювання — часта проблема самостійної автоматизації. Ми реалізували подвійний захист:
- В SQL-запиті агента — умова
NOT EXISTS(нове замовлення не створюється, поки попереднє в статусіpending,sentабоconfirmed). - Логіка блокування: якщо замовлення не підтверджено постачальником протягом 24 годин, агент не створює повторне, а сповіщає адміністратора.
Також ведеться лог всіх операцій (згідно з рекомендаціями офіційної документації Бітрікс по створенню агентів).
Як ми це робимо: кейс з нашої практики
Наш клієнт — мережа з 15 магазинів автозапчастин з каталогом 80 000 позицій та 200 постачальників. Потрібно було автоматизувати замовлення по API для 10 великих постачальників та по email для решти. Ми спроектували три таблиці:
-
bl_reorder_settings— пороги для товару з прив'язкою до постачальника. -
bl_supplier_orders— історія замовлень зі статусами. -
bl_supplier_shipping_methods— спосіб та конфігурація відправки.
Агент створює запис у bl_supplier_orders, потім SupplierOrderService вибирає адаптер (API/Email/EDI) та відправляє. Після підтвердження постачальником статус оновлюється через вебхук або вручну. При приході товару менеджер створює документ надходження — залишки зростають автоматично.
Результат: менеджери перестали витрачати 3 години на день на замовлення, дефіцит знизився з 12% до 2%. Вартість проекту окупилася за 3 місяці за рахунок скорочення простоїв та термінових доставок.
Що входить в роботу
| Компонент | Опис |
|---|---|
| Аналітика | Збір вимог, аудит поточних залишків та постачальників |
| Проектування | Схема БД, архітектура агента та адаптерів |
| Розробка | Таблиці, агент, класи відправки, адмін-інтерфейс |
| Тестування | Перевірка на дублювання, edge-кейси (нульові залишки, помилки API) |
| Деплой | Налаштування розкладу агента, міграції, документація |
| Навчання | Інструкція для менеджерів по підтвердженню замовлень та приходу |
Орієнтовні терміни: від 5 до 20 днів залежно від кількості постачальників та способів інтеграції. Вартість розраховується індивідуально. Напишіть нам — ми оцінимо проект за 1 день.
Порівняння ручного та автоматичного замовлення
| Параметр | Ручне замовлення | Автоматичне замовлення |
|---|---|---|
| Час на закупівлі на день | 3–4 години | 15 хвилин (контроль) |
| Дефіцит на складі | 12–15% | 2–3% |
| Витрати на термінові доставки | 5–7% від обороту | 0,5–1% |
| Помилки при замовленні | 5–8% | <1% |
Типові помилки при самостійному налаштуванні
- Відсутність блокування повторних замовлень — агент створює нове, поки попереднє не підтверджено. - Поріг без урахування часу поставки — при затримках товар не встигає прийти. - Ігнорування помилок API — замовлення не відправлено, а статус залишився sent. Ми додаємо логування та повторні спроби.Гарантуємо стабільну роботу: після введення в експлуатацію надаємо підтримку на 30 днів. Досвід команди — 10+ років на Бітрікс. Отримайте консультацію та дізнайтеся, як автоматизація закриє ваші проблеми із закупівлями.







