Інтеграція з доставкою

Інтеграція з доставкою — це автоматичний або напівавтоматичний обмін даними між ERP-системою компанії та службами доставки, кур’єрськими сервісами, поштовими операторами, транспортними компаніями, власною логістикою, інтернет-магазином, CRM і складом.

Простими словами, інтеграція з доставкою відповідає на питання:

куди потрібно доставити замовлення;
якою службою доставки;
хто отримувач;
які контактні дані клієнта;
який склад відвантаження;
яка вага і габарити посилки;
скільки коштує доставка;
чи створена ТТН;
який статус доставки;
чи отримав клієнт товар;
чи повернулась посилка;
чи надійшов накладений платіж;
чи можна закривати замовлення;
де саме зараз вантаж;
хто винен, якщо “воно десь їде вже третій день”.

Головне. Інтеграція з доставкою потрібна для того, щоб замовлення з ERP, CRM або інтернет-магазину швидко перетворювались на відправлення, ТТН, задачі складу, статуси доставки, повідомлення клієнтам і фінансові операції без ручного копіювання адрес, телефонів і номерів накладних.

Для керівника. Доставка — це не просто “відправили клієнту”. Це швидкість продажу, якість сервісу, гроші в дорозі, накладені платежі, повернення, вартість логістики, помилки складу, рейтинг компанії і повторні покупки.

Для складу і продажів. Інтеграція з доставкою зменшує ручну роботу: не потрібно повторно вводити адресу, телефон, ПІБ, вагу, габарити, службу доставки, місто, відділення і номер ТТН у кількох системах.

Поширена проблема. Якщо менеджер копіює адресу з CRM, вставляє її в кабінет служби доставки, потім копіює номер ТТН назад у замовлення, а потім ще пише клієнту в месенджер — це не логістика. Це ручний спорт на витривалість.

Вступ

Доставка є важливою частиною продажів, складу, інтернет-магазину, сервісу, виробництва, B2B-торгівлі і клієнтського обслуговування.

Компанія може продавати чудовий товар, мати красивий сайт, швидких менеджерів і гарні ціни, але якщо доставка працює погано, клієнт запам’ятає саме це.

Типові проблеми без інтеграції:

адреси вводяться вручну;
номери телефонів копіюються з помилками;
ТТН створюються окремо в кабінеті служби доставки;
менеджери вручну повідомляють клієнтам номери накладних;
статуси доставки не оновлюються в ERP;
склад не бачить, які замовлення вже готові до відправлення;
продажі не бачать, чи клієнт отримав товар;
фінанси не бачать, чи повернувся накладений платіж;
повернення обробляються вручну;
важко рахувати реальну вартість доставки;
немає аналітики по службам доставки;
клієнти самі дзвонять і питають “де моє замовлення?”;
частина відправлень зависає без контролю.

Інтеграція з доставкою дозволяє зв’язати замовлення, склад, службу доставки, клієнта, оплату, повернення і аналітику в один процес.

ERP може створювати відправлення, передавати дані в службу доставки, отримувати ТТН, відстежувати статус, повідомляти клієнта, контролювати повернення і пов’язувати доставку з фінансовим обліком.

Що таке інтеграція з доставкою простими словами

Інтеграція з доставкою — це коли ERP автоматично обмінюється даними зі службою доставки або логістичною системою.

Приклад:

Клієнт оформив замовлення в інтернет-магазині.

ERP отримала замовлення.

Склад зібрав товар.

ERP передала дані в службу доставки:

отримувач;
телефон;
місто;
відділення;
вага;
габарити;
оголошена вартість;
накладений платіж;
платник доставки.

Служба доставки повернула номер ТТН.

ERP записала номер у замовлення.

Клієнт отримав повідомлення.

Далі ERP автоматично отримує статуси:

створено;
передано на склад доставки;
у дорозі;
прибуло у відділення;
отримано;
повернення;
відмова;
накладений платіж перераховано.

Це і є нормальна інтеграція.

Без інтеграції ці дії виконує людина вручну. І чим більше замовлень, тим більше шансів, що десь адреса поїде не туди, телефон буде не той, а ТТН загубиться в чаті.

Для чого потрібна інтеграція з доставкою

Інтеграція з доставкою потрібна для автоматизації логістичних процесів і покращення клієнтського сервісу.

Вона допомагає:

швидко створювати відправлення;
автоматично формувати ТТН;
зменшувати ручне введення;
зменшувати помилки в адресах;
контролювати статуси доставки;
повідомляти клієнтів;
контролювати повернення;
контролювати накладений платіж;
рахувати вартість доставки;
порівнювати служби доставки;
пов’язувати доставку із замовленням;
пов’язувати доставку зі складом;
автоматизувати відвантаження;
контролювати SLA доставки;
аналізувати проблемні відправлення;
покращувати роботу інтернет-магазину;
підвищувати швидкість обробки замовлень.

Практичний сенс. Інтеграція з доставкою перетворює доставку з ручного копіювання даних на керований бізнес-процес: замовлення → склад → ТТН → відправлення → статус → отримання → оплата або повернення.

Основні сценарії інтеграції з доставкою

Інтеграція з доставкою може включати різні сценарії:

створення відправлення;
створення ТТН;
друк етикетки;
розрахунок вартості доставки;
вибір служби доставки;
вибір відділення;
адресна доставка;
кур’єрська доставка;
передача габаритів і ваги;
контроль статусів;
повідомлення клієнта;
накладений платіж;
повернення;
відмова клієнта;
переадресація;
зміна отримувача;
контроль строків доставки;
аналітика логістики;
робота з кількома службами доставки;
інтеграція з власною доставкою;
інтеграція з WMS;
інтеграція з інтернет-магазином.

Для малого бізнесу може бути достатньо автоматичного створення ТТН і друку етикеток.

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

Для великого — повноцінна логістична система з кількома перевізниками, тарифами, SLA, маршрутами, власною доставкою, аналітикою і фінансовим контролем.

ТТН

ТТН — товарно-транспортна накладна або транспортна накладна, яка супроводжує доставку.

У контексті служб доставки ТТН часто означає номер відправлення, за яким можна відстежити посилку.

ТТН містить:

номер відправлення;
відправника;
отримувача;
адресу або відділення;
телефон;
опис вантажу;
вагу;
габарити;
оголошену вартість;
платника доставки;
суму накладеного платежу;
дату створення;
службу доставки;
статус.

