РЕЕСТР ЗАСТРОЙЩИКОВ РФ

ЕДИНЫЙ РЕЕСТР ЗАСТРОЙЩИКОВ ЕДИНЫЙ РЕЕСТР ПРОБЛЕМНЫХ ОБЪЕКТОВ

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

ЧТО МОЖНО УЗНАТЬ ИЗ ЭТИХ РЕЕСТРОВ?

В реестре застройщиков можно узнать, какие юрлица работают под брендом девелоперской компании, их юридические и фактические адреса, реквизиты, контактные данные и ФИО руководителя каждого юрлица (застройщика), учредителей и бенефициаров. Там же есть сведения о том, сколько домов строит каждый застройщик, по каким адресам, параметры объектов (этажность, площадь и т.п.) и планируемые сроки ввода в эксплуатацию. Есть данные о том, применяет ли застройщик эскроу-счета при продаже своих квартир.

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

В реестре проблемных объектов можно увидеть те дома или жилые комплексы, по которым начата процедура банкротства застройщика, а также те дома, по которым нарушены сроки завершения строительства и/или сроки передачи объекта дольщикам более, чем на 6 месяцев.

В обоих реестрах есть системы поиска по региону, адресам, застройщикам, названиям ЖК и т.п.Дополнительно ниже приведен рейтинг застройщиков по версии ЕРЗ.

ИСТОЧНИК СВЕДЕНИЙ

Источник сведений – Минстрой России. Реестры регулярно обновляются и проверяются на актуальность сведений. Достоверность сведений обеспечивается Федеральным законом 214-ФЗ (ст. 23.1, ФЗ-214).

Оба реестра бесплатны и общедоступны – в Единой информационной системе жилищного строительства (ЕИСЖС).

Официальная база данных Минстроя России, в которой содержатся сведения обо всех компаниях-застройщиках РФ, ведущих свою деятельность в соответствии с законом ФЗ-214 о долевом строительстве. База включает в себя и каталог строящихся новостроек – многоквартирных домов и жилых комплексов (ЖК).

Оператором этой базы данных является АО «ДОМ.РФ»

Официальная база данных Минстроя России, в которой содержатся сведения обо всех строящихся многоквартирных домах, которые признаны «проблемными» на основании ФЗ-214. То есть о тех домах, где срок сдачи (или передачи квартир дольщикам) нарушен более, чем на 6 месяцев, а также о тех домах, где начата процедура банкротства застройщика.

ЕДИНЫЙ РЕСУРС ЗАСТРОЙЩИКОВ (ЕРЗ)

Еще одна база данных о застройщиках жилья в России и их строящихся объектах, но из другого источника – от Национального объединения застройщиков жилья.

В целом информация о застройщиках здесь аналогичная базе Минстроя, но есть некоторые отличия. Например, здесь есть привязка к карте строящихся объектов, с разбивкой на классы жилья (эконом/комфорт/бизнес/элит). Есть данные не только о строящихся, но и о сданных домах (ЖК). Есть «рейтинг надежности» застройщиков (рейтинг ЕРЗ), который строится на основе соблюдения застройщиком декларируемого срока ввода жилья.

ЗАЩИТА

Государство гарантирует возмещение ущерба Покупателю, в случае оспаривания сделки в суде и изъятия у него квартиры. Но право на выплату компенсации от государства получают только те, кто обеспечит себе статус «добросовестного приобретателя» (подробнее – по ссылке).

Здесь можно заказать ЮРИДИЧЕСКОЕ ЗАКЛЮЧЕНИЕ по приобретаемой квартире на основе предоставленных исходных данных

Такой документ обеспечивает Покупателю статус «добросовестного приобретателя» и, соответственно, дает ему право на получение ДЕНЕЖНОЙ КОМПЕНСАЦИИ от государства, в случае изъятия квартиры по суду.

ЮРИДИЧЕСКОЕ

Проверяются данные о квартире и ее владельцах по ВСЕМ ОФИЦИАЛЬНЫМ ИСТОЧНИКАМ и БАЗАМ ДАННЫХ, открытым для доступа. Результаты оформляются и визируются юристами.

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

