Новостройки-Сравни · правовая информация

Техническое подключение — архив 22.09.2026

Архивная версия: 2026-09-22

Код версии: DEV-TECH-SLA-0.5-DRAFT Статус: проект; значения нагрузки, доступности и контакты подтверждаются после выбора инфраструктуры.

1. Контур подключения

Тестовые данные не смешиваются с боевыми; переход в промышленный режим фиксируется подписанным актом подключения.

1А. Оферта, Индивидуальные условия и Акцепт

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

1А.2. После заполнения карточки подключения DEV-13 Платформа формирует неизменяемые Индивидуальные условия с individual_terms_id и единый манифест всего комплекта. Акцепт блокируется, если обязательное поле не заполнено, срок экземпляра истёк, версия любого документа недоступна либо проверка организации/полномочий не завершена.

1А.3. Событие developer_offer_accepted содержит:

• organization_id, account_id и подтверждённое полномочие;
• onboarding_card_id, package_manifest_id и контрольная сумма манифеста;
• individual_terms_id;
• версии и контрольные суммы Оферты, Общих условий и приложений;
• способ Акцепта platform_qualified_signature, edo_qualified_signature, paper или cabinet_simple_signature;
• время показа и скачивания документов;
• время Акцепта по МСК и UTC;
• сертификат КЭП, результат проверки подписи/отзыва/цепочки и полномочие подписанта либо доказательства ПЭП: MFA/OTP, IP, session/user-agent и текст подтверждённого действия;
• присвоенный номер Договора и доказательство направления копии Заказчику.

1А.4. Повтор с тем же individual_terms_id и доказательством Акцепта не создаёт второй Договор. Изменение Индивидуальных условий создаёт новую версию; исходный акцептованный комплект не перезаписывается.

1А.5. Состояния договора и Проекта разделяются: contract_accepted не означает project_live. Боевая передача Лидов разрешается только после объективных проверок и статуса project_live.

1А.6. Стандартный комплект подписывается Заказчиком одним действием КЭП непосредственно на Платформе без встречной подписи администратора Исполнителя на экземпляре конкретного Заказчика. Исполнитель до публикации подписывает КЭП манифест стандартной версии. Любое отклонение вне разрешённых полей переводит карточку в manual_approval_required, формирует новый манифест после согласования и исключает скрытое изменение уже показанной версии.

2. Каталог и фид

2.1. Для каждой версии передаются стабильные идентификаторы Заказчика, Проекта, корпуса и лота; цена, валюта, площадь, статус, срок, дата актуальности и ссылка на источник.

2.2. Изменение не перезаписывает историческую версию, использованную в сохранённом результате или Лиде.

2.3. Рабочая частота обновления: [не реже одного раза в __]. Критические изменения из DEV-06 передаются вне очереди либо ближайшим фидом.

2.4. Невалидная строка изолируется с кодом ошибки; ошибка одного лота не блокирует весь фид. Стороны видят принятые, отклонённые и устаревшие записи.

3. Передача Лида

3.1. Платформа передаёт Лид только после серверной проверки лота, точного получателя и правового основания.

3.2. Обязательные поля события:

• уникальные event_id, lead_id, версия схемы;
• точный получатель и Проект;
• время создания и передачи;
• минимальные контакты;
• предмет интереса и действие покупателя;
• версия основания/согласия;
• подпись webhook либо защищённая сессия Кабинета.

3.3. Webhook проверяется по подписи, времени, получателю, версии и уникальности события. Повтор с тем же event_id подтверждается, но не создаёт дубль.

3.4. Заказчик подтверждает получение технически в течение [5] минут. Отсутствие подтверждения запускает повтор с ограничением и эскалацию, не меняя Дату передачи до фактической доступности данных.

4. Уникальность и статусы

4.1. Проверка создаётся вместе с Лидом; рабочий срок due_at = transmitted_at + 1 час.

4.2. Решение unique содержит версию правила, основание и сотрудника. non_unique дополнительно содержит код причины, доказательство и границы предшествующего периода.

