Разработка приложения для транспортной компании.

Выбор решения

Сначала проверьте мобильный модуль вашей системы.

«Водитель УАТ» — внешний продукт. Совместимость будущего приложения BORNLI с вашей системой проверяется отдельно.

Модельный сценарий

Перевозка груза с изменением места выгрузки.

Это собирательный пример возможного приложения. Клиент, внедрение и результаты BORNLI в нём не заявляются. Названия статусов и порядок действий предложены для обсуждения.

Модельный сценарий. В этом примере назначение и закрытие рейса остаются в диспетчерской системе.

1. Диспетчер назначает рейс. В карточке — водитель, груз, точки, контакты и окна прибытия. Приложение показывает полученную версию задания.
2. Водитель принимает задание. Он подтверждает готовность после просмотра условий. До этого диспетчер видит «ожидает принятия»; полученное телефоном уведомление не заменяет ответ водителя.
3. Водитель отмечает ход рейса. В примере доступны прибытие и завершение работ на каждой точке. Если груз не готов, водитель сообщает причину ожидания; диспетчер решает, как изменить план.
4. Диспетчер меняет место выгрузки. Система сохраняет прежнее задание. Водитель просматривает и принимает новую версию. Диспетчер отдельно видит получение изменения устройством и подтверждение водителем.
5. Диспетчер проверяет завершение. После последней выгрузки рейс переходит в «на проверке». Диспетчер проверяет события и обязательные вложения, затем закрывает рейс или возвращает с вопросом.

Статусы и ответственность

Опишите, кто и на каком основании меняет состояние рейса.

Это предложенные состояния модельного сценария. События маршрута и состояние обмена отображаются отдельно.

«Ожидает отправки» — состояние обмена. Водитель может отметить прибытие без связи, если такая работа включена в проект. До подтверждения сервером приложение показывает событие в очереди, а диспетчер видит время последнего обновления. В истории полезно хранить отдельно время события и время его получения системой.

Для каждого перехода запишите: кто его выполняет, какие данные обязательны, можно ли отменить действие и кто разбирает конфликт. Эта запись становится основой прототипа и приёмки.

Первая версия

Соберите один путь от задания до закрытого рейса.

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

Единица работы здесь — грузовой рейс. Осмотры и обслуживание относятся к управлению автопарком; складские операции разобраны на странице приложения для склада. Как выбрать объём первой рабочей версии.

Обмен с диспетчерской системой

Пять решений до оценки интеграции.

1. Где хранится действующее задание. В примере рейс и актуальную версию создаёт TMS. Каждое событие связывается с рейсом, точкой и версией задания.
2. Как поступает изменение маршрута. Нужны три подтверждения: сохранено системой, получено устройством, принято водителем. Согласуйте действия диспетчера, если водитель недоступен.
3. Что происходит со старой версией. Позднее событие сохраняется с исходной точкой и версией. Спорный результат передаётся диспетчеру на разбор.
4. Кто видит и меняет данные. Согласуйте права при смене водителя, отмене и закрытии. Для внешних перевозчиков определите доступные грузы, контакты и вложения.
5. Как проверяется обмен. Запросите описание доступных методов, тестовый рейс и среду. Повторная отправка должна распознаваться как та же операция, подтверждение — возвращаться в приложение.

Возможность читать и менять нужные данные, ограничения доступа, лицензии и ответственность за доработку системы выясняют с её сопровождающим специалистом.

В примере фото — вложение к событию. Юридически значимый документооборот определяют отдельной задачей: документы, участники, оператор и способ подписания.

Лист приёмки

Проверьте изменение задания после его принятия.

Предлагаемый тест для будущей рабочей версии. Рейс TR-TEST-01, склад А и склад Б — вымышленные обозначения тестовых данных. Критерии нужно согласовать с вашим процессом до разработки.

Что сохранить для приёмки: версии задания до и после изменения, историю подтверждений, событие с устройства и результат в диспетчерской системе. Они покажут, какое задание было доступно участникам в момент действия.

Ещё четыре проверки перед первым рабочим рейсом.

1. Отказ от назначения. Причина возвращается диспетчеру, а рейс не отображается принятым. Повторное назначение имеет понятную историю.
2. Замена водителя. Прежний водитель теряет право менять рейс по согласованным правилам, новый получает актуальное задание. История прежних действий сохраняется.
3. Задержка на погрузке. Время и причина ожидания доходят до диспетчера. Изменение плана проходит тот же порядок подтверждения, что и смена точки.
4. Результат принят, ответ потерян. После восстановления связи повторная отправка не создаёт второе событие. Приложение получает подтверждение уже принятой операции.

Модельный сценарий и предложенные критерии приёмки. Это не отчёт о тестировании готового транспортного приложения BORNLI.

Обсудить разработку

Пришлите пример рейса и одно сложное изменение.

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

Пример короткого обращения

Модельный сценарий: вымышленный текст для подготовки вашей заявки, не обращение клиента BORNLI.

«Рейсы ведём в диспетчерской системе, изменения отправляем водителям сообщениями. При замене склада не всегда понятно, увидел ли водитель новый адрес. Хотим показывать актуальное задание в приложении, получать подтверждение водителя и сохранять историю изменений. Первым этапом проверим назначение рейса и смену точки выгрузки. Описание обмена уточним с нашим специалистом».

Замените этот пример своим процессом. Для оценки объёма пригодятся следующие данные:

1. Пример задания без реальных контактов и конфиденциальных данных: груз, точки, окна прибытия и необходимые события.
2. Правила назначения, отказа, смены водителя и закрытия рейса; роли, которые принимают решения.
3. Пример отклонения: изменили выгрузку, груз не готов или водитель не вышел на связь. Что диспетчер делает сейчас?
4. Название и версию TMS, 1С или другой системы, описание доступного обмена и контакт ответственного за неё специалиста.
5. Рабочие устройства, требования к офлайн-действиям и результат, который вы хотите увидеть при сдаче первой версии.

На обсуждении определим состав приложения и сценарий прототипа. Обсудить приложение для транспортной компании ↗.

Редакция BORNLI. Подготовлено 13 октября, проверено перед публикацией 15 октября 2026 года. Модельный сценарий, статусы и лист приёмки разработаны для этой статьи. Описание внешнего продукта 1С проверено по первичному источнику 15 октября 2026 года.