Только в этом случае Покупатель получает право на «финансовую страховку» от государства – получение ДЕНЕЖНОЙ КОМПЕНСАЦИИ в случае причиненных убытков.

Ответьте, пожалуйста, на 3 вопроса:

1. Что вы покупаете?

квартира
комната

Внимание! Выплата компенсации от государства не относится к покупке апартаментов, так как они имеют статус нежилых помещений.

2. Где вы покупаете недвижимость?

3. У кого вы покупаете недвижимость?

у физического лица
у юридического лица

Стоимость юридического заключения по объекту и субъектам права
= 5 900 руб.

Срок исполнения – в течение 3-х раб. дней (со дня получения исходных данных и документов).

Формат получения – в электронном виде по e-mail (PDF-документ, с печатью юридической компании и подписью руководителя).

Заказ документа оформляется дистанционно у наших партнеров – специализированных юристов по недвижимости. Для этого нужно предоставить исходные данные для проверки, заполнив форму заказа.

В ПОМОЩЬ ПОКУПАТЕЛЮ КВАРТИРЫУслуги, справки, консультации и бесплатные базы данныхдля проверки квартиры и продавца, новостройки и застройщикаВЫПИСКИ ИЗ ЕГРНонлайн заказОнлайн-заказ выписок из ЕГРН о характеристиках объекта недвижимости и правообладателях, и о переходе прав собственности на квартиру.ЮРИДИЧЕСКИЙ КАБИНЕТправовая поддержкаКонсультации специализированных юристов по недвижимости. Проверка «юридической чистоты» квартиры и полномочий продавца. Полное сопровождение сделки «под ключ».ВОЗВРАТ 13%-НДФЛза покупку жильяКонсультации по налогам и налоговым вычетам в недвижимости. Помощь в заполнении декларации 3-НДФЛ и возврате налога за покупку жилья.

Как в ДОМ. РФ выстроена работа над крупными проектами

Время на прочтение

Плюсы, минусы, подводные камни спецификаций – на примере Единой информационной системы жилищного строительства (ЕИСЖС).

Информационно и технически Единая информационная система жилищного строительства (ЕИСЖС) позволяет переводить отрасли жилищного строительства на проектное финансирование.

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

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

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

Основа нашего подхода в части аналитики – шаблон спецификации требований, который разработан с учетом особенностей систем внутри ЕИСЖС и рабочих процессов при разработке программного обеспечения внутри ДОМ.РФ.

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

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

Пользователями спецификации являются почти все участники процесса:

Вот, что дает нам единый подход, понятный и привычный всем участникам процесса развития ЕИСЖС:

• позволяет сократить время на погружение нового специалиста в проект, а также на переключение сотрудников ИТ-подразделения между проектами;
• снижает количество вопросов между участниками проектной команды, а значит – и затраты времени на каждый этап разработки. Разработчик всегда знает, где описаны требования, тестировщик не тратит время на поиск описания сценариев, а технический писатель может разработать полный комплект отчетной документации только на основе уже готовых постановок;
• облегчает восприятие IT-информации для сотрудников бизнес-подразделений, в интересах обеспечения деятельности которых разрабатываются сервисы;
• приводит к тому, что спецификация согласуется с заказчиком, поэтому записи спецификации являются зафиксированной договоренностью между исполнителем и заказчиком;
• позволяет определить, каковы были требования в любой момент времени за счет того, что спецификация поддерживает историчность изменения требования – на случай противоречий между любыми участниками процесса. Следовательно, если система работает, как описано в спецификации, то это не может считаться багом, и все новые требования должны стать доработкой.

В основе рассматриваемого шаблона лежит подход Boundary-Control-Entity, который лучше других подходит к разрабатываемым нами системам и проектам.

Его принцип – в декомпозиции требований на три слабосвязанных слоя: требования к данным, требования к функциям и требования к интерфейсу.

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

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

Как оценить качество нашей спецификации?

Мы используем основные классические свойства:

