ЭПД ещё не запускали
Нужно понять готовность базы и состав работ до выбора окончательной схемы запуска.
Проверяем, готова ли ваша 1С и бизнес-процесс к электронным перевозочным документам: конфигурацию, документы-источники, справочники, пользователей, КЭП/МЧД, оператора, интеграции и сценарий реальной перевозки. На выходе — понятный перечень работ до запуска.
Аудит особенно полезен перед комплексным внедрением или когда компания уже пыталась подключить ЭПД, но столкнулась с ограничениями 1С, прав, подписей или внешних систем.
Нужно понять готовность базы и состав работ до выбора окончательной схемы запуска.
Есть собственные документы, расширения и обмены, которые могут повлиять на типовую настройку.
Данные о рейсе, грузе или транспорте распределены между несколькими системами.
Нужно унифицировать роли, справочники и правила до масштабного запуска.
Обмен уже используется, но статусы, подписи или данные работают нестабильно.
Без аудита легко смешать тариф сервиса, настройку и интеграционную разработку.
Проверка делится на техническую и организационную части. Рабочий запуск возможен только тогда, когда обе стороны процесса согласованы.
В одной компании данные для ЭПД берутся из реализации, в другой — из рейса или отдельной логистической системы. Аудит фиксирует реальную архитектуру до начала работ.
Даже полностью готовая 1С не запустит рабочий процесс, если не определены ответственные сотрудники и юридически значимые действия.
Проверяем, кто готовит исходные сведения и откуда они берутся в учётной системе.
Разбираем рейс, транспорт, водителя, диспетчера и действия в процессе перевозки.
Фиксируем действия на этапе получения груза и завершения своего этапа документа.
Проверяем, кто должен подписывать документы и готовы ли сертификаты и полномочия.
Если оператор уже выбран, проверяем его место в текущем процессе. Если нет — фиксируем требования, чтобы выбор оператора не происходил отдельно от архитектуры 1С.
Определяем используемый или планируемый операторский контур для перевозочных документов.
Проверяем маршрут электронных перевозочных документов и возврат статусов.
Учитываем Контур.Логистика, СБИС/Saby, Астрал и другие выбранные решения.
Фиксируем, какие данные должны приходить из логистических и складских систем.
Проверяем, где пользователь будет видеть результат обмена и причины сбоев.
Учитываем будущие филиалы, документы и новые сценарии, чтобы не переделывать архитектуру полностью.
Результат аудита должен быть прикладным: не просто список проблем, а последовательность действий для запуска.
Конфигурация, процессы, роли и внешние системы.
Релиз, документы, справочники и доработки.
Роли, подписи, оператор и рабочий маршрут.
Фиксируем критичные ограничения и зависимости.
Определяем подключение, настройку и интеграции.
Формируем приоритеты и последовательность работ.
У разных типов бизнеса слабые места находятся в разных точках: в производстве — отгрузка, в торговле — массовость, у перевозчика — рейс и водитель.

Проверяем связь выпуска, реализации, склада, транспорта и электронного перевозочного документа.

Оцениваем массовые отгрузки, качество справочников и повторяемость процесса.

Особое внимание — рейсу, водителю, диспетчеру, транспорту и мобильному сценарию.

Проверяем нестандартные маршруты, роли и исключительные сценарии до запуска.
Чем раньше обнаружены ограничения, тем меньше незапланированных доработок во время самого проекта.
Перед настройкой требуется обновление или отдельная проверка совместимости.
Не хватает транспорта, водителей, адресов или иных данных для формирования документа.
Процесс описан технически, но неясно, кто выполняет действие и отвечает за ошибку.
Подписание становится блокирующим этапом после технического подключения.
Информация уже есть в TMS/WMS, но проект не предусматривает автоматический обмен.
Нельзя проверить реальную готовность, если не выбран документ или рейс для сквозного теста.
Итог должен позволить принять решение о запуске и перейти к работам без повторного обследования тех же вопросов.
Понятно, какие части процесса уже готовы, а какие требуют подготовки.
Критичные ограничения выявлены до внедрения, а не во время запуска.
Разделены подключение, настройка и интеграционная разработка.
Есть последовательность шагов и приоритетный тестовый сценарий.
Для одной типовой базы и для холдинга с несколькими 1С и TMS нужен разный объём обследования. Поэтому стоимость формируется после короткого вводного разговора.
Основные факторы трудоёмкости аудита.
Следующий этап выбирается по результату диагностики.
Страница аудита не дублирует внедрение. Её задача — точно определить объём следующих работ.
Если система готова и требуется технический старт.
Подробнее →Если основной объём задачи — роли, данные и рабочий процесс.
Подробнее →Если данные распределены между несколькими системами.
Подробнее →Если нужен полный переход компании на электронные документы.
Подробнее →Если проект сосредоточен на электронной транспортной накладной.
Подробнее →Если нужно сравнить варианты архитектуры по процессу и роли компании.
Подробнее →Аудит готовности к ЭПД в 1С помогает заранее определить технические и организационные ограничения проекта. Проверка особенно важна для доработанных конфигураций, нескольких подразделений и процессов, где данные о перевозке находятся в разных информационных системах.
Во время аудита анализируются версия 1С, документы-источники, справочники, пользователи, КЭП/МЧД, операторский контур и внешние интеграции. Для ЭТрН отдельно учитываются роли участников перевозки, транспорт, водитель и рабочий рейс.
Для компании в Москве результат аудита позволяет выбрать между подключением ЭПД, настройкой, интеграцией и комплексным внедрением. Это снижает риск начать проект с неправильного объёма работ.
Аудит также полезен перед расчётом бюджета: он позволяет отделить стоимость сервиса от проектных работ и понять, какие доработки действительно обязательны. Для специализированных сценариев можно отдельно проверить ГИС ЭПД, интеграцию ЭТрН и другие контуры.
Что проверяется, когда аудит нужен и какой результат он даёт.
Проверка конфигурации и релиза 1С, документов и справочников, ролей пользователей, КЭП/МЧД, операторского контура, внешних интеграций и тестового сценария.
Если процесс простой, аудит может быть коротким. Его задача — подтвердить, что типовой настройки действительно достаточно и нет скрытых ограничений.
Да. В этом случае фиксируются требования к операторскому контуру и будущему обмену, чтобы выбор сервиса соответствовал процессу компании.
Да. Если сотрудники должны выполнять юридически значимые действия, проверяется готовность подписей и полномочий.
Если эти системы участвуют в перевозочном процессе или являются источниками данных, их место в архитектуре обязательно учитывается.
Карту готовности, перечень рисков, рекомендации по архитектуре и последовательность дальнейших работ.
Да. Аудит как раз нужен для того, чтобы следующий этап можно было запускать уже с понятным объёмом и приоритетами.
Опишите текущую 1С, перевозочный процесс и используемые системы. Проверим ключевые риски и подготовим понятный план дальнейших действий.