Данная версия позволяет развивать работу с местоположениями в различных компонентах Управления Сайтом (редакции интернет-магазин) и Битрикс 24.
Героев нужно знать в лицо
Сложнейшую работу по модулю «Местоположений 2.0» выполнил Сергей Ганноченко.
[spoiler]
Устанавливаем обновление
Обновление доступно клиентам и партнерам, которые устанавливают бета-версии обновлений. По завершении тестирования «Местоположения 2.0» станет доступно всем клиентам без ограничений.
После установки обновления, система предложит сконвертировать ваши местоположения. На экране появится зеленая плашка, знакомая пользователям нашего продукта.
Конвертацию местоположений я записал в небольшом ролике:
Местоположения сконвертировались. Магазин продолжит работать, используя старую базу местоположений.
Готовимся к загрузке местоположений
Мощь «Местоположений 2.0» раскрывается с новыми данными местоположений, которые доступны, начиная с версии 15.0. Давайте их установим.
Для этого переходим в раздел «Импорт местоположений» и удаляем все старые местоположения:
Не стоит производить данные действия на рабочем проекте. Ошибки и неверные действия могут привести к блокировке продаж в магазине, так как придется заново настроить местоположения. Поэтому я рекомендую совершить действия на копии проекта.
Перехожу во вкладку «Очистить список местоположений» и удаляю все установленные местоположения.
Столько интересного в местоположениях
Прежде чем показать, как добавить местоположения, я расскажу о нововведениях.
В предыдущей версии мы загружали список только тех местоположений, с которыми работал конкретный сайт. Загрузить новые местоположения, которые «вроде и не нужны» было невозможно.
В новой версии вы можете загрузить все местоположения и выбрать из них те, с которыми будет работать конкретный сайт. Или загрузить необходимые, и в любой момент их дополнить.
Если у вас многосайтовая конфигурация (когда на одном ядре/ключе установлены несколько магазинов, и каждый работает со своими регионами), вы можете загрузить все регионы и назначить каждому конкретному магазину те, с которыми он будет работать.
Теперь можно создавать любое количество уровней вложенности данных.
Раньше можно было использовать только структуру вида:
Страна -> Область -> Регион -> Город
Теперь количество вложений не ограничено. Обновленная база данных, которая вошла в поставку 15-го релиза, позволяет выбрать месторасположение любого масштаба: от страны до района и улицы.
Загружаем свежую базу местоположений
Загрузку местоположений я покажу на ролике:
В ролике показана загрузка двух областей, рассмотрим работу с ними.
Обратите внимание, загрузка базы данных – длительный процесс, продолжительность которого зависит от мощности вашего хостинга.
У меня полная загрузка заняла около 50 минут, на слабом железе она может длиться несколько часов. Я рекомендую начинать загрузку в часы наименьшей активности на сайте, чтобы не создавать клиентам неудобств.
Импорт местоположений детально
Давайте разберем, что нового появилось в импорте данных и в структуре данных местоположений:
Мы обновили и расширили базу Украины, обеспечили написание городов на украинском языке.
База для России также была серьезно обновлена и расширена. Это нововведение стало важнейшим в версии «Местоположения 2.0». Появилась возможность указать село, район, микрорайон, загрузить названия улиц, выбрать детализацию перед началом загрузки данных.
Теперь вы можете загружать «Коды Яндекс Маркета». Они пригодятся в интеграции с Яндекс маркетом и расширяют возможности работы по доставке.
Почтовые индексы городов, выбранных в публичном и административном разделах, появятся автоматически. Аналогично при вводе индекса система распознает местоположение.
Гео-координаты для городов и сел Российской базы, пригодятся в будущих реализациях продукта. Также вы сможете через API использовать их в своих разработках.
Также загруженные данные можно добавить в любой момент. Ниже я покажу добавление Казахстана к ранее добавленным данным.
Вы можете добавить любые данные, не нарушая общей структуры.
Настраиваем местоположения
Импорт произведен, загружен Казахстан и несколько областей России. Но для сайта, который я использую, мне нужна только Калининградская область.
Раньше приходилось удалять лишние местоположения. Теперь их можно группировать, а также выбрать избранные местоположения, которые помогают пользователям быстрее оформить заказ.
Разберем ролик:
Добавляю к двум ранее загруженным областям России весь Казахстан. Данные добавились, не изменив ранее загруженные.
Удаляю старую группу и добавляю новую с некоторыми городами Казахстана. Я делаю необычный выбор, чтобы показать различные действия в настройках.
Выбираю местоположения, необходимые конкретному сайту. Показываю, что можно выбрать ранее созданную группу. Так как я хочу показать только одну область из списка, удаляю группу. Выбираю данные из Калининградской области (можно выбрать только те местоположения, с которыми вы собираетесь работать). Я выбрал все, что было в списке.
Перехожу к созданию избранных местоположений. Они облегчают набор данных в тех городах, из которых чаще других поступают заказы. Вы можете искать города вручную или выбрать из списка, опуститься до любого уровня иерархии загруженных данных и остановиться на удовлетворяющем вас уровне.
Например, вы загрузили данные всей России. Наиболее частые заказы из Московской области, но не обязательно из Москвы. Вы можете выбрать Московскую область, а клиент заполнит недостающие поля во время оформления заказа. Если некорректно указать данные (в ролике я допустил ошибку в написании), система выведет ошибку поиска.
Работа с местоположениями в заказах
Данные загружены, основные настройки указаны. Посмотрим, как с ними работать в публичном и административном интерфейсе:
Разберем ролик:
Когда вы выбираете избранные местоположения, их индексы появляются автоматически (если они есть в базе). При вводе улицы остается ввести номер дома и квартиры (если необходимо).
Если вы ввели данные, которые отсутствуют в базе, появляется диалог. Он помогает оформить заказ и выбрать местоположение.
Переключаем в компоненте строку поиска на привычные для многих «выпадашки». Пробуем делать выбор с помощью них.
Переключаемся на админку и пробуем делать аналогичные действия в рамках создания нового заказа.
Вы можете переключать вид выбора местоположений на строку поиска местоположений или на представление в виде «выпадашек». Для этого перейдите в настройки модуля интернет-магазина. (Наглядно в ролике или на скриншоте)
Приятного вам использования. Задавайте в комментариях свои вопросы.
p.s. На удаление местоположений мы добавили "alert" (сообщение с вашим согласием), который будет предупреждать о последствиях удаления старых местоположений и будет требовать явного вашего повторного согласия на такую операцию, спасибо за вашу критику в комментариях!
.
Фото:
только что обновил один из сайтов -там нет такого!
1. Загрузка до городов, все остальное клиент заполняет сам
2. Загрузка до сел и только одно область (например Калининградская)
3. Загрузка до улиц
И во всех трех сценариях, будет разная схема полей, и разные названия которые нужно спросить. Но к местоположениям это не имеет отношения, а вот в дистрибутиве и какой та мастер создания напрашивается (но тут нужны самые востребованные сценарии).
И это немного уже не про местоположения.
Критикуйте ребята, критикуйте, ваша критика очень полезна!
Лег не отвечает но действие идет, или лег упало с ошибкой?
Захожу в местоположение "Калининград" - , а там индекса нет.
В некоторых есть -
Что я делаю не так?
Например Калининград, в базе Фиаса нет на него индекса, но есть индексы на улицы и различные образования в рамках Калининграда. Например в базе почты, общий городской индекс Калининграда 236000, а в базе Фиаса его нет. Но если загрузить данные до улиц, индекс почти всегда есть. Мы работаем над адаптацией данных, и к релизу думаем, что они улучшаться и получат больше логичности.
Первый вопрос: Как теперь убрать поле выбор улицы, если оно мне не нужно?
Второй: У меня по каким-то причинам пропала возможность вводить свой город, если нужного не оказалось в списке, как вернуть? Нажимаю "---Другое местоположение", поле обновляется "Выберите местоположение". Это так и должно быть?
Первый вопрос: Как теперь убрать поле выбор улицы, если оно мне не нужно?
Видимо надо в ТП написать, закрался глюк какой-то.
И уже работаем над исправлением, нет панацеи и нормальной базы, придется делать кастомный микс и ручками допиливать.
Смена местоположений задача многоходовая, последствия будут не только в заказах, в профилях пользователей (но в них не так страшно), в платежных системах, расчетах доставки, связях с маркетом, везде где были выбраны старые местоположения.
Как вариант, но я не пробовал, не удалять старое, убрать их в отдельную группу и забыть, а новое доставить, и их использовать.
Проапдейтить всю таблицу заказов старых очень сложно, если только периодом, она просто может быть очень большой. В данном случае это ID старого элемента местоположений.
было бы круто подключить саджест поиска с яндекс карт...это так, мысли вслух.
возможно я не так понял, и у вас щас ищет также
Есть какие-то подвижки в поиске "улиц в куче городов"?
У меня проблема немного другая, с поиском города. Например, набираем в строке "Красноярск" и видим очень длинный список всех населенных пунктов КРАСНОЯРСКого края, но не город Красноярск.
Но мысль интересная, спасибо!
Я думаю, что для улиц можно подставлять первый найденный индекс и указывать, что он приблизительный. Ведь он нужен в первую очередь для расчета доставки.
Работаем над этим, спасибо!
Вообще как я вижу идеальное заполнение адреса доставки, это карта, например яндекс, тыкаешь в свой дом, он автоматически заполняет поля, в т.ч. индекс и готово. Для клиента 1 клик, для владельца полная информация. (кстати что-то подобное сейчас присутствует в способе доставки "самовывоз со склада", только там можно только из списка выбирать склад выдачи, но на карте отображается нужный нам склад)
Возможен ли такой сценарий?
Ну и конечно сами данные еще будем оптимизировать.
Это еще немного позже, для этого и вводились данные по геокоординатам.
База Украины еще в работе и будет обновляться, есть высокая вероятность, что она появится до улиц.
Скриншоты:
Но и у вас проблема другая, попробуйте удалить и заново загрузить местоположения, проверить подключение нужных местоположений именно к вашему сайты в соответствующем пункте меню в местоположениях, затем полностью на сайте сбросить кеш.
Ну и попробовать заново сделать эти же операции, должно все сработать.
Сейчас при наборе Москва появляется сперва деревня Москва, потом ещё много всего, а только после этого уже город.
Если одно местоположение такое, то ничего страшного, можно для него задать приоритет, но вот городов более 1000, и у каждого есть по несколько дублей. У Саратова так вообще много станций сперва, а город где-то далеко..
Допустим, высший приоритет у городов, потом у областей, потом у сёл, потом у деревень и т.д.
Из плюсов появились индексы у всех городов и больших образований.
Уменьшили данные, пока база будет без совсем мелких образований, будем думать как с ними быть.
1). по Украине - нет русских названий у городов, там где должно быть русское название - стоит украинское (у областей есть - а это критично т.к. на Украине много русскоговорящего населения которое и пишет соответственно по русски)
2). нет возможности выбрать зону обслуживания магазина (т.е. она как бы есть но не работает - уже пробовали и группы редактировать и местоположения для сайтов - все равно выбирает со всего списка местоположений который есть)
3). избранные местоположения на сколько я понял задают приоритетность показа (т.е. подымает выше по списку) - если выставить страну - то тоже не работает к сожалению...
По первому, базу нашли более качественную по Украине, будем подправлять.
По второму и третьему пункту, вы используете штатный sale.order.ajax или кастомный? У меня на проекте отрабатывают оба пункта корректно.
Вводим индекс Октябрьского района, г. Калининграда - . Нам выдает п. Совхозный. Ну ладно, черт бы с ним, с поселком, хотя это индекс в городской черте. Но попробуйте удалить этот поселок? Это же атас, надо прокрутить :!:ВЕСЬ:!: список сел, товариществ садовых и всего всего всего. Неужели нельзя крестик поставить хоть какой-нибудь? Удалить поле или скрыть, ну не знаю, да все что угодно. Ну нельзя же так оставлять
Чуть позже мы обновим и большую базу для избежания таких колизий, и крестик не пригодится.
В заказе выбираем вариант 1 -
В заказе выбираем вариант 2 -
При выборе района, получаем доставку в 58 рублей. Как исправить?
обновлял базу с удалением старых.
Проверил на демо-сайте. Там все прекрасно работает при тех же настройках админки. Буду разбираться где все-таки разница. Видимо, у меня рыльце в пушку ...
Москва внутри МКАДАа
Москва снаружи МКАДа
Если нет такового - то сохранность при повторной загрузке. На конференции говорили о сохранности связей с местоположениями через их код (а не ИД), но ничего не сказано о внешних системах местоположений, будет ли сохраняться с ними связь.
Есть задача выдать строку адреса в формате XML для 1C (не CML):
В более старой конфигурации подобная строка выглядит так:
Статистика базы местоположений:
- Страна: 1
- Округ: 1
- Область: 1
- Район области: 33
- Город: 13
- Село: 1253
- Улица: 8549
В "Избранные местоположения" хочу указать город, но вот в списке выводится один и тот же город аж 4 раза. Какой выбрать?В чем может быть проблема ?
ввожу данные уже в админке, вот что вылезает -
помогите разобраться, а то очень сложно так сейчас .
Сделал, сейчас проверю на заказе !
- тут видно как проставляется код Родительское местоположение !!!
Написал в ТП битрикса ! ID
Обновил модуль, там стало вылезать очень много ошибок, вот то что было в самом начале....
Аргумент "$nodeInfo[]" должен быть непустым массивом bitrix
Благо модуль sale был в резервной копии, его откатил обратно.
Вопрос Актуален, сколько можно так цифры принимать при заказе вместо местоположений.... ) Почему со старыми местоположениями не было проблем ? Уровень вложенностей увеличился ? Почему села не ищутся......
После перехода на Местоположения 2.0:
ПЛЮСЫ
+стала понятнее иерархия
+есть индексы
+большая база адресов
МИНУСЫ
-------------------- упала конверсия оформления заказов
||
-стало больше шагов для оформления заказов по модели step - рост отказов
-увеличилось время выбора населенного пункта по модели search - рост отказов
-более 70% тех, кто пытался сделать заказ и обратился к консультанту или сделал его, не знает свой федеральный округ - рост отказов
те, кто все же знает свой федеральный округ
- при выборе модели step недоумевают: почему им предлагается еще выбрать местоположение, если они живут, например, в Кирове
- вбивая индекс, не понимают, почему система заменяет его(после выбора местоположения) на свой
Варианты корректного решения задачи:
1. Использовать привязку по IP, что частично даст возможность заполнить местоположение пользователя по умолчанию
2. Использовать реверсивный поиск, предлагая пользователю только ввести индекс, заполнив далее все поля (хотя конечно часть индексов некорректная, но все же). При отсутствии вариантов по индексу в БД (нет групп и т.п.) предлагать вариант наиболее близкий по индексу (все мы знаем, что уточнение индекса это его окончание, 610000 - Киров, Почтамт, а 610007 - Киров, но с уточнением по группе улиц)
Нет, конечно же, Вас не дождаться и нам быстрее будет сделать все самим, потому что падение конверсии - это смерть для бизнеса. Но все же про юзабилити для пользователя забывать не нужно
Старые местоположения заменить новыми, как я понял, не получится? А как тогда переходить, на двух сайтах попробовал, и удалить и не удалять старые, если старые не удалять, то они в оформлении заказа выводятся.
Подумайте о возможности выбора, привязывать доставку к местоположению или нет.
но похоже оно не используется нигде. Так как я попробовал проставить у Москвы значение "Y", но ничего не поменялось. Что это за поле вообще?
И еще одно предложение. Если установлен шаблон выбора местоположений в виде выпадающих списков, когда мы выбираем местоположение 2-го, 3-го или большего уровня вложенности, то чтобы поменять местоположение предыдущего уровня, нужно нажать на "отменить выбор". Получается лишний клик. Почему бы ни сделать списки всегда доступными? То есть я выбрал Россию, Москву, а потом вспомнил, что я из Эстонии, и решил поменять страну. Но щелкнув по списку стран я его не вижу, а вижу только надпись "отменить выбор". Причем, когда нажимаем "отменить выбор", еще и перезагрузка области местоположений происходит. Это тоже на конверсии сказывается, Вы же сами понимаете, что получается много лишних действий.
Москву сгруппировать на внутри МКАДа или вне МКАДа... Или, как вариант, сгруппировать по Административным округам...
Выбрать из списка в Москве улицу даже на букву А..... или Б..... - это с минуту нужно крутить колесо мыши... Добраться до улиц с названиями в конце алфавита - просто нереально...
А вот в новом обновление который доступен в бете клиентам, решена схема с поиском в выпадашке, которая облегчает поиск и прокрутку.
Проверил на бетах, ничего не изменилось, сделал заново импорт местоположений, вот что получается, Новосибирск по алфавиту, не первый. Как я понял, это только вручную можно сделать, автоматически на двух сайтах это не работает.
А то сейчас та же проблема - чтобы найти Киев среди городов и сёл Киевской области нужно очень много времени - неудобно
Поисковый индекс местоположений утратил свою актуальность.
т.е. чтобы города крупные сортировались нормально, нужно пересохранить местоположения для сайта, чтобы эта надпись появилась, именно восстановление поискового индекса все портит.
Вот я пересохранил местоположения
При вводе в строку “Местоположение” в форме заказа несуществующий в базе адрес, появляется подсказка: Местоположение не найдено. Нажмите добавить местоположение, чтобы мы узнали, куда нам доставить ваш заказ. Выбираем добавить местоположение после чего открывается форма где надо все выбирать из списка, но, если в этом списке сотни строк, то можно застрелиться пока что-то найдешь.
Когда будет реализован поиск по всем этим полям?
Ведь в админке при редактировании заказа искать можно в любом поле.
Спасибо за ответ.
P.S. Чуть выше
05.05.2015 13:32:57
...
А вот в новом обновление который доступен в бете клиентам, решена схема с поиском в выпадашке, которая облегчает поиск и прокрутку.
У меня установлены все бета, но поиска нет, только можно выбирать из списка!!!
В данный момент можно использовать просто поиск, он в данный момент отлично работает.
Да, действительно, поиск отлично работает. Но, я из Беларуси, а база местоположений для нашей страны, в официальном релизе НЕ наполнена (ну может на 0,1%) и поэтому поиск вообще бесполезен, а выпадашки неудобны. Результат необходима нормальная база. Я уже не раз задавала этот вопрос разработчикам 1С-Битрикс, но, как видно это им не очень интересно, хотя система официально в нашей стране уже, по-моему, 1,5 года. Я думаю база наверняка есть у ваших партнеров из Беларуси, но почему ее нет в релизе???
Вот как-то так, печально...
Вы можете дать конкретный ответ, например, планов на ближайший год нет или не планируем наполнение данной базы вообще или да планируем, в планах до… и т.п.
Может у кого есть данная база в виде файла?
Спасибо за ответ.
Если у вас она есть или вы ее найдете, присылайте.
Я тут потратила определенное количество времени и собрала базу. Она до села. Она конечно не совсем полная, но для 99% заказов для нашей страны она подойдет.
Будет очень приятно, если вы ее добавите в общую базу, и я думаю Вам за это многие скажут спасибо.
P. S. Все населенные пункты (CITY) поделила на две группы (GROUP) город и село.
Я также не стала объединять поля CITY и TIP, Вы сами это сделайте как правильно, например:
CITY - Бриксичи TIP - деревня, после объединения – деревня Бриксичи
Куда Вам выслать этот файл?
Спасибо.
Можно выслать на myth@bitrix.ru
Спасибо Вам за базу.
С уважением, Юрий
Выше был задан вопрос, но так и не вижу на него ответа.
Привязка новых местоположений битрикса к каким либо внешним системам. КЛАДР? ФИАС?
Существует ли такое соответствие?
Вижу что есть привязка к кодам яндекса. Но если честно? не нашел что это за коды, где и как используются.
Поделитесь ссылкой на документацию яндекса что это за коды?
Существует ли такое соответствие?
Поделитесь ссылкой на документацию яндекса что это за коды?
Сейчас конкретно, мне необходимо связать базу местоположений DPD, у них соответственно есть своя база, и там связь с кодом КЛАДР.
Почтовые индексы это не совсем надежная связь. Они не всегда актуальнные, и для городов имеют диапазон. Вообщем по ним сложно найти строгое соответствие.
Я также смотрю на будущее, когда с большой долей вероятностью придется подключать дополнительные службы доставки, и у них наверняка будут свои базы местоположений. И их надо будет скрещивать с моей базой в битриксе.
Насколько я понимаю новая версия местоположений битрикса основана на базе ФИАС. Так почему не оставить этот универсальный уникальный код в битриксе.
В новой версии сделали замечательную вещь "Внешние сервисы". Каждый может создавать связь с другими базами не кастомизируя функционал местоположений. Но для того чтобы заполнить эту связь, нужен какой-то универсальный идентификатор , не руками же это всё заполнять....
А сейчас у Вас есть база соответствий кодов яндекса - кодам КЛАДР? В любом формате. Мы сами обработаем эти данные и проставим нужную нам связь.
Под вашу задачу мы как раз закладывали возможность введения неких общих идентификаторов и связке между системами, как мы сделали для яндекса. Если покопать, то можно сделать как мы предполагали.
Например, заказ на сайте оформили по классификатору Местоположения 2.0
Теперь его надо выгрузить в 1С УТ11 с КЛАДР или ФИАС, и далее в службу доставки с КЛАДР или ФИАС или ЯНДЕКС
Я правильно понимаю что соответствия кодов классификаторов Местоположения 2.0 и КЛАДР или ФИАС или ЯНДЕКС на текущий момент нет?
Т.е. что бы загрузить адрес в 1С УТ с КЛАДР надо в 1С допиливать распознание текста из адреса пришедшего с сайта???
1. В Местоположениях 2.0 для каждого местоположения есть возможность указать внешней код системы, но в данный момент для Яндекса они не заполнены. Как то сейчас можно воспользоваться этим функционалом? Как заполнить внешние коды?Где-то взять соответствие класслассификаторов Местоположениях 2.0 и ЯНДЕКС? Цель - передать адрес в курьерскую компанию по классификатору, что бы снизить вероятность ошибок при распознание адреса на стороне курьерской компании.
2. Про 1С УТ 11 как то странно получается, БУС и УТ 11 два продукта которые позиционируются как один дополняющий второй, а классификаторы разные Т.е. в УТ11 получается ни функционалом по доставке (зоны доставки), ни анализом продаж по регионам не воспользуешься, т.к. адреса в заказах забиры не по классификатору.
Спасибо за ответ.
Воспользоваться можно, создав свою структуру хранения нужных соответствий, API для этого есть, заполнить нужными данными и проверять по ней.
Документации к сожалению по этой теме нет, так-как она пока в процессе работы, но можно по коду посмотреть, мы стараемся расставлять пояснения по коду.
Спасибо за ответ.
В 1С данные заносит менеджер, и там обычно заносятся (если необходимо) подробные данные, жестко структурированные, с кучей дополнительных полей (которые или заполняются или пропускаются).
В нашем случае в продукте заполнение данных делают обычные клиенты интернет магазинов, и делается все возможное, чтобы упростить ввод таких данных, чтобы не убить конверсию заказов. Нет жёсткой структуры, очень часто нет жёстких требований по заполнению. В новом релизе, вообще можно будет управлять запрашиваемой информацией, и например для самовывоза, не заполнять вообще не чего кроме ФИО и телефона. По этой причине, очень сложно передать информацию в 1С структурировано. Мы обычно передаем только страну и город. А дальше информация ложится в обычные текстовые поля.
Если вам требуется иное, вы вполне легко это можете настроить, как со стороны Управления Сайтом, задав нужную структуру полей для 1С, сделав их обязательными, указав мапинг на вкладке настроек 1С. Так и на стороне 1С указав куда что попадет.
Делать такую жесткую связку в коробке по умолчанию мы не будем, но все для этого есть.
Да можно привести массу причин по которым интернет магазину сложно работать без интеграции с 1С УТ 11 или другой учётной системой. Так же есть крупные компании которые изначально работали в УТ и делают себе интернет магазин.
Если этого не делать, а как вы предлагаете "просто загрузить данных в текстовые поля", то это будут данные не по классификатору, их нельзя использовать для отчётов или например для отбора всех заказов из определённого города.
Максимум, что можно это передать их дальше как текстовые поля в курьерскую компанию, но если там используется иной классификатор чем Местоположения 2.0 то вероятность того что адрес будет корректно воспринят в курьерской компании не 100%.
Нужно городить костыль в 1С УТ 11 который будет через поиск по вхождению названий местоположений искать их в классификаторе в 1С УТ 11.
И каждая компания которая пользуется и БУС и УТ 11 рано или поздно будет вынуждена решать эту проблему.
Да можно привести массу причин по которым интернет магазину сложно работать без интеграции с 1С УТ 11 или другой учётной системой. Так же есть крупные компании которые изначально работали в УТ и делают себе интернет магазин.
Если этого не делать, а как вы предлагаете "просто загрузить данных в текстовые поля", то это будут данные не по классификатору, их нельзя использовать для отчётов или например для отбора всех заказов из определённого города.
Максимум, что можно это передать их дальше как текстовые поля в курьерскую компанию, но если там используется иной классификатор чем Местоположения 2.0 то вероятность того что адрес будет корректно воспринят в курьерской компании не 100%.
Данные с сайта приходят структурированные, вопрос в том что нет соответствия классификаторов используемого на сайте и в 1С. Поэтому если с сайта приходить:
<АдресноеПоле>
<Тип>Страна</Тип>
<Значение>Россия</Значение>
</АдресноеПоле>
<АдресноеПоле>
<Тип>Регион</Тип>
<Значение>Московская область</Значение>
</АдресноеПоле>
<АдресноеПоле>
<Тип>Город</Тип>
<Значение>Химки</Значение>
</АдресноеПоле>
То по классификатору 1С УТ 11
Региона "Московской области" нет, а есть "Московская обл."
Города "Химки" нет, а есть "Химки г"
Про Москву вообще отдельная история. Москва это отдельный регион такой же как Московская область.
Т.е. получается изменено не только написание, но и структура.
Это прекрасно что благодаря Местоположениям 2.0 покупателям стало проще делать заказа.
Но ведь Местоположениям 2.0 это классификатор, а не свободное текстовое поле и если покупатель при оформление заказа на сайте выбрал Москву, сайт точно знаете, что это за город и его код. Почему отказались от возможности указать в каждом Местоположение на сайте его код по КЛАДР или ФИАС. Тогда бы можно было с сайта отдавать прямо внешний код элемента по КЛАДР или ФИАС и адрес бы загружался корректно в 1С УТ 11.
Или сделать для модуля обмена БУС-УТ11 таблицу соответствия которую бы можно было подгружать в модуль на стороне 1С.
Даже если бы это работало на 70% адресов это было бы всё равно лучше чем то что есть сейчас.
На сайте idea.1c-bitrix.ru есть несколько идей на эту тему с рейтингом 15+
Но получается что дальше идей процесс не движется.
array_search()
Сделал переход на Местоположения 2.0, вроде бы все настроил, но в корзине в окне Город постоянно висит Россия. Можно удалить или выбрать другой город, но если выбрать Санкт-Петербург или Москва, это поле автоматически слетает на "Россия"! В заказе город правильный, визуально косяк. Что я сделал не правильно в настройках?
Необходима регистрация пользователей с выбором города.
Если вдруг изменятся названия улиц в каком то населенном пункте или само название населенного пункта изменится, то нужно сносить все местоположения и затягивать заново весь список, поскольку загрузка "поверх" не изменит названия улицы или населенного пункта.
Точно также нет возможности добавить еще один язык в существующие местоположения, если вдруг заказчик решит добавить еще один сайт на другом языке.
Загрузка рассчитана раз и на всегда. Ну можно еще добавить не существующие местоположения и все! Обновить уже не возможно...
Доставка из-за этого считается неверно!