• Полнота. Совокупность элементов спецификации должна исчерпывающе описывать поведение системы. Не должно быть скрытых функций, не описанных в спецификации – это баги! Все, что есть в спецификации, должно быть и в нашей системе – мы можем провести аналогию спецификации с программным кодом: спецификация – тот же код, только написанный другим языком.
• Завершенность. Требование полностью определено в одном месте, и вся необходимая информация присутствует (необходимо избегать повторного описания требования в разных местах). Например, описание проверки ФЛК может быть описано и в сценарии, и в описании интерфейса. Такое дублирование с высокой долей вероятности приедет к нарушению целостности спецификации и появлению противоречий. Поэтому описывайте каждое требование только один раз и используйте ссылки.
• Атомарность. Спецификация не может быть разбита на более мелкие требования без потери завершенности.  Каждый элемент не может быть декомпозирован на более мелкие требования. При этом необходимо придерживаться здравого смысла, не вынося в отдельное описание каждое поле. В нашем случае мы пришли к тому, что отдельная страница спецификации (страница wiki) должна содержать описание одного элемента, такого как “сущность”, “функция”, “элемент интерфейса” (например, витрина данных, pop-up, меню и т.д.).
• Непротиворечивость. Требование не противоречит другим требованиям. Понятие непротиворечивости тесно связано с понятием завершённости. Одно требование – одно описание!
• Идентифицируемость. Элемент спецификации должен быть однозначно идентифицируемым. Наименования элементов и страниц описания должны быть уникальным и единым в рамках спецификаций всех систем. Для этого можно использовать префикс системы, код в иерархии описания, название функции. При разработке большого количества систем – в настоящее время мы развиваем одновременно более 50 информационных систем, а поддерживаем еще больше – крайне важно поддерживать единый реестр терминов и определений, в том числе использовать для одинакового функционала одинаковые названия функций. Даже если ранее какая-то из функций (например, загрузка файла) не была выделена в микросервис, одинаковое наименование функции в целом ряде систем приведет к необходимости вынесения одинакового функционала в виде отдельного сервиса.
• Трассируемость. Связь между требованиями, или возможность проследить одно требование относительно других. При описании сценария можно и нужно сослаться на другие элементы спецификации (например, на пользователя, который может выполнить этот сценарий, общие требования к личному кабинету, в котором доступна та или иная функция). Для удобства работы используйте ссылки.

Как упоминалось выше, в нашем описании мы используем большое количество слоев. На рисунке ниже приведен раздел описания одной из систем в составе ЕИСЖС, которая называется «Каталог жилищных программ»:

Раздел организационных материалов содержит ссылки на бэклог (сам бэклог ведется в Jira, однако ссылка на него обязательно присутствует в wiki), стенды, страницу проекта в git, ссылки на рабочие чаты, список участников команды, протоколы совещаний. Данный раздел ведется руководителем проекта и используется всеми участниками команды для нахождения в едином информационном поле о текущем состоянии проекта.

Раздел архитектуры содержит схему развертывания. В нем отдельно следует выделить страницу нефункциональных требований. Страница фактически ведется по ГОСТ 34. Нефункциональные требования важны как при проектировании архитектуры системы, так и при разработке отчетной документации техническими писателями.

Основной рабочий раздел аналитика – раздел спецификация требований. В нашем случае мы поддерживаем на всех проектах следующую структуру описания требований:

