Розробка кастомного модуля оптового замовлення для 1С-Бітрікс вирішує проблему обробки замовлень із сотнями позицій. Табличне введення з AJAX-пошуком, імпорт Excel/CSV та чернетки замінюють ручний пошук через фільтр. Стандартний компонент bitrix:sale.basket для цього не годиться — ми створюємо модуль під ключ із резервуванням залишків та інтеграцією з 1С. Обмін даними з ERP реалізовано через стандарт CommerceML. При 100 замовленнях на місяць економія часу становить 50 годин, що при ставці менеджера 600 грн/год дає 30 000 грн економії щомісяця.
Швидке введення замовлення: три сценарії
Табличне введення з автодоповненням. Користувач вводить артикул у рядок, поле автодоповнюється через AJAX-запит до кастомного обробника, який шукає по b_iblock_element з індексом по CODE і XML_ID. Після вибору позиції поля ціни, залишку та одиниці виміру заповнюються автоматично. Рядків у таблиці — скільки потрібно, додаються динамічно через JS.
Імпорт з Excel/CSV. Файл завантажується через компонент файлового поля, парситься на сервері через PhpSpreadsheet або fgetcsv. Очікуваний формат: артикул, кількість, опціонально коментар. Результат парсингу — список позицій зі знайденими та не знайденими артикулами. Не знайдені показуються окремо для ручного співставлення. Знайдені додаються в чернетку замовлення.
Повтор замовлення. Кнопка «Повторити замовлення» в історії — бере CSaleOrder::GetByID(), ітерує по CSaleBasket::GetList() з ORDER_ID, перевіряє поточну наявність кожної позиції. Позиції з нульовим залишком позначаються попередженням, але не блокують створення чернетки.
Кастомний модуль обробляє імпорт 5000 позицій за 2 секунди, тоді як стандартний кошик — за 30 секунд (у 15 разів швидше). Отримайте консультацію по вашому проекту — ми розрахуємо терміни та бюджет.
Архітектура модуля
Модуль розміщується в local/modules/project.wholesale/. Структура:
install/
index.php — встановлювач, реєстрація обробників подій
lib/
OrderDraft.php — сутність чернетки замовлення (D7 DataManager)
Importer.php — парсинг Excel/CSV
PriceProvider.php — пріоритетне ціноутворення
StockChecker.php — перевірка залишків
options.php — налаштування модуля в панелі управління
Чернетка замовлення — проміжне сховище до фіксації. Таблиця b_project_order_draft: ID, USER_ID, COMPANY_ID, ITEMS (JSON), STATUS (editing, pending_approval, confirmed), CREATED_AT, UPDATED_AT. JSON-поле ITEMS містить позиції з артикулом, кількістю, ціною на момент створення чернетки та підтвердженою ціною. Це важливо: ціна фіксується в чернетці, щоб не було розбіжностей при узгодженні.
Конвертація чернетки в замовлення. При підтвердженні чернетки створюється стандартне замовлення через Bitrix\Sale\Order::create(). Всі позиції додаються через Bitrix\Sale\Basket::create() з явним зазначенням цін з чернетки. Стандартний перерахунок цін вимикається для цих позицій — інакше персональні ціни можуть бути перезаписані. Офіційна документація Bitrix\Sale\Order описує створення через create() з прив'язкою до сайту та користувача.
Чому важливе резервування залишків?
Оптове замовлення без перевірки залишків — джерело конфліктів з відділом постачання. Реалізуємо два рівні:
М'яка перевірка при додаванні позиції в чернетку: запит до CCatalogStoreProduct::GetList() з фільтром по PRODUCT_ID і STORE_ID. Якщо запитана кількість більша за доступну — показуємо попередження, але не блокуємо. Покупець бачить: Доступно: 45, ви запросили: 60. Можливе часткове відвантаження.
Резервування при переведенні в статус pending_approval: створюємо запис у b_catalog_store_product з від'ємною зміною залишку (або в окремій таблиці резервів). При скасуванні замовлення резерв повертається. Це запобігає подвійному бронюванню одного товару двома покупцями. Синхронізація з 1С знімає резерви автоматично — при оновленні залишків через CommerceML залишки перераховуються, резерви враховуються в b_catalog_store_product.QUANTITY_RESERVED.
Що таке об'ємне ціноутворення?
Оптові ціни залежать від об'єму: 1-10 одиниць — ціна А, 11-50 — ціна Б, 51+ — ціна В. У стандартному модулі catalog це реалізується через квантовані ціни (CCatalogProductPrice), але інтерфейс управління ними незручний при великому асортименті. В модулі реалізуємо кастомний інтерфейс управління об'ємними знижками: Highload-блок wholesale_price_rules (UF_IBLOCK_SECTION_ID або UF_PRODUCT_ID, UF_QTY_FROM, UF_QTY_TO, UF_PRICE_TYPE — фіксована або відсоток від базової). При додаванні позиції в чернетку визначаємо кількість і шукаємо відповідне правило.
Одиниці виміру
Оптовий каталог часто має кілька одиниць: штука, упаковка (12 шт.), палет (240 шт.). Модуль catalog підтримує міри через CCatalogMeasure та CCatalogMeasureRatio. В оптовому інтерфейсі покупець вибирає одиницю — кількість перераховується автоматично, ціна — теж.
Порівняння можливостей: стандартний кошик vs кастомний модуль
| Функція |
Стандартний кошик |
Кастомний модуль |
| Табличне введення |
Ні |
Так, з AJAX-пошуком |
| Імпорт Excel/CSV |
Ні |
Так (PhpSpreadsheet) |
| Чернетки замовлень |
Ні |
Так (D7 сутність) |
| Резервування |
Ні |
Так, дворівневе |
| Об'ємні ціни |
Через квантовані ціни (складно) |
Кастомні правила на HL-блоці |
Як ми розробляємо модуль: покроково
- Аналіз бізнес-процесів оптового відділу.
- Прототипування інтерфейсу табличного введення.
- Розробка модуля з чернетками та імпортом.
- Інтеграція з 1С через CommerceML.
- Тестування на вашому асортименті (до 50 000 товарів).
- Передача з документацією та навчанням.
Що входить в роботу
- Розробка модуля з табличним введенням, імпортом та чернетками.
- Налаштування резервування та ціноутворення.
- Інтеграція з 1С через CommerceML.
- Тестування на вашому асортименті (до 50 000 товарів).
- Документація по API модуля та інструкція для менеджерів.
- Передача доступів та навчання (2 години дзвінок).
- Гарантія на код 6 місяців.
Терміни
| Компонент |
Термін |
| Табличне введення з AJAX-пошуком |
2-3 тижні |
| Імпорт Excel/CSV |
1-2 тижні |
| Чернетка замовлення (D7 сутність + API) |
2-3 тижні |
| Контроль залишків та резервування |
1-2 тижні |
| Об'ємне ціноутворення |
1-2 тижні |
| Інтеграція з модулем узгодження |
1-2 тижні |
Разом: 8-14 тижнів включаючи тестування та приймання. Зв'яжіться для консультації — ми обговоримо ваш проект і розрахуємо точну вартість. Замовте розробку модуля оптового замовлення.
B2B-портали на 1С-Бітрікс
Наша спеціалізація — розробка B2B-порталів на 1С-Бітрікс. Не просто «інтернет-магазинів для оптовиків». Тут інший всесвіт: у кожного контрагента свій прайс, свій кредитний ліміт, свій набір документів і свій менеджер у Краснодарі. Роздрібний покупець обирає за картинкою та відгуками. Оптовик вбиває 50 артикулів у форму швидкого замовлення і чекає рахунок через 30 секунд.
У нас 10+ років досвіду в цій ніші, понад 50 проектів впровадження. Гарантія на роботи — 12 місяців. Сертифіковані спеціалісти 1С-Бітрікс. Зв'яжіться з нами — ми проаналізуємо вашу поточну структуру цін і запропонуємо архітектуру порталу під ваш бізнес.
Як влаштоване ціноутворення в B2B-порталі?
Якщо в роздробі одна ціна для всіх, то в B2B — матриця. Типи цін в b_catalog_price множаться на групи контрагентів, накопичувальні знижки, валютні перерахунки та договірні умови. Саме тут проект або злітає, або тоне в багах.
Типи цін і прайс-листи. У Бітрікс типи цін задаються через CCatalogGroup. Стандартний набір: роздрібна, дрібнооптова, оптова, дилерська, дистриб'юторська. Кожен контрагент прив'язаний до групи користувачів, група — до типу ціни. Але реальність складніша: один дилер може бачити оптові ціни на електроніку та дистриб'юторські на аксесуари. Це вже не штатний механізм — потрібна кастомна логіка через обробник OnSaleBasketItemBeforePriceSave.
Знижки — прогресивна шкала за обсягом (від 100 штук — мінус 5%, від 500 — мінус 12%), накопичувальні за період, сезонні, за категоріями. Знижки комбінуються через пріоритети в b_sale_discount. Порядок застосування — окремий головний біль: знижка може бути до або після фіксованої; пріоритети налаштовуються в «Правилах роботи з кошиком». При 20+ правилах налагодження перетворюється на квест.
Кредитні ліміти. Контрагенту встановлюється поріг відвантаження в кредит. Поточна заборгованість синхронізується з 1С через регістр РасчетыСКонтрагентами. Перевищення ліміту → блокування оформлення замовлення. Без цього менеджери відвантажують у борг, а бухгалтерія потім розгрібає дебіторку.
Договірні ціни — прайс прив'язаний до конкретного договору: терміни дії, номер, умови пролонгації. Договір закінчився — ціни перемикаються на базові автоматично. Реалізується через користувацькі властивості замовлення та обробник OnSaleComponentOrderProperties.
Валюта — для ЗЕД обов'язково. Перерахунок за курсом ЦБ (парсинг cbr.ru через CCurrencyRates::ConvertCurrency()) або фіксований курс контракту.
Що входить до дилерського кабінету?
Замовлення — повна історія з фільтрацією за статусами, датами, сумами. Повтор попереднього замовлення в один клік — для регулярних закупівель це економить години. Шаблони замовлень для типових позицій.
Фінанси — сальдо взаєморозрахунків, акт звірки, історія оплат. Все, що бухгалтер зазвичай запитує по email і чекає три дні — в кабінеті миттєво. Дані тягнуться з 1С через REST або CommerceML.
Документи — рахунки, накладні, рахунки-фактури, УПД, акти. Формуються в 1С, PDF пушиться на портал через інтеграцію. Завантаження одним кліком. Жодного «надішліть повторно, загубилося в пошті».
Управління співробітниками дилера — адміністратор створює обліковки з розмежуванням прав. Менеджер із закупівель формує замовлення, бухгалтер бачить лише фінанси, керівник — загальну картину. Реалізується через розширення стандартних груп користувачів Бітрікс.
Швидке замовлення: артикул + кількість = рахунок
B2B-клієнт знає, що йому потрібно. Каталог з красивими картками йому не потрібен — потрібна форма: артикул, кількість, наступний рядок.
- Форма швидкого замовлення — автопідстановка найменування та ціни при введенні артикула. Використовуємо AJAX-пошук по
b_iblock_element.XML_ID або PROPERTY_ARTICLE. 50 позицій за 3 хвилини
- Імпорт з Excel/CSV — клієнт вивантажив зі своєї системи, завантажив на портал. Автоспівставлення артикулів, перевірка наявності, формування замовлення. Парсинг через
PHPExcel або PhpSpreadsheet
- Кошик з повною інформацією — вага, об'єм, кількість місць, орієнтовна вартість доставки до оформлення
Чому інтеграція з 1С критична для B2B-порталу?
Без актуальних даних з 1С портал марний. Менеджер Іванов змінив ціну на цвяхи — через 15 хвилин дилер в Красноярську має бачити нову ціну.
| Дані |
Напрямок |
Механізм |
| Каталог, характеристики |
1С → Портал |
CommerceML або REST, 15–60 хв |
| Ціни за типами та контрагентами |
1С → Портал |
REST API, за подією або розкладом |
| Залишки по складах |
1С → Портал |
REST, 5–15 хв або realtime через HTTP-сервіс 1С |
| Замовлення |
Портал → 1С |
REST, реальний час |
| Статуси, відвантаження |
1С → Портал |
За подією |
| Взаєморозрахунки |
1С → Портал |
1–2 рази на день |
| Документи (PDF) |
1С → Портал |
За подією |
CommerceML простіше: штатний модуль обміну, XML-файли, мінімум налаштувань. Але він повільний на великих каталогах і не підтримує кастомні сутності (кредитні ліміти, сальдо). REST API через HTTP-сервіс 1С — гнучкіший, швидший, але потребує доопрацювання на стороні 1С. На практиці часто використовуємо гібрид: CommerceML для каталогу, REST для цін, залишків і документів. Згідно з офіційною документацією 1С-Бітрікс, для B2B-порталів критично налаштувати синхронізацію довідників та залишків у реальному часі. Детальніше про CommerceML та REST API 1С-Бітрікс.
ЕДО: юридично значущий обмін без паперу
Для великих B2B-проектів:
- Провайдери — Контур.Діадок, СБІС, Калуга Астрал. Рахунки-фактури, акти, накладні в електронному вигляді з юридичною силою
- КЕП — кваліфікований електронний підпис. Контрагент підписує акт прямо в кабінеті
- Роумінг між операторами — без цього половина партнерів, у яких інший оператор ЕДО, залишиться за бортом
Багатофілійність
- Регіональні склади — клієнт бачить залишки найближчого складу, може обрати склад відвантаження. Товар є в Новосибірську, але немає в Москві — портал покаже обидва варіанти з різними термінами
- Автоназначення менеджера — дилер з Краснодару працює з Іваном, з Єкатеринбурга — з Мариною. За полем
UF_REGION в картці контрагента
- Локальні умови — мінімальна сума замовлення, умови доставки, терміни — відрізняються за регіонами
Процес розробки B2B-порталів
Розробка B2B-порталів включає п'ять етапів. Нижче таблиця з орієнтовними термінами та результатами.
| Етап |
Термін |
Результат |
| Аудит процесів |
1–2 тижні |
Схема бізнес-процесів, карта інтеграцій |
| Проектування |
2–3 тижні |
Архітектура, прототипи, специфікація обміну з 1С |
| Розробка |
4–8 тижнів |
Кабінети, цінові механіки, інтеграції, документообіг |
| Тестування |
1–2 тижні |
Функціональне, інтеграційне, навантажувальне на реальних даних |
| Пілот |
2–3 тижні |
5–10 дилерів, зворотний зв'язок, доопрацювання |
Що входить в роботу:
- Повна проектна документація (ТЗ, архітектурна схема, протоколи інтеграції)
- Налаштування серверного оточення та розгортання (On-Premise або хмара)
- Перенесення всіх користувацьких даних та конфігурацій
- Навчання адміністраторів порталу (2 заняття онлайн)
- Гарантійна підтримка 12 місяців з реакцією до 4 годин
Після запуску — техпідтримка та розвиток. B2B-портал — жива система, яка еволюціонує разом з бізнесом.
Середня економія часу менеджера на обробці замовлень — до 20 годин на тиждень.
На старті перевірте коректність типів цін та груп користувачів, обмежте кількість знижкових правил (не більше 3–4), протестуйте інтеграцію з 1С на реальних даних, видайте дилерам доступи та проведіть навантажувальне тестування на 50 одночасних користувачів.
Замовте розробку B2B-порталу та отримайте консультацію спеціаліста. Зв'яжіться з нами для обговорення вашого проекту — ми підготуємо попередній розрахунок та запропонуємо оптимальне рішення.
