Ошибки электронной подачи

Ошибка электронной подачи не всегда означает, что проблема находится в самом проекте. Документация может быть подготовлена по существу, но при передаче в электронном виде часть файлов отсутствует, передана не в той редакции, дублируется или не позволяет однозначно определить, к какому разделу и приложению относится. Поэтому сначала нужно разделить две ситуации: технический сбой передачи и проблему самого переданного комплекта. Исправляются они по-разному.

Сначала проверяют фактически переданный комплект

Отправной точкой служит не рабочая папка проектировщика и не перечень документов, которые планировалось передать, а именно тот набор файлов, который фактически ушёл на рассмотрение. Его сопоставляют с описью или электронным реестром документов. Это позволяет установить, присутствует ли нужный файл, совпадает ли его версия с заявленной и нет ли в комплекте одновременно старой и новой редакций.

Такое различие принципиально. Документ может существовать у проектировщика и быть полностью подготовлен, но если он не вошёл в переданный набор, для получателя этого документа в комплекте нет. Обратная ситуация возникает, когда файл присутствует, однако содержит предыдущую редакцию раздела. Формально позиция реестра закрыта, но фактическое содержание не соответствует текущему состоянию проекта.

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

Как отличить ошибку передачи от ошибки содержания

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

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

Есть и промежуточная ситуация. Например, в папке присутствуют две редакции одного раздела, а из названий и сопроводительных сведений невозможно уверенно определить, какая из них актуальна. Передача технически состоялась, однако комплект не позволяет установить единственную действующую версию. Тогда сначала устраняют конфликт редакций и только после этого оценивают содержание документации.

Почему реестр и файлы нужно сверять в обе стороны

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

Так обнаруживаются разные типы несогласованности:

• запись есть, файла нет — комплект фактически неполон относительно собственного реестра;
• файл есть, но не отражён в составе — его назначение и статус могут быть неочевидны;
• есть несколько файлов одной функции — требуется определить актуальную редакцию и убрать конфликт версий;
• имя файла не соответствует содержанию — документ может быть ошибочно принят за другой раздел или другую редакцию;
• реестр и содержимое файла относятся к разным версиям — формальное совпадение перечня не подтверждает актуальность переданного материала.

Задача такой сверки — получить однозначный комплект, в котором для каждой позиции понятно, какой именно документ передан и какая редакция должна использоваться при рассмотрении.

Как возникают конфликты версий

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

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

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

Что делать при возврате или замечании к электронной подаче

Сообщение о возврате или замечании сначала сопоставляют с фактически отправленным комплектом. Не стоит сразу пересобирать всю документацию. Если проблема указывает на конкретный отсутствующий или неоднозначный файл, сначала устанавливают его состояние в исходной отправке: был ли он передан, в какой версии и как отражён в реестре.

Когда причина локализована, корректируют именно нарушенное звено. Отсутствующий документ добавляют в комплект; конфликтующие редакции приводят к однозначному состоянию; реестр синхронизируют с фактическими файлами; после замены проверяют, не осталось ли старой версии в другом месте отправки.

Если же сообщение связано с содержанием документа, маршрут меняется. Тогда требуется работа с соответствующим проектным, расчётным или исходным материалом, а электронная подача становится только способом передачи исправленной редакции. Это разграничение позволяет не смешивать техническую подготовку комплекта с профессиональной корректировкой документации.

Как проверить комплект перед повторной передачей

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

1. фиксируют перечень документов, которые должны войти в повторную передачу;
2. для каждой позиции определяют единственную актуальную редакцию;
3. сверяют реестр с реальным набором файлов;
4. проверяют отсутствие устаревших дублей и конфликтующих версий;
5. убеждаются, что файл можно однозначно связать с нужным разделом или приложением;
6. отдельно проверяют документы, которые были заменены после первоначальной отправки.

После этого полезна обратная проверка: открыть фактический набор, не используя исходный рабочий перечень, и по каждому файлу определить его назначение и место в комплекте. Если для какого-либо документа приходится догадываться, какая это версия или к чему она относится, электронный комплект ещё не приведён в однозначное состояние.

Когда требуется проверять не только электронную упаковку

Наличие всех файлов не означает автоматически, что документация готова по существу. Электронная сверка отвечает на вопрос, что именно передано и насколько однозначно организован комплект. Она не подтверждает правильность проектных решений, расчётов или взаимосвязей между разделами.

Поэтому после устранения технической проблемы может обнаружиться отдельный содержательный вопрос. Например, передан правильный файл нужной редакции, но связанные документы остались прежними. В таком случае сама электронная подача уже организована корректно, а дальнейшая работа относится к согласованию содержания документации.

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

Результатом проверки электронной подачи должен быть однозначный состав файлов для повторной передачи: понятно, какие документы входят в комплект, какая редакция каждого файла является действующей и где устранены пропуски, дубли или конфликты версий. Без сведений о конкретной системе подачи и фактического сообщения о проблеме нельзя достоверно устанавливать её точные требования к формату, электронной подписи или структуре файлов; такие параметры нужно проверять применительно к используемому способу передачи.