
+1
Завершен
Номера домов и номера телефонов
Здравствуйте!
Написал в комментариях к своему предыдущему сообщению, но, видимо, не заметили. Поэтому выношу в отдельную тему.
Хотелось бы дополнить список возможных "типов" номеров домов:
house_type домовладение
block_type литера, сооружение, участок
flat_type бокс, помещение
Так же, было бы полезным "разбирать" номер телефона на составляющие:
- код страны
- код города/оператор сотовой связи
- собственно номер телефона
Написал в комментариях к своему предыдущему сообщению, но, видимо, не заметили. Поэтому выношу в отдельную тему.
Хотелось бы дополнить список возможных "типов" номеров домов:
house_type домовладение
block_type литера, сооружение, участок
flat_type бокс, помещение
Так же, было бы полезным "разбирать" номер телефона на составляющие:
- код страны
- код города/оператор сотовой связи
- собственно номер телефона
Ответ

0
Ответ
Завершен
Антон Жиянов 10 лет назад
Добавили в API стандартизации гранулярные поля телефона: country_code, city_code, number, extension.

Довожу до совершенства пользовательский интерфейс в своих разработках. До сих пор пользовался КЛАДРом, Яндекс-картами, геокодерами Яндекс и Google.... Но вы своим сервисом превзошли всех. Мои просьбы основаны только на личной практике (более 10 лет занимаюсь управленческим учетом, в том числе и клиентскими базами).

А какие преимущества для вас, как для клиента сервиса, предоставляет высокая гранулярность (например, когда код города в телефоне отдельно от номера или делается различие между домом и домовладением)? Ведь чтобы позвонить по номеру, достаточно иметь его одной строкой. А чтобы отправить письмо Почтой России, неважно — дом это или домовладение.
Дело в том, что, к примеру, гранулярный телефон у нас и так есть, но на уровне API специально склеиваем "код страны + код города + номер" в одно значение, чтобы потребителю API было проще :-) Скажите, пожалуйста, какие задачи вам позволит решить высокая гранулярность, которые вы сейчас не можете решить?
Дело в том, что, к примеру, гранулярный телефон у нас и так есть, но на уровне API специально склеиваем "код страны + код города + номер" в одно значение, чтобы потребителю API было проще :-) Скажите, пожалуйста, какие задачи вам позволит решить высокая гранулярность, которые вы сейчас не можете решить?

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

А что касается различий "владение" и "домовладение", так это не я разницу установил, а Яндекс :-)

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

Поддерживаю, очень нужно разделение телефона [код страны] [код города] [номер].

Было бы также полезно выводить отдельным полем номер телефона без разделителей (11 цифр в формате 71234567890). В БД в таком формате хранить удобнее

голосую за отдельный корпус и домовладение. Используем интеграцию со службами доставки, там все поголовно требуют указывать все очень дотошно.

А в подсказки можно добавить домовладение и корпус? Или это фича только стандартизации?

Тогда видимо ошибка разбора
исходная строка адреса - "г Ставрополь ул Чехова 79/1 кв113"
запрашиваем через апи и получаем
"house": "79/1",
"block": null
хотя корпус должен быть 1
исходная строка адреса - "г Ставрополь ул Чехова 79/1 кв113"
запрашиваем через апи и получаем
"house": "79/1",
"block": null
хотя корпус должен быть 1

А почему должен быть корпус 1? Номер дома с дробью и корпус — это не одно и то же.

Ответ
Завершен
Добавили в API стандартизации гранулярные поля телефона: country_code, city_code, number, extension.
Сервис поддержки клиентов работает на платформе UserEcho