Зачем связывать медосмотры с 1С:Управление автотранспортом
1С:Управление автотранспортом (УАТ) уже содержит журналы транспортных документов и блок учета предрейсовых медосмотров, которые используются для контроля ТС по путевым листам. Если оставить медосмотр “отдельной системой”, диспетчер получает разрыв: статус допуска хранится у медика, а 1С видит только путевой лист.
Интеграция даёт автопарку:
-
единый источник правды по допуску водителя к рейсу (1С, TMS, ЭПЛ);
-
автоматическую привязку результата осмотра к конкретному водителю и путевому листу;
-
закрытие требований закона по фиксации времени и результата медосмотра в документах.
По факту это связь “кабинет/терминал медосмотра → журнал медосмотров → путевой лист → ЭПЛ → TMS”.
Какие данные должны передаваться автоматически
Типовой набор данных, который уходит из системы медосмотра в 1С и TMS:
-
идентификатор водителя (ФИО, табельный номер, уникальный ID);
-
дата и время предрейсового медицинского осмотра;
-
результат: “допущен” / “не допущен”;
-
идентификатор записи/заключения (для связи с журналами и медицинской организацией);
-
при необходимости — показатели давления, пульса, температуры, факт проверки на алкоголь (без раскрытия лишних медданных в TMS).
В учётных системах это выглядит так:
-
в 1С:УАТ — запись в журнале предрейсовых осмотров + флаг допуска для связанного путевого листа;
-
в системе электронных путевых листов (ЭПЛ) — автоматическое заполнение титула Т2 “Предрейсовый медосмотр” и изменение статуса путевого листа;
-
в TMS-платформе — статус “водитель допущен/не допущен”, который участвует в логике выпуска, планирования рейса и контроля заказов.
Цель: чтобы диспетчеру не нужно было вручную переносить данные из кабинета в 1С или ЭПЛ — система должна сама “запретить” выпуск при недопуске.
Как работают терминалы СоюзМедТранс через API (концепция)
По рынку уже есть готовые примеры интеграции терминалов дистанционных медосмотров с 1С и ЭПЛ через API. Логика терминалов СоюзМедТранс может и должна строиться так же.
Пошагово:
-
Водитель подходит к терминалу
Идентификация (карта, PIN, QR-код, интеграция с табельным номером). -
Терминал проводит измерения
Давление, пульс, температура, проверка на алкоголь, фото/видео фиксация при необходимости. -
Формируется медицинское заключение
Система формирует результат (“допущен/не допущен”), присваивает уникальный идентификатор записи. -
Передача в ЭПЛ/1С/TMS через API
Терминал отправляет структурированный JSON/файл обмена с результатами осмотра в:
-
систему электронных путевых листов (титул Т2 в формате, который использует 1С-ЭПД);
-
1С:УАТ (обновление журнала медосмотров и связанного путевого листа);
-
TMS-платформу (разрешение/запрет выпуска машины и назначения рейса).
-
Автоматический блок/разрешение выпуска
TMS/1С проверяет статус: при “допущен” путевой лист переводится в состояние “готов к рейсу”, при “не допущен” блокируется выпуск, а диспетчеру приходит уведомление.
На уровне API это простая схема: терминал — поставщик события “осмотр завершён, статус такой-то”, учётные системы — потребители, которые меняют состояние документов и объектов.
Какие TMS-платформы могут работать с дистанционными осмотрами
С точки зрения интеграции главное не название TMS, а наличие:
-
REST/JSON API или другого интерфейса обмена;
-
возможности хранить статус допуска водителя;
-
привязки водителя к рейсу/заказу/ТС в системе.
По рынку встречаются решения, которые уже декларируют интеграцию электронный медосмотр TMS автопарк: дистанционные медосмотры с интеграцией в ERP и TMS, включая 1С-решения и внешние платформы.
Примеры, которые можно упомянуть в статье как ориентиры:
-
1С:Управление автотранспортом (ПРОФ) + модуль взаимодействия с API телемедицинских сервисов;
-
системы электронных путевых листов (1С-ЭПД и совместимые решения), умеющие принимать файл/сообщение Т2 “Предрейсовый медосмотр”;
-
TMS-платформы, в которых уже реализована интеграция с дистанционными медосмотрами: отдельные B2B-решения заявляют “Интеграция с 1С и ERP, электронные журналы осмотров”.
Пошаговое руководство по интеграции
Для IT-директора и руководителя автопарка полезно дать понятный маршрут.
Шаг 1. Описать бизнес-процесс
-
от регистрации водителя на осмотр;
-
до выпуска ТС на линию и закрытия рейса.
Чётко прописать точки, где нужен статус “допущен/не допущен”.
Шаг 2. Определить учётные системы
-
какая версия 1С:УАТ/ERP используется;
-
есть ли ЭПЛ (и какая система его формирует);
-
какие TMS/логистические платформы стоят сверху.
Шаг 3. Оценить возможности API
-
есть ли API у терминалов предрейсовых осмотров (СоюзМедТранс — телемедицинский сервис/терминалы);
-
есть ли API/обменные форматы у 1С, ЭПЛ и TMS (в 1С это может быть веб-сервис, HTTP-сервис или стандартный формат файла обмена).
Шаг 4. Спроектировать формат обмена
Минимальный JSON/файл должен содержать:
-
ID водителя;
-
дату/время осмотра;
-
результат (bool/enum);
-
ID медорганизации/терминала;
-
при необходимости — ID путевого листа (если он уже сформирован).
Ориентироваться можно на структуру титула Т2 из 1С-ЭПД и описанные схемы интеграции терминалов с ЭПЛ.
Шаг 5. Реализовать интеграцию и протестировать
-
настроить передачу данных из терминала на тестовый контур 1С/TMS;
-
проверить, что при “допущен” путевой лист/рейс переходит в нужный статус, а при “не допущен” система блокирует выпуск;
-
настроить уведомления диспетчеру и ответственным (e-mail, SMS, внутри TMS).
Шаг 6. Закрепить регламент и обучение
-
прописать, что выпуск ТС возможен только при статусе “допущен” в системе;
-
обучить диспетчеров, медиков и IT, как реагировать на ошибки/ситуации недопуска.
Экономия времени диспетчера и сокращение рисков
По описаниям решений на рынке, дистанционный предрейсовый медосмотр занимает 1–2 минуты, а данные сразу уходят в электронный журнал и ERP/TMS.
Это даёт автопарку:
-
снижение ручного ввода (не нужно переписывать данные из бумажного журнала в 1С и TMS);
-
сокращение ошибок человеческого фактора при переносе информации
-
ускорение выпуска транспорта на линию — статус “допущен” появляется в системе сразу после осмотра
-
прозрачную историю осмотров для проверок и внутренних аудитов.