Начните с реестра одного этапа
К сдаче этапа в папке уже лежат акты, схемы и приложения. Начальнику ПТО всё равно приходится выяснять, чего не хватает и какой файл отправлять: исправленный документ мог остаться у инженера, а в общем архиве лежит предыдущая версия. Автоматизация исполнительной документации полезна именно здесь: она связывает требуемую позицию, работу, конкретную версию и решение проверяющего.
Мы предлагаем начать с одного этапа. На его реестре можно настроить сбор документов, возвраты и проверку комплектности, затем испытать выдачу пакета. Ниже приведены пример матрицы и тест, с которыми можно подготовить требования к системе и сравнить предложения подрядчиков.
Результат для ПТО: список недостающих и возвращённых позиций с ответственными, выбранные версии документов и воспроизводимый состав выдаваемого пакета. Техническое содержание и допустимость передачи подтверждают уполномоченные специалисты.
Сначала согласуем границы: объект, участок, этап работ, кто готовит документы, кто проверяет и кому передают результат. Требуемые позиции выводим из применимых требований и правил заказчика. В реестр заносим основание каждой позиции, чтобы позже было понятно, почему она обязательна и кто может изменить состав.
Приказ Минстроя № 344/пр от 16.05.2023 утверждает состав и порядок ведения исполнительной документации для строительства, реконструкции и капитального ремонта объектов капитального строительства. При настройке конкретного объекта сверяем действующую редакцию, применимость и требования к передаче. Формы и перечень документов закрепляем вместе с ПТО и заказчиком до программирования проверок.
Матрица связывает документ, версию и ответственного
Одна строка реестра описывает требование к документу. Файл прикрепляют к этой строке как версию; имя файла служит подсказкой, а связь хранится по отдельному идентификатору. Два файла с названием «акт_исправленный.pdf» тогда можно различить по документу, версии и истории загрузок.
В примере ниже условный этап включает одну работу и несколько связанных позиций. Состав показан для объяснения системы: для вашего объекта его утверждают отдельно. «Принята» здесь означает решение указанного проверяющего в рабочем процессе.
| Позиция / связь | Версия / статус | Ответственный / действие |
|---|---|---|
| Акт скрытых работ, работа Р-01 | v3, возвращена: ссылка на схему требует исправления | Инженер ПТО: исправить акт и передать новую версию |
| Исполнительная схема к Р-01 | v2, принята проверяющим | Ответственный за схему: сообщить об изменениях |
| Приложение к акту, позиция М-01 | Документ отсутствует | Назначенный сотрудник: приложить документ для М-01 |
| Реестр выдачи по этапу Э-01 | Сборка заблокирована открытыми расхождениями | Начальник ПТО: проверить устранение замечаний |
Кроме этих колонок храним основание требования, срок подготовки, проверяющего и связанные позиции. Если документ для этой работы не требуется, уполномоченный сотрудник отмечает «не применимо» с причиной. Простое удаление строки скрывает историю решения и затрудняет следующую проверку.
Удобно сразу разделить три состояния: файл загружен, содержание проверено, версия допущена к выдаче. Владелец файла видит ближайшее действие, а начальник ПТО видит препятствия по этапу. Одинаковая зелёная отметка для всех трёх состояний сделает отчёт слишком оптимистичным.
Как новая версия влияет на связанные документы
Допустим, схема v2 уже проверена, затем её заменили схемой v3. Если акт ссылается на прежнюю схему, система должна показать затронутую связь. Мы предлагаем сохранять старую версию и прежнее решение в истории, а актуальному комплекту назначать повторную проверку по согласованному правилу.
Правило зависит от изменения. Новый файл, исправление реквизита, изменение работы и замена приложения могут затрагивать разные позиции. Вместе с ПТО определяем, когда снимается допуск к выдаче, кто видит уведомление и может ли проверяющий подтвердить, что связанный документ менять не требуется. Причина такого решения остаётся в журнале.
Возврат привязываем к конкретной версии и расхождению. Например: «В акте указан номер схемы v1, в реестре принята v2». Ответственный получает документ, замечание и ожидаемое исправление. После загрузки новой версии акта проверяющий видит, какое замечание она закрывает. Возврат одной позиции не должен скрывать уже принятые документы остального комплекта.
Для инженера ПТО мы предлагаем автоматическое заполнение актов скрытых работ: система подставляет согласованные реквизиты и связи из реестра в утверждённую для проекта форму. Проверяем источник каждого поля и запрещаем незаметно переписывать уже проверенную версию. Факт выполнения работ, достоверность содержания и полномочия подписантов требуют отдельной проверки специалистами.
Пакет выдачи должен открываться в том же составе
При выдаче мы фиксируем снимок комплекта: какие позиции вошли, какие версии выбраны и какое решение разрешило передачу. Вместе с перечнем сохраняем неизменяемые файлы выбранных версий или отдельную копию пакета. Поздняя загрузка новой версии меняет рабочий реестр, а ранее выданный пакет сохраняет свои файлы. Для доступа к ним согласуем срок хранения и проверяем восстановление из резервной копии.
В предлагаемой системе состав выдачи содержит идентификатор этапа и пакета, список документов с версиями, дату сборки и ответственного. Для каждого файла можно сохранять контрольную сумму: цифровой признак, по которому проверяют, изменилось ли его содержимое. Она помогает сверить файл после передачи; требования к подписи и юридически значимому обмену определяются отдельно.
- Экспорт сопоставляем с реестром: все требуемые и допущенные позиции вошли в пакет.
- Формат и структуру папок проверяем на стороне получателя: файлы открываются, приложения находятся по ссылкам.
- Сохраняем подтверждение передачи и замечания получателя в пределах согласованного процесса.
- При повторной выдаче создаём отдельный пакет и показываем, какие позиции изменились.
Если заказчик принимает часть комплекта, её границы фиксируем явно. Остальные позиции остаются открытыми. Такой порядок позволяет восстановить, что именно передали, и не присваивать целому этапу статус готовности по одному принятому акту.
Что связывать с 1С и существующим документооборотом
Сначала выясняем, где уже ведутся объекты, договоры, контрагенты и работы. Если источником этих данных служит 1С, предлагаем получать согласованные справочники и идентификаторы из неё. Версии исполнительных документов и решения ПТО могут оставаться в отдельном реестре. Для каждого поля назначаем систему, в которой его изменяют.
Платформа 1С:Предприятие поддерживает стандартный REST-интерфейс на основе OData для чтения и записи данных. Подходящий способ обмена выбираем после проверки вашей конфигурации, размещения и прав. Наличие интерфейса само по себе не задаёт нужный состав работ или доступ к файлам.
В проекте «Бакаев» мы помогли перенести локальную 1С в облако и связали её с админ-панелью мобильного магазина. Карточки товаров, остатки и изображения обновляются в обе стороны. Когда сотрудник меняет фотографию в админ-панели, она отражается в 1С; изменения из 1С доходят до приложения.
Реальный проект 13FOX · продуктовый ритейл
Связанные данные магазина и 1С
Мы настроили двусторонний обмен, чтобы сотрудники управляли каталогом через связанную систему.
Для вашего этапа проверяем обмен на конкретной записи: объект и работа приходят с правильными идентификаторами, повторная загрузка не создаёт вторую позицию, ошибка доступа видна ответственному. При недоступности 1С показываем время последней успешной сверки и предупреждение о недоступном обмене. Запись обратно в учётную систему добавляем только для согласованных объектов и действий.
Если файлы уже хранятся в системе документооборота, проверяем возможность обращаться к определённой версии и получать её статус. Портал подрядчиков даёт участникам общее рабочее пространство. Реестр ПТО дополняет его проверками комплектности и составом выдачи; маршрут согласования определяет, кто принимает решение по документу.
Проверьте пилот на намеренно испорченном комплекте
Для приёмки системы нужен обычный комплект и несколько известных ошибок. Мы предлагаем прогнать их вместе с инженером и начальником ПТО. Ожидаемые результаты записываем заранее, чтобы проверка не зависела от того, как выглядит демонстрация.
| Тест комплекта | Ожидаемый результат |
|---|---|
| Убрать обязательное приложение | Видны недостающая позиция и ответственный; выдача блокируется по правилу этапа |
| Заменить принятую схему новой версией | Связанные позиции направлены на проверку; прежний допуск не действует автоматически |
| Загрузить два файла с одинаковым названием | Файлы различимы по документу и версии, выбранная версия однозначна |
| Вернуть один акт, остальные документы принять | Возврат адресован нужной версии; состояние остальных позиций сохраняется |
| Изменить связанную работу | Система показывает затронутые документы и требует согласованной повторной проверки |
| Выдать пакет, заменить файл в реестре и восстановить выдачу из сохранённой копии | Доступны исходные файлы выбранных версий; контрольные суммы совпадают; новый экспорт сверяется с реестром |
Сохраняем протокол: вводные, действие, ожидаемый и фактический результат, открытое замечание. После исправления повторяем затронутый тест. В первой версии можно ограничиться одним этапом, несколькими типами документов и одним способом выдачи, при условии, что вся цепочка от требования до пакета работает.
Из чего складывается стоимость электронного ПТО
Смету связываем с вашим реестром. Базовый объём включает структуру этапа, карточку документа, историю версий, роли, возвраты, проверку комплектности и экспорт. Затем отдельно оцениваем перенос архива, заполнение форм, обмен с 1С, подключение существующего хранилища и необходимые средства подписи.
На трудоёмкость влияет качество исходных данных: единые номера работ и документов позволяют настроить связи быстрее, чем архив с дубликатами и непонятными версиями. Несколько заказчиков с разными формами и правилами увеличивают число сценариев проверки. Эти различия стоит увидеть на предпроектном обследовании и отразить отдельными строками оценки.
Готовую систему сравниваем по тому же тесту комплекта. Если она поддерживает ваши связи, правила версий и выдачу, обсуждаем настройку и интеграцию. Собственную разработку рассматриваем, когда существенные требования остаются вне готового решения. Стоимость сопровождения включает изменение форм и правил, контроль обмена, резервное копирование и проверку восстановления выбранного пакета.
Вопросы перед запуском
Можно начать с Excel-реестра?
Да. Для пилота разбираем обезличенный реестр, назначаем постоянные идентификаторы и проверяем связи с файлами. На момент переноса согласуем, кто может менять исходный список и как новые изменения попадут в систему.
Система сама решит, что документация готова к сдаче?
Она проверит настроенные условия: наличие позиций, выбранные версии, решения и открытые возвраты. Техническое содержание, подписи и допустимость передачи проверяют уполномоченные стороны. Их решения связываем с конкретными версиями.
Нужно переносить все документы в новую систему?
Это зависит от возможностей текущего хранилища. Можно связать реестр с ним, если оно сохраняет неизменяемые версии и обеспечивает доступ к ним в течение согласованного срока. Иначе предлагаем отдельную копию выдаваемого пакета. В пилоте проверяем доступ и восстановление исходных файлов после изменения рабочего архива.
Как подготовиться к обсуждению?
Соберите обезличенный реестр этапа, используемые формы, пример возврата и корректную версию. Добавьте правила заказчика, роли проверяющих и формат передачи. Для обмена с 1С нужны название конфигурации и описание данных, которые хотите связать.
Разберём комплект вашего этапа
Пришлите обезличенный реестр этапа, формы и пример возврата. Разберём комплектность и версии, подготовим карту документов, ролей и проверок пилота.
Выберите удобный способ связи. После обращения согласуем, как передать материалы.