Интеграция 1С с АС ЭТРАН в режиме АСУ-АСУ: что нужно знать до старта проекта
Мы несколько лет занимаемся интеграцией «1С:Предприятия» с АС ЭТРАН и за это время собрали практический набор наблюдений: какие процессы реально автоматизируются, какие документы есть смысл забирать в 1С, где проходят границы возможностей, что в проекте зависит от РЖД, а что от 1С-команды. Эта статья – для тех, кто впервые сталкивается с задачей: внедренцев, ИТ-директоров и 1С-специалистов, которым предстоит оценить такой проект. Решения по коду и коммерческие детали мы здесь не раскрываем – речь про условия, ограничения и порядок действий, о которых редко говорят заранее.
1. Почему возникает задача
Типовая ситуация выглядит так. В компании есть процессы, связанные с железнодорожными перевозками, и вся работа с ними идёт в АС ЭТРАН – системе РЖД для оформления заявок, накладных, ведомостей и прочих документов. Параллельно живёт «1С:Предприятие», где ведется управленческий и бухгалтерский учёт. Между двумя системами – Excel (как правило, с номерами вагонов, датами отправления/прибытия, простоями и прочей оперативной информацией), ручной перенос данных, пересылка PDF по почте и постоянные уточнения «где сейчас вагон» и «какой статус у заявки».
Следствий несколько, и они накапливаются. Доступ в ЭТРАН обычно есть только у логистов, поэтому отделы продаж, снабжения и финансов вынуждены дёргать логистов по каждому вопросу. Управленческая отчетность по перевозкам – доходность, простои, затраты по вагонам – собирается вручную, долго и с ошибками. Планирование погрузки и разгрузки идёт без оперативных данных о подходе вагонов. А заявки ГУ-12, которые не скорректировали вовремя, превращаются в повышенные штрафы.
Интеграция 1С с ЭТРАН как способ закрыть эти проблемы существует не первый год. Но у неё есть регуляторные и технические условия, без которых проект не запускается, и именно про них – основная часть статьи.
2. Какие задачи закрывают интеграцией
Прежде чем переходить к условиям, коротко – что в принципе автоматизируют, когда соединяют 1С и ЭТРАН:
- загрузка заявок ГУ-12 и накладных ГУ-27 (в том числе с печатными формами и электронной подписью);
- получение ведомостей подачи-уборки, накопительных ведомостей, актов общей формы, уведомлений ГУ-2;
- контроль статусов заявок по данным учётной карточки;
- загрузка УПД и УКД с разнесением сумм по вагонам и накладным;
- отслеживание дислокации вагонов и контейнеров, история операций, расчёт простоев;
- запрос справок по подвижному составу – техническое состояние, ремонты, паспорта вагонов;
- создание заявок и накладных непосредственно в 1С с последующей отправкой в ЭТРАН.
Это список возможностей. Дальше – не про функции, а про условия, без которых ни одна из них не заработает.
3. Что нужно понять до старта проекта
Это самая важная часть. Большинство сложностей в таких проектах не в коде, а в том, что команда узнаёт о требованиях слишком поздно.
ПТР и режим АСУ-АСУ
Первое заблуждение, которое нужно снять: интеграция с ЭТРАН – это не «1С отправляет запросы на сайт ЭТРАН». Обмен идёт в режиме АСУ-АСУ, то есть система-система. Это отдельный канал взаимодействия с РЖД, и чтобы его открыть, нужен согласованный с РЖД проект технических решений – ПТР.
ПТР оформляется через ТЦФТО – территориальный центр фирменного транспортного обслуживания РЖД. Это не разработка и не настройка софта, а организационно-регуляторная процедура: согласование того, как и какими данными ваша система будет обмениваться с АС ЭТРАН. Со стороны РЖД оформление ПТР бесплатное. Ключевой момент для планирования сроков: оформление, согласование и подписание ПТР занимает примерно 1–2 месяца. Здесь важно понимать, что ЭТРАН относится к объектам критической информационной инфраструктуры (КИИ) РФ, поэтому к каналам взаимодействия предъявляются повышенные требования по информационной безопасности. Именно этим обусловлен особый, строго регламентированный порядок согласования подключения.
С учетом этого фактора регуляторная часть проектам может быть длиннее технической, и она не зависит от вендора или качества вашей штатной 1С-команды. Правильный порядок – запускать оформление ПТР параллельно с этапом на котором команда проекта снимает требования с бизнес-заказчика, изучает документацию по интеграции и проектирует архитектуру. Закладывайте 1–2 месяца как ориентир, а не как обязательство.
ViPNet и защищённый канал
Обмен 1С с ЭТРАН в режиме АСУ-АСУ идёт через защищенный канал с использованием ViPNet Client или ViPNet Coordinator. Это инфраструктурное требование, а не строчка в техническом задании, которую можно «дописать потом».
В инструкцию по настройке ViPNet здесь углубляться не будем – это отдельная задача для системных администраторов. Важно понимать другое: «просто SOAP-запрос из 1С» в этой схеме не сработает. Защищённый канал нужно развернуть таким образом чтобы запросы с сервера 1С могли «достучаться» до ЭТРАНа и это тоже часть подготовки, которую лучше начинать заранее, а не обнаруживать в середине проекта. В случае если подключение осуществляется с использованием ViPNet Client (а таких в нашей практике большинство) рекомендуем приобрести дополнительную лицензию и указать именно её номер в ПТРе.
Клиент-серверная 1С
Главная ценность интеграции – автоматическая загрузка документов и дислокации без участия человека. В 1С это реализуется через регламентные задания, которые запускаются по расписанию. А регламентные задания требуют серверного контура. На файловой базе интеграция будет работать, однако придется всегда держать 1С запущенной на каком-то из компьютеров что является не самым надежным решением.
Практический вывод: для полноценной работы нужен клиент-серверный вариант «1С:Предприятия», платформа 8.3.14 или выше. Если у компании сейчас файловая база, переход на серверный вариант становится частью проекта – и это влияет на смету и сроки. Проверить конфигурацию и вариант базы стоит до того, как обсуждать функциональность.
Ограничения, о которых нужно знать сразу
Честный разговор про границы возможностей экономит всем нервы. Факты, которые лучше проговорить с бизнесом на старте:
Дислокация доступна не по любому вагону, а только по перевозкам, в которых ваша компания является участником. Посмотреть произвольный чужой вагон через интеграцию нельзя – это ограничение самого ЭТРАН, а не модуля.
Запрос печатных PDF-форм накладной из 1С всегда платный и тарифицируется РЖД по их действующему прайс-листу. Это отдельная операция, и её платность не зависит от вендора интеграции.
Важно не путать её с хранением документов – об этом ниже, в разделе про архив.
Эти ограничения не делают интеграцию менее полезной. Но если о них узнают уже после внедрения, разговор с бизнесом получается неприятным.
4. Архитектура обмена: как это выглядит
Без раскрытия исходного кода общую схему можно показать так:
1С → модуль интеграции → защищённый канал ViPNet → шлюз ЭТРАН → АС ЭТРАН 1С ← документы, статусы, справки, дислокация ← ЭТРАН
Получать данные можно в двух режимах. Ручной запрос – когда пользователь сам инициирует загрузку: по идентификатору документа, по его номеру или списком за период. Автоматический режим – когда документы и дислокация подгружаются по расписанию через регламентное задание, без участия человека. Именно второй режим даёт основной эффект, и именно он требует серверной 1С.
Ещё один вопрос, который обычно волнует 1С-специалистов: не сломает ли модуль типовые обновления конфигурации. Поставка в виде расширения (.cfe) или отдельной конфигурации (.cf) ставится «сбоку» и на обновление типовых конфигураций не влияет. Это снимает один из частых страхов на этапе оценки.
5. Какие данные имеет смысл хранить в 1С
Когда обмен настроен, в 1С есть смысл накапливать:
- сами документы ЭТРАН – накладные, заявки, ведомости, акты;
- печатные формы документов;
- статусы заявок и накладных и историю их изменения;
- историю дислокации вагонов и контейнеров;
- связку «вагон – накладная – УПД – затраты» как основу для управленческой аналитики;
- нормативно-справочную информацию по вагонам и контейнерам.
Отдельно стоит разобрать тезис про архив, потому что его легко сформулировать неточно. В АС ЭТРАН документы доступны бесплатно только ограниченное время, после чего доступ к ним становится платным. Поэтому уже полученные документы имеет смысл хранить локально в 1С – там они лежат бесплатно и бессрочно. Ценность локального архива не в том, что «ЭТРАН платный», а в том, что вы не запрашиваете и не оплачиваете повторно то, что однажды уже выгрузили, и не зависите от сроков хранения на стороне ЭТРАН.
Это не то же самое, что платность печатных PDF-форм из раздела 3. Хранение ранее полученных документов в 1С — бесплатно. Запрос свежей печатной формы накладной с электронной подписью — платная операция РЖД.
6. Типовые ошибки внедрения
Ошибки в таких проектах повторяются от компании к компании. Перечислим их вместе с причинами и последствиями – так понятнее, как их избежать.
- Начинать с разработки, не проверив ПТР и доступы. Команда садится писать код, а потом проект на 1–2 месяца встаёт в ожидании согласования с РЖД. Результат – сорванные сроки и простой оплаченных специалистов. ПТР запускают первым шагом.
- Не назначить владельца процесса со стороны логистики. Если нет человека, который принимает решения по данным и приоритетам, интеграция повисает: разработчику не у кого уточнять, а бизнес не понимает, кто отвечает за результат.
- Хотеть «всё и сразу». Документы, отправка, дислокация, справки и аналитика одним заходом – проект раздувается, усложняется и рискует не дойти до работающего результата. Лучше поэтапно (см. следующий раздел).
- Не продумать права доступа в 1С. Либо данные ЭТРАН видят все подряд, либо доступ снова остаётся только у логистов – и тогда теряется сам смысл «единого окна» для других отделов.
- Не хранить историю статусов и дислокации. Без накопленной истории невозможно посчитать простои и доходность перевозок. Данные «здесь и сейчас» есть, а базы для анализа нет.
- Не связать документы ЭТРАН с управленческой аналитикой. Документы загружаются в 1С, но не попадают в управленческие отчёты – техническая интеграция сделана, а бизнес-эффекта нет.
7. Минимальный MVP: разумный порядок внедрения
Чтобы не утонуть в объёме, имеет смысл двигаться поэтапно.
Шаг 1. Загрузка документов из ЭТРАН в 1С. Это база: документы, статусы, локальный архив, контроль. Уже на этом этапе появляется заметный эффект, а отделы перестают зависеть от логистов в части доступа к данным.
Шаг 2. Дислокация вагонов или контейнеров. Подключается, если у компании регулярная работа с подвижным составом и нужен оперативный контроль движения грузов.
Шаг 3. Справки и НСИ. Актуальны, когда важны характеристики вагонов, данные о ремонтах и техническом состоянии – например, чтобы не отправить вагон с истекающим сроком ремонта.
Шаг 4. Отправка документов из 1С в ЭТРАН. Имеет смысл подключать, когда процесс уже стабилизирован и понятно, кто отвечает за корректность данных на стороне 1С. Отправка работает в связке с загрузкой документов, отдельно – нет.
Такая поэтапность снижает риск: каждый следующий шаг подключается, когда предыдущий уже работает и понятно, кто отвечает за данные. Браться за весь объём сразу — частая причина, почему проект не доходит до результата
8. Чек-лист перед стартом проекта
Короткий список для самопроверки – по сути, краткое резюме третьего раздела:
Перед стартом интеграции 1С с АС ЭТРАН проверьте:
- Есть ли действующий договор / процедура АСУ-АСУ с РЖД
- Понятно ли, кто и когда оформляет ПТР через ТЦФТО
- Есть ли ViPNet и доступ к защищённому каналу
- Какая конфигурация 1С используется
- Клиент-серверная ли база (нужна для автозагрузки по расписанию)
- Какие документы нужны: ГУ-12, ГУ-27, ведомости, акты, УПД
- Нужна ли отправка документов из 1С в ЭТРАН
- Нужна ли дислокация вагонов / контейнеров
- Кто будет пользователем: логистика, продажи, снабжение, финансы
- Какие отчёты бизнес хочет получить после интеграции
Если на старте не закрыты первые пять пунктов, начинать разработку рано – она просто упрётся в ожидание.
9. Делать самим или брать готовое решение
Закономерный вопрос для 1С-специалиста: собрать интеграцию своими силами или взять готовый продукт. Ответ зависит от того, насколько регулярны железнодорожные перевозки в компании, и от трезвой оценки трудоёмкости.
Что в таком проекте действительно сложно и долго: освоение протокола обмена с АС ЭТРАН, развёртывание и согласование защищённого канала ViPNet, прохождение ПТР, а главное – последующая поддержка при изменениях форматов и требований на стороне РЖД. Последнее особенно важно: интеграция – это не разовая задача, её нужно сопровождать. Что относительно проще: интерфейсная часть в 1С и отчётность.
Отдельно стоит сказать про отсутствие тестового контура у ЭТРАН. Нет среды, где можно безопасно отлаживать обмен, имитировать разные сценарии и проверять обработку ошибок – всю разработку и отладку придётся вести «на живую», прямо в рабочем контуре. Это многократно повышает риски, требует предельной аккуратности и сильно увеличивает время на каждую доработку: любой некорректный запрос может повлиять на реальные перевозки.
Если ж/д-перевозки – профильный и постоянный процесс, держать всю эту экспертизу в штате обычно дороже, чем взять готовый контур и сопровождение. Если перевозки разовые и редкие, возможно, ручной работы пока достаточно, и затевать интеграцию преждевременно. Решение разумно принимать после того, как посчитаны трудозатраты на текущую ручную работу и оценён объём проекта по чек-листу выше.
Вступайте в нашу телеграмм-группу Инфостарт