Как мы построили автоматизацию логистики поверх старой 1С

Год назад картина была такой: офисная 1С, где живут заявки, реализации и платежи, — система рабочая и критичная, останавливать её нельзя ни на час; файловый обмен со складом в виде манифестов в общей папке; GPS-мониторинг по своим машинам, но без всякой связи между «машина едет там-то» и «груз клиента в этой машине»; клиент, который узнаёт статус звонком менеджеру, а менеджер — звонком водителю; и закрывающие документы, которые ездят почтой. Каждая из этих точек по отдельности терпима, но вместе они съедали рабочий день команды на ручную координацию.

Главное ограничение мы сформулировали сразу и держались его всё время: офисный сервер с 1С работает только на чтение. Никаких доработок конфигурации, никаких записей в боевую базу «на живую» — любая автоматизация строится снаружи учётной системы. Звучит как самоограничение, которое всё усложняет, но на деле именно оно спасло нас минимум дважды и задало здоровую архитектуру: сервисы для клиента не могут уронить учёт, потому что физически не имеют к нему доступа на запись. Кейс поэтому полезен всем, у кого есть работающая учётная система, которую нельзя ломать, люди, привыкшие работать как привыкли, и нет бюджета на внедрение корпоративной TMS.

Первое, что понадобилось, — доступ к данным 1С в машинном виде, потому что автоматизация на ручной выгрузке Excel это не автоматизация. Мы сделали два независимых канала: штатный интерфейс OData с отдельным пользователем, у которого права только на чтение нужных документов, и парсинг файлов складского обмена как резервный источник и как источник данных, которых в 1С попросту нет. Второй канал оказался важнее, чем мы думали: выяснилось, что связка «какой груз в какой машине» в учётной системе не ведётся вообще, а госномер автомобиля есть только в складском манифесте — без него не было бы ни трекинга, ни ETA.

Зеркало данных вместо нагрузки на боевую базу

Поверх этого мы подняли read-only зеркало данных в отдельной базе на арендованном сервере: инкрементальная синхронизация по окнам дат раз в полчаса, полная — ночью. Все витрины, отчёты и клиентские сервисы ходят в зеркало, а не в боевую 1С, поэтому скорость работы офиса не зависит от того, сколько клиентов одновременно смотрят свои отправки. Мораль для тех, кто собирается повторять: прежде чем проектировать сервис, проверьте, существуют ли в ваших данных сущности, которыми вы собираетесь оперировать, — у нас половины не существовало, и это выяснилось уже в процессе. Как всё это выглядит для клиента, видно на живом сервисе отслеживания груза.

Сборный груз едет по цепочке: забор, склад консолидации, магистраль, транзитный склад, выдача. GPS есть только на своих машинах, а часть плеч везут наёмные перевозчики и железная дорога, где трекинга в реальном времени нет в принципе. Поэтому мы строили отслеживание не на GPS-точке, а на вехах: каждое подтверждённое событие — принят на склад, погружен в такую-то машину, отправлен, прибыл на транзитный склад, выдан — плюс расчётное время прибытия на основе маршрута и истории похожих рейсов. GPS-позиция стала приятным оверлеем поверх вех, а не основой модели, и это оказалось не компромиссом, а правильным решением.

Клиенту, как выяснилось, не нужна мигающая точка посреди трассы — ему нужно знать, приедет ли груз к четвергу. Веха «отправлен со склада Челны рейсом вторника» плюс честный ETA отвечают на этот вопрос лучше, чем координаты на карте, потому что переводят технический факт в понятное обещание по дате. Сейчас отслеживание работает по номеру транспортной накладной без регистрации и показывает этап перевозки, госномер машины и ожидаемую дату прибытия — так же прозрачно, как онлайн-расчёт в калькуляторе стоимости. Для сборных отправок это особенно важно, потому что груз проходит через перевалки, и на каждой из них клиент видит новую подтверждённую веху.

Следующим шагом логично было отдать клиенту его собственные данные целиком: список отправок, статусы, счета, закрывающие документы. Главная сложность здесь оказалась не технической, а сущностной: в учётной системе клиент — это контрагент с ИНН, а в кабинете клиент — это человек с логином, и привязка между ними критична, потому что ошибка означает, что один клиент увидит документы другого. Мы сделали привязку ИНН к аккаунту подтверждаемой вручную владельцем, а не самим клиентом: медленнее, зато без сценария «зарегистрировался, вписал чужой ИНН, получил чужую бухгалтерию». Если будете делать похожее, закладывайте это правило в архитектуру сразу, а не потом.

ЭДО, который мы взяли на себя

С 1 сентября 2026 года по 140-ФЗ транспортная накладная существует только в электронном виде, и для нас это был не столько ИТ-проект, сколько продуктовое решение: можно было разослать клиентам инструкцию «подключите ЭДО, купите подпись, настройте роуминг», а можно было взять оформление на себя. Мы взяли на себя: клиент один раз присоединяется к оферте транспортной экспедиции в кабинете, а дальше поручение экспедитору, экспедиторская расписка, ЭТрН на плече с перевозчиком и закрывающие документы формируются и уходят оператору без его участия, и своя электронная подпись клиенту не нужна. Технически это самая нудная часть истории — интеграция с оператором, форматы, роуминг, стыковка номеров с учётной системой, — но именно она даёт ощутимую разницу: документы приходят в день перевозки, а не через три недели почтой, о чём мы подробно пишем в материалах об электронной транспортной накладной.

Грабли стоит перечислить честно, потому что на них наступит каждый, кто повторит путь. Первая: режим «только чтение» надо охранять, а не декларировать, — любые записи в боевую систему мы вынесли под отдельный предохранитель, который по умолчанию выключен. Вторая: данных, которые вам нужны, в учётной системе может не быть, поэтому наличие сущностей проверяется до проектирования. Третья: статусы в учётной системе отстают от реальности, флаг «отгружено» ставится, когда до него дойдут руки, и строить клиентский сервис можно только на событиях с источником вне рук менеджера. Четвёртая: не доверяйте своим же отчётам без проверки на живом документе — любая цифра для клиента сверяется с конкретным документом, а не с «данными в таблице». Пятая: доступность важнее функций, поэтому изменения сетевого контура делаются только со сторожем, который откатывает конфигурацию при потере связи.

Что всё это дало: клиент перестал звонить за статусом, документы приходят в день перевозки, склад не подписывает этикетки руками, дебиторка видна каждое утро без сборки отчётов, а требования по электронным документам закрыты и для нас, и для клиентов. Чего не дало, тоже важно сказать прямо: автоматизация не привезла ни одного нового клиента сама по себе и не сделала перевозку дешевле — экономику определяют топливо, «Платон», лизинг и загрузка обратного пути. Она лишь убирает издержки на координацию и делает обещание клиенту проверяемым, а в рынке с тонкой маржой это ровно та разница, которая позволяет небольшой компании конкурировать с сетевыми ТК не ценой, а предсказуемостью. Мы возим сборные грузы и отдельные машины из Набережных Челнов и Казани в 130+ городов России, отправки по вторникам и пятницам.