Оптові покупці працюють зі своїми прайс-листами та специфікаціями в Excel. Вони хочуть взяти готову таблицю «артикул — кількість», завантажити її на сайт і одразу отримати кошик. Без цього функціоналу менеджер витрачає годину на ручне введення, робить помилки, і клієнт іде до конкурента з більш зручним сайтом. Стандартний Бітрікс не включає інструментів для читання Excel — необхідна кастомна реалізація. Наше рішення — модуль завантаження замовлень з Excel під ключ, адаптований під ваші бізнес-процеси та формати файлів. Це виключає рутину, скорочує операційні витрати на десятки тисяч гривень щомісяця та знижує навантаження на менеджерів.
Як працює завантаження замовлення з Excel?
Завантаження складається з кількох етапів: парсинг файлу на сервері, детектор заголовків, резолвінг артикулів та додавання в кошик. Розглянемо кожен крок з реальним кодом.
Парсинг Excel на сервері
Для читання .xlsx файлів використовується бібліотека PhpSpreadsheet (наступник PHPExcel). Підключається через Composer:
composer require phpoffice/phpspreadsheet
AJAX-контролер обробки файлу:
public function uploadAction(): array
{
$file = $_FILES['excel_file'];
if (!$file || $file['error'] !== UPLOAD_ERR_OK) {
return ['status' => 'error', 'message' => 'Файл не завантажено'];
}
$allowedMimes = [
'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet',
'application/vnd.ms-excel',
];
if (!in_array($file['type'], $allowedMimes)) {
return ['status' => 'error', 'message' => 'Невірний формат файлу'];
}
$reader = \PhpOffice\PhpSpreadsheet\IOFactory::createAutomatic(
\PhpOffice\PhpSpreadsheet\IOFactory::identify($file['tmp_name'])
);
$spreadsheet = $reader->load($file['tmp_name']);
$sheet = $spreadsheet->getActiveSheet();
$rows = $sheet->toArray();
return $this->processRows($rows);
}
Логіка розбору рядків
Формат файлу клієнта непередбачуваний: шапка може бути в першому або другому рядку, колонки — в будь-якому порядку. Реалізуємо детектор заголовків:
private function processRows(array $rows): array
{
// Шукаємо рядок-заголовок за ключовими словами
$headerRow = null;
$articleCol = null;
$quantityCol = null;
foreach ($rows as $i => $row) {
foreach ($row as $j => $cell) {
$cell = mb_strtolower(trim((string)$cell));
if (in_array($cell, ['артикул', 'арт', 'article', 'sku', 'код'])) {
$articleCol = $j;
$headerRow = $i;
}
if (in_array($cell, ['кількість', 'кіл-ть', 'qty', 'quantity', 'кіл'])) {
$quantityCol = $j;
}
}
if ($headerRow !== null) break;
}
// Якщо заголовок не знайдено — припускаємо: колонка 0 = артикул, колонка 1 = кількість
$articleCol = $articleCol ?? 0;
$quantityCol = $quantityCol ?? 1;
$dataStart = ($headerRow ?? -1) + 1;
$items = [];
for ($i = $dataStart; $i < count($rows); $i++) {
$article = trim((string)($rows[$i][$articleCol] ?? ''));
$qty = (float)str_replace(',', '.', $rows[$i][$quantityCol] ?? 1);
if ($article !== '') {
$items[] = ['article' => $article, 'quantity' => max(1, $qty)];
}
}
return $this->resolveArticles($items);
}
Повний код детектора заголовків
Цей метод перебирає рядки, шукає клітинки з ключовими словами ('артикул', 'sku', 'qty' тощо) і визначає позиції колонок. Якщо заголовок не виявлено, використовується припущення по першій колонці та другій.
Резолвінг артикулів
Після парсингу отримуємо масив артикулів. Резолвимо їх пакетним SQL-запитом — це в 10-15 разів швидше, ніж N окремих запитів:
private function resolveArticles(array $items): array
{
$articles = array_column($items, 'article');
// Шукаємо у властивостях торгових пропозицій
$placeholders = implode(',', array_fill(0, count($articles), '?'));
$rs = $connection->query(
"SELECT ie.ID, iep.VALUE AS ARTICLE, ie.IBLOCK_ELEMENT_ID AS PRODUCT_ID
FROM b_iblock_element ie
JOIN b_iblock_element_property iep ON iep.IBLOCK_ELEMENT_ID = ie.ID
WHERE iep.IBLOCK_PROPERTY_ID = ? AND iep.VALUE IN ($placeholders)",
array_merge([$articlePropertyId], $articles)
);
// ...
}
Чому пакетний запит швидше?
При імпорті 1000 рядків виконання 1000 окремих SELECT-запитів створює колосальне навантаження на базу даних. Пакетний запит з одним WHERE IN знижує час резолвінгу з десятків секунд до часток секунди. У наших проектах це дає прискорення в 10–15 разів на каталогах від 10 000 товарів.
Прев'ю перед додаванням до кошика
Після завантаження файлу користувач бачить таблицю з результатами:
| Артикул з файлу |
Знайдений товар |
Кількість |
Ціна |
Статус |
| ABC-123 |
Болт М8×20 |
100 |
2.50 грн |
Знайдено |
| XYZ-999 |
— |
5 |
— |
Не знайдено |
| DEF-456 |
Гайка М8 |
50 |
1.20 грн |
Немає на складі |
Клієнт може скоригувати кількість, прибрати не знайдені позиції та натиснути «Додати до кошика». Додавання — те ж пакетне \Bitrix\Sale\Basket з попереднього сценарію.
Шаблон для завантаження
На сторінці завантаження розміщуємо посилання на завантаження шаблону Excel — файл з правильними заголовками колонок. Генерується через PhpSpreadsheet або зберігається як статичний файл у /upload/templates/order_template.xlsx.
Чому варто довірити розробку нам?
Ми спеціалізуємося на Бітріксі понад 10 років, реалізували десятки інтеграцій з Excel для оптових замовлень та виконали понад 50 успішних проектів у цій сфері. Наші рішення проходять навантажувальне тестування на каталогах до 100 000 товарів. Гарантуємо стабільну роботу та підтримку після впровадження.
Кейс: дистриб'ютор будівельних матеріалів (наш клієнт, з нашої практики)
Ситуація: 300+ корпоративних клієнтів, кожен зі своєю таблицею замовлення, менеджери витрачали 2–3 години на день на введення позицій вручну.
Реалізація:
- Детектор формату: розпізнає 7 варіантів шапок (артикул, код, SKU, арт та ін.)
- Підтримка
.xlsx та .xls (через PhpSpreadsheet)
- Обмеження: максимум 1 000 рядків за завантаження, файл до 5 МБ
- Прев'ю з можливістю редагування кількості
- Автоматичне зіставлення по
XML_ID якщо артикул не знайдено у властивості
Результат: менеджери звільнили 2+ години на день, клієнти розміщують замовлення самостійно. Економія: зниження витрат на обробку замовлень до 70% (близько 15 000 грн щомісяця). Весь функціонал був впроваджений за 8 робочих днів.
| Етап |
Термін |
| Налаштування PhpSpreadsheet, завантаження файлу |
1 день |
| Парсер з детектором заголовків |
2 дні |
| Резолвінг артикулів, пакетний запит |
1 день |
| Прев'ю-таблиця з редагуванням |
2 дні |
| Пакетне додавання до кошика |
1 день |
| Тестування на реальних файлах клієнтів |
1 день |
Що входить у розробку?
- Завантажувач файлів
.xlsx/.xls з валідацією формату
- Парсер з авто визначенням заголовків та позицій колонок
- Пакетний резолвінг артикулів по
b_iblock_element_property
- Прев'ю результатів з можливістю корекції перед додаванням до кошика
- Пакетне додавання знайдених товарів до кошика
\Bitrix\Sale\Basket
- Шаблон Excel для завантаження
Особливі випадки: коли потрібен кастомний парсер
Якщо ваші клієнти надсилають файли з нестандартною структурою — плаваючими заголовками, різними кодуваннями або додатковими колонками — стандартний імпорт Бітрікса не впорається. Тільки кастомний парсер з детектором формату забезпечить коректне завантаження.
Оцінимо ваш проект за один робочий день — зв'яжіться з нами, щоб обговорити деталі. Ми підготуємо комерційну пропозицію з точними термінами та вартістю. Замовте розробку модуля, і ми протягом дня підготуємо оцінку.
Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії
Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.
sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.
Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.
Чому однокроковий чекаут збільшує конверсію?
Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:
- Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
- Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
- Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
- Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
- Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.
Під капотом:
- Повний AJAX — жодного перезавантаження. Компонент працює через
Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
- Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска
inputmask + серверна перевірка.
- Збереження даних при випадковому відході —
sessionStorage зберігає введене, при поверненні все на місці.
- Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
- Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.
Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.
Як відновити покинуті кошики?
Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.
Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.
Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.
Гостьове замовлення: убити обов'язкову реєстрацію
«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.
- Покупка без акаунта — оформлюємо через
CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
- Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
- Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
- Авторизація прямо в чекауті: SMS-код замість пароля — через
Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.
Крос-сел: допродажі, які не дратують
У кошику
Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.
Управління через адмінку
Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.
Промокоди: правильна реалізація
| Тип |
Механізм у Бітрікс |
Нюанс |
| Фіксована знижка |
CSaleDiscount, тип «на замовлення» |
Обмежити мінімальну суму — інакше знижка може бути завеликою порівняно із замовленням |
| Відсоткова |
CSaleDiscount, умова «купон» |
Максимальна знижка — задати стелю, інакше при замовленні на велику суму знижка може бути надто високою |
| Безкоштовна доставка |
Правило кошика + прив'язка до служби доставки |
Працює тільки з конкретними службами — не можна дати безкоштовну «будь-яку» |
| Подарунок |
Автододавання товару в кошик через обробник |
Товар-подарунок має бути в наявності, інакше кошик зламається |
UX промокоду:
- Поле видно, але не кричить — не відволікає тих, у кого коду немає.
- Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
- Знижка видна в підсумковому розрахунку окремим рядком.
- Можна прибрати промокод і застосувати інший.
UX-оптимізація: дрібниці, які вирішують
Десктоп:
- Прогрес-бар — користувач бачить, де він.
- Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою
b_sale_order).
- Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
- Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.
Мобільні:
- Великі кнопки — палець не промахується.
min-height: 48px за гайдами Google.
- Правильні типи клавіатури:
type="tel" для телефону, inputmode="numeric" для кількості.
- Кнопка «Оформити» зафіксована внизу —
position: sticky.
- Згорнуті секції — екранний простір на 375px дорогий.
Обробка помилок:
- «Перевірте номер картки» замість «Payment processing error».
- Автопрокрутка до першої помилки —
scrollIntoView({ behavior: 'smooth' }).
- «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.
Інтеграції
-
DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
-
Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
-
НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
-
LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
-
CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
-
Склад — перевірка залишків через
CCatalogStoreProduct::GetList() у реальному часі.
Приклад AJAX-запиту для розрахунку доставки
// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
$promises[] = async(function() use ($tariff, $basket) {
return $tariff->calculate($basket);
});
}
$results = awaitAll($promises, 3000);
Що входить у роботу
- Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
- Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
- Розробка компонента чекауту на основі
Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
- Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
- Налаштування промокодів, крос-селу, покинутих кошиків.
- Тестування на реальних сценаріях: десктоп, мобільні, планшети.
- Передача документації (опис API, інструкції для менеджерів, доступи).
- Навчання співробітників роботі з новим кошиком.
- Пост-релізна підтримка — 2 тижні моніторингу та правок.
Строки
| Задача |
Строк |
| Оптимізація поточного чекауту |
1–2 тижні |
| Однокроковий чекаут з нуля |
3–5 тижнів |
| Система промокодів |
1–2 тижні |
| Крос-сел у кошику |
1 тиждень |
| Механізм покинутих кошиків |
2–3 тижні |
| Комплексна переробка |
6–10 тижнів |
Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.