SalesDrive — українська CRM для інтернет-торгівлі: у ній менеджери обробляють заявки, дзвонять покупцям, оформлюють доставку й друкують ТТН. Elbuz підключається до неї з іншого боку: веде каталог і залишки, а заявки забирає до себе, щоб продажі, склад і документи зійшлися в одному місці.
Це підключення відрізняється від інших тим, що працює двома каналами одночасно: заявки приходять миттєво вебхуком, а каталог і залишки завантажуються з YML-експорту SalesDrive. Спільні правила приймання замовлень описано в огляді імпорту замовлень через API; тут — про SalesDrive.
Де це у програмі
У вікні завантаження створіть шаблон і оберіть тип «CRM SalesDrive». У картці «Підключення» три поля, і кожне відповідає за свій канал:
| Поле | За що відповідає |
|---|---|
| Посилання API | YML-експорт товарів із SalesDrive — каталог і залишки |
| Кабінет SalesDrive | Субдомен вашого кабінету (наприклад mycompany) — потрібен для завантаження замовлень по API |
| API-ключ | Ключ для читання заявок — історія замовлень і добір змінених |
Окремо у формі є поле з адресою вебхука: Elbuz генерує її сам, вам лишається скопіювати (достатньо клацнути по полю) і вставити в налаштування SalesDrive.
1
Посилання на YML-експорт — каталог і залишки2
Поле «Кабінет SalesDrive» — субдомен3
Поле «API-ключ» — для завантаження замовлень- Посилання на YML-експорт товарів із кабінету SalesDrive використовується для завантаження каталогу і залишків.
- У полі «Кабінет SalesDrive» вказується субдомен облікового запису, наприклад mycompany.
- API-ключ потрібен для завантаження історії замовлень через API.
Де що взяти в кабінеті SalesDrive
| Де | Що зробити |
|---|---|
| SalesDrive | «Установки» → «Товари/Послуги» → «Експорт YML» — скопіювати посилання на експорт |
| Там само | «Установки» → «Інші сервіси» → «Webhook» — вставити адресу вебхука з Elbuz |
| Там само | «Установки» → «Інші сервіси» → «API» — створити ключ із правами «Заявки — читання» |
| Elbuz | Вікно завантаження → ваш шаблон «CRM SalesDrive» → картка «Підключення» |
Elbuz забирає заявки й нічого не змінює в CRM, тож ключу вистачає прав читання заявок. Не видавайте інтеграції зайвих прав — це загальне правило безпеки, і тут воно нічого не коштує.
Як підключити крок за кроком
Створіть шаблон типу «CRM SalesDrive» і збережіть його — адреса вебхука з'являється саме для збереженого шаблону. Вставте посилання на YML-експорт, субдомен кабінету й API-ключ, скопіюйте адресу вебхука й пропишіть її в налаштуваннях SalesDrive. Порядок тут зручніший такий: спершу запустіть завантаження каталогу, щоб товари вже були в Elbuz, і лише потім вмикайте заявки.
Причина проста: коли каталог на місці, позиції заявок одразу знаходять свої картки, а не створюють напівпорожні дублікати. Перші заявки перевірте очима — склад, суму, покупця, службу доставки — і заповніть таблиці зіставлення статусів, якщо бачите, що всі документи приїхали з однаковим статусом.
Вебхук: заявки без затримки
Більшість підключень у Elbuz працюють поллінгом — програма періодично питає майданчик, чи є новини. SalesDrive — один із випадків, коли працює вебхук (так само приймаються замовлення з Shopify і Wix): CRM сама стукає в Elbuz, щойно заявка створена або змінена. Заявка з'являється в Elbuz за секунди, а не за розкладом.
Адреса вебхука містить секретний ключ, який Elbuz генерує при першому відкритті форми шаблону, — саме за ним він розуміє, у який шаблон класти заявку. Тому адресу не варто публікувати десь, окрім налаштувань самої CRM.
Обидва канали пишуть заявки з однаковими ознаками джерела, тому одна й та сама заявка, що приїхала й вебхуком, і плановим завантаженням, не подвоюється: Elbuz упізнає її за внутрішнім ID заявки SalesDrive і працює з тим самим документом. Практично це означає: вебхук ловить поточний потік, а планове завантаження добирає те, що могло загубитися (наприклад, поки Elbuz був недоступний), і переносить історію при першому підключенні.
Повторний прогін поверх ваших правок
Та сама заявка приїжджає до Elbuz не один раз: спершу вебхуком, потім її може принести планове завантаження, а після зміни в CRM — знову вебхук. Документ при цьому завжди один: програма шукає його за внутрішнім ID заявки SalesDrive у парі з кодом джерела salesdrive, і обидва канали пишуть цей код однаково. Далі важливо, що станеться з полями, які менеджер уже правив руками.
Не змінюється ніколи. Сума документа, ПІБ покупця, телефон, пошта, коментар, місто, адреса, номер відділення й номер ТТН записуються в момент створення документа — повторний прогін їх не переписує. Так само він не чіпає склад документа: назви, ціни й кількості в рядках лишаються ваші, навіть якщо в CRM їх потім змінили.
Накладна, виписана в SalesDrive уже після того, як заявка приїхала, у документ не потрапить: номер ТТН, місто й адреса беруться з заявки лише при створенні документа. Якщо ТТН у вас оформлює менеджер CRM, номер доведеться вписати в документ руками. Те саме з сумою й позиціями: додали товар у заявку на боці SalesDrive — у документі Elbuz нічого не зміниться.
Приймається з CRM. Спосіб оплати, служба доставки й статус доставки — поля, якими володіє SalesDrive, і планове завантаження приводить їх до того, що сказала CRM. Статусу оплати заявка SalesDrive не передає, тому оновлення його в документі не змінює. Робить це планове завантаження, коли в блоці «Розширене» вже стоїть дата в полі «Завантаження замовлень починаючи з дати (РРРР-ММ-ДД)», і вебхук про зміну статусу заявки. Поруч із вашим статусом Elbuz зберігає ще й статус самої заявки: його видно в колонці «Статус документа (сайт)» у списку замовлень.
Ваш статус змінюється лише тоді, коли статус змінився в CRM. Програма порівнює код, що прийшов, із тим, який вона бачила минулого разу, і чіпає ваш статус тільки при розбіжності. Перевели документ у свій статус, а в SalesDrive усе лишилось як було — ваш статус вціліє. Загальний розбір сценаріїв «хто кого перезаписує» — в огляді завантаження замовлень.
Незіставлений статус нічого не псує. Якщо для статусу замовлення чи статусу оплати в таблиці зіставлення немає рядка, програма не запише в документ порожнє замість наявного — там лишиться те, що вже стоїть. А от вид оплати й вид доставки порожніми не бувають: не знайшовши рядка зіставлення, програма підбирає їх за назвою, що прийшла з CRM, а коли й це не вдалося — ставить значення за замовчуванням.
Оновлення обходить проведені документи: у проведеного завантаження не змінює жодного поля — ні статус, ні оплату, ні доставку. Ознаку видно в колонці «Статус проводки (підписи)». Тож коли заявка відпрацьована і ви не хочете, щоб CRM у ній ще щось рухала, — проведіть документ.
Між каналами тут теж є різниця. Вебхук про нову заявку вже наявного документа не змінює: він лише створює документ, якого ще немає. А вебхук про зміну статусу в CRM оновлює наявний документ за тими самими правилами, що й планове завантаження. А перше перенесення історії по API — коли поля «Завантаження замовлень починаючи з ID» і «Завантаження замовлень починаючи з дати (РРРР-ММ-ДД)» у блоці «Розширене» порожні — наявних документів не чіпає взагалі: воно тільки додає заявки, яких у вас ще немає.
І те, про що питають найчастіше: таблицю зіставлення статусів заповнили пізніше, ніж приїхали перші заявки, — уже завантажені документи від цього не переграються. Зіставлення застосовується в момент приймання заявки, тож старим документам статус міняють руками, а таблиця працює вже для наступних.
Що приходить у заявці
| Дані SalesDrive | Поле документа в Elbuz |
|---|---|
| зовнішній номер заявки | Номер документа |
| дати створення й зміни | Дата замовлення, дата зміни |
| ім'я, по батькові, прізвище контакту | ПІБ покупця |
| телефон і пошта контакту | Телефон, e-mail |
| сума до сплати | Сума документа |
| коментар | Опис замовлення |
| статус заявки | Статус документа (через зіставлення) |
| спосіб оплати | Вид оплати (через зіставлення) |
| служба доставки, статус ТТН | Вид доставки, статус доставки |
| номер ТТН, місто, адреса, відділення | Дані доставки |
| позиції: назва, артикул, ціна, кількість | Рядки документа |
Статуси заявки, види оплат і служби доставки приходять кодами SalesDrive. Зіставити їх зі своїми довідниками можна кнопками в картці «Пов'язані налаштування» у формі шаблону — це різні таблиці: окремо статуси замовлення, окремо статуси доставки, оплати й види оплат.
Якщо в заявці на позицію задано знижку — у відсотках чи сумою, — Elbuz перераховує ціну рядка одразу, з урахуванням цієї знижки. Тому ціна позиції в Elbuz може відрізнятися від «базової» ціни товару: це та ціна, за якою реально продано.
Каталог і залишки
Товари з SalesDrive приходять не по API, а звичайним YML-фідом: ви вставляєте посилання на експорт із кабінету, і Elbuz читає його так само, як будь-який інший XML-прайс. Це зручно тим, що фід можна відкрити в браузері й побачити на власні очі, що саме віддає CRM.
Головна користь цього каналу — зіставлення позицій. У заявці SalesDrive у кожної позиції є поле «ID товару/послуги», і саме туди потрапляє ідентифікатор з фіда. Коли каталог і заявки приходять з одного джерела, позиції зіставляються з вашими картками автоматично, без здогадок за назвою.
Каталог із фіда лягає в базовий каталог — у ті самі товари, з якими ви працюєте у вікні «Товари», а не в прайс-листи постачальників. Картка впізнається за ідентифікатором оферу з фіда: збігся — оновлюються залишок, ціна, категорія, артикул, назва й опис; не збігся — заводиться нова картка. Що саме тягнути з фіда, крім самих товарів, вмикають галочками в секції «Що завантажувати»: «Завантажувати атрибути», «Завантажувати фото», «Заповнювати довідник виробників».
Один запуск шаблону робить обидві роботи по черзі: спершу читає YML-фід, потім іде по API за заявками. Порожнє поле посилання означає «каталог не вантажити», порожній API-ключ — «заявки не вантажити», і кожну частину можна лишити вимкненою.
Далі каталог сам нікуди не поїде. Завантаження наповнює базовий каталог і на цьому зупиняється; щоб товари й ціни доїхали на вашу вітрину або на майданчик, потрібне окреме «Вивантаження даних» зі своїм шаблоном і розкладом — ланцюжок цілком описано в огляді завантаження каталогу через API.
Чого не стало у фіді
Позиція зникла з YML-експорту SalesDrive — за замовчуванням із її карткою в Elbuz не відбувається нічого. Вона лишається в каталозі з останньою відомою ціною й останнім відомим залишком: не деактивується, залишок не обнуляється, у журналі про неї немає жодного рядка. Оновлюються тільки ті картки, які у фіді були. Тому зняті з продажу позиції прибирають руками — інакше вони тихо висять зі старими цифрами й потрапляють у вивантаження.
Змінює це галочка «Видаляти записи в базовому каталозі, яких немає в завантаженому файлі» в секції «Що завантажувати». Для цього підключення вона справді працює — каталог тут приходить фідом, — але наслідки в неї важкі.
Товар видаляється фізично, разом з описами, фото, характеристиками й зв'язками з категоріями; категорії, яких немає у фіді, видаляються так само. І головне: відбір не звужений до товарів цього джерела, тож під видалення потрапляє весь базовий каталог — зокрема те, що ви завели руками або завантажили з іншого підключення. Вмикати її має сенс лише тоді, коли фід SalesDrive — єдине наповнення вашого каталогу.
На вже завантажені заявки це не впливає: рядок документа зберігає назву, артикул, ціну й кількість власними полями, тож документ лишається читабельним, навіть якщо картки товару в каталозі більше немає.
Ліміти й розклад
API SalesDrive має жорсткі обмеження: близько 10 запитів на хвилину, 100 на годину і 1000 на добу. Elbuz їх поважає — заявки він забирає сторінками по 100 штук і витримує між сторінками паузу 6 секунд, — але це означає, що масове завантаження історії йде неквапливо. Розклад планового завантаження тримайте консервативним: не частіше ніж раз на 15 хвилин. Поточний потік усе одно ловить вебхук, тож частіше й не треба.
Як побачити, що прогін відпрацював
Журнал завантаження відкривається в Центрі операцій — правій панелі, яка не блокує роботу: картку шаблону можна закрити, прогін від цього не зупиниться.
У журналі стоять числа, і кожне означає своє.
| Рядок журналу | Що він означає |
|---|---|
| «SalesDrive: сторінка замовлень 2 із 5, завантажено всього: 200» | скільки сторінок API вже прочитано і скільки заявок з них розібрано |
| «Отримано замовлень: 100» | скільки заявок принесла ця сторінка — разом і нових, і вже відомих |
| «Всього замовлень завантажено: 12» | скільки з них стало новими документами; решта вже була в базі |
| «Всього товарів завантажено: 3» | скільки карток довелося завести під позиції, яких не знайшлося в каталозі |
| «SalesDrive: помилка API — …» | червоний рядок із текстом відмови від CRM; прогін на ньому зупиняється |
| «Завантаження даних завершено!» | кінець прогону, поруч — витрачений час |
Якщо всі заявки на сторінці вже були в базі, рядка «Всього замовлень завантажено» не буде зовсім — це нормально й означає «нового нічого».
У списку замовлень приймання підтверджують колонки «Джерело: назва» (назва вашого шаблону) і «Джерело (код)» зі значенням salesdrive. Поруч корисні ще чотири: «№ документа (сайт)» — номер заявки в CRM, «ID документа зовнішній (рядок UUID)» — її внутрішній ідентифікатор, за яким документ і впізнається при повторному прогоні, «Дата додавання (джерело)» і «Дата оновлення (джерело)» — дати самої заявки, а не моменту завантаження. Немає потрібної колонки — увімкніть її в налаштуванні колонок вікна.
Заявку, що прийшла вебхуком, шукають там само: картки операції з підсумком вебхук не показує, про його роботу свідчить сама поява документа в списку.
Якщо прогін обірвався
Заявки не чекають кінця прогону. Сторінка на 100 заявок читається з API й одразу пишеться в базу, і одразу ж зсувається позначка «докуди дійшли» — поля «Завантаження замовлень починаючи з ID» і «Завантаження замовлень починаючи з дати» в блоці «Розширене» картки шаблону. Тому обрив ділить роботу надвоє: прочитані сторінки вже лежать документами, до решти справа не дійшла.
1
Починаючи з ID2
Починаючи з дати- «Починаючи з ID» — докуди дійшло завантаження заявок.
- «Починаючи з дати» — з неї планове завантаження бере змінені заявки.
Повтор безпечний. Заявка, яка вже стала документом, упізнається за своїм ID і другого документа не створює — ні того ж дня, ні через тиждень. Тож найпростіша реакція на обрив — просто запустити завантаження ще раз.
Скільки програма чекає CRM: 30 секунд на з'єднання і до 120 секунд на відповідь. Не дочекалася або отримала відмову — у журналі з'являється червоний рядок «SalesDrive: помилка API —» з текстом причини, і прогін зупиняється на цьому місці; повторних спроб у цього підключення немає. Кнопка зупинки в журналі на заявках спрацьовує між сторінками: поточну сторінку програма дочитує й записує, а наступну вже не бере.
Заповнений ключ без кабінету дає свій рядок: «SalesDrive: вкажіть кабінет і API-ключ для завантаження замовлень». А якщо порожній сам API-ключ, заявки просто не вантажаться, і в журналі про них не буде жодного рядка — прогін мовчки зробить тільки каталог.
Якщо завантажили не те
Найчастіший привід — перший прогін із незаповненими таблицями зіставлення: заявки приїхали, але всі з одним статусом. Лікується це не перезавантаженням, а відбором і видаленням.
У списку замовлень відфільтруйте «Джерело (код)» за значенням salesdrive і додайте відбір за «Дата додавання» — вийде рівно те, що це підключення завело в конкретний день. Виділіть рядки й видаліть пачкою. Одразу після видалення з'являється повідомлення «Видалено документів: N» із кнопкою «Скасувати», яка повертає всю пачку цілком, разом із рядками. Пропустили момент — та сама пачка лежить у «Кошику документів» (бургер-меню вікна) 30 днів, звідти її теж можна відновити.
Проведені документи пачка не забере: у відповідь прийде «Проведені документи не видалено (N). Спершу скасуйте проведення». Це навмисно — видалення проведеного не відкотило б ні оборот контрагента, ні резерв.
Після видалення заявки самі назад не приїдуть: позначка «докуди дійшли» вже зсунута, і наступне завантаження почне з неї. Щоб перезалити той самий період, очистіть у блоці «Розширене» поля «Завантаження замовлень починаючи з ID» і «Завантаження замовлень починаючи з дати», збережіть шаблон і запустіть завантаження заново — тоді заявки приїдуть уже через заповнені таблиці зіставлення.
Вимкнути шаблон чи зняти вебхук
У шапці картки шаблону є пілюля «Активний» / «Вимкнений», а в секції приймання заявок — галочка «Використовувати вебхуки». Вони вимикають різне.
1
Пілюля стану «Вимкнений»- Пілюля стану: «Вимкнений» знімає шаблон із розкладу й зупиняє приймання вебхука.
| Що зробили | Що перестає працювати |
|---|---|
| Перевели пілюлю у «Вимкнений» | планувальник більше не бере цей шаблон, і вебхук теж перестає прийматися: заявку від SalesDrive Elbuz не запише |
| Зняли «Використовувати вебхуки» | вебхук не приймається, розклад працює як раніше |
| Прибрали API-ключ | заявки по API не тягнуться, каталог із фіда вантажиться |
| Прибрали посилання на YML-експорт | каталог не вантажиться, заявки приймаються |
Коли шаблон вимкнений або галочка знята, Elbuz на звернення CRM не відповідає нічим і нічого не пише в журнал: з боку SalesDrive відправка виглядає вдалою, а заявки в Elbuz немає. Тому після вимкнення шаблону дивіться в список замовлень, а не у звіт вебхуків на боці CRM.
Увімкнули назад — усе повертається: ключі, галочки, розклад і адреса вебхука лишаються на місці, її не треба переставляти в CRM. Заявки, які SalesDrive намагався віддати за час простою, вебхук повторно не пришле, але їх добере завантаження по API: воно бере заявки, змінені після дати в полі «Завантаження замовлень починаючи з дати».
Ручний запуск — окрема історія: кнопка завантаження працює й на вимкненому шаблоні. Пілюля знімає шаблон із розкладу, а не блокує запуск руками.
Службові контрагенти й категорії
Приймання заявок саме заводить дві речі, яких ви не створювали.
Покупці. Кожна заявка шукає контрагента за поштою, потім за телефоном, потім за ідентифікатором контакту SalesDrive — і заводить нового в групі «Клієнт», якщо нікого не знайшла. Якщо в заявці є контакт SalesDrive, а пошти й телефону немає, програма теж заводить нового контрагента й прив'язує його до ID цього контакту. Службовому контрагенту «Кінцевий споживач» дістається лише заявка без контакту, пошти й телефону: він створюється один раз і далі приймає всі такі документи.
Категорія під невідомі позиції. Якщо товар із рядка заявки не знайшовся в каталозі, Elbuz заводить під нього картку й кладе її в службову категорію з назвою «Товари - salesdrive - назва вашого шаблону». Вона створюється вимкненою і без участі у вивантаженнях, тож такі товари самі собою нікуди не поїдуть. Повторно категорія не дублюється: наступний прогін знаходить її за назвою і кладе картки туди ж.
Прибирати це можна, але з двома застереженнями.
- Контрагент спершу йде в кошик. Картка з бази нікуди не дівається, і нова заявка з тією ж поштою чи телефоном знову знайде саме її. Повне видалення контрагента рядків документів не ламає: сам документ, його позиції, суми й ім'я покупця в ньому лишаються, зникає лише посилання на картку контрагента.
- Видалення категорії забирає з собою товари, для яких вона основна, — разом з описами, фото й характеристиками. Тому спершу перенесіть потрібні картки у свої категорії й лише потім видаляйте службову. Рядки вже завантажених документів не постраждають у будь-якому разі: назву, артикул, ціну й кількість документ зберігає власними полями. А нову службову категорію наступний прогін створить знову, щойно в заявці трапиться невідомий товар.
Видалений «Кінцевий споживач» теж повернеться сам: програма заводить його заново, щойно приїде заявка без контакту, пошти й телефону.
Сценарії
Заявки з CRM — у документи, каталог ведете в Elbuz самі
Заповніть «Кабінет SalesDrive» і «API-ключ», поле «Посилання API» лишіть порожнім, адресу вебхука пропишіть у SalesDrive, а в картці «Приймання замовлень (Webhook)» поставте галочку «Використовувати вебхуки». Запуск шаблону тоді не читає фід, а лише завантажує заявки по API, а нові заявки з вебхука стають документами продажу. Каталог при цьому не оновлюється. Позицію заявки програма шукає у ваших картках за назвою разом з артикулом, потім за самою назвою; не знайшла — заводить картку в службовій категорії «Товари - salesdrive - назва шаблону», яка створюється вимкненою й без участі у вивантаженнях.
Перенести історію заявок при підключенні
Заповніть «Кабінет SalesDrive» і «API-ключ», поля «Завантаження замовлень починаючи з ID» і «Завантаження замовлень починаючи з дати (РРРР-ММ-ДД)» у блоці «Розширене» лишіть порожніми й запустіть шаблон. Заявки приходять сторінками по 100 з паузою 6 секунд між сторінками, кожна сторінка пишеться в базу до запиту наступної, а поля «Розширене» заповнюються самі. Наявних документів цей прогін не змінює: він лише додає ті заявки, яких у вас ще немає. Потрібна історія не з початку — впишіть у поле «Завантаження замовлень починаючи з ID» внутрішній ID заявки SalesDrive, до якої включно переносити не треба, а поле дати лишіть порожнім: прогін почне з наступної.
Статуси й оплата з CRM доходять у документ, а менеджер веде свій статус
У картці «Пов'язані налаштування» заповніть таблиці «Статуси замовлення» й «Статуси доставки», увімкніть вебхук і розклад планового завантаження. Коли заявка в CRM змінюється, вебхук про зміну статусу або планове завантаження оновлює в документі оплату й доставку, а ваш статус — лише якщо статус у самій CRM став іншим, ніж минулого разу. Сума, склад, покупець і номер ТТН при цьому лишаються такими, якими документ створився. Проведених документів оновлення не чіпає зовсім.
Каталог Elbuz повністю дзеркалить фід SalesDrive
Вставте посилання на YML-експорт у «Посилання API» і в секції «Що завантажувати» поставте галочку «Видаляти записи в базовому каталозі, яких немає в завантаженому файлі». Товари, яких немає у фіді, видаляються фізично разом з описами, фото й характеристиками, так само видаляються категорії, яких у фіді немає. Під видалення потрапляють і картки, які ви завели руками. Уже завантажені документи від цього не псуються: рядок документа зберігає назву, артикул, ціну й кількість власними полями.
Часті труднощі
Перша — заявки не приходять вебхуком. Перевірте, що адресу скопійовано повністю, разом із ключем на кінці, і що вона прописана в налаштуваннях SalesDrive, а не збережена десь у документі. Адреса генерується для конкретного шаблону, тож із чужим ключем заявка просто не знайде, куди їй лягти.
Друга — позиції не зіставляються з каталогом. Майже завжди причина в тому, що каталог у Elbuz прийшов не з того самого YML-експорту: ідентифікатори в заявці й у картках різні. Завантажте каталог із фіда SalesDrive і повторіть.
Третя — помилка про перевищення лімітів. Зменшіть частоту розкладу: поточний потік заявок і так ловить вебхук, а планове завантаження потрібне лише для історії та добору.
Навіщо зводити SalesDrive в Elbuz
SalesDrive сильна там, де йдеться про роботу менеджера із заявкою: воронка, дзвінки, ТТН. Але вона не веде склад із партіями й собівартістю, не рахує націнки за правилами й не збирає прайси постачальників. Elbuz бере на себе саме це: каталог, ціни, залишки, закупівлі й документи. Заявки, що приїхали з CRM, стають повноцінними документами продажу — з них списується товар, за ними видно виторг і маржу, а покупець лягає у вашу базу контрагентів разом із історією покупок.
Часті питання
Які права потрібні API-ключу SalesDrive?
Достатньо читання заявок («Заявки — читання»). Elbuz забирає дані й нічого не змінює в CRM, тож зайві права видавати не потрібно. Ключ створюється в кабінеті: «Установки» → «Інші сервіси» → «API».
Навіщо вебхук, якщо є API-ключ?
Вони роблять різне. Вебхук приносить заявки миттєво — CRM сама повідомляє Elbuz про нову чи змінену заявку. API-ключ потрібен, щоб перенести історію при першому підключенні й добрати те, що могло не дійти. Разом вони не конфліктують: та сама заявка не подвоюється, а оновлюється.
Чому завантаження історії таке повільне?
Через ліміти SalesDrive: близько 10 запитів на хвилину. Elbuz витримує паузи між сторінками, щоб не впертися в обмеження, тому велика історія переноситься поступово. Розклад планового завантаження не варто ставити частіше ніж раз на 15 хвилин.
Звідки беруться товари — теж по API?
Ні, каталог і залишки приходять з YML-експорту SalesDrive: ви вставляєте посилання на нього в поле URL шаблону. Це ж дає точне зіставлення позицій у заявках, бо в заявці зберігається ідентифікатор товару з цього самого фіда.
Чому всі заявки отримали однаковий статус?
Швидше за все, не заповнена таблиця зіставлення статусів: статус приходить кодом SalesDrive, і якщо відповідності не знайдено, документ отримує статус за замовчуванням. Відкрийте кнопку «Статуси замовлення» в картці «Пов'язані налаштування» і додайте потрібні рядки. Уже завантажені документи від заповнення таблиці не переграються — їм статус міняють руками.
Чи затре повторне завантаження мої правки в заявці?
Сума, покупець, коментар, адреса, номер ТТН і склад документа лишаються ваші — їх повторний прогін не переписує. Ваш статус змінюється тільки тоді, коли статус змінився в самій CRM. А проведений документ завантаження не чіпає взагалі: це найнадійніший спосіб закріпити все, що ви в ньому зробили.
Помилково завантажив заявки — як прибрати?
Відфільтруйте список замовлень за колонкою «Джерело (код)» зі значенням salesdrive, виділіть рядки й видаліть пачкою: одразу після видалення з'явиться кнопка «Скасувати», а сама пачка ще 30 днів лежить у «Кошику документів». Проведені документи пачка не видаляє. Щоб потім завантажити той самий період заново, очистіть у блоці «Розширене» поля «Завантаження замовлень починаючи з ID» і «...з дати».