Уявіть: інтернет-магазин з 10 000 товарів, прайс від постачальника надходить щоденно о 6 ранку. Ручне оновлення займає 3 години, і до 10 ранку ціни вже застарілі, якщо постачальник змінює їх о 8. Автоматизація вирішує цю проблему: заплановане оновлення через cron знижує затримку до хвилин і виключає помилки введення. Ми автоматизуємо синхронізацію цін із зовнішніх джерел у 1С-Бітрікс — від парсингу прайсів до контролю аномалій. Наш досвід показує, що правильне налаштування окупається за кілька тижнів. Ми маємо багаторічний досвід в інтеграціях 1С-Бітрікс із зовнішніми системами та реалізували понад 50 проєктів з автоматизації цін. Оцінимо ваш проєкт після розгляду вимог.
Як налаштувати оновлення цін за розкладом у 1С-Бітрікс?
Джерела даних про ціни
Постачальники віддають ціни в різних форматах. Порівняємо їх:
| Формат | Спосіб отримання | Складність | Надійність |
|---|---|---|---|
| CSV/Excel | FTP, посилання, email | Низька | Середня |
| XML (YML, CommerceML) | HTTP, FTP | Середня | Висока |
| REST API | HTTP-запити | Висока | Висока |
| 1С-вивантаження | CommerceML | Середня | Висока |
Для кожного формату потрібен свій обробник, але логіка оновлення цін у Бітрікс однакова. Парсинг через API в 10 разів надійніший за ручне введення — він виключає людський фактор.
Структура цін у Бітрікс
Ціни зберігаються в таблиці b_catalog_price. Ключові поля: PRODUCT_ID, CATALOG_GROUP_ID, PRICE, CURRENCY. Для оновлення ціни через API:
\Bitrix\Catalog\PriceTable::update($priceId, [ 'PRICE' => $newPrice, 'CURRENCY' => 'USD', ]); Bitrix Documentation: PriceTable API
Алгоритм оновлення
Крок 1. Завантаження прайсу. Скрипт забирає файл з FTP (ftp_get()), завантажує за URL (file_get_contents()) або запитує API постачальника.
Крок 2. Парсинг. CSV парситься через fgetcsv(), Excel — через PhpSpreadsheet, XML — через SimpleXMLElement. Результат — масив пар «ідентифікатор товару → ціна».
Крок 3. Маппінг. Артикул постачальника зіставляється з елементом каталогу Бітрікс. Пошук за властивістю PROPERTY_SUPPLIER_ARTICLE або XML_ID:
$element = CIBlockElement::GetList(
[],
['IBLOCK_ID' => $catalogIblockId, 'PROPERTY_ARTICLE' => $supplierArticle],
false,
['nTopCount' => 1],
['ID']
)->Fetch();Крок 4. Оновлення. Запис нової ціни в b_catalog_price. При оновленні тисяч товарів використовуйте прямі SQL-запити або батчеве оновлення через D7 — поелементне оновлення через CPrice::SetBasePrice() занадто повільне.
Націнки та формули
Постачальник віддає закупівельну ціну. Роздрібна розраховується за формулою:
- Фіксована націнка: роздрібна = закупівельна × 1.3 (30%).
- Прогресивна: націнка залежить від діапазону цін (дешеві товари — 50%, дорогі — 15%).
- Округлення:
ceil($price / 10) * 10 - 1→ ціна 1 287 → 1 289.
Формули націнки зберігаються в конфігурації, а не зашиваються в код. Це дозволяє менеджеру змінювати правила через адміністративний інтерфейс.
| Діапазон закупівлі | Націнка | Приклад |
|---|---|---|
| До $4–6 | 50% | 300 → $4–6 |
| $5–50 | 30% | 2 000 → $23–34 |
| Понад $45–65 | 15% | 10 000 → $100–150 |
Cron-налаштування
Оновлення цін запускається по cron:
# Завантаження прайсу постачальника А — щоденно о 6:00
0 6 * * * /usr/bin/php /home/bitrix/scripts/update_prices.php --source=supplier_a >> /var/log/price_update.log 2>&1
# Завантаження прайсу постачальника Б — щоденно о 6:30
30 6 * * * /usr/bin/php /home/bitrix/scripts/update_prices.php --source=supplier_b >> /var/log/price_update.log 2>&1Розносьте оновлення за часом — паралельний запуск кількох імпортів навантажує базу та може призвести до дедлоків.
Чому важливий контроль аномальних змін?
Сліпе оновлення цін небезпечне. Помилка в прайсі постачальника (ціна 100 замість 10 000) призведе до збитків. Механізми захисту:
- Поріг зміни — якщо ціна змінилася більш ніж на 30%, не оновлювати автоматично, а позначити для ручної перевірки.
- Логування — таблиця
price_update_logз полями: товар, стара ціна, нова ціна, джерело, дата. Дозволяє відкотити помилкове оновлення. - Сповіщення — email або Telegram-сповіщення менеджеру при аномаліях.
$changePercent = abs($newPrice - $oldPrice) / $oldPrice * 100;
if ($changePercent > 30) {
logAnomaly($productId, $oldPrice, $newPrice, $source);
continue; // Пропускаємо оновлення
}Скидання кешу після оновлення
Після масового оновлення цін необхідно скинути кеш каталогу, інакше користувачі побачать старі ціни:
\Bitrix\Iblock\ElementTable::getEntity()->cleanCache(); BXClearCache(true, '/catalog/'); Для сайтів з композитним кешем додатково викличте \Bitrix\Main\Composite\Engine::deleteAllCache() або точкове скидання сторінок змінених товарів.
Процес роботи та що входить
Ми використовуємо перевірену методологію:
- Аналітика — вивчаємо джерела даних постачальників, структуру прайсів, формат.
- Проєктування — розробляємо архітектуру обробників, правила маппінгу та націнок.
- Реалізація — пишемо код завантаження, парсингу та оновлення цін, налаштовуємо cron.
- Тестування — перевіряємо на тестовому каталозі, імітуємо аномалії.
- Деплой — запускаємо в бій, налаштовуємо моніторинг та сповіщення.
Комплекс робіт включає:
- Аналіз джерел даних та форматів.
- Розробка парсерів для кожного джерела.
- Налаштування маппінгу артикулів та формул націнок.
- Реалізація механізмів контролю (пороги, логування, сповіщення).
- Налаштування cron-завдань та моніторингу.
- Документація та інструкції для менеджера.
- Гарантія коректної роботи протягом місяця.
Зв'яжіться з нами — допоможемо налаштувати оновлення цін під ключ. Отримайте консультацію по вашому проєкту. Замовте оцінку — ми проаналізуємо ваші джерела та запропонуємо оптимальне рішення.
