Каталог — це те, що ви продаєте; замовлення — те, що у вас купують. Elbuz уміє забирати не лише товари, а й замовлення напряму з маркетплейсів і систем через API. Тоді всі продажі з різних майданчиків стікаються в одне місце — у документи Elbuz, — і ви обробляєте їх централізовано, не перемикаючись між кабінетами й не переписуючи замовлення руками.
Ця стаття — груповий огляд усіх підключень, які приносять замовлення, і докладний опис того, що саме відбувається із замовленням під час завантаження. Про завантаження товарів дивіться окремий огляд імпорту каталогу через API, а про завантаження даних загалом — огляд завантаження.
Звідки беруться замовлення
Замовлення в Elbuz приходять із двох типів джерел. По-перше, це ті самі каталожні інтеграції, що вміють і товари, і замовлення: Rozetka, Shopify, WooCommerce, Amazon, eBay, Allegro, eMAG. У них замовлення вмикаються тим самим підключенням — окремим перемикачем у шаблоні (докладніше — у статтях відповідних площадок і в огляді каталогу через API).
По-друге, є системи, які приносять тільки замовлення й каталогом не займаються: маркетплейси Kaspi.kz, Prom.ua (сімейство EVO), Епіцентр, Forte KZ, ceneo.pl, а також кас-система (POS) dotykacka. Саме про них ця стаття. Товари з них у каталог не тягнуться — приходять лише як рядки самих замовлень.
Де це у програмі
У вікні імпорту ви створюєте шаблон і обираєте потрібну систему зі списку. Далі вводите ключ доступу (найчастіше це один токен) і вмикаєте завантаження замовлень. Один шаблон — одне підключення до одного акаунта; під різні акаунти чи майданчики заводять окремі шаблони. Порядок для всіх систем однаковий, тож нижче описано спільну частину, а для найбільших — Kaspi та Prom — є окремі детальні статті.
Що відбувається із замовленням крок за кроком
Хоч майданчики різні, далі всі замовлення проходять один і той самий конвеєр усередині Elbuz. Розуміти його корисно: саме тут стає зрозуміло, чому покупець «приклеївся» до наявного контрагента, звідки взявся номер документа й чому в одному замовленні може не вистачати позицій.
- Замовлення забираються з майданчика — новими або зміненими, від місця, де зупинилися минулого разу.
- Шукається покупець серед ваших контрагентів; якщо не знайшовся — створюється новий.
- Позиції зіставляються з каталогом — кожен рядок замовлення шукає свій товар.
- Статуси перекладаються у ваші: статус замовлення, оплати, доставки, тип оплати.
- Створюється документ «замовлення покупця» зі своїм номером за вашою нумерацією.
- Записуються позиції документа, номер накладної (ТТН), вага й одиниці виміру.
- Замовлення потрапляє на дошку (воронку) відповідно до свого статусу.
Як знаходиться покупець
Перш ніж створити нового контрагента, Elbuz намагається впізнати наявного — інакше база швидко заросла б дублями одного й того самого покупця. Для порівняння адреса й телефон приводяться до спільного вигляду: регістр не враховується, від телефону береться тільки цифрова частина (тож +38 (050) 123-45-67 і 380501234567 — це один номер), а у скриньок Gmail не враховуються крапки в імені та все після «плюса» — тому ivan.petrenko+shop@gmail.com і ivanpetrenko@gmail.com вважаються однією людиною.
Приведення до спільного вигляду відбувається тільки під час порівняння. У картці контрагента й у самому замовленні зберігається та адреса, яку вказав покупець, — з крапками й регістром. Це важливо: саме на неї підуть ваші листи.
Далі покупець шукається послідовно, і перший збіг зупиняє пошук:
| Крок | За чим шукаємо |
|---|---|
| 1 | за поштою |
| 2 | за телефоном |
| 3 | за Telegram |
| 4 | за ідентифікатором покупця в цьому ж джерелі (прив'язка, створена минулими завантаженнями) |
| 5 | за зовнішнім ідентифікатором контрагента в картці |
Якщо покупця не знайдено, створюється новий контрагент: ім'я береться з компанії (а якщо її немає — з імені та прізвища), заповнюються телефон, пошта, місто й адреса, і одразу створюється прив'язка до цього джерела — щоб наступного разу той самий покупець упізнався за нею, навіть якщо змінить пошту. Коли в замовленні немає жодного ідентифікатора покупця, Elbuz будує його сам із пошти й телефону — це також захищає від дублів.
Деякі сайти підставляють у замовлення «в один клік» власну адресу магазину — тоді всі такі замовлення злиплися б в одного контрагента. Для цього є загальні списки винятків: перелічені в них адреси та номери телефонів у пошуку контрагента ігноруються. Якщо помітили, що замовлення чіпляються не до тих покупців, — почніть перевірку саме з цього.
Як позиції знаходять товар у каталозі
Кожен рядок замовлення теж проходить пошук — від найнадійнішого способу до найзагальнішого:
| Крок | За чим зіставляємо позицію |
|---|---|
| 1 | за прив'язкою товару до цього джерела (створюється, коли ви вантажите каталог) |
| 2 | за внутрішнім кодом товару (uuid) |
| 3 | за контрольним відбитком товару |
| 4 | за артикулом разом із назвою |
| 5 | за самою лише назвою |
Якщо товар із рядка замовлення не знайшовся в каталозі, він не губиться: Elbuz створює для нього картку. Категорія береться з самого замовлення — за назвою категорії або її зовнішнім кодом. Але деякі джерела (зокрема Kaspi та Prom) категорію в рядку замовлення взагалі не передають, і тоді спрацьовує запобіжник: система заводить службову категорію з назвою виду «Товари — джерело — назва підключення» і складає такі позиції туди. Ця категорія створюється прихованою й виключеною з вивантажень, щоб напівпорожні картки випадково не поїхали на ваші канали продажу.
Картка, створена з рядка замовлення, містить лише те, що було в замовленні: назву, артикул, ціну й кількість — без опису, фото й характеристик. Тому час від часу зазирайте в службову категорію: знайдені там товари варто перенести у правильну гілку каталогу й дозаповнити, або зіставити з уже наявними картками.
Саме тому для майданчиків, які вміють і каталог, і замовлення, правильний порядок такий: спершу завантажте каталог, потім вмикайте замовлення. Тоді в кожного товару вже є прив'язка до джерела, позиції зіставляються з першого кроку — точно й без випадкових збігів за назвою, — а службова категорія не наповнюється дублікатами того, що у вас і так є.
Знайденому товару позиція успадковує вагу з картки, якщо в замовленні її немає, а одиниця виміру визначається за назвою; коли одиницю розпізнати не вдалося, підставляється штука. Це важливо для документів доставки: вага потрібна для розрахунку відправлення.
Статуси і їх зіставлення
У кожного майданчика свої назви статусів замовлення (новий, на підтвердженні, доставляється, виконано, скасовано). Elbuz зводить їх до власних статусів, щоб замовлення з різних джерел виглядали однаково. Зіставлення шукається у три заходи: спершу за кодом зовнішнього статусу, потім за його назвою, а далі — за правилами, де в одному рядку через кому перелічено кілька зовнішніх статусів, які мають зводитися до одного вашого.
Так само окремо зіставляються статус оплати, статус доставки, види оплат і види доставки — це різні таблиці відповідності, і кожна налаштовується своєю кнопкою в картці «Пов'язані налаштування» у формі шаблону: «Статуси замовлення», «Статуси доставки», «Статуси оплати», «Види оплат», «Види доставки» (вони є у Kaspi, Prom, Forte та у каталожних площадок на кшталт Rozetka). Якщо для якогось зовнішнього статусу відповідності не знайдено, замовлення не втрачається: воно отримує статус за замовчуванням. Побачивши, що всі замовлення приїжджають з одним і тим самим статусом, перевірте саме таблицю зіставлення — найчастіше в ній просто немає потрібного рядка.
1
Статуси замовлення2
Статуси оплати- Кнопка «Статуси замовлення» відкриває окно зіставлення статусів замовлень маркетплейсу зі статусами Elbuz.
- Кнопка «Статуси оплати» відкриває окно зіставлення статусів оплати.
Разом зі статусами в документ переносяться й службові дані доставки: якщо майданчик віддав номер накладної, він лягає у відповідне поле служби (Нова пошта, Justin, Укрпошта — кожна у своє), і замовлення одразу можна відстежувати з Elbuz.
Два статуси одного замовлення: ваш і майданчика
У кожного завантаженого замовлення насправді два статуси, і плутати їх не варто:
- Ваш статус — колонка «Статус» у списку замовлень і статус у картці документа. Його веде менеджер: підтвердив, комплектує, відвантажив.
- Статус на майданчику — те, що про це замовлення думає Rozetka, Prom чи Kaspi. Він показується в сусідній колонці «Статус документа (сайт)».
Обидві колонки стоять поруч у списку замовлень, тож розбіжність видно одразу — без заходу в кабінет маркетплейсу. На прикладі нижче менеджер ще не брав замовлення в роботу (у нас «Новий»), а майданчик тримає його в очікуванні:
1
Статус документа (наш)2
Статус документа (сайт)- Статус документа — внутрішній статус, яким керує менеджер (тут «Новий»).
- Статус документа (сайт) — статус на майданчику, наприклад «Очікування» у Kaspi.
Колонки в списку розташовані широко, тому «Статус документа (сайт)» може опинитися за правим краєм — прокрутіть таблицю вправо. Якщо колонки немає зовсім (наприклад, ви давно налаштували список під себе), увімкніть її в «Налаштуванні колонок» вікна — там вона є завжди.
Хто кого перезаписує: розбір сценаріїв
Замовлення одночасно живе у двох системах, і змінювати його можуть обидві сторони. Щоб робота менеджера не зникала після чергового завантаження, діє просте правило: ваш статус змінюється лише тоді, коли статус на майданчику справді змінився з моменту минулої загрузки. Ось як це виглядає на практиці.
| Що сталося | Що буде після наступного завантаження |
|---|---|
| Майданчик змінив статус, ви замовлення не чіпали | Ваш статус оновиться відповідно до зіставлення — це нормальний хід синхронізації |
| Ви змінили статус, майданчик — ні | Ваш статус залишиться. Завантаження його не чіпає |
| Ви поставили «Обробляється», а з майданчика прийшла оплата | Статус замовлення залишиться ваш, а статус оплати оновиться з майданчика — це різні поля, вони не конфліктують |
| Ви перевели в «Комплектується», а покупець скасував замовлення на майданчику | Скасування переважить: майданчик справді змінив статус, і це важливо знати. Далі замовлення знову ведете ви |
| Замовлення вже проведене (підписане) | Не змінюється взагалі — проведений документ завантаження не чіпає |
Ключовий момент останнього рядка таблиці про скасування: майданчик перебиває ваш статус тільки в момент своєї зміни, і рівно один раз. Наступні завантаження вже не повертатимуть його назад — ви спокійно ведете замовлення далі своїми статусами, поки на майданчику знову щось не зміниться.
Щоб оновлення програми не переписало статуси заднім числом, у першому ж запуску Elbuz лише запам'ятовує поточний стан замовлень на майданчику й нічого не змінює. Правило вище починає діяти з наступного завантаження. Тож якщо після оновлення ви не побачили жодних змін у статусах — так і задумано.
Для майданчиків, які вміють приймати статус назад (наприклад, Rozetka), працює й зворотний бік: коли ви рухаєте замовлення у себе, відповідний статус вирушає на майданчик. Повторно те саме не відправляється, і власна відправка не повертається до вас відлунням — Elbuz пам'ятає, що саме він уже передав.
Розклад і оновлення
Усі ці системи працюють поллінгом: Elbuz сам звертається до них за розкладом і забирає свіжі замовлення. Вебхуків (коли майданчик миттєво штовхає замовлення до вас) для них немає — тому важливий саме розклад. Частоту обирають за оборотом: активному магазину має сенс перевіряти замовлення часто, кільканадцять разів на день; спокійному — рідше.
Щоб не тягнути одне й те саме двічі, Elbuz веде інкремент: запам'ятовує дату й номер останнього завантаженого замовлення (їх видно у формі шаблону, у розділі додаткових налаштувань) і наступного разу бере лише те, що з'явилося після. Крім того, кожен документ зберігає ідентифікатор замовлення на майданчику — за ним повторне завантаження впізнає вже наявне замовлення й оновлює його замість створення копії. Перше ж підключення забирає замовлення за розумний період назад, тож історія не губиться.
Кожен запуск лишає слід у журналі: скільки замовлень завантажено, скільки оновлено, чи були помилки. Перші кілька разів варто туди зазирати — так одразу видно, якщо, наприклад, ключ протух або майданчик тимчасово недоступний.
Які системи приносять замовлення
Нижче — системи, з яких Elbuz забирає саме замовлення. Для найбільших заведено окремі статті з їхніми ключами й особливостями; для решти вистачає спільного порядку, описаного тут.
| Система | Що це і що потрібно |
|---|---|
| Kaspi.kz | маркетплейс №1 у Казахстані; потрібен токен із кабінету продавця |
| Prom.ua (EVO) | маркетплейс №1 в Україні, сімейство EVO; потрібен токен кабінету |
| Епіцентр | маркетплейс epicentrk.ua; потрібен токен із кабінету продавця |
| Forte KZ | маркетплейс Forte Market (Казахстан); потрібен API-ключ |
| ceneo.pl | майданчик у Польщі; потрібен ключ доступу (обмінюється на токен) |
| dotykacka | каса/POS (продажі офлайн-точки як замовлення); потрібні ID інстансу й токен |
Перелік у самому вікні імпорту може бути ширшим за цей і поповнюється. Каталожні майданчики (Rozetka, Shopify та інші) у цю таблицю не внесені навмисно — вони приносять замовлення своїм же підключенням, описаним у їхніх статтях.
Підключення ПриватБанку (Автоклієнт) стоїть поруч у списку, але приносить не замовлення, а банківські надходження — виписку по рахунку, з якої створюються платіжні документи. Це окрема тема (звірка оплат), не імпорт замовлень, тож у цьому огляді ми його не розглядаємо.
Навіщо зводити замовлення в Elbuz
Коли ви продаєте на кількох майданчиках, замовлення розкидані по різних кабінетах, і легко щось проґавити або відвантажити те, чого немає. Звівши їх у Elbuz, ви отримуєте одну чергу обробки: усі продажі в одному місці, з єдиними статусами, зі списанням зі складу й обліком контрагентів. Менеджеру не треба тримати десяток вкладок — він працює з одним списком замовлень, звідки б вони не прийшли.
Перш ніж ставити шаблон на частий розклад, зробіть одне пробне завантаження й перевірте кілька замовлень: чи правильно приїхали позиції, суми, покупець і статус. Переконались, що зіставлення статусів вас влаштовує, — тоді вмикайте регулярне оновлення.
Що далі із завантаженими замовленнями
Завантажити замовлення — це початок. Далі вони живуть у Elbuz як документи «замовлення покупця», і з ними працюють як зі звичайними замовленнями: підтверджують, резервують і списують товар зі складу, оформлюють доставку й друкують документи, ведуть покупця в базі контрагентів. Якщо ви тільки починаєте знайомство з системою, орієнтуйтеся на загальну карту дій — з чого почати і куди рухатися: там показано, як влаштований увесь робочий цикл в Elbuz.
Коли підключень кілька, усі замовлення сходяться в один список незалежно від майданчика, і менеджер обробляє їх однаково. Це і є сенс зведення продажів в одну систему: не перемикатися між кабінетами, а працювати з єдиною чергою — з передбачуваними статусами, складом і документами. А ті майданчики, що вміють ще й каталог, можна під'єднати повністю — і товари, і замовлення (див. огляд каталогу через API).
Часті питання
Чи потрібно спершу завантажити каталог, щоб тягнути замовлення?
Формально це різні перемикачі, і замовлення можна вмикати окремо: рядки замовлень не губляться — для невідомих товарів створюються картки, а якщо джерело не передає категорію, вони складаються у приховану службову категорію. Але на практиці каталог краще завантажити першим: тоді в кожного товару є прив'язка до джерела, позиції зіставляються точно, і ви не отримуєте пачку напівпорожніх карток-дублікатів.
Чому замовлення приклеїлося до чужого покупця?
Покупець шукається за поштою, телефоном, Telegram і прив'язкою до джерела. Найчастіша причина — сайт підставляє в замовлення власну пошту магазину або спільний номер: тоді всі замовлення сходяться до одного контрагента. Такі адреси й номери додають у списки винятків, і пошук перестає їх враховувати.
Замовлення приходять миттєво?
Для цих систем — ні, вони працюють поллінгом: Elbuz забирає замовлення за розкладом. Тому для активного магазину варто поставити частіший розклад. Миттєвий прийом (вебхук) у системі є лише для окремих інтеграцій, як-от Shopify.
Чому всі замовлення приїжджають з одним статусом?
Це ознака того, що зовнішній статус не знайшов відповідності: у такому разі замовлення отримує статус за замовчуванням. Перевірте таблицю зіставлення статусів у формі шаблону — найімовірніше, потрібного рядка в ній просто немає. Окремо зіставляються статус замовлення, статус оплати, статус доставки й тип оплати.
Чи затре завантаження статус, який поставив менеджер?
Ні. Ваш статус змінюється лише тоді, коли статус на майданчику справді змінився з моменту минулої загрузки. Якщо менеджер перевів замовлення у свій статус, а на майданчику нічого не відбулося, чергове завантаження його не чіпатиме. Проведені (підписані) документи не змінюються взагалі.
Де подивитися, який статус стоїть на майданчику?
У списку замовлень поруч із колонкою «Статус» є колонка «Статус документа (сайт)» — вона показує статус так, як його бачить маркетплейс. Колонки широкі, тож її може знадобитися прокрутити вправо; якщо її немає зовсім, увімкніть у «Налаштуванні колонок» вікна.
Повторне завантаження задвоїть замовлення?
Ні. Elbuz веде інкремент за датою й номером останнього замовлення, а кожен документ зберігає ідентифікатор замовлення на майданчику — за ним уже завантажене замовлення впізнається й оновлюється, а не дублюється.
Можна підключити кілька майданчиків одразу?
Так. Під кожен акаунт заводиться окремий шаблон зі своїм ключем і розкладом, а всі замовлення стікаються в одну чергу обробки в Elbuz.