Взыскание долгов по оплате услуг ЖКХ: правительство планирует внедрить особую цифровую процедуру
В IV квартале 2026 года в Правительстве планируют подвести итоги эксперимента по извещению должников через Госуслуги и ГИС ЖКХ о вынесении судебных приказов. Тогда же планируется подготовить рекомендации о том, как улучшить процесс. Еще через год механизм электронного взыскания долгов может заработать полностью. Полный состав планируемых мероприятий В IV квартале 2026 года в Правительстве планируют подвести итоги эксперимента по извещению должников через Госуслуги и ГИС ЖКХ о вынесении судебных приказов. Тогда же планируется подготовить рекомендации о том, как улучшить процесс. Еще через год механизм электронного взыскания долгов может заработать полностью. Полный состав мероприятий ранее нашел свое отражение в Распоряжение Правительства РФ от 02.03.2026 N 398-р «Об утверждении стратегического направления в области цифровой трансформации отраслей строительства и жилищно-коммунального хозяйства Российской Федерации до 2030 года».
Напомним, сейчас проходит пилотный проект, по которому среди прочего можно:
- подготовить в ГИС ЖКХ цифровое заявление о вынесении судебного приказа;
- направить через эту систему заявление мировому судье, а также физлицу. Последнему документ приходит, например, на Госуслуги;
- получить в ГИС ЖКХ электронное определение о возврате заявления, отказе его принять, отмене судебного приказа либо исправлении в нем описок и явных арифметических ошибок.
Организации ЖКХ участвуют в мероприятии добровольно. В числе его целей – улучшить информирование физлиц о долгах и сократить сроки их взыскания.
📸 bimsert
В IV квартале 2026 года в Правительстве планируют подвести итоги эксперимента по извещению должников через Госуслуги и ГИС ЖКХ о вынесении судебных приказов. Тогда же планируется подготовить рекомендации о том, как улучшить процесс. Еще через год механизм электронного взыскания долгов может заработать полностью. Полный состав планируемых мероприятий В IV квартале 2026 года в Правительстве планируют подвести итоги эксперимента по извещению должников через Госуслуги и ГИС ЖКХ о вынесении судебных приказов. Тогда же планируется подготовить рекомендации о том, как улучшить процесс. Еще через год механизм электронного взыскания долгов может заработать полностью. Полный состав мероприятий ранее нашел свое отражение в Распоряжение Правительства РФ от 02.03.2026 N 398-р «Об утверждении стратегического направления в области цифровой трансформации отраслей строительства и жилищно-коммунального хозяйства Российской Федерации до 2030 года».
Напомним, сейчас проходит пилотный проект, по которому среди прочего можно:
- подготовить в ГИС ЖКХ цифровое заявление о вынесении судебного приказа;
- направить через эту систему заявление мировому судье, а также физлицу. Последнему документ приходит, например, на Госуслуги;
- получить в ГИС ЖКХ электронное определение о возврате заявления, отказе его принять, отмене судебного приказа либо исправлении в нем описок и явных арифметических ошибок.
Организации ЖКХ участвуют в мероприятии добровольно. В числе его целей – улучшить информирование физлиц о долгах и сократить сроки их взыскания.
Please open Telegram to view this post
VIEW IN TELEGRAM
ТИМ на бюджетных ОКС обязали использовать с 2021 года. Результат?
Счётная палата: 1,5 трлн руб. нарушений в стройке, 24 млрд - чисто по капвложениям. По материалам СП возбуждено 77 уголовных дел (взрыв на 267%), в суды направлено 162 материала. Привлечено к дисциплинарной ответственности 188 должностных лиц, из них 21 уволен. Инспекторы СП сами возбудили 22 дела об админправонарушениях, суды назначили 231 млн руб. штрафов.
Цифровая модель есть - контроля нет. ТИМ превратился в галочку: модель сдали, деньги освоили, объект недостроен.
Кто следующий? Технологии по искусственному интеллекту…
ТИМ - зачеркнули, ТИИ - приготовиться.
P.S. Кстати, в том же отчёте СП хвалится внедрением ИИ для «риск-ориентированного подхода». Круг замкнулся.
📸 bimsert
Счётная палата: 1,5 трлн руб. нарушений в стройке, 24 млрд - чисто по капвложениям. По материалам СП возбуждено 77 уголовных дел (взрыв на 267%), в суды направлено 162 материала. Привлечено к дисциплинарной ответственности 188 должностных лиц, из них 21 уволен. Инспекторы СП сами возбудили 22 дела об админправонарушениях, суды назначили 231 млн руб. штрафов.
Цифровая модель есть - контроля нет. ТИМ превратился в галочку: модель сдали, деньги освоили, объект недостроен.
Кто следующий? Технологии по искусственному интеллекту…
ТИМ - зачеркнули, ТИИ - приготовиться.
P.S. Кстати, в том же отчёте СП хвалится внедрением ИИ для «риск-ориентированного подхода». Круг замкнулся.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Просто о сметах
Отчеты Счетной палаты @auditgov сейчас выходят как горячие пирожки — только успевай читать эти грустные цифры в стройке.
На заседании Комитета по бюджету и финансовым рынкам Совета Федерации Борис Ковальчук представил отчет о работе за 2025 г.
Если смотреть…
На заседании Комитета по бюджету и финансовым рынкам Совета Федерации Борис Ковальчук представил отчет о работе за 2025 г.
Если смотреть…
🔥5❤1
Рубрика «Вопрос/Ответ»: как оценивают заключение специалиста в судебной практике за последние 3 года (ст.71 АПК)
Вопрос: Имеет ли заключение эксперта для суда заранее установленную доказательственную силу?
Ответ: Нет. Согласно разъяснениям высших судов, заключение эксперта не имеет для суда заранее установленной силы и оценивается наряду с другими доказательствами по делу.
Вопрос: Признаётся ли заключение специалиста доказательством, если он не был предупреждён об уголовной ответственности?
Ответ: Судебная практика по этому вопросу неоднозначна. Существуют как решения, в которых такое заключение не признаётся доказательством, так и решения с противоположным выводом. Из актуальной практики: рецензия на экспертное заключение, выражающая субъективное мнение специалиста, не предупреждённого об уголовной ответственности, не принимается в качестве доказательства (Постановление АС ЦО от 25.02.2025 по делу № А48-673/2022).
Вопрос: Может ли суд отказаться от экспертного заключения только на основании несогласия стороны с его результатами?
Ответ: Нет. Несогласие стороны спора с результатами экспертизы само по себе не является достаточным основанием для признания экспертного заключения ненадлежащим доказательством или для назначения повторной экспертизы.
Вопрос: В каких случаях судебный акт будет отменён из-за нарушений при оценке доказательств?
Ответ: Судебный акт подлежит отмене, если суд не оценил все доказательства по делу и не указал мотивы, по которым их отверг. Вместе с тем акт не будет отменён только потому, что в мотивировочной части отсутствует оценка каждого доказательства в отдельности.
Вопрос: Признаются ли заключение судебной экспертизы по другому делу и заключение внесудебной экспертизы экспертным заключением?
Ответ: Нет, они не признаются экспертным заключением в смысле процессуального закона, однако могут быть приняты судом как иные доказательства.
Основные нормативные акты по ст. 71 АПК РФ:
📸 bimsert
Вопрос: Имеет ли заключение эксперта для суда заранее установленную доказательственную силу?
Ответ: Нет. Согласно разъяснениям высших судов, заключение эксперта не имеет для суда заранее установленной силы и оценивается наряду с другими доказательствами по делу.
Вопрос: Признаётся ли заключение специалиста доказательством, если он не был предупреждён об уголовной ответственности?
Ответ: Судебная практика по этому вопросу неоднозначна. Существуют как решения, в которых такое заключение не признаётся доказательством, так и решения с противоположным выводом. Из актуальной практики: рецензия на экспертное заключение, выражающая субъективное мнение специалиста, не предупреждённого об уголовной ответственности, не принимается в качестве доказательства (Постановление АС ЦО от 25.02.2025 по делу № А48-673/2022).
Вопрос: Может ли суд отказаться от экспертного заключения только на основании несогласия стороны с его результатами?
Ответ: Нет. Несогласие стороны спора с результатами экспертизы само по себе не является достаточным основанием для признания экспертного заключения ненадлежащим доказательством или для назначения повторной экспертизы.
Вопрос: В каких случаях судебный акт будет отменён из-за нарушений при оценке доказательств?
Ответ: Судебный акт подлежит отмене, если суд не оценил все доказательства по делу и не указал мотивы, по которым их отверг. Вместе с тем акт не будет отменён только потому, что в мотивировочной части отсутствует оценка каждого доказательства в отдельности.
Вопрос: Признаются ли заключение судебной экспертизы по другому делу и заключение внесудебной экспертизы экспертным заключением?
Ответ: Нет, они не признаются экспертным заключением в смысле процессуального закона, однако могут быть приняты судом как иные доказательства.
Основные нормативные акты по ст. 71 АПК РФ:
• Постановление Пленума ВС РФ от 08.11.2022 № 31
• Постановление Пленума ВС РФ от 23.04.2019 № 10
• Постановление Пленума ВС РФ от 26.06.2018 № 26
• Постановление Пленума ВС РФ от 26.12.2017 № 57
• Постановление Пленума ВС РФ от 21.12.2017 № 53
• Обзоры судебной практики ВС РФ № 4 (2018), № 2 (2018), № 3 (2015)
• Постановления и информационное письмо Президиума ВАС РФ
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
На сайте Минстроя России опубликованы новые версии XML-схем
Для этапа инженерных изысканий и архитектурно-строительного проектирования размещены 3 новых версии XML-схем ПЗ, Заключения и Задания на проектирование:
Раздел №1 проектной документации «Пояснительная записка»
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
Задание на проектирование
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
XML-схема заключения экспертизы
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
Также расширен состав раздела разрабатываемых XML-схем вошли 4 новые схемы:
Выписка из реестра уведомлений об окончании строительства