ERP повинна зберігати ТТН у замовленні, відвантаженні, CRM, кабінеті клієнта і фінансових процесах.

Створення ТТН з ERP

Один із найважливіших сценаріїв — створення ТТН прямо з ERP.

Процес:

Замовлення клієнта → Перевірка оплати → Резерв товару → Комплектація → Створення ТТН → Друк етикетки → Відвантаження

ERP бере дані з замовлення:

клієнт;
телефон;
місто;
відділення;
адреса;
товар;
кількість;
сума;
вага;
габарити;
спосіб оплати;
служба доставки.

Після створення ТТН система отримує номер відправлення і записує його в замовлення.

Друк етикеток

Після створення ТТН потрібно надрукувати етикетку.

Етикетка може містити:

номер ТТН;
штрихкод;
QR-код;
отримувача;
телефон;
адресу;
відділення;
службу доставки;
вагу;
кількість місць;
оголошену вартість;
накладений платіж.

ERP може друкувати етикетки одразу після створення ТТН або пакетно для групи замовлень.

Для складу це дуже важливо.

Бо якщо етикетка надрукована неправильно або наклеєна не на ту коробку, клієнт може отримати не свій товар. А це вже не доставка, а лотерея з репутацією.

Вибір служби доставки

Компанія може працювати з різними службами доставки.

Наприклад:

поштові оператори;
кур’єрські служби;
транспортні компанії;
локальні перевізники;
власна доставка;
міжнародна доставка;
служби доставки маркетплейсів.

ERP може допомагати обирати службу доставки за правилами:

місто;
регіон;
вага;
габарити;
вартість;
строк доставки;
тип товару;
клієнт;
договір;
тариф;
спосіб оплати;
наявність відділення;
можливість адресної доставки;
накладений платіж;
обмеження товару.

Приклад:

Якщо замовлення важке — обрати транспортну компанію.

Якщо клієнт у великому місті — кур’єрська доставка.

Якщо це інтернет-магазин — доставка у відділення або поштомат.

Адресна доставка

Адресна доставка означає доставку до конкретної адреси клієнта.

Для неї потрібні:

місто;
вулиця;
будинок;
квартира або офіс;
контактна особа;
телефон;
бажаний час;
коментар кур’єру;
поверх;
ліфт;
обмеження доступу;
спосіб оплати.

ERP повинна зберігати адресу структуровано.

Поганий варіант:

Київ, ну там біля метро, під’їзд другий, подзвоніть

Для кур’єра це може бути романтична пригода. Для бізнесу — затримка доставки.

Доставка у відділення

Доставка у відділення потребує вибору конкретного пункту видачі.

ERP може отримувати довідник:

міст;
відділень;
поштоматів;
адрес відділень;
графіку роботи;
обмежень по вазі;
обмежень по габаритах.

Клієнт може обрати відділення на сайті, а ERP отримає його код і назву.

Це краще, ніж коли менеджер вручну шукає “відділення біля клієнта” і сподівається, що вибрав правильне.

Поштомати

Поштомат — це автоматизований пункт видачі.

Для поштомату важливі:

код поштомату;
адреса;
обмеження по габаритах;
обмеження по вазі;
строк зберігання;
доступність;
статус;
спосіб отримання.

ERP повинна враховувати, що не всі замовлення можна доставити в поштомат.

Наприклад, великий або важкий товар може не підійти.

Кур’єрська доставка

Кур’єрська доставка може бути:

власна;
через службу доставки;
через локального партнера;
по місту;
міжміська;
експрес;
запланована на конкретний час.

ERP може керувати:

маршрутами;
кур’єрами;
статусами;
оплатами;
поверненнями;
підписами клієнтів;
фотофіксацією;
геолокацією;
накладеним платежем;
актами доставки.

Для власної доставки ERP може працювати як TMS або інтегруватися з окремою транспортною системою.

Власна доставка

Власна доставка потрібна компаніям, які мають своїх кур’єрів, автомобілі або логістичні маршрути.

ERP може автоматизувати:

планування маршрутів;
призначення кур’єра;
завантаження авто;
маршрутний лист;
статуси доставки;
підтвердження отримання;
оплату при доставці;
повернення;
контроль часу;
фото або підпис;
витрати на доставку;
паливо;
аналітику по кур’єрах.

Приклад процесу:

Замовлення → Комплектація → Маршрут → Кур’єр → Доставка → Підпис клієнта → Закриття замовлення

Міжміська доставка

Міжміська доставка часто пов’язана зі службами доставки або транспортними компаніями.

Потрібно контролювати:

місто відправлення;
місто отримання;
склад відправлення;
службу доставки;
строк доставки;
тариф;
габарити;
вагу;
кількість місць;
страхування;
статус;
повернення;
оплату доставки.

ERP може автоматично вибирати оптимальний спосіб доставки на основі правил.

Міжнародна доставка

Міжнародна доставка складніша.

Потрібно враховувати:

країну;
митні документи;
інвойс;
пакувальний лист;
сертифікати;
код товару;
вагу;
габарити;
вартість;
валюту;
умови поставки;
обмеження товарів;
строки;
статуси;
брокера;
податки і мито.

ERP може формувати частину документів і передавати дані перевізнику.

Розрахунок вартості доставки

ERP може розраховувати або отримувати вартість доставки.

На вартість впливають:

служба доставки;
тариф;
вага;
габарити;
місто;
відстань;
тип доставки;
оголошена вартість;
накладений платіж;
страхування;
кількість місць;
терміновість;
адресна доставка;
повернення документів;
додаткові послуги.

Приклад:

Доставка у відділення може коштувати дешевше.

Адресна доставка — дорожче.

Велика вага або нестандартні габарити — ще дорожче.

ERP може показувати менеджеру або клієнту прогноз вартості доставки ще до створення ТТН.

Хто платить за доставку

Доставка може оплачуватися різними сторонами:

відправник;
отримувач;
третя сторона;
компанія-продавець;
клієнт;
постачальник;
партнер;
за договором;
безкоштовно для клієнта, але за рахунок продавця.

ERP повинна фіксувати платника доставки.

Це важливо для фінансового обліку.

Бо “безкоштовна доставка” для клієнта не означає безкоштовна для бізнесу. Просто її платить компанія.

Безкоштовна доставка

Компанія може пропонувати безкоштовну доставку.

Наприклад:

