Послуги з розробки маркетплейсів на 1С-Бітрікс

Розробка маркетплейсів на 1С-Бітрікс

Почнемо з того, що ламає більшість проєктів: таблиця b_sale_order та пов'язані з нею b_sale_basket не розраховані на мультивендорність із коробки. У Бітріксі немає штатного модуля «маркетплейс» — щоразу це кастомна розробка поверх модуля sale. Ми пишемо окремий модуль, який розширює стандартний кошик: додає прив'язку товару до постачальника через властивість замовлення, розбиває одне замовлення на субзамовлення за продавцями та маршрутизує кожне окремо.

Моделі маркетплейсів

Класичний маркетплейс — оператор не тримає склад. Уся товарна логіка лежить на продавцях, майданчик займається трафіком і платіжним шлюзом. Технічно це окремий інфоблок постачальників зі зв'язком через UF_VENDOR_ID у highload-інфоблоці каталогу.

Гібридна модель — оператор продає нарівні із зовнішніми постачальниками. Головний біль: ранжування в каталозі. Якщо постачальники бачать, що картки майданчика завжди вище — вони йдуть. Ми вирішуємо це окремим компонентом сортування, де позиція визначається рейтингом, швидкістю відвантаження та ціною, без привілеїв для «своїх».

Маркетплейс послуг — заявки, тендери, ескроу. Тут замість b_sale_basket працює кастомна сутність заявки з воркфлоу через бізнес-процеси Бітрікс.

B2B-маркетплейс — договори, акти звірки, кредитні лінії, EDI. Зовсім інший світ: авторизація за ІПН, мультицінові групи через b_catalog_group, ліміти відвантаження.

Моделі монетизації

Кабінет продавця

Кабінет — серце маркетплейсу. Незручний кабінет = порожній майданчик. Стандартного рішення немає, пишемо з нуля на компонентах Бітрікс.

• Управління каталогом — CRUD товарів через кастомний компонент, масове завантаження CSV/XML через CIBlockXMLFile. Вручну вбивати 10 000 SKU ніхто не стане, тому імпорт — перше, що робимо.
• Обробка замовлень — субзамовлення потрапляють у кабінет через ajax-polling або websocket. Підтвердження, друк накладних через CSalePdf, оновлення статусу зі зворотною синхронізацією в основне замовлення.
• Фінансова аналітика — дашборд на highload-інфоблоці агрегованих даних. Виручка, комісії, виплати — деталізація за товарами та періодами. Продавець бачить, що продається, а що просто займає вітрину.
• Налаштування доставки — власні тарифи продавця, прив'язка до sale.delivery.handler.
• Комунікація — вбудований чат без розкриття контактів. Реалізуємо через модуль im або кастомну таблицю повідомлень.
• Акції — знижки, промокоди через b_sale_discount з фільтром за vendor_id.

Модерація та контроль якості

Одна партія контрафакту вбиває репутацію майданчика. Тому модерація — не «nice to have», а обов'язковий шар.

• Модерація товарів — статус ACTIVE='N' до проходження перевірки. Автомодерація відсікає очевидне (заборонені слова, відсутність фото), ручна розбирає спірне. Обробник OnBeforeIBlockElementUpdate не дає обійти.
• Верифікація продавців — перевірка ІПН через API ДПС, завантаження сканів документів. Статуси: новий → перевірений → преміум. Кожен рівень відкриває ліміти за кількістю товарів та комісіями.
• Рейтингова система — не просто зірки. Алгоритм враховує швидкість відправлення (AVG(ship_date - order_date)), відсоток повернень, якість відповідей на запитання.
• Антифрод — виявляємо накрутку рейтингів за патернами (одна IP, однакові тексти, аномальна частота). Дублювання облікових записів ловимо за ІПН та банківськими реквізитами.

Система виплат продавцям

Фінансовий модуль — те, заради чого продавці приходять на майданчик.

• Розрахунок комісії — обробник на зміну статусу замовлення. Комісія залежить від категорії, статусу продавця, поточних умов. Зберігається в окремій таблиці vendor_transactions.
• Періодичні виплати — cron-завдання формує реєстр: щотижня, двічі на місяць або щомісяця. Мінімальна сума виплати, холдування до підтвердження отримання.
• Акти та звітність — генерація PDF актів через PhpOffice\PhpSpreadsheet, автоматична нумерація, завантаження в один клік.
• Холдування — кошти утримуються до події OnSaleStatusOrder зі статусом «Отримано». Зменшує суперечки та повернення.
• Виплати через банківські API — ЮKassa, CloudPayments, прямі банківські API. Продавець отримує кошти без дзвінків і нагадувань.

Технологічний стек

• 1С-Бітрікс «Бізнес» або «Ентерпрайз» — модуль sale + catalog як фундамент. Мультивендорна обв'язка — кастомні модулі.
• Highload-інфоблоки — каталоги понад 100 000 SKU. Звичайні інфоблоки за таких обсягів падають на фільтрації: CIBlockElement::GetList з десятком властивостей починає генерувати JOIN-и на десятки таблиць b_iblock_element_prop_sNN. Highload вирішує це плоскою структурою.
• Elasticsearch — повнотекстовий пошук. Користувач пише «кросівки найк» — знаходить «Nike кросівки». Штатний пошук Бітрікса на великих каталогах неприйнятно повільний.
• Черги — імпорт каталогів, розрахунок виплат, генерація звітів. Агенти Бітрікс (CAgent) для легких завдань, окрема черга через RabbitMQ або supervisor + кастомний CLI для важких.

Галузеві маркетплейси

Кожна ніша — свої підводні камені:

• Будматеріали — розрахунок доставки великогабаритних вантажів. Палети, тоннаж, підйом на поверх. Звичайний калькулятор доставки не справляється, пишемо кастомний sale.delivery.handler.
• Продукти харчування — терміни придатності у властивостях інфоблоку, температурний режим, слоти доставки «день у день». Помилка в логістиці = списання.
• Автозапчастини — підбір за VIN через laximo API, крос-номери, оригінали та аналоги. Окремий головний біль — різні терміни постачання від різних продавців на одну деталь.
• Одяг — розмірні сітки (EU/US/UA), високий відсоток повернень. Логіка обробки повернень з перерозподілом комісії — окремий пласт.
• Промислове обладнання — B2B з тендерами, запитами КП. Картка товару з 50+ параметрами в табличному вигляді.

Терміни та етапи

Намагатися запустити все одразу — надійний спосіб не запустити нічого.

1. Бізнес-модель (2-3 тижні) — модель монетизації, MVP-скоуп. Відсікаємо 80% побажань, які не потрібні на старті.
2. Проєктування (3-4 тижні) — UX, прототипи вітрини та кабінетів, архітектура БД.
3. MVP (2-3 місяці) — каталог, реєстрація продавців, замовлення, базова модерація. Перші реальні продажі.
4. Пілот (2-3 тижні) — перші продавці, тестові покупки, навантажувальне тестування через ab або k6.
5. Масштабування (постійно) — нові фічі за фідбеком, оптимізація запитів, горизонтальне масштабування.

MVP за 3-4 місяці. Повнофункціональна платформа — 6-12 місяців ітеративної розробки.