Выписка из реестра о планируемом строительстве

Выписка из реестра разрешений на строительство

Выписка из реестра разрешений на ввод объектов в эксплуатацию

📸 bimsert
Для этапа инженерных изысканий и архитектурно-строительного проектирования размещены 3 новых версии XML-схем ПЗ, Заключения и Задания на проектирование:
Раздел №1 проектной документации «Пояснительная записка»
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
Задание на проектирование
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
XML-схема заключения экспертизы
Опубликовано:
11.03.2026
Вступит в силу:
11.06.2026
Также расширен состав раздела разрабатываемых XML-схем вошли 4 новые схемы:
Выписка из реестра уведомлений об окончании строительства

Выписка из реестра о планируемом строительстве

Выписка из реестра разрешений на строительство

Выписка из реестра разрешений на ввод объектов в эксплуатацию

Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
Обзор изменений XML-схемы заключения экспертизы версии 1.04
1. Добавлен новый тип tElectronicBudgetObjectCode, предназначенный для хранения уникального кода объекта капитального строительства, присвоенного государственной интегрированной информационной системой управления общественными финансами «Электронный бюджет».
2. Тип tObject расширен:
- необязательным атрибутом ElectronicBudgetObjectCode типа tElectronicBudgetObjectCode - уникальный код объекта капитального строительства в системе «Электронный бюджет»;
- обязательным атрибутом DangerousAndComplex типа tYesNo - сведения об отнесении объекта к технически сложным или опасным объектам;
- обязательным атрибутом Unique типа tYesNo -,сведения об отнесении объекта к уникальным объектам.
3. Изменён подход к описанию адреса в связи с введением обязательного указания кода ОКТМО и наименования муниципального образования.
Добавлены типы tRussianAddress, tForeignAddress, tObjectAddress.
Изменены типы tAddress, tPostAddress.
Из справочника кодов субъектов Российской Федерации исключено значение «00».
4. Добавлен элемент NationalProject типа tNationalProject, предназначенный для указания сведений о включении объекта:
- в федеральный проект в составе национального проекта;
- в региональный проект в составе национального проекта.
5. В сложный тип tExpert добавлен элемент SNILS, предназначенный для хранения страхового номера индивидуального лицевого счёта эксперта.
6. Добавлен тип tRequirementsDate, предназначенный для указания даты, на которую действовали нормативные требования, применённые при проведении экспертизы.
7. Часть типов данных переопределена в целях унификации используемых типов между различными XML-схемами системы государственной экспертизы.
#XML #Заключение_экспертизы #XML_схема
📸 bimsert
1. Добавлен новый тип tElectronicBudgetObjectCode, предназначенный для хранения уникального кода объекта капитального строительства, присвоенного государственной интегрированной информационной системой управления общественными финансами «Электронный бюджет».
2. Тип tObject расширен:
- необязательным атрибутом ElectronicBudgetObjectCode типа tElectronicBudgetObjectCode - уникальный код объекта капитального строительства в системе «Электронный бюджет»;
- обязательным атрибутом DangerousAndComplex типа tYesNo - сведения об отнесении объекта к технически сложным или опасным объектам;
- обязательным атрибутом Unique типа tYesNo -,сведения об отнесении объекта к уникальным объектам.
3. Изменён подход к описанию адреса в связи с введением обязательного указания кода ОКТМО и наименования муниципального образования.
Добавлены типы tRussianAddress, tForeignAddress, tObjectAddress.
Изменены типы tAddress, tPostAddress.
Из справочника кодов субъектов Российской Федерации исключено значение «00».
4. Добавлен элемент NationalProject типа tNationalProject, предназначенный для указания сведений о включении объекта:
- в федеральный проект в составе национального проекта;
- в региональный проект в составе национального проекта.
5. В сложный тип tExpert добавлен элемент SNILS, предназначенный для хранения страхового номера индивидуального лицевого счёта эксперта.
6. Добавлен тип tRequirementsDate, предназначенный для указания даты, на которую действовали нормативные требования, применённые при проведении экспертизы.
7. Часть типов данных переопределена в целях унификации используемых типов между различными XML-схемами системы государственной экспертизы.
#XML #Заключение_экспертизы #XML_схема
Please open Telegram to view this post
VIEW IN TELEGRAM
Обзор основных изменений в XML-схеме задания на проектирование версии 01.01
Часть 1/2
1. Тип tSecurityLabel (гриф ограничения доступа к документу):
в перечень допустимых значений добавлено значение «Для служебного пользования».
2. Элемент Agreements (перечень необходимых согласований):
уточнена аннотация элемента.
3. Элемент TechnicalCustomers (технические заказчики):
изменена кратность элемента - теперь допускается указание нескольких технических заказчиков.
4. Тип tFinanceRatioValue (размер финансирования - доля в процентах):
тип изменён на xs:decimal (десятичное число).
5. Элемент EngineeringSurvey (необходимость выполнения инженерных изысканий для подготовки проектной документации):
элемент сделан необязательным (minOccurs="0").
Значение minOccurs="0" означает, что данный элемент может отсутствовать в XML-документе.
6. Элемент Adjacents (смежные объекты капитального строительства, сведения о которых должны быть учтены при проектировании):
уточнена аннотация элемента.
Тип tSurveysRequirements (требования к инженерным изысканиям по видам изысканий):
изменена структура указания видов изысканий.
7. Тип tEngineeringSurveyType (необходимость выполнения инженерных изысканий для подготовки проектной документации):
изменена структура типа для указания видов изысканий.
Удалены проверки, обеспечивавшие указание либо вида инженерных изысканий (@Type), либо вида дополнительных обследований (@SpecialType).
8. Атрибут DangerousIndustrialObject (принадлежность к опасным производственным объектам):
атрибут сделан необязательным.
9. Группа gObjectAttributes (перечень атрибутов объекта капитального строительства):
обязательность указания атрибутов группы снята.
10. Тип tComponentRequirements:
исправлена аннотация - «Группа требований к техническим решениям».
11. Типы tObject, tComplex, tOKS, tAdjacentObject:
тип адреса унифицирован - вместо ранее используемых типов применяется tObjectAddress.
Добавлена возможность выбора между адресом пересечения и адресом параллельного следования (ранее требовалось указывать оба).
12. Тип tRequirements (требования к техническим решениям):
из типа удалён необязательный элемент Author.
13. Тип tDocumentInfo (сведения о документе):
тип элемента Author изменён на tAuthor, реализующий выбор (xs:choice) варианта автора.
#XML #ЗнП #XML_схема
📸 bimsert
Часть 1/2
1. Тип tSecurityLabel (гриф ограничения доступа к документу):
в перечень допустимых значений добавлено значение «Для служебного пользования».
2. Элемент Agreements (перечень необходимых согласований):
уточнена аннотация элемента.
3. Элемент TechnicalCustomers (технические заказчики):
изменена кратность элемента - теперь допускается указание нескольких технических заказчиков.
4. Тип tFinanceRatioValue (размер финансирования - доля в процентах):
тип изменён на xs:decimal (десятичное число).
5. Элемент EngineeringSurvey (необходимость выполнения инженерных изысканий для подготовки проектной документации):
элемент сделан необязательным (minOccurs="0").
Значение minOccurs="0" означает, что данный элемент может отсутствовать в XML-документе.
6. Элемент Adjacents (смежные объекты капитального строительства, сведения о которых должны быть учтены при проектировании):
уточнена аннотация элемента.
Тип tSurveysRequirements (требования к инженерным изысканиям по видам изысканий):
изменена структура указания видов изысканий.
7. Тип tEngineeringSurveyType (необходимость выполнения инженерных изысканий для подготовки проектной документации):
изменена структура типа для указания видов изысканий.
Удалены проверки, обеспечивавшие указание либо вида инженерных изысканий (@Type), либо вида дополнительных обследований (@SpecialType).
8. Атрибут DangerousIndustrialObject (принадлежность к опасным производственным объектам):
атрибут сделан необязательным.
9. Группа gObjectAttributes (перечень атрибутов объекта капитального строительства):
обязательность указания атрибутов группы снята.
10. Тип tComponentRequirements:
исправлена аннотация - «Группа требований к техническим решениям».
11. Типы tObject, tComplex, tOKS, tAdjacentObject:
тип адреса унифицирован - вместо ранее используемых типов применяется tObjectAddress.
Добавлена возможность выбора между адресом пересечения и адресом параллельного следования (ранее требовалось указывать оба).
12. Тип tRequirements (требования к техническим решениям):
из типа удалён необязательный элемент Author.
13. Тип tDocumentInfo (сведения о документе):
тип элемента Author изменён на tAuthor, реализующий выбор (xs:choice) варианта автора.
#XML #ЗнП #XML_схема
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Обзор основных изменений в XML-схеме задания на проектирование версии 01.01
Часть 2/2
14. Элемент ProjectDocuments:
элемент сделан необязательным.
15. Тип tProjectDocumentsRequirements (требования к разделам проектной документации по виду объекта капитального строительства):
группа выбора (xs:choice) сделана необязательной.
16. Элемент Land (сведения о земельном участке - общие сведения, категория земель, сведения об изымаемых для государственных или муниципальных нужд земельных участках и др.): элемент сделан необязательным.
17. Элемент Standardization (требования о применении при разработке проектной документации документов в области стандартизации):
изменено наименование элемента на Standartization.
18. Аннотации элементов:
дополнены в соответствии с приказом Минстроя России от 21.04.2022 № 307/пр (ред. от 07.08.2023).
19. Тип tFunctionalRole (функциональная роль подписанта документа):
обновлён перечень допустимых значений справочника.
Ранее использовались значения: ИП, ФЛ.
В новой версии: ЮЛ, ИП, ФЛ.
20. Элемент Representative (представитель организации, подписавший документ):
тип элемента изменён на tWorkPersonNoSNILS (должностное лицо, для которого указание СНИЛС не требуется).
21. Элемент Designers (разработчики проектной документации):
переработана структура указания разработчиков проектной документации.
Добавлен генеральный разработчик проектной документации.
22. Тип tObjectCode (код сложного объекта капитального строительства):
тип исключён.
Вместо него используется тип tNotEmptyString200.
23.Атрибут SecurityInfluence (признак принадлежности к объектам транспортной инфраструктуры и другим объектам, функционально-технологические особенности которых влияют на безопасность):
атрибут сделан необязательным.
24. Тип tComponentRequirements:
переименован в tGroupRequirements (группа требований к техническим решениям - наименование группы, описание группы, требования к техническим решениям).
25. Элемент ComponentRequirements:
переименован в GroupRequirements.
В файле описания XML-схемы добавлены иллюстрации, демонстрирующие различия между формированием задания на проектирование в формате PDF (как использовалось ранее) и XML (новый формат представления), а также приведена структурная схема XML-документа задания на проектирование.
#XML #ЗнП #XML_схема
📸 bimsert
Часть 2/2
14. Элемент ProjectDocuments:
элемент сделан необязательным.
15. Тип tProjectDocumentsRequirements (требования к разделам проектной документации по виду объекта капитального строительства):
группа выбора (xs:choice) сделана необязательной.
16. Элемент Land (сведения о земельном участке - общие сведения, категория земель, сведения об изымаемых для государственных или муниципальных нужд земельных участках и др.): элемент сделан необязательным.
17. Элемент Standardization (требования о применении при разработке проектной документации документов в области стандартизации):
изменено наименование элемента на Standartization.
18. Аннотации элементов:
дополнены в соответствии с приказом Минстроя России от 21.04.2022 № 307/пр (ред. от 07.08.2023).
19. Тип tFunctionalRole (функциональная роль подписанта документа):
обновлён перечень допустимых значений справочника.
Ранее использовались значения: ИП, ФЛ.
В новой версии: ЮЛ, ИП, ФЛ.
20. Элемент Representative (представитель организации, подписавший документ):
тип элемента изменён на tWorkPersonNoSNILS (должностное лицо, для которого указание СНИЛС не требуется).
21. Элемент Designers (разработчики проектной документации):
переработана структура указания разработчиков проектной документации.
Добавлен генеральный разработчик проектной документации.
22. Тип tObjectCode (код сложного объекта капитального строительства):
тип исключён.
Вместо него используется тип tNotEmptyString200.
23.Атрибут SecurityInfluence (признак принадлежности к объектам транспортной инфраструктуры и другим объектам, функционально-технологические особенности которых влияют на безопасность):
атрибут сделан необязательным.
24. Тип tComponentRequirements:
переименован в tGroupRequirements (группа требований к техническим решениям - наименование группы, описание группы, требования к техническим решениям).
25. Элемент ComponentRequirements:
переименован в GroupRequirements.
В файле описания XML-схемы добавлены иллюстрации, демонстрирующие различия между формированием задания на проектирование в формате PDF (как использовалось ранее) и XML (новый формат представления), а также приведена структурная схема XML-документа задания на проектирование.
#XML #ЗнП #XML_схема
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Различия между формированием задания на проектирование в формате PDF/XML и структурная схема XML-документа задания на проектирование
В файле описания XML-схемы Задания на проектирование добавлены иллюстрации, демонстрирующие различия между формированием задания на проектирование в формате PDF (как использовалось ранее) и XML (новый формат представления), а также приведена структурная схема XML-документа задания на проектирование.
#XML #ЗнП #XML_схема
📸 bimsert
В файле описания XML-схемы Задания на проектирование добавлены иллюстрации, демонстрирующие различия между формированием задания на проектирование в формате PDF (как использовалось ранее) и XML (новый формат представления), а также приведена структурная схема XML-документа задания на проектирование.
#XML #ЗнП #XML_схема
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🤯1
Обзор основных изменений в XML-схеме Раздела ПД N 1 Пояснительная записка версии 01.07
1. Изменена версия схемы до 01.07.
2. Добавлен элемент ChiefProjectEngineerSurvey, описывающий главного инженера проекта, обеспечившего подготовку инженерных изысканий. Элемент содержит ФИО, СНИЛС, номер в НРС НОПРИЗ и e-mail (необязательный).
3. Тип tProjectDocParticipants заменен на новый тип tDocParticipants. Новый тип содержит сведения о ФИО, СНИЛС, номере в НРС НОПРИЗ и e-mail. Используется для описания участников разработки, нормоконтроля и согласования документа.
4. Тип tEngineeringSurveyDocument дополнен элементом DocParticipants для фиксации участников разработки и согласования отчетной документации по инженерным изысканиям.
5.Структура подписантов документа переработана:
• ChiefProjectEngineer использует тип tEngineerPersonNOPRIZ
• Signer использует тип tEngineerPersonNoNOPRIZ
• Добавлен элемент ChiefProjectEngineerSurvey типа tEngineerPersonNOPRIZ
6. Тип tAuthor изменен для использования новых унифицированных типов:
• Organization типа tOrganizationNOPRIZ
• IP типа tIndividualEntrepreneurNOPRIZ
Иностранные организации описываются через tOrganization с реквизитом RAFP.
7. Тип tDeveloper изменен для использования:
• Organization (tOrganization)
• IP (tIndividualEntrepreneur)
• Person (tPersonSNILS)
Ранее использовавшийся тип ForeignOrganization исключен.
8. Тип tTechnicalCustomer изменен: теперь используется только OrganizationNOPRIZ.
9. Тип tProjectDocumentationAuthor использует новые типы:
• tOrganizationNoNOPRIZ
• tIndividualEntrepreneurNoNOPRIZ
Это позволяет указывать организации и индивидуальных предпринимателей без обязательного номера НОПРИЗ.
10. Адресные типы (tObjectAddress, tAddress, tPostAddress, tRussianAddress, tRussianPostAddress, tForeignAddress) перенесены в блок общих типов и используют новый тип tRegionCode вместо устаревшего tRegionsRF.
11. Введена иерархия типов для физических лиц:
• tAbstractPerson
• tPersonSNILS
• tPersonNoSNILS
• tEngineerPersonNOPRIZ
• tEngineerPersonNoNOPRIZ
12. Введены новые типы для индивидуальных предпринимателей:
• tIndividualEntrepreneur
• tIndividualEntrepreneurNOPRIZ
• tIndividualEntrepreneurNoNOPRIZ
13. Введены новые типы для организаций:
• tOrganization
• tOrganizationNOPRIZ
• tOrganizationNoNOPRIZ
Иностранные организации описываются через tOrganization с реквизитом RAFP.
14. Добавлены новые простые типы реквизитов:
• OGRN
• RAFP
• KPP
• INN
• INNIP
• NOPRIZOrganizationNumber
• NOPRIZPersonNumber
• EngineerRole
• CyrillicFIO
15. Введен новый тип tRegionCode для указания кодов субъектов Российской Федерации. Старый тип tRegionsRF сохранен для обратной совместимости, новые элементы используют tRegionCode.
16. В результате унификации структура схемы стала более согласованной и расширяемой. Унификация охватывает участников разработки, подписантов, авторов документации, адреса и реквизиты организаций и физических лиц. Это обеспечивает совместимость с другими схемами строительной отрасли.
#XML #ПЗ #XML_схема
📸 bimsert
1. Изменена версия схемы до 01.07.
2. Добавлен элемент ChiefProjectEngineerSurvey, описывающий главного инженера проекта, обеспечившего подготовку инженерных изысканий. Элемент содержит ФИО, СНИЛС, номер в НРС НОПРИЗ и e-mail (необязательный).
3. Тип tProjectDocParticipants заменен на новый тип tDocParticipants. Новый тип содержит сведения о ФИО, СНИЛС, номере в НРС НОПРИЗ и e-mail. Используется для описания участников разработки, нормоконтроля и согласования документа.
4. Тип tEngineeringSurveyDocument дополнен элементом DocParticipants для фиксации участников разработки и согласования отчетной документации по инженерным изысканиям.
5.Структура подписантов документа переработана:
• ChiefProjectEngineer использует тип tEngineerPersonNOPRIZ
• Signer использует тип tEngineerPersonNoNOPRIZ
• Добавлен элемент ChiefProjectEngineerSurvey типа tEngineerPersonNOPRIZ
6. Тип tAuthor изменен для использования новых унифицированных типов:
• Organization типа tOrganizationNOPRIZ
• IP типа tIndividualEntrepreneurNOPRIZ
Иностранные организации описываются через tOrganization с реквизитом RAFP.
7. Тип tDeveloper изменен для использования:
• Organization (tOrganization)
• IP (tIndividualEntrepreneur)
• Person (tPersonSNILS)
Ранее использовавшийся тип ForeignOrganization исключен.
8. Тип tTechnicalCustomer изменен: теперь используется только OrganizationNOPRIZ.
9. Тип tProjectDocumentationAuthor использует новые типы:
• tOrganizationNoNOPRIZ
• tIndividualEntrepreneurNoNOPRIZ
Это позволяет указывать организации и индивидуальных предпринимателей без обязательного номера НОПРИЗ.
10. Адресные типы (tObjectAddress, tAddress, tPostAddress, tRussianAddress, tRussianPostAddress, tForeignAddress) перенесены в блок общих типов и используют новый тип tRegionCode вместо устаревшего tRegionsRF.
11. Введена иерархия типов для физических лиц:
• tAbstractPerson
• tPersonSNILS
• tPersonNoSNILS
• tEngineerPersonNOPRIZ
• tEngineerPersonNoNOPRIZ
12. Введены новые типы для индивидуальных предпринимателей:
• tIndividualEntrepreneur
• tIndividualEntrepreneurNOPRIZ
• tIndividualEntrepreneurNoNOPRIZ
13. Введены новые типы для организаций:
• tOrganization
• tOrganizationNOPRIZ
• tOrganizationNoNOPRIZ
Иностранные организации описываются через tOrganization с реквизитом RAFP.
14. Добавлены новые простые типы реквизитов:
• OGRN
• RAFP
• KPP
• INN
• INNIP
• NOPRIZOrganizationNumber
• NOPRIZPersonNumber
• EngineerRole
• CyrillicFIO
15. Введен новый тип tRegionCode для указания кодов субъектов Российской Федерации. Старый тип tRegionsRF сохранен для обратной совместимости, новые элементы используют tRegionCode.
16. В результате унификации структура схемы стала более согласованной и расширяемой. Унификация охватывает участников разработки, подписантов, авторов документации, адреса и реквизиты организаций и физических лиц. Это обеспечивает совместимость с другими схемами строительной отрасли.
#XML #ПЗ #XML_схема
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
⚠️ Ошибка в версии 01.07 XML-схемы Пояснительной записки: дублирование адресных типов
В версии схемы 01.07 выявлена ошибка, связанная с дублированием адресных типов, которая может вызвать критические проблемы при валидации XML-документов и компиляции XSD.
Суть ошибки - в схеме дважды определены одни и те же типы адресов:
• tObjectAddress
• tAddress
• tPostAddress
• tRussianAddress
• tRussianPostAddress
• tForeignAddress
Первое определение находится в основной части схемы и использует устаревший тип tRegionsRF.
Второе определение находится в блоке общих типов и использует новый тип tRegionCode.
В XSD не допускается наличие двух типов с одинаковым именем, даже если структура элементов почти идентична. Разные ссылки на типы регионов создают конфликт.
Это приводит к тому, что:
- компилятор XSD выдаст ошибку определения типа;
- валидаторы не смогут корректно проверять XML-документы;
- инструменты, использующие схему для генерации форм или документов, могут выдавать ошибки.
Кому ошибка осложнит жизнь:
Ошибка создаёт реальные трудности для разработчиков и интеграторов. Они не смогут сразу использовать схему для проверки документов или генерации форм и классов, придётся вручную разбираться, какой тип правильный, и исправлять ссылки. Также могут возникнуть конфликты при интеграции между системами, использующими старые и новые определения адресов.
Рекомендации по исправлению:
- удалить все старые определения адресных типов из основной части схемы;
- оставить только новые определения в блоке общих типов с tRegionCode;
- обновить ссылки всех элементов схемы на новые определения.
После исправления схема станет корректной и унифицированной для всех типов адресов, включая физические и юридические лица, организации и иностранные структуры.
#XML #ПЗ #XML_схема #BagFixes
📸 bimsert
В версии схемы 01.07 выявлена ошибка, связанная с дублированием адресных типов, которая может вызвать критические проблемы при валидации XML-документов и компиляции XSD.
Суть ошибки - в схеме дважды определены одни и те же типы адресов:
• tObjectAddress
• tAddress
• tPostAddress
• tRussianAddress
• tRussianPostAddress
• tForeignAddress
Первое определение находится в основной части схемы и использует устаревший тип tRegionsRF.
Второе определение находится в блоке общих типов и использует новый тип tRegionCode.
В XSD не допускается наличие двух типов с одинаковым именем, даже если структура элементов почти идентична. Разные ссылки на типы регионов создают конфликт.
Это приводит к тому, что:
- компилятор XSD выдаст ошибку определения типа;
- валидаторы не смогут корректно проверять XML-документы;
- инструменты, использующие схему для генерации форм или документов, могут выдавать ошибки.
Кому ошибка осложнит жизнь:
Ошибка создаёт реальные трудности для разработчиков и интеграторов. Они не смогут сразу использовать схему для проверки документов или генерации форм и классов, придётся вручную разбираться, какой тип правильный, и исправлять ссылки. Также могут возникнуть конфликты при интеграции между системами, использующими старые и новые определения адресов.
Рекомендации по исправлению:
- удалить все старые определения адресных типов из основной части схемы;
- оставить только новые определения в блоке общих типов с tRegionCode;
- обновить ссылки всех элементов схемы на новые определения.
После исправления схема станет корректной и унифицированной для всех типов адресов, включая физические и юридические лица, организации и иностранные структуры.
#XML #ПЗ #XML_схема #BagFixes
Please open Telegram to view this post
VIEW IN TELEGRAM
Уточнен порядок уведомления СРО о заключенных договорах подряда
Приказ Минстроя России от 03.02.2026 № 59/пр внесены изменения в Порядок уведомления СРО в области инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции, капитального ремонта, сноса ОКС о заключенных членом такой СРО договорах подряда на выполнение инженерных изысканий, подготовку проектной документации, договорах строительного подряда, договорах подряда на осуществление сноса, а также о фактическом совокупном размере обязательств по договорам, заключенным с использованием конкурентных способов заключения договоров‚ утв. Приказом Минстроя России от 27 октября 2025 г. № 655/пр.
В частности, изменения затронули корректировку ссылок на внутренний пункты документа, указанных ранее ошибочно.
📸 bimsert
Приказ Минстроя России от 03.02.2026 № 59/пр внесены изменения в Порядок уведомления СРО в области инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции, капитального ремонта, сноса ОКС о заключенных членом такой СРО договорах подряда на выполнение инженерных изысканий, подготовку проектной документации, договорах строительного подряда, договорах подряда на осуществление сноса, а также о фактическом совокупном размере обязательств по договорам, заключенным с использованием конкурентных способов заключения договоров‚ утв. Приказом Минстроя России от 27 октября 2025 г. № 655/пр.
В частности, изменения затронули корректировку ссылок на внутренний пункты документа, указанных ранее ошибочно.
Please open Telegram to view this post
VIEW IN TELEGRAM
Упрощается согласование АГО для проектов КРТ
На публичное обсуждение размещен проект постановления Правительства РФ о внесении изменения в постановление Правительства РФ от 29 мая 2023 г. № 857» (далее — проект постановления).
Проект постановления подготовлен в инициативном порядке в целях оптимизации процедуры согласования архитектурно-градостроительного облика объекта капитального строительства (далее — АГО), сокращения сроков инвестиционно-строительного цикла строительства объектов капитального строительства, осуществляемого в рамках КРТ.
Согласно действующей редакции абзаца первого пункта 4 Правил согласования АГО, утвержденных постановлением Правительства РФ от 29 мая 2023 г. № 857 «Об утверждении требований
к архитектурно-градостроительному облику объекта капитального строительства и Правил согласования архитектурно-градостроительного облика объекта капитального строительства» (далее — Правила), подать в уполномоченный орган местного самоуправления заявление для согласования АГО может правообладатель ЗУ, на котором планируется строительство такого объекта, или правообладатель ОКС в случае его реконструкции, или иное лицо в случае, предусмотренном частью 1.1 статьи 57.3 ГрК РФ.
К иным лицам, исходя из положений части 1.1 статьи 57.3 ГрК РФ, относятся лица, обеспечившие подготовку ПД объектов федерального, регионального, местного значения, не являющиеся правообладателями ЗУ в виду того, что ЗУ, на котором запланирован к размещению соответствующий объект, подлежит образованию.
Федеральным законом от 25 декабря 2023 г. № 627-ФЗ статья 57.3 ГрК РФ была дополнена частью 1.2, включившей в состав лиц, не являющихся правообладателями ЗУ и имеющих право на обращение за выдачей ГПЗУ, который образуется из земель и (или) земельных участков, которые находятся в гос- или муниципальной собственности, в целях КРТ, оператора КРТ или лицо, с которым заключен договор о КРТ.
При этом действующая редакция Правил не допускает возможность обращения оператора КРТ или лица, с которым заключен договор о КРТ, за согласованием АГО до тех пор, пока не будет осуществлен кадастровый учет, зарегистрированы и оформлены права на соответствующие ЗУ.
В административных регламентах, утвержденных уполномоченными органами власти, несоответствие категории заявителя кругу лиц, указанных в Правилах, является основанием для отказа в приеме документов и (или) в предоставлении услуги по согласованию АГО.
Ситуация усложняется тем, что процедура согласования АГО достаточно длительная, поскольку может осуществляться неоднократно в связи
с необходимостью доработки по замечаниям согласующего органа архитектурных решений, содержащихся в ПД.
С учетом вышеизложенного предлагается дополнить перечень иных лиц, имеющих право обращения за согласованием АГО, операторами КРТ и лицами, с которым заключен договор о КРТ.
Возможность согласования АГО одновременно с осуществлением процедур кадастрового учета, регистрации и оформления прав на ЗУ позволит избежать временных потерь и ускорить реализацию проектов КРТ.
📸 bimsert
На публичное обсуждение размещен проект постановления Правительства РФ о внесении изменения в постановление Правительства РФ от 29 мая 2023 г. № 857» (далее — проект постановления).
Проект постановления подготовлен в инициативном порядке в целях оптимизации процедуры согласования архитектурно-градостроительного облика объекта капитального строительства (далее — АГО), сокращения сроков инвестиционно-строительного цикла строительства объектов капитального строительства, осуществляемого в рамках КРТ.
Согласно действующей редакции абзаца первого пункта 4 Правил согласования АГО, утвержденных постановлением Правительства РФ от 29 мая 2023 г. № 857 «Об утверждении требований
к архитектурно-градостроительному облику объекта капитального строительства и Правил согласования архитектурно-градостроительного облика объекта капитального строительства» (далее — Правила), подать в уполномоченный орган местного самоуправления заявление для согласования АГО может правообладатель ЗУ, на котором планируется строительство такого объекта, или правообладатель ОКС в случае его реконструкции, или иное лицо в случае, предусмотренном частью 1.1 статьи 57.3 ГрК РФ.
К иным лицам, исходя из положений части 1.1 статьи 57.3 ГрК РФ, относятся лица, обеспечившие подготовку ПД объектов федерального, регионального, местного значения, не являющиеся правообладателями ЗУ в виду того, что ЗУ, на котором запланирован к размещению соответствующий объект, подлежит образованию.
Федеральным законом от 25 декабря 2023 г. № 627-ФЗ статья 57.3 ГрК РФ была дополнена частью 1.2, включившей в состав лиц, не являющихся правообладателями ЗУ и имеющих право на обращение за выдачей ГПЗУ, который образуется из земель и (или) земельных участков, которые находятся в гос- или муниципальной собственности, в целях КРТ, оператора КРТ или лицо, с которым заключен договор о КРТ.
При этом действующая редакция Правил не допускает возможность обращения оператора КРТ или лица, с которым заключен договор о КРТ, за согласованием АГО до тех пор, пока не будет осуществлен кадастровый учет, зарегистрированы и оформлены права на соответствующие ЗУ.
В административных регламентах, утвержденных уполномоченными органами власти, несоответствие категории заявителя кругу лиц, указанных в Правилах, является основанием для отказа в приеме документов и (или) в предоставлении услуги по согласованию АГО.
Ситуация усложняется тем, что процедура согласования АГО достаточно длительная, поскольку может осуществляться неоднократно в связи
с необходимостью доработки по замечаниям согласующего органа архитектурных решений, содержащихся в ПД.
С учетом вышеизложенного предлагается дополнить перечень иных лиц, имеющих право обращения за согласованием АГО, операторами КРТ и лицами, с которым заключен договор о КРТ.
Возможность согласования АГО одновременно с осуществлением процедур кадастрового учета, регистрации и оформления прав на ЗУ позволит избежать временных потерь и ускорить реализацию проектов КРТ.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Об обязательности заполнения раздела SoftwareNote в XML-схеме Пояснительной записки версии 01.07 и перспективах контроля используемого ПО для подготовки ПД
В версии XML-схемы Пояснительной записки 01.07 раздел SoftwareNote (Сведения о программном обеспечении) остался без изменений по сравнению с версией 01.06.
Как и ранее, SoftwareNote представляет собой текстовый информационный блок, предназначенный для указания программных средств, использованных при подготовке проектной документации.
Особенности раздела:
• необязательный элемент: блок может отсутствовать в XML; его отсутствие не вызывает ошибок валидации
• структура неизменна: по-прежнему текстовый пояснительный блок, аналогичный версии 01.06
• заполнение по усмотрению: разработчик документации сам решает, включать ли сведения о программном обеспечении
Технически в XML-схеме это реализовано через minOccurs=“0”, что обеспечивает корректную валидацию даже при отсутствии блока.
Таким образом, на текущий момент SoftwareNote служит дополнительным информационным блоком и не влияет на корректность XML-документа.
В перспективе, после изменений в ГрК РФ по части ЦИМ и соответствующих НПА, включая постановления Правительства РФ, устанавливающих случаи обязательного формирования и ведения информационной модели с применением российского программного обеспечения, раздел SoftwareNote может стать обязательным.
Для реализации такой форматно-логической проверки разработчикам российского ПО потребуется регулярно передавать в адрес Минстроя России или ФАУ «Главгосэкспертиза России» сведения о номерах приоритетных лицензий, сроках их действия, а также реквизиты юридических лиц и индивидуальных предпринимателей, являющихся лицензиатами соответствующего ПО.
Практическая реализация этих процедур, включая передачу вендорами списков своих клиентов с номерами лицензий, остаётся дискуссионной. Вопрос крайне чувствительный, так как затрагивает аспекты коммерческой тайны. Часто то, что знают двое, знают все.
Сам механизм проверки использования соответствующего ПО через XML (ПЗ) не является единственным. Возможны и другие варианты (вариаций больше чем одна): например, через атрибуты ПО в сущностях IFC, который может стать обязательным после корректировки соответствующих НПА, а также через создаваемую систему рейтингования подрядчиков, нацреестры, СРО и другие инструменты. Тем не менее, для реализации автоматизированных проверок именно через ПЗ и органы экспертизы вендорам придётся на регулярной основе передавать сведения из своей клиентской базы в адрес экспертных организаций (например, через API в ИС экспертных организаций).
#XML #ПЗ #XML_схема #SoftwareNote
📸 bimsert
В версии XML-схемы Пояснительной записки 01.07 раздел SoftwareNote (Сведения о программном обеспечении) остался без изменений по сравнению с версией 01.06.
Как и ранее, SoftwareNote представляет собой текстовый информационный блок, предназначенный для указания программных средств, использованных при подготовке проектной документации.
Особенности раздела:
• необязательный элемент: блок может отсутствовать в XML; его отсутствие не вызывает ошибок валидации
• структура неизменна: по-прежнему текстовый пояснительный блок, аналогичный версии 01.06
• заполнение по усмотрению: разработчик документации сам решает, включать ли сведения о программном обеспечении
Технически в XML-схеме это реализовано через minOccurs=“0”, что обеспечивает корректную валидацию даже при отсутствии блока.
Таким образом, на текущий момент SoftwareNote служит дополнительным информационным блоком и не влияет на корректность XML-документа.
В перспективе, после изменений в ГрК РФ по части ЦИМ и соответствующих НПА, включая постановления Правительства РФ, устанавливающих случаи обязательного формирования и ведения информационной модели с применением российского программного обеспечения, раздел SoftwareNote может стать обязательным.
Для реализации такой форматно-логической проверки разработчикам российского ПО потребуется регулярно передавать в адрес Минстроя России или ФАУ «Главгосэкспертиза России» сведения о номерах приоритетных лицензий, сроках их действия, а также реквизиты юридических лиц и индивидуальных предпринимателей, являющихся лицензиатами соответствующего ПО.
Практическая реализация этих процедур, включая передачу вендорами списков своих клиентов с номерами лицензий, остаётся дискуссионной. Вопрос крайне чувствительный, так как затрагивает аспекты коммерческой тайны. Часто то, что знают двое, знают все.
Сам механизм проверки использования соответствующего ПО через XML (ПЗ) не является единственным. Возможны и другие варианты (вариаций больше чем одна): например, через атрибуты ПО в сущностях IFC, который может стать обязательным после корректировки соответствующих НПА, а также через создаваемую систему рейтингования подрядчиков, нацреестры, СРО и другие инструменты. Тем не менее, для реализации автоматизированных проверок именно через ПЗ и органы экспертизы вендорам придётся на регулярной основе передавать сведения из своей клиентской базы в адрес экспертных организаций (например, через API в ИС экспертных организаций).
#XML #ПЗ #XML_схема #SoftwareNote
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Реформа 304-ФЗ застряла в неопределённости: регионы не готовы вкладываться в системы, которые устареют через 2-3 года
Федеральный закон от 31.07.2025 № 304-ФЗ внёс поправки в статью 51 ГрК РФ.
В соответствии с поправками начиная с 1 сентября 2026 год выдача разрешений на строительство и ввод объектов в эксплуатацию будут выдаваться исключительно в виде записи в реестре.
С начала осени этого года вместо документа «Разрешение на строительство» (РнС) заявители будут получать уведомление о внесении записи и «выписку из реестра РнС». Состав сведений, типовая форма выписки из реестра РнС и порядок его ведения будут утверждены отдельным НПА.
В соответствии с частью 1.4. статьи 51 ГрК РФ, Реестр РнС, выдаваемых органами исполнительной власти субъектов РФ и органами местного самоуправления, ведется в ГИСОГД субъектов РФ.
Для исполнения 304-ФЗ в части выдачи уведомлений о внесении записи и выписок из реестра РнС требуется выполнение доработок региональных ГИСОГД.
По информации от субъектов РФ стоимость таких доработок региональных ГИСОГД в среднем составляет от 20 до 40 млн. рублей в зависимости от применяемой регионом системы. Взяв 30 млн. рублей за ориентир, как среднее между 20 и 40, а затем умножив на 89 субъектов РФ получим, что исполнение 304-ФЗ в части реестровой модели РнВ обойдется чуть более 2,6 млд. рублей.
В это же время цифровой блок федерального Минстроя анонсирует переход субъектов РФ с региональных ГИСОГД на федеральное же типовое облачное решение «Управление строительством». Исходя из презентации директора проекта ГИС ТОР «Управление строительством» Александра Павловского первые субъекты перейдут на ТОР уже в 2026 году.
Следует также отметить, что одной из причин создания ГИС ТОР «Управление строительством» заявлена дороговизна и сложность развития систем ГИСОГД субъектов РФ, ИСУП, ГСН и т.д.
«Дорого» или «дёшево» понятия субъективные. В бюджетном заказе, как и в контрольно-надзорных органах, а равно с ними и в компетентных органах, оперируют понятиями обосновано и необоснованно.
Несмотря на то, что 1 сентября 2026 не за горами, региональные операторы ГИСОГД не спешат дорабатывать свои системы, т.к. им решительно не понятно посчитает ли контролирующий орган обоснованным расходование ~30 млн. руб. на развитие в ИСОГД, если по федеральному замыслу системой регион будет пользоваться лишь 2-3 года.
Снять неопределённость в вопросе обоснованности развития региональных систем, сэкономить бюджетные средства субъектов РФ, а также поспособствовать в скорейшем переходе регионов с ГИСОГД на ТОР «Управление строительством» предложил Первый Заместитель Министра строительства Новосибирской области Дмитрий Тимонов.
Суть предложения коллеги, озвученного на Сибирской строительной неделе, заключается в приоретизации разработки модуля по выдаче уведомлений о внесении записи и выписок из реестра РнВ в ГИС ТОР «Управление строительством». Мысль выглядит здравой и рациональной.
Прислушается ли федеральные Минстрой и Минцифра к предложению с мест, которое позволяет не допустить возникновение ситуации с неэффективным использованием без малого 30 млн. рублей бюджетных средств каждым из субъектов РФ (~2,6 млрд. руб.)?
А надо бы прислушаться, так как вместо того чтобы требовать от регионов срочных вложений в устаревающие системы, разумнее ускорить разработку нужного модуля в ГИС ТОР «Управление строительством». Это избавит субъекты РФ от неоправданных расходов и обеспечит единое цифровое пространство отрасли - без промежуточных потерь и двойной работы.
Да и принцип ответственности за результативность обеспечения гос- и муниципальных нужд, эффективность осуществления закупок, установленный статьей 12 Закона № 44-ФЗ, которым должны руководствоваться государственные органы, органы управления государственными внебюджетными фондами, муниципальные органы, казенные учреждения, иные юридические лица в случаях, установленных Законом № 44-ФЗ, при планировании и осуществлении закупок, никто не отменял. То же касается и принципа эффективности использования бюджетных средств, установленного статьей 34 БК РФ.
📸 bimsert
Федеральный закон от 31.07.2025 № 304-ФЗ внёс поправки в статью 51 ГрК РФ.
В соответствии с поправками начиная с 1 сентября 2026 год выдача разрешений на строительство и ввод объектов в эксплуатацию будут выдаваться исключительно в виде записи в реестре.
С начала осени этого года вместо документа «Разрешение на строительство» (РнС) заявители будут получать уведомление о внесении записи и «выписку из реестра РнС». Состав сведений, типовая форма выписки из реестра РнС и порядок его ведения будут утверждены отдельным НПА.
В соответствии с частью 1.4. статьи 51 ГрК РФ, Реестр РнС, выдаваемых органами исполнительной власти субъектов РФ и органами местного самоуправления, ведется в ГИСОГД субъектов РФ.
Для исполнения 304-ФЗ в части выдачи уведомлений о внесении записи и выписок из реестра РнС требуется выполнение доработок региональных ГИСОГД.
По информации от субъектов РФ стоимость таких доработок региональных ГИСОГД в среднем составляет от 20 до 40 млн. рублей в зависимости от применяемой регионом системы. Взяв 30 млн. рублей за ориентир, как среднее между 20 и 40, а затем умножив на 89 субъектов РФ получим, что исполнение 304-ФЗ в части реестровой модели РнВ обойдется чуть более 2,6 млд. рублей.
В это же время цифровой блок федерального Минстроя анонсирует переход субъектов РФ с региональных ГИСОГД на федеральное же типовое облачное решение «Управление строительством». Исходя из презентации директора проекта ГИС ТОР «Управление строительством» Александра Павловского первые субъекты перейдут на ТОР уже в 2026 году.
Следует также отметить, что одной из причин создания ГИС ТОР «Управление строительством» заявлена дороговизна и сложность развития систем ГИСОГД субъектов РФ, ИСУП, ГСН и т.д.
«Дорого» или «дёшево» понятия субъективные. В бюджетном заказе, как и в контрольно-надзорных органах, а равно с ними и в компетентных органах, оперируют понятиями обосновано и необоснованно.
Несмотря на то, что 1 сентября 2026 не за горами, региональные операторы ГИСОГД не спешат дорабатывать свои системы, т.к. им решительно не понятно посчитает ли контролирующий орган обоснованным расходование ~30 млн. руб. на развитие в ИСОГД, если по федеральному замыслу системой регион будет пользоваться лишь 2-3 года.
Снять неопределённость в вопросе обоснованности развития региональных систем, сэкономить бюджетные средства субъектов РФ, а также поспособствовать в скорейшем переходе регионов с ГИСОГД на ТОР «Управление строительством» предложил Первый Заместитель Министра строительства Новосибирской области Дмитрий Тимонов.
Суть предложения коллеги, озвученного на Сибирской строительной неделе, заключается в приоретизации разработки модуля по выдаче уведомлений о внесении записи и выписок из реестра РнВ в ГИС ТОР «Управление строительством». Мысль выглядит здравой и рациональной.
Прислушается ли федеральные Минстрой и Минцифра к предложению с мест, которое позволяет не допустить возникновение ситуации с неэффективным использованием без малого 30 млн. рублей бюджетных средств каждым из субъектов РФ (~2,6 млрд. руб.)?
А надо бы прислушаться, так как вместо того чтобы требовать от регионов срочных вложений в устаревающие системы, разумнее ускорить разработку нужного модуля в ГИС ТОР «Управление строительством». Это избавит субъекты РФ от неоправданных расходов и обеспечит единое цифровое пространство отрасли - без промежуточных потерь и двойной работы.
Да и принцип ответственности за результативность обеспечения гос- и муниципальных нужд, эффективность осуществления закупок, установленный статьей 12 Закона № 44-ФЗ, которым должны руководствоваться государственные органы, органы управления государственными внебюджетными фондами, муниципальные органы, казенные учреждения, иные юридические лица в случаях, установленных Законом № 44-ФЗ, при планировании и осуществлении закупок, никто не отменял. То же касается и принципа эффективности использования бюджетных средств, установленного статьей 34 БК РФ.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Задание на проектирование: что изменилось в версии XML-схемы 01.01
11 марта 2026 года Минстрой России разместил на своем сайте обновлённую версию XML-схемы задания на проектирование - DesignAssignment-01-01.xsd. Новая версия учитывает изменения в законодательстве, исправляет ошибки прошлых редакций и делает ряд требований необязательными.
Ниже, разобрали простым языком ключевые изменения.
Общая логика изменений
Главный тренд версии 01.01 - гибкость и унификация. Разработчики схемы убрали избыточные обязательные поля, унифицировали типы данных, добавили возможность указывать несколько технических заказчиков и актуализировали справочники под новые нормы.
Что стало необязательным
Раньше многие разделы требовали обязательного заполнения. Теперь их можно пропускать.
Элементы, ставшие необязательными
EngineeringSurvey - необходимость выполнения инженерных изысканий. Был обязательным, стал опциональным.
Land - сведения о земельных участках. Был обязательным, стал опциональным.
InitialDocuments - материалы, предоставляемые застройщиком. Был обязательным, стал опциональным.
ProjectDocuments - требования к составу проектной документации. Был обязательным, стал опциональным.
Выбор раздела проектной документации (IndustrialObject, NotIndustrialObject, LinearObject) - был обязательным, теперь можно не выбирать.
Атрибуты объекта, ставшие необязательными
В версии 01.00 многие атрибуты объекта были обязательными: SecurityInfluence, DangerousIndustrialObject, FireDangerCategory, ResponsibilityLevel и другие. В версии 01.01 все они стали опциональными. Это значит, что теперь можно указывать только те характеристики, которые действительно известны.
Новые возможности и уточнения
Технические заказчики. Раньше можно было указать только одного технического заказчика. Теперь их может быть несколько - появился контейнер TechnicalCustomers.
Разработчики проектной документации. Структура полностью переработана. Появился отдельный элемент DesignerGeneral для генпроектировщика. Можно указывать несколько элементов Designer для субподрядчиков. Добавлена возможность указать номер в реестре НОПРИЗ.
Адреса. Введён новый тип tObjectAddress, который позволяет указывать не только обычный адрес, но и расположение на континентальном шельфе, в исключительной экономической зоне и во внутренних водах.
Справочники и типы данных
Гриф доступа tSecurityLabel - добавлено значение 4 - Для служебного пользования.
Доля финансирования tFinanceRatioValue - тип изменён с float на decimal для большей точности.
Роль подписанта tFunctionalRole - теперь текстовые значения Утверждено и Согласовано вместо числовых 1 и 2.
Код объекта tObjectCode - тип исключён, вместо него используется просто непустая строка tNotEmptyString200.
Технические правки и унификация
Тип автора в DocumentInfo приведён к единому tAuthor, как в других частях схемы.
Удалён элемент Author внутри Requirement - теперь требования без указания автора.
Удалён элемент IULFile - информационно-удостоверяющий лист больше не требуется.
Исправлена орфографическая ошибка: Standardization переименован в Standartization.
Аннотации элементов дополнены ссылками на приказ Минстроя 307/пр.
Общий вывод
Версия 01.01 XML-схемы стала гибче: разработчики убрали обязательность многих полей, упростили структуру и исправили ошибки. Теперь застройщик может включать в документ только те сведения, которые действительно есть и значимы для объекта.
Важная оговорка: часть атрибутов, ставших необязательными в схеме (уровень ответственности, категория пожарной опасности и другие), согласно части 11 статьи 4 Федерального закона № 384-ФЗ должны указываться в ЗнП в обязательном порядке. Снятие обязательности в XML-схеме не отменяет требований закона - на экспертизе отсутствие этих признаков станет основанием для замечания.
В остальном изменения полезные: унифицированы типы данных, появилась возможность указывать несколько техзаказчиков и выделять генпроектировщика, добавлена поддержка нестандартных адресов (шельф, исключительная экономическая зона).
📸 bimsert
11 марта 2026 года Минстрой России разместил на своем сайте обновлённую версию XML-схемы задания на проектирование - DesignAssignment-01-01.xsd. Новая версия учитывает изменения в законодательстве, исправляет ошибки прошлых редакций и делает ряд требований необязательными.
Ниже, разобрали простым языком ключевые изменения.
Общая логика изменений
Главный тренд версии 01.01 - гибкость и унификация. Разработчики схемы убрали избыточные обязательные поля, унифицировали типы данных, добавили возможность указывать несколько технических заказчиков и актуализировали справочники под новые нормы.
Что стало необязательным
Раньше многие разделы требовали обязательного заполнения. Теперь их можно пропускать.
Элементы, ставшие необязательными
EngineeringSurvey - необходимость выполнения инженерных изысканий. Был обязательным, стал опциональным.
Land - сведения о земельных участках. Был обязательным, стал опциональным.
InitialDocuments - материалы, предоставляемые застройщиком. Был обязательным, стал опциональным.
ProjectDocuments - требования к составу проектной документации. Был обязательным, стал опциональным.
Выбор раздела проектной документации (IndustrialObject, NotIndustrialObject, LinearObject) - был обязательным, теперь можно не выбирать.
Атрибуты объекта, ставшие необязательными
В версии 01.00 многие атрибуты объекта были обязательными: SecurityInfluence, DangerousIndustrialObject, FireDangerCategory, ResponsibilityLevel и другие. В версии 01.01 все они стали опциональными. Это значит, что теперь можно указывать только те характеристики, которые действительно известны.
Новые возможности и уточнения
Технические заказчики. Раньше можно было указать только одного технического заказчика. Теперь их может быть несколько - появился контейнер TechnicalCustomers.
Разработчики проектной документации. Структура полностью переработана. Появился отдельный элемент DesignerGeneral для генпроектировщика. Можно указывать несколько элементов Designer для субподрядчиков. Добавлена возможность указать номер в реестре НОПРИЗ.
Адреса. Введён новый тип tObjectAddress, который позволяет указывать не только обычный адрес, но и расположение на континентальном шельфе, в исключительной экономической зоне и во внутренних водах.
Справочники и типы данных
Гриф доступа tSecurityLabel - добавлено значение 4 - Для служебного пользования.
Доля финансирования tFinanceRatioValue - тип изменён с float на decimal для большей точности.
Роль подписанта tFunctionalRole - теперь текстовые значения Утверждено и Согласовано вместо числовых 1 и 2.
Код объекта tObjectCode - тип исключён, вместо него используется просто непустая строка tNotEmptyString200.
Технические правки и унификация
Тип автора в DocumentInfo приведён к единому tAuthor, как в других частях схемы.
Удалён элемент Author внутри Requirement - теперь требования без указания автора.
Удалён элемент IULFile - информационно-удостоверяющий лист больше не требуется.
Исправлена орфографическая ошибка: Standardization переименован в Standartization.
Аннотации элементов дополнены ссылками на приказ Минстроя 307/пр.
Общий вывод
Версия 01.01 XML-схемы стала гибче: разработчики убрали обязательность многих полей, упростили структуру и исправили ошибки. Теперь застройщик может включать в документ только те сведения, которые действительно есть и значимы для объекта.
Важная оговорка: часть атрибутов, ставших необязательными в схеме (уровень ответственности, категория пожарной опасности и другие), согласно части 11 статьи 4 Федерального закона № 384-ФЗ должны указываться в ЗнП в обязательном порядке. Снятие обязательности в XML-схеме не отменяет требований закона - на экспертизе отсутствие этих признаков станет основанием для замечания.
В остальном изменения полезные: унифицированы типы данных, появилась возможность указывать несколько техзаказчиков и выделять генпроектировщика, добавлена поддержка нестандартных адресов (шельф, исключительная экономическая зона).
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всё про IFC
Требования к ЦИМ в формате IDS от Мособлэкспертизы
Мособлэкспертиза разработала новую редакцию требований к ЦИМ, в том числе в формате IDS:
- Требования к ЦИМ автомобильных дорог и улично-дорожной сети.
- Требования к ЦИМ наружных инженерных сетей.
- Требования к ЦИМ производственным и непроизводственным ОКС.
> СКАЧАТЬ <
@IFC_ru
@IFC_club
Мособлэкспертиза разработала новую редакцию требований к ЦИМ, в том числе в формате IDS:
- Требования к ЦИМ автомобильных дорог и улично-дорожной сети.
- Требования к ЦИМ наружных инженерных сетей.
- Требования к ЦИМ производственным и непроизводственным ОКС.
> СКАЧАТЬ <
@IFC_ru
@IFC_club
www.moexp.ru
Технологии информационного моделирования (BIM)
Технологии информационного моделирования (ТИМ)
❤1
ЗП-2025-001.pdf
355.4 KB
ИИ-агент в проектировании: пример генерации XML-задания и его XSLT-преобразования
Пример XSLT-преобразования задания на проектирование, разработанного в формате XML на основе версии XML-схемы 01.01, вступающей в силу с 11 июня 2026 года.
Из примечательного - данное задание на проектирование сформировано в формате XML полностью искусственным интеллектом. Данные заполнены рандомно, без каких-либо указаний, в связи с чем содержание пунктов носит «творческий» характер.
Однако сегодня мы можем уже точно сказать, что, используя довольно несложный промпт, на базе большинства доступных ИИ-агентов задание на проектирование можно сформировать как в формате XML на основе соответствующей XML-схемы, так и выполнить его XSLT-преобразование с экспортом в HTML и иные человекочитаемые форматы.
Достаточно установить для ИИ-агента условия по формированию задания на проектирование в формате XML на основе соответствующей версии XML-схемы и XSLT-файла в режиме диалога с пользователем. ИИ-агент задаёт вопросы, пользователь отвечает на них и предоставляет необходимые файлы. Затем ИИ-агент формирует задание в XML и выполняет его XSLT-преобразование с экспортом в требуемый формат.
Для упрощения работы часть сведений для тех или иных элементов и атрибутов XML-схемы ИИ-агенты могут брать из предварительно созданных пользователем справочников условий, представленных в разных форматах (в т.ч. полученные из СОД или CRM). Такие справочники типовых формулировок для задания на проектирование можно разработать как для конкретных видов функционального назначения объектов капитального строительства (ОКС), так и для заполнения общих сведений (общих элементов и атрибутов) для любых ОКС, вне зависимости от вида их функционального назначения. Если данные будут заимствовать из документов в СОД или CRM систем будет еще удобнее. Вариаций тут больше чем одна.
Фактически, в перспективе, если бы у нас было больше времени и ресурсов, мы могли бы уже сегодня приблизиться к тому самому желаемому результату «нажми на кнопку - получишь результат», когда формирование задания на проектирование можно было бы получать за 10–15 минут практически без участия человека, не считая данной им команды «создай задание». И поверьте, это ближе, чем мы думаем.
На начальном этапе достаточно начать с одного функционального назначения объекта или с нескольких общих справочников, далее - по нарастающей. Это уже данность. С одной стороны, это открывает новые возможности, с другой - мы, возможно, слишком быстро подошли к таким технологиям. И это заставляет задуматься.
UPD: на момент создания указанного здания отсутствовали доступные решения, позволяющих сформировать ЗнП.xml по версии XML-схемы 01.01.
📸 bimsert
Пример XSLT-преобразования задания на проектирование, разработанного в формате XML на основе версии XML-схемы 01.01, вступающей в силу с 11 июня 2026 года.
Из примечательного - данное задание на проектирование сформировано в формате XML полностью искусственным интеллектом. Данные заполнены рандомно, без каких-либо указаний, в связи с чем содержание пунктов носит «творческий» характер.
Однако сегодня мы можем уже точно сказать, что, используя довольно несложный промпт, на базе большинства доступных ИИ-агентов задание на проектирование можно сформировать как в формате XML на основе соответствующей XML-схемы, так и выполнить его XSLT-преобразование с экспортом в HTML и иные человекочитаемые форматы.
Достаточно установить для ИИ-агента условия по формированию задания на проектирование в формате XML на основе соответствующей версии XML-схемы и XSLT-файла в режиме диалога с пользователем. ИИ-агент задаёт вопросы, пользователь отвечает на них и предоставляет необходимые файлы. Затем ИИ-агент формирует задание в XML и выполняет его XSLT-преобразование с экспортом в требуемый формат.
Для упрощения работы часть сведений для тех или иных элементов и атрибутов XML-схемы ИИ-агенты могут брать из предварительно созданных пользователем справочников условий, представленных в разных форматах (в т.ч. полученные из СОД или CRM). Такие справочники типовых формулировок для задания на проектирование можно разработать как для конкретных видов функционального назначения объектов капитального строительства (ОКС), так и для заполнения общих сведений (общих элементов и атрибутов) для любых ОКС, вне зависимости от вида их функционального назначения. Если данные будут заимствовать из документов в СОД или CRM систем будет еще удобнее. Вариаций тут больше чем одна.
Фактически, в перспективе, если бы у нас было больше времени и ресурсов, мы могли бы уже сегодня приблизиться к тому самому желаемому результату «нажми на кнопку - получишь результат», когда формирование задания на проектирование можно было бы получать за 10–15 минут практически без участия человека, не считая данной им команды «создай задание». И поверьте, это ближе, чем мы думаем.
На начальном этапе достаточно начать с одного функционального назначения объекта или с нескольких общих справочников, далее - по нарастающей. Это уже данность. С одной стороны, это открывает новые возможности, с другой - мы, возможно, слишком быстро подошли к таким технологиям. И это заставляет задуматься.
UPD: на момент создания указанного здания отсутствовали доступные решения, позволяющих сформировать ЗнП.xml по версии XML-схемы 01.01.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Выписка_на_ввод_объектов_в_эксплуатацию.html
42 KB
Как будет выглядеть выписка из реестра разрешений на строительство и выписка из реестра разрешений на ввод в эксплуатацию
Напомним, 11 марта 2026 года на сайте Монстроя России в разделе «Разрабатываемые XML-схемы» среди прочих были размещены XML-схемы
Выписки из реестра разрешений на строительство и Выписка из реестра разрешений на ввод объектов в эксплуатацию.
Прикладываем примеры визуализации указанных выписок в формате HTML.
📸 bimsert
Напомним, 11 марта 2026 года на сайте Монстроя России в разделе «Разрабатываемые XML-схемы» среди прочих были размещены XML-схемы
Выписки из реестра разрешений на строительство и Выписка из реестра разрешений на ввод объектов в эксплуатацию.
Прикладываем примеры визуализации указанных выписок в формате HTML.
Please open Telegram to view this post
VIEW IN TELEGRAM
Минцифры готовит законопроект о праве отказаться от обслуживания с использованием ИИ
Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации подготовило законопроект о регулировании технологий искусственного интеллекта, который предусматривает возможность для граждан отказаться от услуг, оказываемых с использованием нейросетей. Об этом «Известиям» сообщили источники, знакомые с разработкой документа.
Согласно инициативе, организации будут обязаны предоставить клиенту услугу без применения искусственного интеллекта, если пользователь отказался от такого формата взаимодействия. Документ сейчас проходит межведомственное согласование, а ориентировочной датой вступления закона в силу называется 1 сентября 2027 года. Перечень ситуаций, в которых гражданин сможет отказаться от обслуживания ИИ, должно определить правительство.
В версии законопроекта, с которой ознакомились журналисты, само право на отказ и механизм его реализации прямо не прописаны. Однако, по словам источников, эта норма присутствовала в предыдущих редакциях документа и может вернуться в более доработанный вариант.
Проект также содержит ряд других требований к применению искусственного интеллекта. В частности, если ИИ принимает решение, затрагивающее права и свободы человека, пользователь должен быть уведомлён об этом. Разработчиков нейросетей могут обязать тестировать системы на предмет возможного использования в противоправных целях, а также исключать функции, способные привести к дискриминации пользователей.
📸 bimsert
Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации подготовило законопроект о регулировании технологий искусственного интеллекта, который предусматривает возможность для граждан отказаться от услуг, оказываемых с использованием нейросетей. Об этом «Известиям» сообщили источники, знакомые с разработкой документа.
Согласно инициативе, организации будут обязаны предоставить клиенту услугу без применения искусственного интеллекта, если пользователь отказался от такого формата взаимодействия. Документ сейчас проходит межведомственное согласование, а ориентировочной датой вступления закона в силу называется 1 сентября 2027 года. Перечень ситуаций, в которых гражданин сможет отказаться от обслуживания ИИ, должно определить правительство.
В версии законопроекта, с которой ознакомились журналисты, само право на отказ и механизм его реализации прямо не прописаны. Однако, по словам источников, эта норма присутствовала в предыдущих редакциях документа и может вернуться в более доработанный вариант.
Проект также содержит ряд других требований к применению искусственного интеллекта. В частности, если ИИ принимает решение, затрагивающее права и свободы человека, пользователь должен быть уведомлён об этом. Разработчиков нейросетей могут обязать тестировать системы на предмет возможного использования в противоправных целях, а также исключать функции, способные привести к дискриминации пользователей.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Главгосэкспертиза приступила к пилотированию ЕЦПЭ 2.0: новая платформа станет гибким конструктором для экспертных организаций
ФАУ «Главгосэкспертиза России», являясь разработчиком действующей Единой цифровой платформы экспертизы (ЕЦПЭ версии 1.0), в настоящий момент проектирует её вторую, значительно более гибкую версию. Ключевое отличие ЕЦПЭ 2.0 - возможность тонкой настройки под нужды каждой конкретной организации: от изменения форм заявлений и состава комплектов документации до настройки бизнес-процессов.
В настоящее время пилотирование Платформы уже ведется сотрудниками региональных экспертных организаций и специалистами самого Учреждения. Первые практические результаты ожидаются в ближайшее время: пилотные экспертизы проектной документации и результатов инженерных изысканий с использованием новой версии запланированы на начало III квартала 2026 года.
Особое внимание разработчики уделили потребностям негосударственных экспертиз. Для них прорабатывается несколько версий платформы, различающихся по глубине функциональности.
Базовая версия
Предусматривает необходимый минимум для эффективной работы:
1. Подача документов: Загрузка заявителем проектной документации через личный кабинет. Реализована возможность автоматического формирования заявления на основе данных из пояснительной записки, если она предоставлена в машиночитаемом формате.
2. Подготовка заключения: Формирование сводного заключения с предзаполнением сведений о рассмотренной документации на основе ранее загруженных файлов, что сокращает время на ручной ввод.
3. Интеграция с госреестром: Подписание готового заключения и его автоматическая передача вместе с проектной документацией в Единый государственный реестр заключений (ЕГРЗ).
Расширенная версия
Включает в себя весь функционал базовой версии и дополнена инструментами для комплексного управления процессами экспертизы:
1. Юридический блок - формирование договорных документов на основе встроенных шаблонов.
2. Управление экспертизой - формирование экспертной группы и назначение индивидуальных заданий на рассмотрение разделов документации.
3. Взаимодействие с заявителем - формирование, направление и отслеживание процесса исправления заявителем замечаний, представленных в машиночитаемом виде, что исключает двусмысленность трактовок и ускоряет доработку.
📸 bimsert
ФАУ «Главгосэкспертиза России», являясь разработчиком действующей Единой цифровой платформы экспертизы (ЕЦПЭ версии 1.0), в настоящий момент проектирует её вторую, значительно более гибкую версию. Ключевое отличие ЕЦПЭ 2.0 - возможность тонкой настройки под нужды каждой конкретной организации: от изменения форм заявлений и состава комплектов документации до настройки бизнес-процессов.
В настоящее время пилотирование Платформы уже ведется сотрудниками региональных экспертных организаций и специалистами самого Учреждения. Первые практические результаты ожидаются в ближайшее время: пилотные экспертизы проектной документации и результатов инженерных изысканий с использованием новой версии запланированы на начало III квартала 2026 года.
Особое внимание разработчики уделили потребностям негосударственных экспертиз. Для них прорабатывается несколько версий платформы, различающихся по глубине функциональности.
Базовая версия
Предусматривает необходимый минимум для эффективной работы:
1. Подача документов: Загрузка заявителем проектной документации через личный кабинет. Реализована возможность автоматического формирования заявления на основе данных из пояснительной записки, если она предоставлена в машиночитаемом формате.
2. Подготовка заключения: Формирование сводного заключения с предзаполнением сведений о рассмотренной документации на основе ранее загруженных файлов, что сокращает время на ручной ввод.
3. Интеграция с госреестром: Подписание готового заключения и его автоматическая передача вместе с проектной документацией в Единый государственный реестр заключений (ЕГРЗ).
Расширенная версия
Включает в себя весь функционал базовой версии и дополнена инструментами для комплексного управления процессами экспертизы:
1. Юридический блок - формирование договорных документов на основе встроенных шаблонов.
2. Управление экспертизой - формирование экспертной группы и назначение индивидуальных заданий на рассмотрение разделов документации.
3. Взаимодействие с заявителем - формирование, направление и отслеживание процесса исправления заявителем замечаний, представленных в машиночитаемом виде, что исключает двусмысленность трактовок и ускоряет доработку.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2