від суми замовлення;
для VIP-клієнтів;
за акцією;
для певного регіону;
для певних товарів;
при передоплаті;
при самовивозі до точки видачі.

ERP може автоматично визначати, коли доставка безкоштовна.

Приклад:

Якщо сума замовлення понад 3 000 грн — доставка за рахунок компанії.

Система повинна віднести вартість доставки на витрати продажу або іншу статтю.

Накладений платіж

Накладений платіж — це коли клієнт оплачує товар при отриманні, а служба доставки потім перераховує гроші продавцю.

ERP повинна контролювати:

суму накладеного платежу;
комісію;
дату отримання;
дату перерахування;
статус платежу;
зв’язок із замовленням;
повернення;
часткове отримання;
відмову клієнта.

Процес:

Замовлення → Відправлення з накладеним платежем → Клієнт отримав → Служба доставки прийняла оплату → Гроші перераховано → ERP закрила оплату

Якщо накладений платіж не контролювати, можна мати товар уже в клієнта, а гроші “десь у доставці”.

Контроль накладеного платежу

ERP може звіряти накладені платежі з банком або звітами служби доставки.

Потрібно бачити:

які замовлення відправлені з накладеним платежем;
які отримані клієнтами;
які гроші очікуються;
які гроші надійшли;
які комісії утримані;
які платежі прострочені;
які відправлення повернулись.

Це важливо для фінансів і продажів.

Повернення товару

Повернення може виникати, якщо:

клієнт відмовився;
клієнт не забрав посилку;
товар пошкоджено;
адреса неправильна;
клієнт змінив рішення;
товар не відповідає очікуванням;
помилка складу;
помилка менеджера;
доставка затрималась.

ERP повинна обробляти повернення як окремий процес.

Приклад:

Відправлення → Клієнт не отримав → Статус “Повернення” → Товар повернувся на склад → Перевірка стану → Оприбуткування або списання → Закриття замовлення

Відмова клієнта від посилки

Клієнт може відмовитися від отримання.

ERP повинна фіксувати:

причину відмови;
статус доставки;
вартість доставки;
вартість повернення;
відповідального менеджера;
товар;
можливість повторного продажу;
фінансові наслідки;
коментар клієнта.

Причини відмов корисні для аналітики.

Якщо багато відмов через “довго доставлялось”, проблема в логістиці.

Якщо через “не той товар” — проблема у складі або замовленні.

Якщо через “передумав” — вітаємо, це класика інтернет-торгівлі.

Пошкодження при доставці

Товар може бути пошкоджений під час доставки.

ERP повинна дозволяти фіксувати:

службу доставки;
номер ТТН;
товар;
партію або серію;
фото;
акт;
суму збитків;
відповідального;
рекламацію до служби доставки;
рішення;
компенсацію;
списання або повернення.

Це важливо для фінансового обліку і оцінки якості перевізників.

Страхування відправлення

Деякі вантажі потрібно страхувати.

ERP може передавати оголошену вартість і контролювати:

суму страхування;
тариф;
вартість страховки;
умови компенсації;
пошкодження;
втрату;
претензії;
документи.

Для дорогих товарів страхування може бути обов’язковим правилом.

Статуси доставки

Статуси доставки показують, що відбувається з відправленням.

Типові статуси:

створено;
очікує передачі;
передано перевізнику;
прийнято службою доставки;
у дорозі;
прибуло у відділення;
очікує отримання;
доставляється кур’єром;
отримано;
відмова;
повернення;
повернуто відправнику;
втрачено;
пошкоджено;
скасовано;
потребує уточнення.

ERP повинна отримувати статуси автоматично або за розкладом.

Статус “відправили” — це ще не “клієнт отримав”.

Це різні етапи, і бізнесу потрібно бачити різницю.

Автоматичне оновлення статусів

ERP може періодично запитувати статуси у служби доставки.

Наприклад:

кожні 30 хвилин;
кожну годину;
раз на день;
при відкритті замовлення;
за подією;
через webhook, якщо служба доставки підтримує.

Автоматичне оновлення дозволяє:

не перевіряти вручну;
повідомляти клієнта;
контролювати проблеми;
закривати замовлення після отримання;
запускати процес повернення;
контролювати накладені платежі.

Повідомлення клієнту

ERP може автоматично повідомляти клієнта про доставку.

Повідомлення можуть містити:

номер ТТН;
службу доставки;
посилання для відстеження;
адресу відділення;
суму до оплати;
дату прибуття;
нагадування про отримання;
повідомлення про затримку;
повідомлення про повернення.

Канали повідомлень:

SMS;
email;
месенджер;
push;
особистий кабінет;
чат-бот;
дзвінок менеджера.

Головне — не перетворити повідомлення на спам.

Клієнту потрібна корисна інформація, а не 12 повідомлень про те, що коробка змінила внутрішній статус у логістичному всесвіті.

Відстеження доставки клієнтом

Клієнт може самостійно відстежувати доставку.

ERP або сайт може показувати:

номер ТТН;
статус;
службу доставки;
дату відправлення;
очікувану дату прибуття;
адресу відділення;
суму накладеного платежу;
історію статусів.

Це зменшує навантаження на менеджерів.

Бо питання “де моє замовлення?” краще закривати автоматично, ніж вручну 50 разів на день.

Інтеграція з інтернет-магазином

Для інтернет-магазину інтеграція з доставкою особливо важлива.

Процес може виглядати так:

Клієнт оформив замовлення → Обрав службу доставки → Обрав відділення → ERP отримала замовлення → Склад зібрав товар → ERP створила ТТН → Клієнт отримав повідомлення

Інтернет-магазин може передавати в ERP:

спосіб доставки;
місто;
відділення;
адресу;
контактні дані;
спосіб оплати;
коментар клієнта;
бажаний час доставки.

ERP повертає:

номер ТТН;
статус;
дані відправлення;
оплату;
повернення.

Інтеграція з CRM

CRM повинна бачити статус доставки, бо доставка впливає на клієнтський досвід.

Менеджер у CRM може бачити:

замовлення відправлено;
номер ТТН;
клієнт отримав товар;
клієнт не забрав посилку;
посилка повертається;
клієнт відмовився;
накладений платіж очікується;
доставка затримується.

Це дозволяє менеджеру вчасно реагувати.

Наприклад, якщо клієнт 3 дні не забирає посилку, CRM може створити задачу: зателефонувати і нагадати.

Інтеграція зі складом

Доставка пов’язана зі складом.

Склад повинен знати:

