Налаштування трекінгу відправлень на 1С-Бітрікс

Трекінг відправлень — завдання, яке на перший погляд здається простим, поки не починаєш робити його правильно. «Показувати статус замовлення» означає: отримувати актуальний статус від перевізника, зберігати історію статусів, сповіщати покупця при зміні, коректно відображати в особистому кабінеті. На практиці це вимагає грамотної архітектури, відмовостійкого агента та інтеграції з різними API. Ми, сертифіковані спеціалісти 1С-Бітрікс, зібрали перевірене рішення під ключ. Ручна перевірка статусів — дороге задоволення: оператор витрачає в середньому 5 хвилин на одне замовлення, а при 500 замовленнях на місяць це 40–60 робочих годин. Автоматизація трекінгу в 5 разів ефективніша за ручну перевірку і окупається за кілька місяців.

Чому ручна перевірка статусів неефективна?

Кожен сервіс доставки має свій формат API, обмеження за частотою запитів та способи авторизації. Наприклад, СДЕК використовує OAuth-токени і повертає детальний статус з 30+ кодами, а Пошта Росії вимагає ключ доступу і працює через SOAP. Ми реалізуємо абстракцію: єдиний інтерфейс TrackerInterface, під який пишемо конкретних трекерів. Це спрощує додавання нових перевізників і заміну застарілих. Автоматизований трекінг у 5 разів знижує навантаження на підтримку порівняно з ручним — це підтверджують проекти з впровадженням.

Проблеми, які вирішує трекінг

Типові болі інтернет-магазину: клієнти дзвонять «де моє замовлення?», оператори витрачають години на ручну перевірку статусів, загублені посилки виявляються занадто пізно. Автоматичний трекінг знімає ці проблеми:

• Зниження навантаження на підтримку на 60–70% — покупець бачить статуси сам.
• Раннє виявлення збоїв — якщо статус не оновлюється більше N днів, система шле алерт.
• Підвищення лояльності — прозорість процесу прискорює прийняття рішення про повторну покупку (зростання повторних замовлень на 15–20% за даними наших проектів).

Чому автоматичний трекінг вигідніший за ручний?

Автоматизація трекінгу окупається за рахунок зниження витрат на підтримку та зменшення кількості скасувань замовлень через невизначеність. В одному з проектів після впровадження кількість запитів у тикети по доставці скоротилася на 70%, а повторні покупки зросли на 15%. Крім того, система сама фіксує затримки доставки — ви зможете оперативно реагувати. Порівняйте: ручна перевірка 500 замовлень займає ~40 годин на місяць, автоматизований агент — 0.5 години на сервер.

Як налаштувати трекінг: покрокова інструкція

1. Аналіз — визначаємо перевізників та їх API, узгоджуємо структуру даних.
2. Проектування — створюємо таблицю історії (HL-блок або кастомна ORM-таблиця) та агента.
3. Реалізація — пишемо класи-трекери для кожного перевізника, налаштовуємо крон.
4. Сторінка в ОК — розробляємо компонент для відображення історії статусів.
5. Сповіщення — налаштовуємо email-шаблони при зміні статусу.
6. Тестування — перевіряємо на тестових замовленнях, логуємо помилки.
7. Деплой та документація — передаємо код, доступи, навчаємо вашого розробника.

Як ми це робимо: стек і приклад реалізації

Використовуємо штатні механізми Бітрікс: агенти, ORM, інфоблоки v2.0. Для зберігання історії створюємо таблицю custom_tracking_history (HL-блок або кастомна таблиця через ORM). Агент опитує API перевізників для замовлень в активних статусах (N, P, Q). Приклад базової структури:

// Таблиця історії трекінгу (міграція) class TrackingHistoryTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'custom_tracking_history'; } public static function getMap(): array { return [ new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new \Bitrix\Main\ORM\Fields\IntegerField('ORDER_ID'), new \Bitrix\Main\ORM\Fields\StringField('CARRIER'), // sdek, boxberry, etc. new \Bitrix\Main\ORM\Fields\StringField('TRACK_NUMBER'), new \Bitrix\Main\ORM\Fields\StringField('STATUS_CODE'), new \Bitrix\Main\ORM\Fields\StringField('STATUS_TEXT'), new \Bitrix\Main\ORM\Fields\StringField('LOCATION'), // поточне місцезнаходження new \Bitrix\Main\ORM\Fields\DatetimeField('STATUS_DATE'), new \Bitrix\Main\ORM\Fields\DatetimeField('CREATED_AT'), ]; } } 