4.3. Просрочка создаёт одну эскалацию и уведомление. Текущая система не присваивает unique автоматически. До запуска договорного правила раздела 4.2 DEV-03 требуется отдельное системное состояние contractually_deemed_unique либо эквивалентная проверяемая логика.

4.4. Открытый спор сохраняет прежнее состояние, но блокирует только спорное финансовое подтверждение.

4.5. После unique система вычисляет initial_attribution_expires_at = unique_confirmed_at + 3 календарных месяца.

4.6. Каждое событие in_person_meeting_attended или online_meeting_attended, произошедшее не позднее текущего attribution_expires_at, подтверждает состоявшуюся встречу и перезаписывает только вычисляемое окончание: attribution_expires_at = meeting_at + 4 календарных месяца. Исходные встречи не изменяются и не удаляются. Повторная очная и повторная онлайн-встреча перезапускают срок на тех же условиях.

4.7. Договор покупателя должен иметь signed_at в одном из действующих периодов. После этого атрибуция сохраняется до Платёжного события либо прекращения договора независимо от окончания периода.

5. Сделка и Вознаграждение

5.1. События договора и оплаты разделяются:

• equity_participation_contract_signed;
• sale_purchase_contract_signed;
• registration_confirmed;
• in_person_meeting_attended;
• online_meeting_attended;
• mortgage_approved;
• mortgage_funds_disbursed_to_escrow;
• escrow_first_credit_confirmed;
• escrow_funded;
• escrow_released;
• settlement_partial;
• installment_30_percent_reached;
• payment_trigger_confirmed;
• deal_terminated;
• price_changed.

5.2. payment_trigger_confirmed допускается только при сохранённой итоговой цене, виде договора и схеме расчёта:

• escrow_first_credit: подтверждено фактическое зачисление суммы более 0 рублей именно на счёт эскроу; полное либо частичное зачисление достаточно;
• installment_30_percent: сумма принятых платежей не ниже 30% итоговой цены; сумма ниже порога недостаточна.

mortgage_approved и подписанный кредитный договор без mortgage_funds_disbursed_to_escrow не создают триггер. escrow_released не является обязательным событием.

5.3. Коммерческое правило выбирается по приоритету сделка → лот → Проект → организация; версия фиксируется и не заменяется поздней настройкой.

5.4. Начисление требует атрибуцию, уникальность/договорный эквивалент, своевременно заключённый договор, регистрацию при необходимости, Платёжное событие, версию правила и отсутствие блокирующего спора. Сумма Вознаграждения без НДС равна полным 2% всей Расчётной базы независимо от размера платежа-триггера. Уникальный ключ buyer_contract_id + commercial_rule_version исключает повторное начисление по последующим платежам.

Финансовая запись хранит раздельно reward_net, vat_status, vat_rate, vat_amount и total_due. До даты возникновения обязанности Исполнителя по НДС vat_amount = 0; после неё система применяет действующую на дату реализации ставку сверх reward_net. Изменение налогового статуса не перезаписывает ранее сформированные документы и не изменяет ставку 2%.

5.5. Статусы платежа платформе различают confirmed, reconciled, issued, partially_paid, paid, overdue, disputed, adjusted, cancelled. Система хранит reconciliation_at и вычисляет due_at как 7 рабочих дней с Даты сверки по производственному календарю; молчание Заказчика после срока возражений создаёт договорную Дату сверки.

6. Электронные действия представителей

Для признания простой электронной подписи Кабинет обеспечивает:

1. индивидуальную учётную запись; 2. проверенный email/телефон и MFA для финансовых/административных ролей; 3. связь пользователя с юридическим лицом, ролью и областью полномочий; 4. показ содержания действия до подтверждения; 5. неизменяемую запись пользователя, времени, IP, user-agent/session, версии данных и результата; 6. запрет передачи учётных данных; 7. немедленную блокировку по уведомлению; 8. архив журналов на срок договорных требований; 9. возможность выгрузить воспроизводимое доказательство.

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

7. Доступность и поддержка

7.1. Рабочие уровни

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

