У регионального оператора по обращению с ТКО одновременно могут работать расчетная система, учет договоров, диспетчерская, личный кабинет и сервис обработки обращений. Интеграционный проект стоит начинать с перечня конкретных событий: появился договор, изменился адрес объекта, получен платеж, выполнен перерасчет или поступило обращение. Для каждого события запишите источник, получателя и ожидаемый результат. Так становится понятно, какие обмены действительно нужны процессу и где сотрудники пока переносят информацию вручную.
Согласуйте идентификаторы и владельцев данных
До разработки обмена сопоставьте объекты учета. Адрес, договор, лицевой счет и плательщик связаны между собой, но описывают разные сущности. Один адрес может встречаться в нескольких записях, а исправление реквизитов не должно создавать новый договор. Для каждой сущности определите внутренний идентификатор, внешний идентификатор и правило связи между ними. Сомнительные совпадения вынесите на проверку специалисту. Автоматическое объединение только по похожему названию или адресу способно распространить ошибку сразу в несколько систем.
Если в проект входит ГИС ЖКХ, состав обменов и форматы следует уточнять по документации самой системы. В ее официальном разделе документации указано, где опубликованы регламент сопряжения, форматы взаимодействия и шаблоны массовой загрузки. Сохраните в проекте перечень использованных документов и их версий. Пример выгрузки из старого проекта можно применять как тестовый материал после проверки; согласованный формат должен быть привязан к документации выбранного обмена.
Разделите отправку и результат обработки
В интеграционном журнале полезно различать подготовку записи, отправку, технический прием и итог обработки получателем. Для каждого события храните идентификатор, время, состояние и понятную причину ошибки. При повторной передаче платежа или документа получатель должен узнавать уже обработанное событие. Правила повторов, сверки и ручного исправления согласуйте для каждого вида данных. Это помогает разбирать ситуацию, когда связь прервалась после приема сообщения и отправитель еще не знает, завершилась ли операция.
Проверку начните с небольшой выборки, в которой есть обычные и сложные случаи: смена реквизитов, несколько объектов у одного контрагента, исправление счета, отмена документа и повторное поступление события. Сверяйте не только количество переданных записей, но и итоговое состояние в обеих системах. Для расчетных данных договоритесь о контрольных суммах и периоде сверки. Полезно заранее определить, какой сотрудник решает расхождение и какие подтверждающие материалы он получает из журнала.
Запускайте обмен поэтапно
Первый рабочий запуск лучше ограничить одним потоком с измеримым результатом: например, передачей обращений или синхронизацией справочника объектов. После него оцените долю событий, требующих ручного вмешательства, время исправления ошибок и трудозатраты на сверку. Добавляйте новые потоки, когда понятны причины сбоев и порядок поддержки. При обновлении внешней системы повторяйте контрольные сценарии на стенде. Такой подход превращает набор подключений в обслуживаемый процесс, у которого есть владелец, журнал и проверяемый результат.