Агент циклічно опитує замовлення і при зміні статусу зберігає запис та відправляє сповіщення. Код агента:

class DeliveryTrackingAgent { public static function run(): string { // Вибираємо замовлення з трекінг-номерами в активних статусах $orders = \Bitrix\Sale\Order::getList([ 'filter' => [ '!PROPERTY_TRACK_NUMBER' => false, 'STATUS_ID' => ['N', 'P', 'Q'], // не закриті ], 'select' => ['ID', 'PROPERTY_TRACK_NUMBER', 'PROPERTY_CARRIER_CODE'], ]); $carriers = [ 'sdek' => new SdekTracker(), 'boxberry' => new BoxberryTracker(), 'pochta' => new PochtaTracker(), ]; while ($order = $orders->fetch()) { $carrier = $carriers[$order['PROPERTY_CARRIER_CODE_VALUE']] ?? null; if (!$carrier) continue; try { $status = $carrier->getStatus($order['PROPERTY_TRACK_NUMBER_VALUE']); self::saveStatus($order['ID'], $status); } catch (\Throwable $e) { // логуємо, не падаємо \Bitrix\Main\Diag\Debug::writeToFile($e->getMessage(), 'tracking', '/local/logs/tracking.log'); } } return __CLASS__ . '::run();'; } private static function saveStatus(int $orderId, array $status): void { // Перевіряємо, чи змінився статус $last = TrackingHistoryTable::getRow([ 'filter' => ['ORDER_ID' => $orderId], 'order' => ['STATUS_DATE' => 'DESC'], 'select' => ['STATUS_CODE'], ]); if ($last && $last['STATUS_CODE'] === $status['code']) return; // не змінився TrackingHistoryTable::add([ 'ORDER_ID' => $orderId, 'STATUS_CODE' => $status['code'], 'STATUS_TEXT' => $status['text'], 'LOCATION' => $status['location'] ?? '', 'STATUS_DATE' => new \Bitrix\Main\Type\DateTime($status['date']), 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), ]); // Відправити сповіщення при зміні статусу self::notifyCustomer($orderId, $status); } } 

// У методі notifyCustomer $event = new \Bitrix\Main\Mail\Event(array( 'EVENT_NAME' => 'TRACKING_STATUS_CHANGED', 'LID' => SITE_ID, 'C_FIELDS' => array( 'ORDER_ID' => $orderId, 'STATUS_TEXT' => $status['text'], 'TRACK_NUMBER' => $trackNumber, ), )); $event->send(); 

Сторінка трекінгу в особистому кабінеті

Для відображення історії в особистому кабінеті використовується компонент, який вибирає дані з TrackingHistoryTable. Приклад отримання даних:

// Компонент відображення історії трекінгу $orderId = (int)$_REQUEST['ORDER_ID']; $order = \Bitrix\Sale\Order::load($orderId); if ($order && $order->getUserId() === $USER->GetID()) { $history = TrackingHistoryTable::getList([ 'filter' => ['ORDER_ID' => $orderId], 'order' => ['STATUS_DATE' => 'ASC'], 'select' => ['STATUS_CODE', 'STATUS_TEXT', 'LOCATION', 'STATUS_DATE'], ])->fetchAll(); // Трекінговий номер для посилання на сайт перевізника $trackNumber = $order->getPropertyCollection() ->getItemByOrderPropertyCode('TRACK_NUMBER') ?->getValue(); } 

Що входить в роботу під ключ

• Аналіз поточних замовлень і використовуваних перевізників.
• Розробка таблиці історії трекінгу (HL-блок або кастомна таблиця).
• Написання класів-трекерів для кожного перевізника.
• Налаштування агента з логуванням і обробкою помилок.
• Розробка сторінки історії в особистому кабінеті покупця.
• Email-сповіщення при зміні статусу (шаблони листів).
• Документація та інструкція з додавання нових перевізників.
• Передача доступів до сервера і коду, навчання вашого розробника.
• Технічна підтримка протягом місяця після здачі.

Строки

Бажаєте отримати консультацію по своєму проєкту? Напишіть нам — ми оцінимо обсяг робіт і запропонуємо оптимальне рішення. Досвід реалізації — понад 20 проєктів з трекінгом, гарантія якості та дотримання термінів. Отримайте безкоштовну оцінку вашого проєкту — просто напишіть нам.