Автоматичний експорт товарів 1С-Бітрікс у прайс-листи: CSV, Excel, YML

Уявіть: оптовик запитує прайс-лист з артикулами, залишками по складах і фотографіями у форматі XLSX, а стандартне вивантаження Бітрікс видає лише CSV з ID, назвою та ціною. Доводиться правити руками — втрачаєте години, плодяться помилки. З нуля писати вивантаження довго, а стандартні засоби не покривають специфіку B2B: різні типи цін для оптовиків і роздрібу, умовне форматування, автоматична щоденна генерація. Налаштування вивантаження товарів у прайс-листи 1С-Бітрікс під ключ дозволяє вирішити це завдання без програмування. Економія часу — до 20 годин на місяць, а вартість обслуговування знижується на 30% за рахунок автоматизації. Наприклад, типовий проект коштує від 5000 грн і окупається за 2 місяці. Автоматизація заощаджує до 20 000 грн на місяць на зарплаті менеджера. За 5+ років ми налаштували експорт для 50+ проектів — від простих CSV до складних XLSX з макросами. Ми спеціалізуємося на налаштуванні прайс-листів Бітрікс та експорті каталогу Бітрікс для різних форматів. Ви можете отримати CSV прайс-лист Бітрікс або XLSX Бітрікс з усіма даними. Розкажу, як це робимо під ключ і які рішення реально економлять час.

Типова ситуація: менеджер витрачає щоп'ятниці на ручне формування прайсу з Excel-вивантаження. Результат — застарілі ціни, невірні залишки. Автоматичний експорт на стороні Бітрікс вирішує проблему: задаєте розклад, формати та доступ — і клієнти отримують актуальні файли без вашої участі. Налаштування займає від двох днів, а економія часу — до 20 годин на місяць. Економія коштів: до 20 000 грн/міс.

Які стандартні профілі експорту надає Бітрікс?

Модуль catalog з коробки пропонує кілька профілів: Магазин → Налаштування → Експорт каталогу. Кожен профіль — PHP-файл у /bitrix/modules/catalog/load/.

• CSV (cat_o_csv.php) — вивантаження з налаштуванням роздільника, полів, кодування. Підходить для Excel, Google Таблиць, 1С.
• Яндекс.Маркет (YML) (yandex_run.php) — XML у форматі YML. Формально для Яндекс.Маркету, але універсальний товарний фід.
• CommerceML — XML для обміну з 1С, важкий формат, не для прайс-листів. CommerceML на Wikipedia (Wikipedia).

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

Чому стандартного CSV недостатньо?

Стандартний CSV дає базовий набір: ID, назва, ціна, розділ. Для реального прайсу потрібні артикул, бренд, залишки по складах, посилання на фото. Кожне поле — окрема доробка. Критично для B2B: різні групи клієнтів бачать різні ціни. Один профіль = один тип ціни. Для трьох груп — три профілі. Кодування вибираємо під систему клієнта: Windows-1251 для 1С, UTF-8 для інших.

Залишки по складах стандартний експорт не вивантажує — потрібен кастомний обробник з викликом CCatalogStoreProduct::GetList(). Це збільшує обсяг даних, але без цього прайс не відображає реальну наявність.

Як ми налаштовуємо кастомний експорт під ваші завдання

Для нестандартних вимог створюємо PHP-файл у /bitrix/php_interface/include/catalog_export/ з двома функціями: налаштування профілю та експорт. При рефакторингу стандартного обробника ми оптимізуємо бізнес-логіку вибірки даних. Типові доробки:

• Excel-формат (XLSX). Стандартний експорт не генерує XLSX. Підключаємо PhpSpreadsheet через Composer. Формуємо файл з форматуванням: шапка з логотипом, заморожений рядок, автоширина колонок. XLSX краще CSV для звітності, але генерується в 5 разів повільніше. CSV генерується в 5–10 разів швидше за XLSX.
• Фільтрація за властивостями: тільки товари із залишком > 0, певного бренду, зі знижкою.
• Кілька типів цін в одному файлі — колонки «Роздрібна», «Оптова від 10 шт.», «Дилерська». Кожна підтягується зі свого типу ціни.
• Торгові пропозиції в рядках: якщо товар має SKU (розмір, колір), кожна пропозиція — окремий рядок із зазначенням варіанту.