які замовлення потрібно зібрати;
які потрібно упакувати;
яка служба доставки;
чи потрібна етикетка;
скільки місць;
які габарити;
які товари в посилці;
чи оплачено замовлення;
чи потрібен накладений платіж;
куди передати відправлення.

Процес складу:

Замовлення → Резерв → Комплектація → Перевірка → Пакування → ТТН → Передача перевізнику

ERP допомагає зв’язати складські задачі з логістикою.

Інтеграція з WMS

Якщо компанія використовує WMS, доставка може бути частиною складської логістики.

WMS може виконувати:

комплектацію;
пакування;
зважування;
визначення габаритів;
друк етикетки;
сортування по перевізниках;
формування реєстру відправлень;
передачу в зону відвантаження.

ERP або WMS може створювати ТТН і передавати дані службі доставки.

У складних компаніях ERP, WMS і служби доставки повинні працювати як один процес, а не як три окремі світи.

Пакування

Пакування впливає на доставку.

ERP може враховувати:

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

Пакування може впливати на тариф доставки.

Наприклад, товар легкий, але великий за об’ємом. Служба доставки може рахувати об’ємну вагу.

Вага і габарити

Для доставки важливі:

фактична вага;
об’ємна вага;
довжина;
ширина;
висота;
кількість місць;
нестандартні габарити.

ERP може брати вагу і габарити з картки номенклатури або з фактичного зважування на складі.

Якщо вагу вводити вручну, помилки можуть впливати на вартість доставки.

Якщо габарити неправильні, посилка може не пройти обмеження служби доставки.

Кількість місць

Одне замовлення може складатися з кількох місць.

Наприклад:

коробка 1;
коробка 2;
палета;
окрема довга деталь;
комплект із кількох упаковок.

ERP повинна дозволяти створювати відправлення з кількома місцями.

Для кожного місця можуть бути свої:

вага;
габарити;
етикетка;
штрихкод;
вміст;
статус.

Консолідація відправлень

Іноді кілька замовлень можна об’єднати в одне відправлення.

Наприклад:

Клієнт зробив 3 замовлення протягом дня.

ERP може запропонувати об’єднати їх, якщо:

той самий клієнт;
та сама адреса;
той самий спосіб доставки;
товари ще не відправлені;
немає обмежень.

Це може зменшити витрати на доставку.

Але об’єднання має бути контрольованим, щоб не переплутати документи, оплату і комплектацію.

Розділення відправлення

Іноді одне замовлення потрібно відправити частинами.

Причини:

товар на різних складах;
частина товару в наявності;
частина очікує поставки;
різні габарити;
різні температурні режими;
різні перевізники;
клієнт просить часткове відвантаження.

ERP повинна підтримувати кілька ТТН для одного замовлення.

Приклад:

Замовлення №100 має 3 товари.

2 товари відправлені сьогодні.

1 товар буде відправлений завтра.

ERP показує часткове відвантаження і статуси по кожній посилці.

Самовивіз

Самовивіз — це теж сценарій доставки.

ERP може контролювати:

точку самовивозу;
дату готовності;
відповідального;
статус “готово до видачі”;
повідомлення клієнту;
факт отримання;
оплату;
документи;
строк зберігання.

Приклад:

Клієнт обрав самовивіз із магазину.

ERP передає задачу на підготовку товару.

Клієнт отримує повідомлення, що замовлення готове.

Після видачі статус змінюється на “Отримано”.

Доставка постачальником

Іноді доставку виконує постачальник напряму клієнту або на склад.

Це може бути:

дропшипінг;
пряма поставка клієнту;
доставка від постачальника на об’єкт;
поставка великогабаритного товару;
поставка матеріалів на будівництво.

ERP повинна контролювати:

хто доставляє;
коли;
кому;
які документи;
статус поставки;
відповідальність;
вартість;
підтвердження отримання.

Дропшипінг

Дропшипінг — це коли товар відправляється клієнту напряму від постачальника.

Процес:

Клієнт замовив товар → Компанія передала замовлення постачальнику → Постачальник відправив товар → ERP отримала ТТН → Клієнт отримав

ERP повинна контролювати:

замовлення клієнта;
замовлення постачальнику;
ТТН;
статус;
оплату;
маржу;
повернення;
рекламації.

Без інтеграції дропшипінг швидко перетворюється на гру “а постачальник точно відправив?”.

Маршрутні листи

Для власної доставки можна використовувати маршрутні листи.

Маршрутний лист містить:

дату;
кур’єра;
транспорт;
список доставок;
адреси;
послідовність точок;
час доставки;
контактів;
суми до отримання;
статуси;
повернення;
підпис клієнта.

ERP може формувати маршрутний лист на основі замовлень.

Планування маршрутів

Планування маршрутів допомагає оптимізувати власну доставку.

ERP або інтегрована TMS може враховувати:

адреси;
час доставки;
завантаження авто;
вантажопідйомність;
об’єм;
пріоритети;
пробки;
вікна доставки;
географію;
кількість кур’єрів;
повернення;
самовивіз документів.

Оптимізація маршрутів зменшує витрати на паливо, час і кількість рейсів.

Доставка і документи

Разом із товаром можуть передаватися документи:

видаткова накладна;
рахунок;
акт;
ТТН;
сертифікат якості;
гарантійний талон;
інструкція;
комплектувальний лист;
договір;
документи для підпису клієнтом.

ERP може формувати комплект документів для доставки.

Якщо документи не вкладені або вкладені не ті, це може затримати оплату, приймання або закриття замовлення.

Повернення документів

У B2B часто потрібно отримати підписані документи назад.

Наприклад:

акт;
видаткова накладна;
договір;
специфікація;
ТТН.

ERP може контролювати:

які документи передані;
які мають повернутися;
через яку службу доставки;
хто відповідальний;
чи отримані підписані документи;
чи можна закривати угоду.

Доставка і сертифікати якості

Для деяких товарів разом із доставкою потрібно передати сертифікати якості.

ERP може автоматично додавати сертифікат до комплекту документів, якщо:

товар потребує сертифіката;
партія має паспорт якості;
клієнт вимагає документ;
договір вимагає документ;
товар імпортний;
це B2B-відвантаження.

Якщо сертифікат не додано, система може показати попередження.

Доставка і контроль якості

Перед відвантаженням може виконуватись контроль якості.

Наприклад:

