+1
Завершен

Номера домов и номера телефонов

Tsygankov 10 лет назад обновлен Антон Жиянов 10 лет назад 17
Здравствуйте!

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

Хотелось бы дополнить список возможных "типов" номеров домов:
house_type домовладение
block_type литера, сооружение, участок
flat_type
бокс, помещение

Так же, было бы полезным "разбирать" номер телефона на составляющие:
- код страны
- код города/оператор сотовой связи
- собственно номер телефона

Ответ

Ответ
Завершен
Добавили в API стандартизации гранулярные поля телефона: country_code, city_code, number, extension.
Олег, скажите, пожалуйста, а зачем вам такая гранулярность?
Довожу до совершенства пользовательский интерфейс в своих разработках. До сих пор пользовался КЛАДРом, Яндекс-картами, геокодерами Яндекс и Google.... Но вы своим сервисом превзошли всех. Мои просьбы основаны только на личной практике (более 10 лет занимаюсь управленческим учетом, в том числе и клиентскими базами).
А какие преимущества для вас, как для клиента сервиса, предоставляет высокая гранулярность (например, когда код города в телефоне отдельно от номера или делается различие между домом и домовладением)? Ведь чтобы позвонить по номеру, достаточно иметь его одной строкой. А чтобы отправить письмо Почтой России, неважно — дом это или домовладение.

Дело в том, что, к примеру, гранулярный телефон у нас и так есть, но на уровне API специально склеиваем "код страны + код города + номер" в одно значение, чтобы потребителю API было проще :-) Скажите, пожалуйста, какие задачи вам позволит решить высокая гранулярность, которые вы сейчас не можете решить?
Не более, чем систематизация. Есть у меня один клиент (как пример), который делает печати, штампы, визитки. В день у него бывает более 100 клиентов, в том числе из других регионов. Он пытается довести до такого совершенства регистрацию клиентов и заказов (контактный телефон, адрес доставки - у него курьерская служба по Москве и доставка почтой в другие регионы, клиентская база - переделенная 1С), чтобы на клиента уходило не более 2 минут. Так вот, менеджеры при таком ритме допускают много ошибок. Вот и появилось желание создать единую систему, которая "вписывается" в стандарты 1С. Ну, тот самый случай, когда менеджер пишет 7 цифр телефона не давая себе отчета, что клиент из Минска.
А что касается различий "владение" и "домовладение", так это не я разницу установил, а Яндекс :-)
Олег, спасибо за внимание к сервису и пожелания! Нам очень важно понимать, чего сейчас не хватает и что можно улучшить, поэтому такая обратная связь очень ценна.

Владение и домовладение, строение и сооружение между собой, безусловно формально отличаются (в том числе согласно федеральной адресной системе, ФИАС). Но с точки зрения практической задачи (рассылка писем или доставка товаров) — не особо :-)

Гранулярный телефон обязательно сделаем, если будет на него спрос :-) Пока вы первый, кто это запросил.
Поддерживаю, очень нужно разделение телефона [код страны] [код города] [номер].
Было бы также полезно выводить отдельным полем номер телефона без разделителей (11 цифр в формате 71234567890). В БД в таком формате хранить удобнее
голосую за отдельный корпус и домовладение. Используем интеграцию со службами доставки, там все поголовно требуют указывать все очень дотошно.
Они и сейчас отдельно, домовладение в поле house, корпус — block.
А в подсказки можно добавить домовладение и корпус? Или это фича только стандартизации?
Эти поля есть и в стандартизации, и в подсказках.
Тогда видимо ошибка разбора
исходная строка адреса - "г Ставрополь ул Чехова 79/1 кв113"
запрашиваем через апи и получаем
"house": "79/1",
"block": null

хотя корпус должен быть 1
А почему должен быть корпус 1? Номер дома с дробью и корпус — это не одно и то же.
Ответ
Завершен
Добавили в API стандартизации гранулярные поля телефона: country_code, city_code, number, extension.

Сервис поддержки клиентов работает на платформе UserEcho