Куди зникають нічні замовлення: розбір обміну CRM з обліковою системою

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

У журналах при цьому порожньо. Не помилка, не попередження - взагалі нічого, ніби замовлення й не було. Розробники обліковки чесно кажуть: у нас слідів немає. Розробники CRM так само чесно кажуть: ми відправили.

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

Проблема: неможливо лагодити те, чого не видно

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

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

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

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

Ключова знахідка: два розклади, які ніхто не звіряв між собою

Обробник черги працює тільки з 07:30 до 21:00, кожні 10 секунд. Прибиральник, який чистить чергу від старих записів, працює цілодобово і видаляє все, що пролежало довше пʼяти хвилин.

Кожен по-своєму розумний. Разом вони дають рівно те, що бачив бізнес: з 21:00 до 07:30 замовлення падає в чергу, лежить пʼять хвилин і зникає. Обробка не починалась, тому в журналі нічого немає.

Частину нічних замовлень рятує резервний канал: облікова система раз на годину сама забирає з CRM усе, що змінилось. Але це вже не секунди, а затримка до години - і рятує він не всіх, бо в нього є власний дефект.

Друга причина: збій, якого не видно вдень

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

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

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

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

Другий результат - зміна тону розмови з підрядником. Ми передали 8 конкретних правок із посиланнями на рядки коду, а не список претензій. Це важливо сказати вголос: проблема була не в людях, а в тому, що два розклади писались у різний час і ніхто не дивився на них разом. Такі речі не ловляться ні код-ревʼю, ні тестуванням - тільки читанням системи цілком.

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

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

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

Що саме читали. Вивантажену конфігурацію облікової системи й зовнішні обробки розібрали в читабельний текст і пройшли ланцюг обміну від точки входу до створення документа. Доступу до середовища розробки при цьому не було.

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

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

Що ще знайшлось у коді дорогою:

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

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

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

Компаніям, де сайт або CRM обмінюються з обліковою системою, і час від часу «щось губиться». Особливо якщо обліковку веде зовнішній підрядник і розмова зайшла в глухий кут взаємних претензій.

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

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