перевірка комплектності;
перевірка зовнішнього вигляду;
перевірка упаковки;
перевірка серійних номерів;
перевірка документів;
фотофіксація;
контроль терміну придатності;
контроль партії.

ERP може не дозволяти створити ТТН, якщо фінальний контроль не пройдено.

Це особливо важливо для дорогих, складних або відповідальних товарів.

Доставка і оплата

Доставка пов’язана з оплатою.

Можливі варіанти:

передоплата;
оплата при отриманні;
накладений платіж;
оплата після доставки;
оплата за договором;
часткова передоплата;
безготівкова оплата після отримання документів.

ERP повинна розуміти, який спосіб оплати використовується.

Наприклад:

Якщо замовлення з передоплатою, ТТН створюється тільки після оплати.

Якщо замовлення з накладеним платежем, ERP контролює перерахування коштів після отримання.

Доставка і банк

Накладений платіж або оплата доставки можуть бути пов’язані з інтеграцією з банком.

Процес:

Клієнт отримав посилку → Оплатив накладений платіж → Служба доставки перерахувала гроші → Банк передав виписку → ERP закрила оплату

ERP може звіряти:

замовлення;
суму накладеного платежу;
комісію;
фактичне надходження;
дату;
службу доставки.

Доставка і фінансовий облік

Доставка створює фінансові операції:

витрати на доставку;
дохід від доставки, якщо клієнт платить окремо;
комісія за накладений платіж;
повернення;
компенсації;
страхування;
пошкодження;
втрати;
послуги перевізника;
заборгованість перед службою доставки;
заборгованість служби доставки перед компанією.

ERP повинна дозволяти відносити витрати доставки на:

замовлення;
клієнта;
канал продажу;
підрозділ;
проєкт;
статтю витрат;
собівартість;
маркетингову акцію.

Доставка і собівартість

Доставка може впливати на собівартість або маржу замовлення.

Приклад:

Замовлення на 2 000 грн.

Маржа товару — 500 грн.

Компанія оплатила доставку — 120 грн.

Комісія накладеного платежу — 40 грн.

Фактична маржа:

500 - 120 - 40 = 340 грн

Якщо доставку не враховувати, продаж виглядатиме прибутковішим, ніж є насправді.

Аналітика доставки

ERP може показувати аналітику доставки:

кількість відправлень;
доставка по службах;
середня вартість доставки;
середній строк доставки;
відсоток повернень;
відсоток відмов;
пошкодження;
втрати;
накладені платежі;
прострочені доставки;
проблемні регіони;
проблемні перевізники;
доставка по менеджерах;
доставка по складах;
доставка по каналах продажу;
доставка по клієнтах;
витрати на безкоштовну доставку.

Аналітика допомагає зрозуміти, яка доставка реально вигідна, а яка просто здається зручною.

KPI доставки

Корисні KPI:

середній час від замовлення до відправлення;
середній час доставки;
відсоток доставок у строк;
відсоток повернень;
відсоток відмов;
кількість пошкоджень;
середня вартість доставки;
вартість доставки у відсотках від продажу;
кількість помилок адреси;
кількість нероздрукованих ТТН;
кількість відправлень без статусу;
час обробки замовлення складом;
відсоток накладених платежів, отриманих у строк.

SLA доставки

SLA доставки — це правила строків.

Наприклад:

замовлення до 14:00 відправляється в той самий день;
доставка по місту — 24 години;
доставка в регіони — 1–3 дні;
кур’єрська доставка — у вибране вікно;
збірка замовлення складом — до 2 годин;
ТТН має бути створена протягом 30 хвилин після комплектації.

ERP може контролювати SLA і показувати прострочення.

SLA корисний не тільки для клієнтів, а й для внутрішньої дисципліни.

Бо “відправимо скоро” — це не логістичний стандарт. Це побажання.

Проблемні відправлення

ERP повинна показувати проблемні відправлення.

Наприклад:

статус не оновлювався;
доставка затримується;
клієнт не забирає посилку;
відправлення повертається;
пошкодження;
втрачено;
неправильна адреса;
потрібне уточнення даних;
накладений платіж не перераховано;
ТТН створена, але товар не переданий перевізнику.

Такі відправлення краще виявляти автоматично.

Інакше менеджери дізнаються про проблему від роздратованого клієнта. Це теж система моніторингу, але погана.

Переадресація

Клієнт може попросити змінити адресу або відділення.

ERP повинна фіксувати:

стару адресу;
нову адресу;
причину;
відповідального;
статус;
додаткову вартість;
службу доставки;
підтвердження клієнта.

Якщо переадресація робиться в кабінеті служби доставки, ERP повинна отримати оновлені дані.

Зміна отримувача

Іноді потрібно змінити отримувача.

Наприклад:

клієнт просить отримати іншій людині;
компанія змінює контактну особу;
помилка в ПІБ;
B2B-отримувач змінив склад або відповідального.

ERP повинна зберігати історію зміни отримувача.

Це важливо для безпеки і спірних ситуацій.

Скасування відправлення

Відправлення може бути скасоване.

Причини:

клієнт скасував замовлення;
товар відсутній;
помилка в замовленні;
неправильна ТТН;
зміна служби доставки;
дубль;
помилка адреси;
зміна способу оплати.

ERP повинна скасувати ТТН або позначити її як неактивну, а також оновити статус замовлення і складу.

Масове створення ТТН

Якщо замовлень багато, потрібне масове створення ТТН.

ERP може:

відібрати замовлення готові до відправлення;
перевірити оплату;
перевірити адресу;
перевірити вагу;
створити ТТН пакетно;
надрукувати етикетки;
сформувати реєстр передачі перевізнику.

Це суттєво економить час складу і менеджерів.

Реєстр відправлень

Реєстр відправлень — це список посилок, які передаються службі доставки.

Він може містити:

номер ТТН;
замовлення;
отримувача;
кількість місць;
вагу;
вартість;
накладений платіж;
склад;
дату передачі;
відповідального.

Реєстр потрібен для контролю фактичної передачі відправлень перевізнику.

Передача перевізнику

Створена ТТН ще не означає, що товар переданий перевізнику.

ERP повинна розрізняти:

ТТН створено;
товар упаковано;
етикетка надрукована;
передано в зону відвантаження;
передано перевізнику;
перевізник прийняв.

Це важливо для складу і клієнтського сервісу.

Бо клієнту часто кажуть “ми вже відправили”, хоча фактично тільки створили накладну. Це дуже оптимістичне трактування логістики.

