Ваши комментарии
Сценарий следующий - интегрируем Ваш сервис с CRM-системой. На входе может быть бухгалтерская информация, например это платежка из банка, в которой минимальный набор реквизитов, но обязательно есть ИНН/КПП, либо счёт (аналогично), эта минимальная информация переносится в систему и на основе её с помощью Вашего сервиса заполняются дополнительные реквизиты (адрес, ген. дир. и прочее). Соответственно, если на входе ИНН/КПП через слэш, то приходится предпринимать дополнительные шаги перед поиском. На самом деле подобная запись долгое время была стандартом де-факто, да сейчас встречается в договорах и т.п. повсеместно, так что это просто логично, если система бы обрабатывало такое, а сейчас просто ничего не выдает
"Населенный пункт" - словарное значение из КЛАДР, привязывается через справочник, "внутригородская территория" в КЛАДРе отсутствует, как максимум ее можно переносить в свободно заполняемую часть адреса, либо вообще игнорировать. Соответственно надо понимать, как обрабатывать полученные данные
Сервис поддержки клиентов работает на платформе UserEcho
Населенный пункт сохраняется в справочник населенных пунктов, туда же пишется код КЛАДР для населенного пункта (его можно получить из кода адреса, который возвращают подсказки) для того, чтобы при дальнейшей работе не было дубликатов - адрес пользователь может вводить вручную через "Подсказки", а может также быть импортирован откуда-то еще и его надо привязать по полям через коды. Но для внутригородской территории код КЛАДР отсутствует и это значение надо обрабатывать по другому, как текст, а не как значение справочника. Соответственно надо понимать, ЧТО вернулось в поле settlement - значение, которому соответствует какое-то значение из КЛАДР и его надо сохранить с кодом либо это прокто текстовое значение, которое надо сохранить как текст. Можно не разные поля, а какой-то флажок, например, уровень согласно http://dadata.userecho.com/topics/1059-urovni-fias-i-urovni-adresa-dadatyi/ т.е. в каком-то поле вернуть либо 5 либо 6