• Концепция продукта (или паспорт проекта). Краткое определение системы: для чего нужна, кто является пользователями, какие основные бизнес функции автоматизирует, высокоуровневая идея продукта, его полное и сокращенное название. Краткое описание назначения продукта/системы. Для систем, которые были созданы давно или другими командами, данный раздел может остаться пустым, т.к. восстановление утраченной информации и первоначальной цели проекта может быть затруднительно. Однако для новых проектов его заполнение обязательно, т.к. помогает и исполнителям, и заказчикам точнее сформулировать назначение системы в целом.
• Глоссарий. Содержит ссылку на единый глоссарий всех систем ЕИСЖС, но также расширяет его уникальными для данной системы терминами и определениями.
• Бизнес-модель. Описание предметной области (сущности, автоматизируемые бизнес-процессы). Аналитик описывает понятными айтишнику словами основные требования к общей концепции системы и к бизнес-процессам в целом, основываясь на нормативной документации или иных документах, регламентирующих функции системы. До начала разработки содержание раздела согласуется с заказчиком (в нашем случае – сотрудниками бизнес-подразделений ДОМ.РФ) и помогает выстроить единый взгляд на бизнес-процессы продукта.
• Описание пользователей. Кто является пользователями (в т.ч. и внешние системы). В сценариях данные пользователи должны будут выступать в качестве участников. Позволяет выявить лишних пользователей или недостаточность пользовательских ролей. При описании пользователей необходимо следить, чтобы в сценариях не было пользователей, не описанных в этом разделе, а также чтобы все описанные здесь пользователи выступали участниками в планируемых сценариях.
• Требования к сущностям. Должна быть приведена модель данных со связями между сущностями. Для каждой сущности логической модели должно быть указано назначение сущности. Каждый элемент должен описывать одну сущность.  Обязательно указывать, как используется сущность, при этом можно дать ссылки на сценарии и пользователей. Далее необходимо расписать атрибуты сущности. Описание атрибутов приводится в виде таблицы, содержащей наименование атрибута, тип атрибута (текстовый, числовой, дата и т.д.), кратность и обязательность заполнения атрибута, способ заполнения (автогенерация в системе, вычисляемое поле или заполняется пользователем). Если поле заполняется одним из возможных значений справочника, то необходимо дать ссылку на описание данного справочника.

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

Отдельный вид сущности – статусная модель. Помимо статусной модели в виде таблицы необходимо приводить варианты переходов между статусами, как минимум в виде последовательности статусов в той же таблице, либо в виде отдельной диаграммы.

На отдельной странице должно быть описание структуры базы данных как результат реализации описанных выше сущностей. Одна сущность может быть реализована в виде нескольких таблиц, поэтому после создания структуры БД необходимо дополнить описание сущностей и привести наименования таблиц в БД, которые ей соответствуют.

• Требования к функциям. Рекомендуется приводить в виде вариантов использования (use case), где это возможно. Надо обязательно указывать участников, цель, активаторы (какое событие является начальным), предусловия и постусловия выполнения сценария. Если в сценарии возможны различные ветки, необходимо описывать все альтернативные сценарии. Важно помнить: если не описано, значит, не реализовано. Значит, будет выявлено как баг после выпуска системы в прод. Нужно определить логическую модель основных функций (диаграмма прецедентов).
• Требования к интерфейсу. Можно разделить на два вида: пользовательский интерфейс и программный (API).

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

Для разработки макетов наши дизайнеры используют figma. Однако при описании пользовательских интерфейсов лучше не ограничиваться ссылкой на figma. Мы рекомендуем помимо ссылки приводить так же скриншоты: figma сторонний инструмент, и мы не может гарантировать его доступность в будущем. Вкладывание скриншотов позволяет отследить изменения в макетах figma, которые не были описаны по тем или иным причинам. Однако следует помнить, что в случае отсутствия дизайнера на проекте возможны случаи “отставания” макетов и скриншотов от описания, поэтому считаем, что для разработчика приоритетно описание.

Для каждого элемента интерфейса необходимо указать:

• тип (например, выпадающий список, текстовое поле, кнопка);
• требования ФЛК (при наличии);
• источник данных, т.е. маппинг экранной формы и сущностей, либо формулу для вычисления, если поле вычисляемое, либо условные выражения, которые будут использованы для заполнения поля);

Описание программных интерфейсов также стандартизировано. В wiki должны быть созданы разделы для интерфейсов разрабатываемой системы и для используемых интерфейсов смежных систем (при наличии).