Доставка для B2B

У B2B-доставці можуть бути додаткові вимоги:

доставка на склад клієнта;
доставка у визначене вікно;
документи для приймання;
сертифікати;
палетування;
маркування;
кількість місць;
підписані документи;
пропуск на територію;
контактна особа;
заявка на в’їзд;
спеціальний транспорт.

ERP повинна зберігати логістичні вимоги клієнта.

Доставка для B2C

У B2C-доставці важливі:

швидкість;
зручність;
повідомлення;
відділення;
поштомат;
накладений платіж;
повернення;
простий трекінг;
якісне пакування;
мінімум дзвінків.

Для інтернет-магазинів інтеграція з доставкою напряму впливає на конверсію і повторні покупки.

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

Маркетплейси можуть мати свої правила доставки.

Наприклад:

конкретні служби доставки;
строки відправлення;
автоматична передача ТТН;
статуси;
штрафи за прострочення;
правила повернення;
вимоги до пакування;
маркування;
етикетки маркетплейсу.

ERP може інтегруватися з маркетплейсом і службами доставки одночасно.

Процес:

Маркетплейс → Замовлення → ERP → Склад → ТТН → Статус доставки → Маркетплейс

Доставка і мультисклад

Якщо компанія має кілька складів, ERP повинна визначати, звідки відправляти товар.

Критерії:

наявність товару;
ближчий склад до клієнта;
вартість доставки;
строк доставки;
завантаження складу;
тип товару;
регіон;
спосіб оплати;
залишки;
резерви.

Приклад:

Клієнт у Львові.

Товар є на складах у Києві і Львові.

ERP може запропонувати відправити зі Львова, якщо це швидше і дешевше.

Доставка і резервування товару

Перед відправленням товар повинен бути зарезервований.

Процес:

Замовлення → Резерв → Комплектація → ТТН → Відвантаження

Якщо товар не зарезервований, може виникнути ситуація:

менеджер створив ТТН;
склад не має товару;
клієнт отримав номер відправлення;
фактично відправити нічого.

ERP повинна не дозволяти створювати відправлення без реального товару або відповідного правила.

Доставка і інвентаризація

Доставка впливає на залишки.

Потрібно правильно відображати статуси товару:

на складі;
зарезервовано;
у комплектації;
передано перевізнику;
в дорозі;
доставлено;
повертається;
повернено;
втрачено;
пошкоджено.

Якщо статуси не контролювати, товар може одночасно “бути на складі” в обліку і їхати до клієнта фізично.

Такі речі погано впливають на інвентаризацію і нервову систему складу.

Доставка і повернення на склад

Повернене відправлення потрібно правильно прийняти.

Процес:

отримати повернення;
перевірити товар;
перевірити упаковку;
визначити стан;
оприбуткувати на склад;
повернути в продаж;
відправити на ремонт;
списати;
створити рекламацію;
оновити замовлення;
оновити фінансові дані.

ERP повинна відрізняти повернення товару в нормальному стані від повернення пошкодженого товару.

Доставка і серійні номери

Для товарів із серійним обліком потрібно фіксувати, який саме серійний номер відправлено клієнту.

Це важливо для:

гарантії;
сервісу;
повернень;
рекламацій;
простежуваності;
обліку дорогих товарів.

ERP повинна зв’язувати:

Замовлення → ТТН → Серійний номер → Клієнт → Гарантія

Доставка і партії

Для партійного товару доставка має зберігати інформацію про партію.

Це важливо для:

строків придатності;
сертифікатів якості;
рекламацій;
відкликання продукції;
простежуваності;
FIFO / FEFO;
складського обліку.

ERP повинна знати, яку партію відправлено конкретному клієнту.

Доставка і температурний режим

Деякі товари потребують спеціального температурного режиму.

Наприклад:

харчові продукти;
медикаменти;
косметика;
хімічні матеріали;
біологічні зразки;
заморожені товари.

ERP може зберігати вимоги доставки:

температура;
тип упаковки;
служба доставки;
час у дорозі;
термоконтейнер;
контроль датчиків;
заборона певних способів доставки.

Небезпечні вантажі

Деякі товари мають обмеження доставки.

Наприклад:

легкозаймисті матеріали;
хімія;
акумулятори;
гази;
небезпечні речовини;
товари з особливими умовами транспортування.

ERP може контролювати, які служби доставки дозволені для таких товарів.

Доставка і габаритний товар

Великогабаритний товар має особливості:

спеціальні тарифи;
вантажний транспорт;
палети;
підйом на поверх;
розвантаження;
доставка за графіком;
обмеження відділень;
додаткові послуги.

ERP повинна враховувати габарити товару і не пропонувати невідповідний спосіб доставки.

Доставка і монтаж

Іноді доставка пов’язана з монтажем або встановленням.

Наприклад:

доставка обладнання;
встановлення меблів;
монтаж техніки;
підключення систем;
сервісний виїзд після доставки.

Процес:

Відправлення → Доставка → Монтаж → Акт виконаних робіт → Закриття замовлення

ERP може створювати сервісну задачу після доставки.

Доставка і сервіс

У сервісі доставка може використовуватися для:

відправки запчастин;
повернення обладнання;
гарантійного ремонту;
обміну товару;
доставки підмінного обладнання;
відправки інструменту;
повернення дефектних вузлів.

ERP повинна пов’язувати доставку з сервісною заявкою.

Доставка і рекламації

Якщо клієнт скаржиться на доставку, потрібно фіксувати рекламацію.

Причини:

затримка;
пошкодження;
втрата;
не той товар;
недокомплект;
неправильна адреса;
неправильний отримувач;
відсутні документи;
висока вартість;
погане пакування.

ERP може пов’язати рекламацію з ТТН, замовленням, складом, перевізником і відповідальним.

Доставка і бізнес-процеси

Інтеграція з доставкою є частиною бізнес-процесів компанії.

Приклад процесу:

Замовлення → Оплата → Резерв → Комплектація → Пакування → ТТН → Відвантаження → Статус доставки → Отримання → Закриття

Якщо на будь-якому етапі виникає проблема, ERP повинна показати її і створити задачу.

Доставка і права доступу

До доставки потрібні права доступу.

Наприклад:

менеджер може створювати ТТН по своїх замовленнях;
склад може друкувати етикетки;
логіст може змінювати службу доставки;
фінанси бачать накладені платежі;
керівник бачить аналітику;
адміністратор налаштовує інтеграції;
клієнт бачить тільки своє відправлення.