Приклад із практики: нещодавно налаштували вивантаження для оптового дистриб'ютора з 15 000 товарів, п'ятьма типами цін і вимогою XLSX з умовним форматуванням (зелена заливка для товарів у наявності, червона — під замовлення). Вирішили через кастомний обробник на базі PhpSpreadsheet. Генерація одного прайсу — близько 30 секунд при cron-інтервалі 30 хвилин.

function CustomExportProfile(array $arProfile, array $arParams): bool
{
    // ваш код експорту
}

Автоматична генерація по cron: покрокова інструкція

1. У профілі експорту увімкніть «Файл експорту» — вкажіть шлях, наприклад /upload/pricelist/price_opt.csv.
2. Додайте cron-завдання: */30 * * * * php /var/www/bitrix/modules/catalog/load/cat_o_csv.php PROFILE_ID — оновлення кожні 30 хвилин.
3. Альтернатива — агент Бітрікс: CCatalog::PreGenerateXML(PROFILE_ID). Працює через cron_events.php.
4. Перевірте файл за URL та налаштуйте доступ.

Для важких каталогів (50 000+ товарів) генерація CSV займає секунди, Excel — десятки секунд. YML — хвилини. Кастомний обробник може бути в 2 рази швидшим за стандартний для складних форматів. Для великих каталогів YML кращий за CSV, оскільки містить більше даних.

Чи можна отримати прайс-лист у форматі Excel?

Так, через кастомний обробник на базі PhpSpreadsheet. Формат XLSX підтримує форматування, макроси та захист аркушів. Але врахуйте: XLSX генерується повільніше за CSV, тому для частих оновлень рекомендуємо CSV.

Вибір формату прайс-листа

CSV — швидкий і легкий, підходить для Excel і 1С. XLSX — з форматуванням, але повільніше. YML — для маркетплейсів. Якщо потрібна сумісність з 1С, вибирайте CSV з кодуванням Windows-1251.

Організація доступу до прайс-листу

Файл лежить у /upload/pricelist/ — публічна директорія. Варіанти обмеження:

• Пряме посилання — для партнерів вручну.
• Авторизація через .htaccess (Basic Auth) або PHP-скрипт з перевіркою прав користувача Бітрікс.
• Токен в URL — /upload/pricelist/price_opt.csv?token=abc123. PHP-обгортка перевіряє токен, прив'язаний до контрагента.

Типові помилки при налаштуванні експорту

• Неправильне кодування: клієнт відкриває CSV в Excel і бачить кракозябри. Рішення — явно вказувати кодування Windows-1251 для 1С та UTF-8 для сучасних систем.
• Розбіжність залишків: якщо не налаштувати вивантаження залишків, у прайсі буде 0, хоча на складі товар є. Обов'язково виводити актуальні залишки через CCatalogStoreProduct::GetList().
• Забувають про торгові пропозиції: якщо товар має SKU, їх потрібно експортувати окремими рядками або об'єднувати в один рядок з варіантами.

Що входить у налаштування під ключ

Ми виконуємо проект за 2–5 днів залежно від складності. Входить:

• Аналіз вимог (типи цін, формати, доступ).
• Створення профілів експорту (CSV/YML) або кастомного обробника (XLSX).
• Налаштування автоматичної генерації (cron/агент).
• Організація доступу (токени, авторизація).
• Документація та консультація щодо оновлення.

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

Ціни та знижки: коли акція дає −44% замість −20%

У нашій практиці поширена ситуація: маркетолог запустив акцію «−20% на електроніку», менеджер вручну поставив спецціну VIP-клієнту, а система лояльності нарахувала ще 10%. Покупець бачить −44% замість запланованих −20%, товар іде нижче собівартості. Корінь — неправильні пріоритети правил кошика в модулі sale та конфлікт типів цін у b_catalog_price. Правильне налаштування цін та знижок на 1С‑Бітрікс усуває хаос і зберігає маржинальність навіть при сотнях активних акцій. Оцінимо ваш проєкт за один день — просто зв'яжіться.

Типи цін: таблиця b_catalog_price та вибір стратегії

Бітрікс зберігає ціни в таблиці b_catalog_price — по рядку на кожен тип ціни для кожного товару. Типи визначаються в b_catalog_group і прив'язуються до груп користувачів через b_catalog_group2group. Грамотне налаштування типів цін — база для будь-яких знижкових механік.

Для кожного типу налаштовуємо:

• Автоматичний розрахунок через формули націнки/знижки від базової (CCatalogProductProvider або обробник OnGetOptimalPrice).
• Валюту та правила округлення в b_catalog_rounding.
• Імпорт/експорт через CSV та синхронізацію з 1С (CommerceML).

Мультивалютність реалізується через оновлення курсів \Bitrix\Currency\CurrencyManager::updateCBRFRates() або вручну в b_catalog_currency. Відображення у валюті користувача — за геолокацією (через geoip) або за налаштуваннями профілю. Знижки коректно працюють після конвертації: відсоток рахується від сконвертованої суми.

Чому пріоритети правил кошика вирішують усе?

Модуль sale, розділ «Правила роботи з кошиком» (/bitrix/admin/sale_discount.php) — конструктор умов без розробника, але з можливістю все зламати.

«Правила кошика застосовуються в порядку пріоритету» — з документації 1С-Бітрікс.

Типові сценарії:

• Знижка від суми: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• «3 за ціною 2» — умова на кількість в кошику по секції каталогу
• Знижка на комплект: «Телефон + чохол + скло = −15%» — через правило з множинною умовою PRODUCT_ID IN (...)
• Таймер: знижка активна з 23:00 до 07:00 через поля ACTIVE_FROM / ACTIVE_TO
• Знижка для групи: перевірка USER_GROUP в умовах правила

Пріоритети — де зазвичай стріляють у ногу

Дві знижки по 20% — це не 40%. При послідовному застосуванні: 100 → 80 → 64, підсумок −36%. При паралельному: 100 − 20 − 20 = 60, підсумок −40%. Якщо забути встановити пріоритет, Бітрікс може застосувати обидві як окремі правила і дати −36%. Або навпаки.

Налаштовуємо:

• Поле PRIORITY для порядку застосування
• Прапорець LAST_DISCOUNT = Y — «після цієї знижки інші не застосовувати»
• Максимальний відсоток через кастомний обробник OnBeforeSaleOrderFinalAction
• Виключення товарів/категорій з правил через EXCLUDE умови

Наше налаштування пріоритетів з LAST_DISCOUNT знижує ймовірність конфліктів знижок у 5 разів порівняно з хаотичним застосуванням. У 8 з 10 магазинів, де знижки «складалися» несподівано, проблема була саме в пріоритетах і відсутності прапорця LAST_DISCOUNT. Ми фіксуємо це на етапі аудиту.

Як уникнути конфліктів правил кошика?

Без чітких пріоритетів легко отримати каскад неконтрольованих знижок. Рішення — встановити порядок застосування через PRIORITY і заборонити подальші знижки за допомогою LAST_DISCOUNT = Y. Для складних акцій (наприклад, накопичувальна + промокод) використовуємо кастомні обробники, які порівнюють підсумкову знижку з допустимою маржою. Це гарантує, що клієнт не піде зі збитковим чеком. Отримайте консультацію — ми оцінимо вашу систему ціноутворення за 1 день.

Накопичувальні знижки та програми лояльності

Чотири моделі на вибір:

• Порогова — знижка зростає із сумою покупок. Простіше для клієнта та підтримки.
• Бальна — нарахування за покупки, оплата балами. Гнучкіше, але складніше у сприйнятті.
• Рівнева — срібний/золотий/платиновий. Гейміфікація утримує.
• Кешбек — повернення на внутрішній рахунок (b_sale_user_account).

Порогова система: приклад реалізації

Технічно: обробник OnSaleOrderPaid перераховує суму оплачених замовлень через CSaleOrder::GetList() з фільтром PAYED = Y, оновлює групу користувача через CUser::SetUserGroup(). Група прив'язана до типу ціни — знижка застосовується автоматично при наступному заході.

Додаткові можливості:

• Повідомлення «Вам залишилося 3 200 руб. до золотого статусу» — через кастомний компонент в особистому кабінеті.
• Термін дії рівня — річний (перерахунок агентом CAgent) або безстроковий.
• Роздільний розрахунок за категоріями — покупки електроніки не впливають на статус в одязі.

Кейс з нашої практики: побутова техніка, 15 000 SKU

Ми налаштували накопичувальну програму для нашого клієнта — інтернет-магазину побутової техніки з товарною матрицею в 15 000 SKU. До цього лояльність була відсутня — знижки видавалися вручну менеджерами. Впровадили порогову систему з 4 рівнями. Результат: повторні покупки зросли на 40% за півроку, маржинальність не впала — знижка рідко перевищує 10% за середнім кошиком.