Данный раздел необходим, если в системе есть генерируемые печатные формы либо входящие документы, которые должны быть оформлены по шаблону. Все требования к этим документам приводятся в отдельном разделе, который должен содержать маппинг полей шаблона/документа полям БД для печатных форм, заполняемых значениями из БД, формулы для расчета показателей в случае необходимости. Для документов, которые загружаются в систему извне, приводятся требования к ФЛК, которые необходимо выполнить при приеме документа в систему. В разделе должны быть приложены исходники/шаблоны документов, которые должны актуализироваться их по мере необходимости.

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

1. Не дублируйте описания, используйте гиперссылки между элементами спецификации.

2. Ведите лист изменений (см. рисунок) на каждой странице wiki с указанием причины внесения изменений (ссылка на договор, задачу jira или иной первоисточник). При такой записи вам будет намного проще восстановить ключевые моменты изменения системы вместо того, чтобы разбираться в истории сохранения страниц без понимания, почему были внесены те или иные изменения.

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

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

Как ДОМ. РФ помогает Банку России комплексно оценивать ипотечные жилищные кредиты в долевом строительстве

Привет, Хабр! Я Илья Крапивцев, и я руковожу направлением “Государственные сервисы подразделения Единой информационной системы жилищного строительства (ЕИСЖС) группы компаний ДОМ.РФ”. Спасибо, что осилили это название, дальше будет интереснее!

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

Зачем мы это делаем

Единая информационная система жилищного строительства (ЕИСЖС) создана в 2018 году в рамках Федерального закона от 30.12.2004 №214-ФЗ «Об участии в долевом строительстве многоквартирных домов и иных объектов недвижимости и о внесении изменений в некоторые законодательные акты Российской Федерации», а оператором ЕИСЖС стал, соответственно, ДОМ.РФ.

На схеме ниже упрощено представлены этапы реализации проекта долевого строительства застройщикам в соответствии с действующими положениями и требованиями упомянутого закона:

Этап публикации застройщиком проектной декларации в ЕИСЖС

Упомянутый закон определяет для застройщика право на привлечение денежных средств дольщиков, а именно: “застройщик вправе привлекать денежные средства участников долевого строительства для строительства (создания) многоквартирного дома и (или) иных объектов недвижимости только после получения в установленном порядке разрешения на строительство, опубликования, размещения и (или) представления проектной декларации в соответствии с настоящим Федеральным законом”.

Часть 6.1 статьи 15.4 говорит о том, что “Проектная декларация до заключения застройщиком договора с первым участником долевого строительства подлежит размещению застройщиком в единой информационной системе жилищного строительства с использованием усиленной квалифицированной электронной подписи путем заполнения электронной формы проектной декларации по форме, предусмотренной частью 2.4 статьи 19 настоящего Федерального закона”.

Другими словами, пока застройщик не опубликует проектную декларацию в ЕИСЖС, продавать квартиры он не сможет. Более того, такие сделки не будут зарегистрированы Росреестром.

“А что это дает дольщикам”?

Закон № 214-ФЗ также определяет, что договор участия в долевом строительстве должен среди прочего содержать характеристики объекта (квартира, кладовая или машиноместо) и срок передачи застройщиком объекта дольщику  в соответствии со сведениями, указанными в проектной декларации. В дополнение частью 4.1 статьи 4 закона определено, что условия договора должны соответствовать информации, включенной в проектную декларацию на момент заключения договора.

“И что же это значит?”

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

Во-вторых, покупатель должен сверить характеристики проекта, указанные в подписываемом им договоре участия в долевом строительстве, с характеристиками в опубликованной проектной декларации, дабы 10-этажный дом не превратился в 20-этажный.

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

Этап размещения дольщиками денежных средств на счете эскроу в банке

“Что такое счет эскроу?”

Счет эскроу — это банковский счет застройщика, на который перечисляются денежные средства дольщиков в случае заключения договора участия в долевом строительстве. Вся разница в том, что доступ к средствам на счете эскроу появляется при соблюдении условий договора участия в долевом строительстве (все криптоэнтузиасты на этом моменте вспомнили о смарт-контрактах?)

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

“А при чем тут все-таки Банк России?”

