Как получить код адрестного элемента
 

В отчете мною разрабатываемом требуется вывод КодаАдресногоЭлемента. Это поле код из регистра сведений адресный классификатор. В отчете имеется данные из регистра сведений Контактная информация, представление, - адрес контрагента. Можно как то по этому адресу получить этот код адресного классификатора? В запросе получить его связав по индексу с контактной информацией не получилось.

В общих модулях типовых конфигураций есть функции по разбору структуры адресного классификатора и соответствующего регистра сведений.

(1) а что разбирать если к примеру есть контрагент и его адрес из представления контактной информации?

На другом форуме я тебе уже ответил.

интересно просто... ЗАЧЕМ?

(4) видимо для того что бы идентифицировать контрагентов по коду адресного классификатора

блин, только у меня одной слово "[b]адрес[em]Т[/em]ного[/b]" вызывает эм-м-м... некие ассоциации со словом "[em]дристать[/em]"?
и подняли же эту а[em]дрисТную[/em] ветку..
некроманты, блин..

УТ 10.3 по контрагенту и его адресу, нельзя выбрать код адресного классификатора, я так понимаю!!! Нужно конфигурацию для этого менять видимо!!!

[quote=LivingStar;31499085]идентифицировать контрагентов по коду адресного классификатора [/quote]
ЗАЧЕМ?

контрагент идентифицируется однозначно по ИНН или на крайний случай по ИНН/КПП, а по адресу... гхм... вы не встречали "резиновые" офисы? где по пару сотен фирм на 1-м адресе сидят, или не было у вас контрагентов которые меняли адрес?

9-Viking > у некоторых нету ИНН, правда и в КЛАДРе их тогда не найти.

9-Viking > про резиновые +100

(0) В моей разработке: [url]http://infostart.ru/public/189714/[/url] выложены некоторые ссылки на документацию по этому вопросу. Если вкратце, вам нужно сначала определить введена ли КЛАДРу строка адреса контрагента (из контактной информации), это просто: СтрЧислоВхождений(ПредставлениеАдреса, ",") = 9. Затем разложить строку адреса в массив адресных элементов и последовательно искать по их наименованиям в регистре сведений. Если подключите внешний КЛАДР как у меня, то в переменной СписокОбъектов обработки ВводАдреса всегда доступны коды всех адресных элементов из КЛАДР.

(11) да, точно, про забугорье то я и забыл... но и код из кладра к ним не подтянешь... (кстати, еше одна проблема при идентификации по коду кладр-а)

2(13) У забугорных (более-менее цивилизованных, я исключаю ИП-шников из всяких людоедско/банановых Папуасий и Гондурасий) есть свои обязательные уникальные номера во всяких реестрах торговых палат и т.п.

14-bma1 > ну да, только у каждого свои они. да и бананиев от Папуасского фермера-ипшника иногда хочется, не отказываться же из-за того, что у него ИНН нету и в кладре он не прописан.

0-LivingStar > если очень надо, то всё-таки сдаётся мне, что надо использовать внешний кладр, как Chastiser написал. ибо 1С - она такая 1С...

(8) требует поставщик, предоставил свою форму отчетности

(12) Скачал, интересно будет посмотреть что там у вас. Да по теории именно так, имея адрес нужно получить коды его составляющих, что и будет представлять собой код адресного классификатора данного адреса. Появится время разверну .cf, посмотрю. Думаю будет продолжение ветки.

(12) Пока не смотрел, но это .cf. Что бы использовать вашу наработку нужно объединять с вашим .cf? Нельзя ли реализовать поставленную задачу внешней обработкой ?

(16) А причем здесь 1С? Внутрь типового регистра сведений закачиваются те же данные из DBF-к с теми же кодами. Внешний КЛАДР просто не занимает 1Gb в объеме базы и обновляется просто за счет распаковки свежих файлов. Если искать код адресного элемента в типовом функционале, то я бы смотрел в сторону процедуры определяющей почтовый индекс дома: перед её вызовом уже должен быть известен самый полный адресный код (который из файла DOMA.DBF).
(4) По поводу "зачем это нужно"? Допустим в большом городе есть фирма, развозящая свой товар сотням покупателей в день (мелкий опт пива, бытовой химии и т.п.). В базу данных занесены тысячи клиентов по которым должны ездить торговые представители. Такие фирмы часто заказывают доработку реквизита _для сортировки_ списка клиентов находящихся рядом друг с другом, а не идентификации клиентов. Обычно если отсортировать большой список по улице и числовому номеру дома, то наглядно видно дислокацию клиента по какому-либо городскому району. Код адресного элемента из КЛАДР может делать ту же функцию - сгруппировать при сортировки рядом находящихся клиентов.

(19) Данная задача и решается внешней обработкой, файл cf выложен просто для демонстрации всех возможностей работы с внешним КЛАДР. Сохраните единственную обработку ВводАдреса как внешнюю, перенесите в неё процедуры из общего модуля, пропишите значение ваше значение константы КаталогКЛАДР в тексте модуля и вызывайте её как внешнюю.

А вообще, если вы скачете и подключите внешний КЛАДР к моей разработке, скопируете нужный вам адрес текстом в новый элемент справочника "Адреса", то поставив точку останова в строке 312 модуля формы "ФормаЗаписиАдреса" в переменной КодПоиска будет искомый 17-значный код вашего адреса.

(0) Во-первых, KLADR сам по себе есть упорядоченная таблица. И по [b]почтовому индексу[/b] можно найти строки, содержащие регион, район, город, и список улиц (парся поле CODE, в котором позиционно есть место для региона, района, и т.д.).
А почтовый индекс содержится в первой позиции адресной строки.
И сам почтовый индекс иерархический, кстати.
(19) Сделай копию своей БД, накати .cf, потом утяни нужные модули в обработку, как локальные.

+(23) О, в (20)-(22) уже разжевано ;)