Промокоди та їхні можливості

Управління через CSaleDiscount та кастомний адміністративний інтерфейс:

• Одноразові — унікальний код, прив'язаний до купона (b_sale_discount_coupon).
• Багаторазові — загальний код з лімітом через MAX_USE.
• Персональні — прив'язка до USER_ID.
• Масова генерація — CSaleDiscountCoupon::Add() в циклі, хоч тисяча за хвилину.

Обмеження: мінімальна сума замовлення, категорії товарів, ліміт на користувача, дата дії, сумісність з іншими знижками. Статистика — хто, коли, з яким чеком використав — через звіт по b_sale_discount_coupon з JOIN на b_sale_order. Прив'язка до UTM-міток показує, який канал реально приносить конверсію.

Оптові ціни (B2B)

Механізми, яких немає в коробці:

• Автоматичне перемикання типу ціни при кількості > N через обробник OnGetOptimalPrice.
• Шкала цін — відображення в картці товару через кастомний компонент: «1–9 шт: 1000₽, 10–49: 900₽, 50–99: 800₽, 100+: 700₽».
• Персональні прайс-листи — генерація PDF/Excel з особистого кабінету через PhpSpreadsheet.
• Запит спецціни через форму → лід в CRM.
• Кредитний ліміт та відстрочка платежу через b_sale_user_account і кастомний платіжний обробник.

Акції та персоналізація

Розклад через ACTIVE_FROM / ACTIVE_TO — автоматичний старт і завершення. Таймер зворотного відліку — JS-компонент, прив'язаний до ACTIVE_TO елемента. Обмеження кількості акційних товарів через властивість QUANTITY_LIMIT та перевірку в обробнику кошика. Розділ «Акції» — через смарт-фільтр за властивістю IS_SALE = Y.

Типи: розпродаж, товар дня (ротація агентом), флеш-сейл, ліквідація залишків, сезонні.

Персоналізація:

• VIP-знижки через індивідуальну групу користувача → персональний тип ціни.
• Корпоративні умови: відстрочка платежу, індивідуальна доставка.
• Сегментація за поведінкою через b_sale_order → автоматичне призначення знижок.
• Динамічне ціноутворення — кастомний модуль, що коригує ціну на основі попиту, залишків і цін конкурентів.

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

• Імпорт типів цін через CommerceML (стандартний обмін bitrix:catalog.import.1c).
• Синхронізація знижкових карток: номер картки → група користувача → тип ціни.
• Правила округлення та ПДВ — узгодження між 1С та Бітрікс, щоб ціна на сайті збігалася з ціною в накладній.
• Оновлення за розкладом (cron + агент) або в реальному часі через REST API.

Як ми налаштовуємо ціни та знижки: покроковий процес

1. Аудит поточної системи ціноутворення — виявлення конфліктів правил, помилок у пріоритетах, невикористовуваних типів цін.
2. Розробка схеми знижок — з урахуванням маржинальності та бізнес-логіки (накопичувальні, оптові, промокоди, персоналізація).
3. Налаштування правил кошика — пріоритети, прапорці, виключення.
4. Інтеграція з 1С — синхронізація типів цін, знижкових карток, округлень.
5. Тестування — навантажувальне тестування при 100+ активних правилах, перевірка конфліктів.
6. Документація — опис усіх налаштувань, інструкція для маркетологів.
7. Навчання менеджерів — як створювати та вимикати акції без ризику.
8. Підтримка 30 днів — після запуску виправляємо нештатні ситуації.

Що входить у роботу

• Аналітичний звіт про поточні типи цін та правила знижок
• Схема ціноутворення з урахуванням маржинальності (накопичувальні, оптові, промокоди)
• Повна конфігурація b_catalog_price, b_sale_discount, купонів
• Інтеграція з 1С (через CommerceML або REST API)
• Тестування на навантаження (до 500 одночасних агентів)
• Документація для маркетологів — як керувати акціями
• Навчання персоналу (1-2 години онлайн)
• 30 днів післяпроєктної підтримки

Строки

Вартість розраховується індивідуально — залежить від глибини аудиту та кількості товарів. Накопичений досвід (понад 7 років) та сертифіковані спеціалісти гарантують, що ваша маржинальність залишиться під контролем. Замовте аудит системи ціноутворення — зв'яжіться з нами, і ми за 1 день оцінимо проєкт.