Чому калькулятор доставки на сайті рахує неправильно
Калькулятор доставки майже завжди розходиться з реальністю не через помилку у формулі, а через дані, на яких він рахує.
Тарифна сітка перевізника змінюється частіше, ніж її встигають перенести в код: поки менеджер вручну править прайс в адмінці, служба вже ввела паливну надбавку або переписала зони.
У результаті розрахунок вартості доставки на сайті показує одну суму, а в накладній при відвантаженні спливає інша — і різницю клієнту пояснює оператор, а не сайт.
Друга причина — габарити. Клієнт вводить «коробка, приблизно невелика», а перевізник рахує об'ємну вагу за трьома вимірами і порівнює його з фактичним.
Якщо калькулятор бере лише масу, посилка 40×30×20 см з легким наповнювачем поїде за ціною кілограма, а перевізник виставить рахунок за об'ємною вагою.
Далі — зони та строки: частина напрямків іде за магістральним тарифом, частина — за місцевим, а передмістя й узагалі рахується окремо.
Третя причина — ручне введення. Менеджер підставляє місто, індекс або спосіб отримання руками, і там, де потрібен точний код населеного пункту, з'являється «приблизно поруч».
Інтеграція служби доставки за довідником і API прибирає цей шар: адреса нормалізується, зона визначається автоматично, тариф запитується в момент оформлення, а не береться з кешу тижневої давності.
Окремо варто відзначити розходження за доплатами — страхування, забір із пункту видачі, доставка до дверей, негабарит. Якщо калькулятор їх не враховує, помилки в розрахунку доставки накопичуються на кожному замовленні й спливають уже в бухгалтерії. Розбираємо, як це закривається на рівні архітектури розрахунку.
Як працює калькулятор доставки з інтеграцією СДЕК і Пошти Росії
Розрахунок будується на двох незалежних контурах: довідник населених пунктів і живі тарифи. Перший кешується надовго — список міст і індексів змінюється рідко. Другий запитується на кожен кошик, бо тариф залежить від ваги, габаритів, оголошеної цінності та обраного режиму.
Інтеграція СДЕК і інтеграція Пошти Росії влаштовані по-різному: в однієї служби тариф рахується за віртуальною вагою та щільністю вантажу, в іншої — за розрядом відправлення та зоною.
Калькулятор доставки приводить обидві відповіді до однієї структури, щоб вітрина порівнювала варіанти за єдиними полями.
Нормалізація відповідей служб
Кожна відповідь API служб доставки мапиться в загальну модель: термін у днях, ознака «до дверей або до пункту видачі», обмеження за габаритами. Це знімає головний біль — коли фронтенд починає розгалужуватися за іменем перевізника.
Терміни перераховуються з урахуванням дати відвантаження та вихідних, інакше «3 дні» у п'ятницю та в понеділок означають різне.
Кеш і деградація
Тарифи кешуються за ключем «маршрут + вага + габаритний клас» на коротке вікно. Це зрізає повторні запити при переборі кошика і тримає розрахунок у межах секунди.
Якщо служба не відповіла, показуємо останній відомий тариф з позначкою «попередньо» — покупець не втрачає кошик через чужий збій.
Негабарит і віддалені зони
Важкі та об'ємні позиції йдуть в окрему гілку: частина служб їх не бере, частина рахує за volumetric weight. Віддалені зони позначаються як «доставка до пункту видачі» — інакше клієнт обирає кур'єра, якого там немає.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Онлайн-запит до API служб | Актуальні тарифи, часті зміни | Залежність від доступності чужого сервісу |
| Власний довідник тарифів | Стабільні маршрути, високе навантаження | Застаріває при зміні прайсу перевізника |
| Гібрид: кеш + онлайн | Більшість інтернет-магазинів | Потрібна логіка деградації та фолбеку |
СДЕК і Пошта Росії віддають тарифи через офіційні інтерфейси, тому розрахунок не доводиться підтримувати вручну.
Етапи впровадження калькулятора доставки на сайт
Впровадження калькулятора доставки починається не з коду, а з аудиту поточної логістики: які служби вже використовуються, як розраховуються тарифи, де менеджери вручну перераховують вартість і на яких замовленнях розрахунок розходиться з фактом.
На цьому етапі фіксуємо правила — звідки беруться вага й габарити, як враховуються зони, післяплата, оголошена цінність і примірка. Без узгоджених тарифних правил налаштування розрахунку доставки перетворюється на нескінченні правки після запуску.
Далі робота йде етапами, кожен завершується перевірюваним результатом:
- Аудит логістики та збір вимог — розбираємо поточні замовлення, знаходимо розходження між розрахунковою та фактичною вартістю, фіксуємо перелік служб і способів доставки.
- Узгодження тарифних правил — описуємо матрицю «зона / вага / габарити / термін», правила округлення, пороги безкоштовної доставки та надбавки. Правила затверджує замовник до початку розробки.
- Проєктування інтеграції — визначаємо, які дані надсилаються до служб доставки, як кешуються відповіді, що показуємо клієнту, якщо служба недоступна або повернула помилку.
- Налаштування розрахунку — підключаємо довідники міст і пунктів видачі, пов'язуємо кошик із тарифами, налаштовуємо поведінку калькулятора при зміні складу замовлення.
- Тестування інтеграції — проганяємо реальні замовлення: різна вага, негабарит, далекі зони, кілька служб в одному замовленні. Звіряємо розрахунок із фактичними накладними.
- Обробка відмов — перевіряємо, що відбувається при недоступності служби: клієнт бачить зрозуміле повідомлення, замовлення не втрачається, менеджер отримує сповіщення.
- Передача документації — віддаємо схему інтеграції, матрицю тарифів, інструкцію з правки правил і регламент оновлення довідників.
Ключовий момент — тестування на реальних замовленнях, а не на тестових даних: саме там випливають розходження за об'ємною вагою та негабаритом. Після здачі замовник може змінювати пороги й надбавки самостійно, без звернення до розробника. Опишіть вашу логістику — повернемося з оцінкою та планом за етапами.
Чим відрізняється розрахунок через API СДЕК від розрахунку через Укрпошту?
Розрахунок через API СДЕК будується навколо зон доставки: сервіс віддає тариф за конкретним напрямком «місто відправника → місто отримувача», і ціна залежить від того, до якої зони потрапив населений пункт.
Укрпошта працює інакше — тариф рахується за розрядом населеного пункту та вагою відправлення, а не за парою міст.
Через це однакове за складом замовлення в одному випадку рахується «від точки до точки», в іншому — «від регіону до регіону», і калькулятор доставки має вміти обидва сценарії, а не підганяти один під інший.
Обмеження за вагою та габаритами теж різні. СДЕК віддає розрахунок за фактичною та об'ємною вагою, окремо враховує негабарит і обмеження за сумою трьох вимірів. Укрпошта рахує за вагою з кроком і жорстко відсікає відправлення понад граничну масу та розмір.
Якщо не розводити ці правила в коді, клієнт побачить ціну, яку служба потім не прийме, — і замовлення відвалиться вже на етапі оформлення, а не в кошику.
Терміни оновлення тарифів — третя розбіжність. У СДЕК тарифи та зони доставки змінюються частіше і приходять разом із відповіддю сервісу, тому їх не можна кешувати надовго. В Укрпошти тарифна сітка стабільніша, але оновлюється пакетно, і між релізами можливий лаг.
Відмінності розрахунку доставки тут проявляються в тому, як часто ви смикаєте API і на який термін кладете відповідь у кеш: занадто довгий кеш дає застарілу ціну, занадто короткий — зайві запити та зростання часу відповіді кошика.
Повернення помилок — найбільш недооцінена ділянка. API СДЕК віддає структуровані коди та зрозумілі причини відмови, API Укрпошти частіше повертає загальну ознаку помилки, і розшифровувати її доводиться за контекстом запиту.
Тому в калькуляторі потрібен шар нормалізації: обидві служби приводяться до одного набору станів — «розраховано», «недоступно для цього напрямку», «перевищено обмеження», «сервіс недоступний».
Тоді інтерфейс не залежить від того, яка служба відповіла, а клієнт бачить виразну причину замість порожнього блоку з ціною.
Практичний висновок: порівнювати дві служби за одним запитом безглуздо — у них різна модель тарифікації, різні обмеження та різна дисципліна відповідей.
Калькулятор будується так, щоб кожна служба рахувалася за своїми правилами, а на виході замовник отримував зіставні варіанти з чесними термінами та зрозумілими причинами відмови.
Кейс: як калькулятор доставки скоротив час оформлення замовлення
До впровадження вартість доставки розраховував менеджер: заявка з адресою та вагою вручну йшла до особистого кабінету перевізника, відповідь поверталася протягом робочого дня, а клієнт увесь цей час не бачив ні ціни, ні терміну.
На пікових навантаженнях черга заявок зростала, частина кошиків охолоджувалася, і замовлення губилося не через товар, а через невизначеність щодо доставки.
Що змінили
Зібрали калькулятор доставки, який на сторінці оформлення сам звертається до API перевізників і віддає клієнту точну ціну та термін.
Логіку розрахунку винесено на сервер: браузер надсилає лише адресу та склад кошика, а вага, габарити й тариф підставляються з карток товарів і довідника перевізника.
- Розрахунок за двома перевізниками одразу — СДЭК і Почта России — з вибором пункту видачі на карті.
- Кеш тарифів на стороні сервера: повторні запити за популярними напрямками не б'ють в API перевізника й відповідають миттєво.
- Резервний сценарій: якщо зовнішній сервіс недоступний, клієнт бачить діапазон ціни та терміну, а замовлення йде менеджеру з позначкою на уточнення.
Метрики до та після
| Показник | До | Після |
|---|---|---|
| Час оформлення замовлення | 20-40 хвилин за участю менеджера | 2-3 хвилини без менеджера |
| Точність розрахунку | ручний перерахунок, розбіжності при негабариті | ціна та термін збігаються з підсумковою накладною |
| Частка замовлень з перерахунком доставки | кожна друга заявка | поодинокі випадки |
| Навантаження на менеджерів | ручний розрахунок по кожному кошику | лише спірні та нестандартні відправлення |
Ключовий ефект — не швидкість відповіді сама по собі, а те, що клієнт ухвалює рішення про покупку, вже бачачи підсумкову суму.
Розбіжності між ціною на сайті та в накладній, які раніше спливали після оформлення й вимагали листування, зникли: тариф розраховується за тими самими правилами, що й у перевізника.
Розрахунок побудовано на офіційних API перевізників — СДЭК і Почты России — з обробкою помилок і таймаутів, щоб недоступність зовнішнього сервісу не блокувала оформлення замовлення.
Що якщо перевізник змінить тарифи? Тарифна сітка та правила розрахунку винесені в конфігурацію, а не зашиті в код — оновлення займає хвилини без релізу.
Що якщо у товару немає габаритів? Калькулятор підставляє значення за замовчуванням і позначає замовлення для перевірки, замість того щоб показати неправильну ціну.
Сумніви перед впровадженням: сумісність, міграція, відкат
Основний ризик при впровадженні калькулятора доставки — не сам розрахунок, а стик з тим, що вже працює на сайті.
Якщо у вас є самописний розрахунок за зонами або фіксовані тарифи в базі, його не потрібно викорчовувати: обгортка над поточною логікою зберігає звичну поведінку кошика, а новий модуль підключається поруч і вмикається прапорцем.
Старі тарифи залишаються як резервний режим — якщо зовнішній сервіс недоступний, покупець бачить ціну за останньою відомою зоною, а не порожній блок.
Що якщо вже є свій розрахунок? Залишаємо його як джерело тарифів за замовчуванням і переводимо на API СДЕК та Пошти Росії лише ті напрямки, де потрібна точна вартість за вагою та габаритами. Як переносити дані?
Історію замовлень і довідник зон вивантажуємо в проміжний формат, звіряємо порядково і заливаємо в нову структуру — розбіжності за кожною позицією фіксуємо у звіті. Чи можна відкотитися?
Так: конфігурація версіонується, перемикання на попередній розрахунок — одна правка без викату нового коду.
Які доступи потрібні для інтеграції?
Тестовий і робочий ключ API СДЕК, договір і логін особистого кабінету Пошти Росії, доступ до адмінки сайту для правки шаблону кошика і до репозиторію. Секрети зберігаємо у змінних середовища, а не в коді — при зміні ключа правиться одне значення.
На руки ви отримуєте: схему потоку розрахунку з точками відмови, конфігурацію тарифів і зон, політику кешування відповідей API, скрипт міграції довідників, інструкцію з перемикання та відкату, чеклист перевірки перед запуском і документацію з доставки для підтримки.
Опишіть поточний розрахунок і стек сайту — повернемося з оцінкою та планом робіт.
Терміни впровадження калькулятора доставки: етапи та орієнтири
Терміни залежать не від кількості перевізників, а від стану каталогу та того, наскільки передбачувано поводяться їхні API. Якщо у товарів уже є габарити та вага, а склад один — проєктування й налаштування йдуть швидше.
Якщо вага розраховується за формулою з характеристик, а частина позицій їде з кількох точок, додається етап нормалізації даних, і він же найчастіше визначає загальний термін.
Етапи йдуть із частковим перекриттям: налаштування починається, поки узгоджуються правила розрахунку, а тести за регіонами запускаються до повної готовності інтерфейсу. Тому сумарний термін — зазвичай 3–5 тижнів, а не сума рядків таблиці.
Окремо варто закласти час на доступи: отримання бойових ключів і узгодження договору з перевізником іде паралельно й іноді займає більше, ніж сама розробка.
СДЕК і Пошта Росії по-різному віддають довідники та тарифи, тому розрахунок будується через єдиний внутрішній шар: перевізник підключається як окремий модуль, і додавання третього не вимагає переписувати кошик. Це ж спрощує відкат — при збої одного API калькулятор продовжує рахувати за рештою.
