Накладна, яку ніхто не створює руками: 7 000+ ТТН за півтора місяця

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

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

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

Проблема: хвилина, яка зʼїдає цілу посаду

Магазин відправляє двома перевізниками, кількома каналами продажу і від різних відправників. Кожне замовлення проходить через ручне оформлення, і кожне ручне оформлення - це місце для помилки.

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

Як автоматизація це вирішує

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

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

Ключова ідея: краще не створити, ніж створити неправильно

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

Коли перевізник лежить: власна наклейка

У вересні власник попросив закрити ще один випадок: накладна є, а надрукувати її неможливо, бо не працює сторона перевізника. Тепер у кабінеті складу є розділ «Наклейки». Комірник сканує або вводить номер - і отримує наклейку 100×100 мм зі штрихкодом і всіма реквізитами, без жодного звернення до перевізника.

Можна відмітити одразу всі посилки в черзі й надрукувати пачкою. Штрихкод той самий, що на офіційній наклейці, і читається сканером рівно як номер накладної.

Що це дало бізнесу

За півтора місяця система створила 7 235 накладних: 5 695 Нової Пошти і 1 540 Укрпошти. У середньому 141 на день, у пікові дні понад 200. Людина, яка раніше робила це руками, тепер займається тим, що справді потребує людини.

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

Окрема користь, якої ніхто не замовляв на старті, - сторож. Люди поруч із конвеєром теж помиляються: хтось робить накладну руками поверх уже створеної, хтось повертає зібране замовлення на збирання ще раз. За півтора місяця команда отримала 126 сигналів про другу накладну і 343 про повторне збирання вже оформленого замовлення. Кожен із них - потенційно посилка, яка поїхала б двічі, а вдруге безкоштовно. Тепер про це дізнаються того ж дня, а не коли товар уже в дорозі.

Чесно про межі. Система не виправляє помилки в самому замовленні: якщо менеджер не вказав відділення, його доведеться вказати. Наклейка з кабінету рятує лише тоді, коли накладна вже існує: якщо перевізник не дає створити саму накладну, друкувати нічого. І те, що відділення приймає таку наклейку без питань, підтверджує тільки практика на відділенні.

Як це влаштовано всередині

Сервіс на FastAPI працює на сервері клієнта поруч із дзеркалом бази CRM у PostgreSQL. Він не смикає CRM постійно: замовлення в потрібному статусі читаються з дзеркала, а в CRM йде лише запис номера накладної і зміна статусу. Власний цикл опитування на asyncio, окремий щогодинний цикл звірки чеків.

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

Запуск ішов сходинками, і кожна сходинка - окремий запобіжник у конфігурації: вимикач, режим «повний цикл без запису», лише замовлення з тестового контакту, точковий список замовлень, добовий ліміт, виключені способи доставки (самовивіз, магазини, маркетплейс зі своєю логістикою). Кожен знімався лише після перевірки попереднього.

Сторож - окремий цикл, який дивиться на те, що зробили люди. Три перевірки різної природи: у картці стоїть не та накладна, яку створила система (хтось зробив другу); одна накладна на замовленнях різних клієнтів (обʼєднання посилок одного клієнта - норма, тому вирішує телефон); замовлення повернули на збирання, коли накладна вже існує. Для післяплати ще одна: накладну створено від іншого ФОП, ніж у замовленні, - тоді гроші й фіскальний чек розійдуться. Кожен сигнал іде в Telegram команді один раз, а щоденне «живий» від сервісу означає, що тиша - це справді «все добре».

Післяплата виявилась найскладнішою частиною. На замовлення з передоплатою її треба ставити тільки на залишок, а чек зі знижкою передоплати має зʼявитися до вручення. Тому окремий цикл щогодини звіряє: чи є чек на кожну зібрану післяплату. Сигнал іде не за фактом «чека немає», а за фактом «чека немає вже довго», бо половина чеків зʼявляється ще до збірки.

Кому це підходить

Інтернет-магазинам і виробникам, які відправляють від кількох десятків посилок на день, особливо якщо є кілька перевізників, кілька відправників або післяплата з частковою передоплатою. Працює з CRM, де статус замовлення вже означає «готово до відправки».

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

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