В новых конфах адрес хранится не по полям, а ввиде XML строки. Думаю, с какой целью 1C сделало такую систему хранения данных?

(0) Чтобы было ох...енно сложно))

не смогли они всю палитру адресов запихнуть в одну общую структуру :)

(0) Так удобнее

для чего удобнее?

(0) А что тебе на партнёрском ответили?

для сериализации на уровне платформы

Чтоб универсально было.
А то что работать с этим невозможно.. Да кого это волнует

Для работы с адресами в типовых есть разные функции.
Их что невозможно использовать или лень поискать?

(8) а в запросе как?

что значит сериализация на уровне платформы? Сериализовать и так можно было?

(10) раньше была строка с запятыми, а теперь специальный тип
"http://www.v8.1c.ru/ssl/contactinfo";

вроде по полям тоже хранится

некоторые поля только хранятся

(11) по ссылке ничего не открывается. Можете привести правильную ссылку?

(14) бу-га-га :)

(9) >> а в запросе как?

А раньше как в запросе было?...
У тебя есть какие-то секретные способы разбора строки с кучей запятых прямо в запросе?

Это $%^здобратия с адресами будет длится вечно.
Сначало была ублюдская система Поле1-Поле9, но там хоть все просто.
Потом Ключ=Значение
Теперь XDTO объект в XML с всякими разными полями и кодами полей.
Ждите, еще ченить придумают.

(16) Есть
Выбрать Поле1, Поле2, Поле3

потому что красиво, модно, современно

(18) было же Поле1, Поле2.....

(18)(20) По-вашему абстрактные "поле1, поле2, поле3..." реально удобнее, чем однозначные "Страна, Индекс, Регион..."?

И кто-то реально пользовался в запросе данными из полей Поле1, Поле2...? Особенно, когда едва ли не в 90% случаев адрес лежал строкой в поле Представление, а не был разобран чётко по полям.

(21) КИ - это не только адреса

(22) >> КИ - это не только адреса

Вот именно!!!
И в Поле1, Поле2 может лежать вообще всё что угодно в зависимости от типа и вида КИ.

Не, ну может я чего-то реально не догоняю....
В конце концов, то, что 1С с такой регулярностью меняет формат хранения КИ, безусловно и меня тоже бесит. В этом плане присоединяюсь к оратору в (17).

Но текущее решение, ИМХО, лучше той дикости, которая была с Поле1, Поле2 и строкой с кучей запятых.

(23) Ну так вид и тип КИ хотя бы анализировать можно было в запросе и вынимать нужные значения из поля1,2,3...
Как сейчас-то быть? Особенно если какой-то отдельный элемент адреса (например город) в отдельную колонку надо вытащить.

То что универсальное решение хранения КИ - это правильно. Но для адреса это не удобно, можно было бы и костыль для специфики страны прикрутить ))

Скоро вся конфа будет одной сплошной xml-строкой...

(21) Конечно нет. Я и написал про ущербность их названий

(21) Да, я реально пользовался той инфой при формировании РегОтчетности

Это все инновации и нанотехнологии...
Давайте сделаем один план счетов - круто, теперь два плана счетов - еще круче, теперь опять один - совсем круто...
Давайте писать КИ в ТЧ объекта - круто, теперь в отдельный РС - еще круче, теперь обратно в ТЧ - совсем круто, теперь нужно сделать ее периодической - добавим в ТЧ "ДействуетС" - ваще круто...