7.2. Целевая месячная доступность промышленного контура: [99,5]%, исключая согласованные работы, внешние сети Заказчика и форс-мажор. Плановые работы сообщаются за [2] рабочих дня, кроме срочного устранения уязвимости.

7.3. SLA не освобождает от восстановления пропущенных Лидов/событий и корректировки финансового учёта.

8. Безопасность

• TLS для передачи, шифрование чувствительных полей и документов;
• секреты вне репозитория и периодическая ротация;
• HMAC/эквивалент для webhook;
• ролевой доступ и аудит привилегированных операций;
• карантин и проверка загружаемых файлов;
• резервные копии и тест восстановления;
• мониторинг ошибок, дублей, отрицательных/невозможных состояний;
• разделение организаций и запрет доступа к чужим данным;
• запрет передачи идентифицирующих данных в AI без отдельной архитектурной оценки.

Инциденты ПДн сообщаются по сроку DEV-07; критический технический инцидент — незамедлительно по P1.

9. Изменения интеграции

9.1. Несовместимое изменение схемы требует новой версии, тестовой среды и уведомления не менее чем за [30] календарных дней.

9.2. Исправление критической уязвимости может выполняться немедленно с последующим отчётом.

9.3. Отключение интеграции не удаляет историю, отчёты и доказательства до истечения законного срока.

10. Приёмочные тесты

Боевой режим блокируется, пока не проверены:

1. точный получатель Лида и отдельное основание передачи; 2. повтор webhook без дубля; 3. маскирование до назначения и разграничение организаций; 4. часовая проверка и однократная эскалация; 5. доказательство non_unique; 6. три месяца от подтверждения уникальности; 7. первая, повторная, очная и онлайн-встреча в действующем периоде каждый раз перезапускает четыре месяца; 8. встреча после истечения действующего периода срок не возобновляет; 9. своевременный ДДУ сохраняет атрибуцию до последующего Платёжного события; 10. для ДДУ без рассрочки частичное или полное зачисление на эскроу создаёт полное начисление, а одно ипотечное одобрение — нет; 11. при рассрочке сумма ниже 30% не создаёт начисление, достижение 30% создаёт полные 2% базы; 12. последующие платежи по тому же договору не создают повторного Вознаграждения; 13. точный расчёт базы, Вознаграждения без НДС 2%, применимого статуса/ставки НДС, суммы НДС, итога к оплате, Даты сверки и 7 рабочих дней; 14. отчёт, возражение, корректировка и неоспариваемая часть; 15. ЭДО/простая электронная подпись и выгрузка журнала; 16. отзыв доступа сотрудника; 17. резервное восстановление и обработка P1; 18. отсутствие реальных ПДн/секретов в логах и репозитории. 19. текущая и архивная версии Оферты доступны для скачивания; 20. Индивидуальные условия с пропуском обязательного поля или истёкшим сроком не акцептуются; 21. КЭП/ПЭП связывает Заказчика, представителя, полномочие и точную версию комплекта; 22. повтор Акцепта не создаёт второй Договор; 23. после Акцепта обеим Сторонам доступна воспроизводимая копия и журнал; 24. заключённый Договор без завершённой проверки Проекта не разрешает боевую передачу Лидов. 25. до даты возникновения обязанности по НДС налог равен нулю и не предъявляется Заказчику; 26. после возникновения обязанности НДС начисляется сверх неизменного reward_net, а не удерживается из 2%; 27. смена применимой ставки НДС не меняет исторические документы и коммерческую ставку Вознаграждения. 28. руководитель по актуальным сведениям ЕГРЮЛ самостоятельно акцептует весь комплект одной КЭП на Платформе без участия администратора Исполнителя; 29. представитель без действующей МЧД/доверенности либо без полномочия принять денежные обязательства не может совершить Акцепт; 30. изменение любого файла после формирования манифеста нарушает контрольную сумму и блокирует Акцепт; 31. нестандартное отклонение переводит карточку в manual_approval_required, тогда как стандартный комплект не требует ручного согласования.