Права доступу важливі, бо доставка містить персональні дані клієнтів: телефони, адреси, ПІБ.

Безпека персональних даних

Інтеграція з доставкою обробляє персональні дані.

Потрібно контролювати:

хто бачить адреси;
хто бачить телефони;
хто може експортувати дані;
хто може змінювати отримувача;
хто може створювати ТТН;
як зберігаються API-ключі;
які дані передаються перевізнику;
історію доступу;
видалення або архівацію даних.

Персональні дані — це не просто текст у замовленні. Це відповідальність.

API служб доставки

Інтеграція часто виконується через API служби доставки.

API може дозволяти:

отримувати міста;
отримувати відділення;
створювати ТТН;
друкувати етикетки;
скасовувати відправлення;
змінювати дані;
отримувати статуси;
розраховувати вартість;
отримувати реєстри;
працювати з поверненнями;
контролювати накладені платежі.

API-інтеграція зручна, але потребує підтримки.

Служби доставки можуть змінювати формати, правила, тарифи і довідники. ERP повинна бути готова до таких змін.

Файлова інтеграція з доставкою

Іноді використовується файловий обмін.

Наприклад:

експорт замовлень у CSV;
імпорт ТТН;
імпорт статусів;
реєстри відправлень;
звіти по накладених платежах.

Файлова інтеграція простіша, але менш зручна, ніж API.

Вона може бути корисною як перший етап автоматизації або для перевізників без API.

Webhook-інтеграція

Webhook — це коли служба доставки сама повідомляє ERP про зміну статусу.

Приклад:

посилка отримана;
статус змінено;
накладений платіж проведено;
посилка повертається;
виникла проблема.

Webhook зручний, бо ERP не потрібно постійно питати службу доставки: “ну що там?”.

Служба сама повідомляє про подію.

Робота з довідниками доставки

ERP повинна отримувати або зберігати довідники:

міст;
відділень;
поштоматів;
вулиць;
тарифів;
типів доставки;
обмежень;
складів відправника;
зон доставки;
кур’єрів;
статусів;
причин повернення.

Довідники повинні оновлюватися.

Бо відділення можуть відкриватися, закриватися, змінювати адресу або обмеження.

Типові помилки при інтеграції з доставкою

Найпоширеніші помилки:

адреси вводяться вручну;
немає перевірки телефону;
неправильно обирається відділення;
ТТН створюється до комплектації;
ТТН створюється без оплати;
статуси не оновлюються;
повернення не контролюються;
накладені платежі не звіряються;
доставка не враховується у маржі;
немає аналітики по перевізниках;
клієнту не надсилається ТТН;
склад і продажі бачать різні статуси;
немає контролю пошкоджень;
немає реєстру передачі перевізнику;
немає історії змін отримувача;
не контролюються персональні дані.

Окрема класика — створити ТТН, повідомити клієнта, а потім виявити, що товару на складі немає.

Це не швидка доставка. Це швидке створення проблеми.

Excel у доставці

Excel часто використовують для:

списку відправлень;
номерів ТТН;
реєстру повернень;
накладених платежів;
звірки з перевізником;
графіка кур’єрів;
адрес клієнтів;
вартості доставки.

На старті це може працювати.

Але з ростом кількості замовлень виникають проблеми:

ручні помилки;
різні версії файлів;
немає автоматичних статусів;
немає зв’язку з замовленнями;
немає зв’язку зі складом;
немає автоматичного повідомлення клієнта;
складно контролювати повернення;
складно звіряти накладений платіж;
немає аналітики в реальному часі;
немає прав доступу;
персональні дані розкидані по файлах.

Типовий файл:

Відправки_ТТН_нова_версія_фінал_після_повернень_12.xlsx

Якщо доставка живе в такому файлі, вона вже давно проситься в ERP. Просто поки що терпить.

Автоматизація інтеграції з доставкою в ERP

ERP дозволяє зробити доставку частиною єдиного процесу.

Система може забезпечити:

вибір служби доставки;
вибір відділення;
адресну доставку;
створення ТТН;
друк етикеток;
розрахунок вартості;
передачу даних перевізнику;
контроль статусів;
повідомлення клієнтів;
контроль накладеного платежу;
повернення;
пошкодження;
реєстри відправлень;
маршрути власної доставки;
аналітику;
зв’язок зі складом;
зв’язок із CRM;
зв’язок з інтернет-магазином;
зв’язок із фінансами;
зв’язок із контролем якості;
права доступу;
історію дій.

ERP не просто створює ТТН.

ERP зв’язує доставку з усім бізнес-процесом продажу і обліку.

Як K2 ERP допомагає з інтеграцією з доставкою

K2 ERP може використовуватися для автоматизації інтеграції з доставкою, службами доставки, кур’єрськими сервісами, власною логістикою, інтернет-магазинами, CRM, WMS і складом.

Система може охоплювати:

замовлення клієнтів;
способи доставки;
служби доставки;
довідники міст і відділень;
адресну доставку;
поштомати;
кур’єрську доставку;
власну доставку;
створення ТТН;
друк етикеток;
реєстри відправлень;
вагу і габарити;
кількість місць;
тарифи;
вартість доставки;
безкоштовну доставку;
накладений платіж;
статуси доставки;
повідомлення клієнтів;
повернення;
відмови;
пошкодження;
рекламації;
зв’язок зі складом;
зв’язок із WMS;
зв’язок із CRM;
зв’язок з інтернет-магазином;
зв’язок із банком;
фінансовий облік доставки;
аналітику логістики.

Для малого бізнесу це може бути створення ТТН із замовлення і друк етикеток.

Для середнього бізнесу — автоматичні статуси, накладений платіж, повернення, інтеграція з інтернет-магазином, складом і CRM.

Для великого бізнесу — багатослужбова логістика, власні маршрути, WMS, TMS, мультисклад, SLA, фінансовий контроль, API-інтеграції і глибока аналітика доставки.

Приклад процесу в K2 ERP: інтернет-магазин і доставка

Приклад процесу:

клієнт оформлює замовлення на сайті;
обирає службу доставки і відділення;
замовлення потрапляє в K2 ERP;
ERP перевіряє оплату або умови накладеного платежу;
склад отримує задачу на комплектацію;
після комплектації ERP створює ТТН;
друкується етикетка;
товар передається перевізнику;
клієнт отримує повідомлення з номером ТТН;
ERP оновлює статуси доставки;
після отримання замовлення закривається;
якщо був накладений платіж — ERP контролює надходження коштів.