Счет эскроу можно открыть не в любом банке, а только в уполномоченном. В уже знакомом нам законе 214-ФЗ для него определен следующий термин: “уполномоченный банк – банк, созданный в соответствии с законодательством Российской Федерации и включенный Банком России в перечень банков, соответствующих критериям, установленным Правительством Российской Федерации”.

Ага, значит Банк России ведет перечень таких банков и, как вы догадались, являясь регулятором, должен комплексно оценивать финансовую устойчивость каждого конкретного банка. Для этого, в частности, требуются сведения о проектах долевого строительства из ЕИСЖС, по которым можно оценивать, например, срок до погашения кредита, по сравнению со сроком до завершения реализации площадей проекта составляет не менее 70% в соответствии с оценкой риска по приложению 5 Положения 590-П.

Что дальше?

Интеграция с информационной системой любого из ведомств состоит из двух составляющих: формальной и технической частей.

Формальная часть

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

Соглашение. Этот документ определяет нормативно-правовое обоснование для организации информационного взаимодействия между сторонами, общий порядок взаимодействия и состав сведений.

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

Что не нужно делать:

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

А что по технике?

Банк России определил требования к интеграционному взаимодействию так:

• должен быть сформирован XML-файл на основании XSD-схемы;
• XML-файл должен передаваться через REST API;
• XML-файл должен быть зашифрован и подписан УКЭП уполномоченного лица;
• XML-файл должен передаваться первого числа каждого месяца.

“Что мы могли на это предложить?”

• каждая публикуемая в ЕИСЖС проектная декларация загружается в аналитическое хранилище данных (это тема для отдельной большой статьи, с подготовкой которой мне поможет Григорий Грязнов, руководитель подразделения «Аналитические сервисы», у которого есть классная статья Применение ML в мониторинге строительства многоквартирных домов);
• в компании внедрен и активно используется для решения задача класса ETL продукт Apache Airflow;
• в компании был реализован сервис работы с электронной подписью.

На схеме ниже упрощенно представлена концепция решения поставленной задачи:

В результате был реализован следующий DAG (Directed Acyclic Graph):

Prepare_env

“Куда же без переменных?” Мы подумали точно так же, поэтому после запуска нашего дага первой выполняется задача, которая отвечает за подготовку и сохранение внутри DAG (XCom) переменных, относящихся ко всему процессу интеграции. Ниже в таблице приведен список переменных и их описание:

Build_emart

“Что по данным?”

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

Первое, что мы должны сделать, — это исключить из данных проекты, которые уже введены в эксплуатацию: то есть обязательства перед дольщиками по ним выполнены. Для этого используются задачи actobjlist и actdevlist.

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

Третье: мы должны сформировать сведения о проектных характеристиках каждой проектной декларации застройщика. Для этого используются задачи merge3 и merge4.

В результате мы получили вот такой красивый самолетик из задач:

Build_xml

“Витрины готовы, отправляем?”

Рано, нам нужно сформировать XML-файл, и здесь на помощь приходит задача, которая отвечает за запуск docker-контейнера с исполняемым cb-report.jar. Под капот cb-report.jar в рамках данной статьи заглядывать не будем.

Sign_xml

Здесь все просто: по REST API вызывается наш сервис работы с электронной подписью для шифрования xml-файла.

Encrypt_xml

Далее идет блок задач в соответствии со спецификацией REST API Банка России. Неуспешное завершение каждой из задачи нотифицируется ответственному через email.

Check_messages

Данная задача по REST API Банка России выполняет проверку того, что на технологическом портале Банка России не проводятся регламентные работы, и можно выполнять отправку.

Submit_files

Данная задача по REST API Банка России выполняет отправку xml-файла в сжатом виде.

Await_status

Эта задача по REST API Банка России выполняет проверку статуса отправки.

Download_documents

Эта задача по REST API Банка России выполняет сохранения квитанции.

Status_validation

Наконец, эта задача по REST API Банка России проверяет статус по квитанции.

Вместо заключения

Принято считать, что в госсекторе нет ни собственной разработки, ни современных решений, ни решения реальных бизнес-задач. Мы же хотим в наших статьях избавить вас от сложившихся стереотипов и предрассудков =)