# Портал, 1С и договор: как подружить три системы и не потерять заявку
Заявка поступила на портал, договор живёт в Документообороте, данные об объекте — в 1С:ЖКХ. Чтобы никто не играл в «ищите документ», мы разработали схему надёжного обмена.
Три системы, одна заявка и множество поводов для путаницы
Клиент отправляет обращение через внешний портал. Сведения об объекте хранятся в 1С:ЖКХ, а договор согласуется в 1С:Документообороте. В идеальном мире все участники видят одну историю.
В реальном мире интернет может пропасть в самый интересный момент. Портал не получил ответ, отправил заявку ещё раз — и вот уже две карточки, три статуса и вопрос «какой договор настоящий?».
Что мы спроектировали
Подготовили архитектуру обмена, где у каждой системы своя зона ответственности, а события не теряются при сбоях.
- Каждая заявка получает устойчивую связь между внешним номером и документом внутри 1С.
- Для обращения, договора и электронной подписи хранятся разные статусы.
- События проходят через очередь: если соединение прервалось, попытку можно повторить без дубля.
- Ошибки фиксируются в журнале, чтобы сотрудник видел проблему, а не гадал, куда исчезла заявка.
- Подписанный файл проверяется отдельно: надпись «подписано» ещё не подтверждает корректность самой электронной подписи.
На языке разработчика это шлюз с защитой от повторов, очередями входящих и исходящих событий и сопоставлением идентификаторов. На языке сотрудников — не нужно восстанавливать историю договора по скриншотам из трёх окон.
Почему не сделали «просто подключение по API»
Наличие слова API на сайте не означает, что доступны все нужные методы. Для полного цикла требуются подтверждённые возможности получать заявки, передавать договоры, обрабатывать подписи и забирать подписанные оригиналы.
Мы не стали придумывать недостающие методы. Вместо этого составили список вопросов владельцу портала и границы первой версии обмена.
Что готово
Документирована целевая архитектура и более 30 функциональных требований. Подготовлена матрица неподтверждённых возможностей внешнего API и локальная демонстрационная заготовка шлюза.
Сквозное подключение к промышленному порталу пока не выполнено: доступность нужных методов и полномочия подключения должны быть подтверждены. Поэтому это готовая архитектурная проработка, но не история запущенной интеграции.
Кому пригодится
Организациям, где обращения принимаются на внешних площадках, договоры согласуются в одной системе, а основной учёт ведётся в другой.
Частые вопросы
Если портал поддерживает REST, значит всё уже можно автоматизировать?
Только после проверки конкретных операций и прав доступа. Слово REST на коробке — ещё не комплект ключей.
Зачем договору свой статус?
Потому что «заявка принята», «договор согласован» и «документ подписан» — три разные вехи.
Обсудим интеграцию
Опишите путь заявки от клиента до закрытия работ и назовите системы, через которые она проходит. Поможем определить, где нужен обмен, а где сначала стоит договориться о правилах.