Приклад процесу в K2 ERP: повернення посилки

Приклад процесу:

клієнт не забрав посилку;
служба доставки передає статус “Повернення”;
K2 ERP оновлює замовлення;
менеджер отримує задачу зв’язатися з клієнтом;
склад очікує повернення;
після повернення товар перевіряється;
якщо товар нормальний — повертається на склад;
якщо пошкоджений — створюється акт або рекламація;
фінанси бачать витрати доставки і повернення;
причина повернення потрапляє в аналітику.

Приклад процесу в K2 ERP: власна доставка

Приклад процесу:

замовлення готове до доставки;
логіст формує маршрут;
ERP призначає кур’єра;
кур’єр отримує список адрес;
клієнти отримують повідомлення;
кур’єр змінює статуси доставки;
клієнт підписує отримання або підтверджує його кодом;
ERP закриває доставку;
якщо є оплата при отриманні — фіксується платіж;
керівник бачить ефективність маршруту і кур’єра.

Що потрібно описати перед впровадженням інтеграції з доставкою

Перед автоматизацією доставки потрібно відповісти на питання:

які служби доставки використовуються;
які способи доставки потрібні;
чи потрібна адресна доставка;
чи потрібні відділення і поштомати;
чи є власна доставка;
чи потрібне планування маршрутів;
які дані передавати перевізнику;
хто створює ТТН;
на якому етапі створюється ТТН;
чи потрібен друк етикеток;
як визначається вага і габарити;
хто платить за доставку;
чи є безкоштовна доставка;
як працює накладений платіж;
як обробляються повернення;
як контролюються пошкодження;
які статуси потрібні;
які повідомлення надсилати клієнту;
як доставка пов’язана зі складом;
як доставка пов’язана з CRM;
як доставка пов’язана з фінансами;
які звіти потрібні керівнику;
які права доступу потрібні.

Чим краще описаний логістичний процес, тим менше буде ручної роботи і помилок після запуску.

Ролі в інтеграції з доставкою

У процесі доставки беруть участь різні ролі.

Роль	Що робить
Менеджер продажів	Оформлює замовлення, перевіряє спосіб доставки, контролює клієнта і статус отримання.
Комірник	Комплектує, пакує, друкує етикетки, передає відправлення перевізнику.
Логіст	Налаштовує служби доставки, маршрути, тарифи, правила і контролює проблемні відправлення.
Кур’єр	Виконує власну доставку, змінює статуси, отримує підпис або оплату.
Фінансист	Контролює вартість доставки, накладені платежі, комісії, повернення і витрати.
Бухгалтер	Відображає послуги доставки, акти перевізників, оплати, комісії і повернення.
Служба підтримки	Відповідає клієнтам на питання щодо доставки, повернень і статусів.
Керівник	Аналізує строки доставки, витрати, повернення, якість перевізників і ефективність процесу.
ERP-адміністратор	Налаштовує служби доставки, довідники, статуси, права, правила і звіти.
IT / інтегратор	Налаштовує API, файловий обмін, webhook, безпеку і технічну підтримку інтеграцій.

Коротко

Питання	Відповідь
Що таке інтеграція з доставкою?	Це автоматичний обмін даними між ERP і службами доставки, кур’єрами, інтернет-магазином, складом або власною логістикою.
Для чого вона потрібна?	Щоб автоматизувати створення ТТН, друк етикеток, статуси доставки, повернення, накладений платіж і повідомлення клієнтів.
Що таке ТТН?	Це транспортна накладна або номер відправлення, за яким можна відстежити доставку.
Що дає автоматичне створення ТТН?	Зменшує ручне введення адрес, телефонів, ваги, габаритів і помилки при оформленні доставки.
Навіщо потрібні статуси доставки?	Щоб бачити, де посилка: створена, передана перевізнику, в дорозі, у відділенні, отримана, повертається або проблемна.
Як доставка пов’язана зі складом?	Склад комплектує, пакує, друкує етикетки, передає товар перевізнику і змінює статуси відвантаження.
Як доставка пов’язана з фінансами?	Через вартість доставки, накладений платіж, комісії, повернення, страхування і витрати логістики.
Що таке накладений платіж?	Це оплата товару клієнтом при отриманні, після чого служба доставки перераховує гроші продавцю.
Чому важливо контролювати повернення?	Бо повернення впливають на залишки, фінанси, клієнтський сервіс, аналітику і якість доставки.
Чому Excel незручний для доставки?	Через ручні помилки, відсутність актуальних статусів, зв’язку зі складом, CRM, оплатами, поверненнями і аналітикою.
Як ERP допомагає?	ERP автоматизує ТТН, етикетки, статуси, доставку, повернення, накладені платежі, склад, CRM, фінанси і звіти.
Як K2 ERP може допомогти?	K2 ERP може автоматизувати інтеграцію з доставкою, службами доставки, власною логістикою, WMS, інтернет-магазином, CRM, банком і фінансовим обліком.

Висновок

Інтеграція з доставкою — це важлива частина автоматизації продажів, складу, інтернет-магазину, CRM, сервісу і фінансів.

Вона дозволяє не копіювати вручну адреси, телефони, відділення, ТТН і статуси, а будувати нормальний процес:

Замовлення → Склад → Пакування → ТТН → Доставка → Статус → Отримання → Оплата або повернення

Якісна інтеграція з доставкою допомагає:

швидше обробляти замовлення;
зменшувати помилки;
автоматично створювати ТТН;
друкувати етикетки;
контролювати статуси;
повідомляти клієнтів;
контролювати повернення;
контролювати накладені платежі;
рахувати вартість доставки;
аналізувати перевізників;
покращувати клієнтський сервіс;
бачити реальні витрати логістики.

K2 ERP може допомогти зробити доставку частиною єдиної системи управління: від замовлення до відвантаження, від складу до перевізника, від ТТН до статусу, від накладеного платежу до банку, від повернення до аналітики.

Інтеграція з доставкою — це не просто кнопка “створити ТТН”.

Це спосіб зробити логістику швидкою, прозорою і контрольованою.

Бо клієнт не оцінює окремо ERP, склад і службу доставки.

Він оцінює просту річ: замовив — отримав швидко, правильно і без зайвих пригод.