Служба поддержки DaData.ru
Если чего-то не хватает, или вы столкнулись с проблемой — оставьте сообщение, и мы ответим в течение 24 часов. Работаем с понедельника по пятницу, с 10 до 19 по Москве.
Плагин для webasyst 7
Сделайте пожалуйста хороший плагин для webasyst 7 (с подсказками фио, email, адреса).
Существующий плагин к сожалению неудобен и не решает проблема заполнения данных клиентами.
Внутри/за пределами МКАД и расстояние в подсказках
Включите пожалуйста beltway_hit и beltway_distance для Мск-Спб в подсказках. Пусть даже это будет только в рамках платных подсказок или за отдельную стоимость, но чтобы было доступно сразу из JS. Сейчас чтобы расчитывать стоимость доставки для введённого адреса на сайте придётся писать серверный код, отдельно получающий эти данные от Стандартизации. Работать наверное будет, но не удобно.
Расстояние до кольцевой возвращается в «Подсказках» для тарифов «Расширенный» и «Максимальный»
Населённый пункт по-умолчанию
Добавьте, пожалуйста, возможность указывать "населённый пункт по-умолчанию" для стандартизации адресов и телефонов.
Мы небольшая контора, работаем только по своему региону, в базе всегда вводят адреса (для внутреннего документооборота) без указания города и телефоны без кода города.
Стандартизация таких данных проблематична, т.к. для адресов вылазят дополнительные подсказки, которых бы не было, если бы при отсутствии явно указанного города dadata использовал город по-умолчанию. Приходится писать кучу дополнительного кода для пост-проверки и фильтрации вернувшихся данных, либо делать 2 запроса если dadata в первом запросе не увидел город.
Ну а телефоны возвращают всегда москву.
Думаю для многих локальных организаций это было бы весьма удобно...
> т.к. для адресов вылазят дополнительные подсказки
Уточните пожалуйста, о каких подсказках речь? Вроде вы выше пишете о стандартизации. В подсказках город по умолчанию как раз есть.
Аккаунты в вотсапе и вайбере
Указание в карточке наличия аккаунта в вотсапе и вибере.
По адресу "Московская обл, Подольский р-н, поселок Молодежный, д 19, кв 7" неправильно определяется индекс
По адресу "Московская обл, Подольский р-н, поселок Молодежный, д 19, кв 7" неправильно определяется индекс и возможно код ФИАС. Для домов 1-17 по этому адресу индекс определяется правильно(142113), для дома 19 же в ответе возвращается индекс 142172(Щербинка). В чём может быть причина
Причина в том, что дома 19 нет в ФИАС. Поэтому мы возвращаем индекс вышестоящего объекта (улицы), и код ФИАС диапазона.
Фильтрация города на ходу из select
<select id="PROPERTY_589" class="form-control" name="PROPERTY[589]">
Не получится вывести форматированный адрес без населенного пункта, потом что поселки и села и есть населенные пункты. Также в списке есть город, а это разные типы. Если вы выбираете один конкретный тип – у вас показаны в выдаче либо города, либо населенные пункты. Если вы их объединяете – показано и то, и то, но ваше условие не выполняется.
Ограничить поиск по адресу также не получится, потому что в исходных данных нет региона, нет понимания н.п. или города в списке. В идеале для корректных ограничений нужно знать код КЛАДР, потому что город или населенный пункт может быть не уникален.
Ошибка при определении почтового индекса
А сегодня выявилась точно такая же проблема с DaData:
- ошибка при определении почтового индекса при вводе адреса.
Результат вполне конкретный и измеримый в деньгах:
- заказ доставляется Почтой России не по верному адресу, а по ошибочно определенному сервисом индексу.
Конкретика:
Краснодарский край, Лабинский р-н, г Лабинск, ул Победы, д 124
Dadata выдает по этому адресу индекс 352001
На самом деле, правильный индекс 352508 (источник: http://www.russianpost.ru/resp_engine.aspx?Path=rp/servise/ru/home/postuslug/searchops)
А индекс, найденный Dadat'ой, принадлежит: край Краснодарский р-н Кущевский ст-ца Шкуринская
Можно как-то избежать таких ошибок?
Или все-таки лучше для таких проверок использовать только сайт Почты России?
Исправили. Теперь возвращаются правильные индексы, потому что Дадата использует индексы Почты.
Сервис Недоступен
Полная строка адреса после стандартизации
Например,
Москва ул кетчерская дом 8 корпус 2 квартира 250
привести к виду
<clearAddr>111402, г. Москва, ул. Кетчерская, д. 8, корп. 2, кв. 250</clearAddr>
Москва ул кетчерская дом 8 корпус 2 квартира 250 → Россия, г Москва, ул Кетчерская, д 8 к 2, кв 250
Баги распознавания украинских ФИО
Классный сервис, начал использовать для проверки на ошибки Имен и Фамилий, был приятно удивлен, что есть скрипт по распознаванию Пола, тоже кстати нужная информация, особенно для сегментирования базы e-mail подписчиков.
Но заметил некоторые баги:
- Anna Ginchar (по умалчанию) - ANNA GINCHAR, сервис разбивает правильно по полям имя и фамилию, но прописывает их Caps Lock-ом
- Георгій Буза (по умолчанию) - Буза Георгий (после проверки) - переводит Имена (написаны укр. языком) на русский, что не совсем правильно по отношению к клиенту (который сам указал, что хочет называться в нашем случае "Георгій "), такие примеры есть с именами: Володимир, Світлана и т.д.
- Ніщенко (фамилия по умолчанию) - НІЩенко - просле проверки, незнаю с чем связано, но большинство фамилий, имен с буквами "І", "Є" (укр.), после них следующая буква пишется в верхнем регистре. (Аліна -> АлІНа; Віталій Мезін -> ВІТалІЙ МезІН, Клєвцов ->КлЄВцов и т.д.
- Украинские Имена в которых есть апостроф также исправляет на русские, что также не совсем правильно. (Мар'яна ->Марьяна)
- Также есть случаи когда Имена и Фамилии путаются местами (Ігор барладін ->ІГор БарладІН)
Спасибо за Ваш сервис и хорошего Вам развития!
Добрый день! Спасибо за ваш отзыв и описание баг :-) Все они связаны с тем, что мы сейчас включили только распознавание русских ФИО (т.е. все ФИО сервис трактует как русские).
Сервис поддержки клиентов работает на платформе UserEcho
