Возникла необходимость (из-за одного электронного обмена данными с партнером) выгружать для всех клиентов их ФИАС коды адресных объектов (код ФИАС города, улицы, дома и т.п.).
С обработкой контактной информации раньше не сталкивался, интересно мнение людей с опытом.
Есть 2 варианта – ваять что-то свое (либо совсем отдельно либо притачивать к контактной информации) либо встраивать (с допилкой или без) типовой механизм из БСП. Первое что бросилось в глаза, это то, что в поле «ЗначенияПолей» (ТЧ контактная информация) хранятся только имена адресных объектов, а кодов и guid их нет. Т.е. надо либо расширять соответствующие XDTO-пакет и добавлять туда нужные данные (либо что?).
Кроме того насколько я понял нет сведений из таблицы HOUSE, т.е. БСП поддерживает ФИАС только до уровня улиц. Кто-нибудь прикручивал таблицу HOUSE?
И тут же встает вопрос преобразования текущих данных в контактной инфе в новый формат.

Итого 3 вопроса:
1.    Как лучше прикрутить guid от ФИАС. Юзать ли для этого БСП?
2.    Как прикрутить инфу о домах
3.    Как преобразовать старую инфу (по КЛАДРУ в виде строки) в новую (сериализованный xml)

Кто сталкивался – поделитесь опытом )

(0) лучше не нуна совсем...

БСП к самописке "без БСП" прикрутить это такое извращение выйдет

с 0 можно только зачем? заюзайте типовую БП с ФИАС для обратного получения кодов (адресных объектов ФИАС по связанному контрагенту) и сохранения (для выгрузки потом)

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

(1) "типовую БП с ФИАС для обратного получения кодов (адресных объектов ФИАС по связанному контрагенту)"

не совсем понял..

Просто в БСП столько кода навалено ) - обработка ввод контактной инфы + все модули.
что либо там много лишнего, либо я не успею реализовать столько.

(3) БП есть? Контрагенты те же что и в "самописке" заведены? С адресами?

ЗЫ обратная синхронизация

в БП клиентов никто не ведет.. Там все не очень хорошо у нас - каждая ТТ как отдельный контрагент в БП приходит и так далее.

(6) эээ? и что такое "ТТ"?

(7) Пистолет такой...

Торговаяточка )

т.е. исторически так сложилось, что каждая торговая точка в БП как отдельный контрагент (а не как контрагент и разные грузополучатели).
Хотя суть не в этом. В БП ведется довольно обобщенный учет и никто там адреса не проставляет. Торговых точек дофига и наиболее актуальная и достоверная инфа именно в управленческой базе (торговле).

Наверное все же попробую прикрутить контактную инфу из БСП (она и сейчас из БСП но прошлой) и расширю ее для домов, для которых отдельный справочник заведу (или РС)

в общем и впрямь, возится с БСП смысла нет. Слишком много общих модулей добавилось-поменялось и все равно нужно доделывать таблицу HOUSE, потому что непременно нужны коды домов..
Интересно почему 1С сделала адресные объекты как РС а не как справочник? для простоты так как похожий классификатор уже был наверное.

(11) потому что место крепления рук определяется наследственностью

(0) как, как - уже обсуждали - я там всё сказал, строка в XDTO хранится, вытаскивать от туда придется. Формируй представление через запятые, потом можно в ХДТО положить, стандартные функции есть в БСП - глубоко там запрятаны - но найти можно.

КонтактнаяИнформация - (28) пост.

только там еще подводные камни есть - но о них нигде не пишут в статьях посвященных внедрению фиаса, на ИТС только как справочное руководство.

я заведу справочник иерархии элементов, где свяжу объекты в дерево в соответствии с их иерархией и не буду париться с привязкой фиаса к контактной информации. (единственное что попробую максимально на автомате "угадывать" какие объекты следует подставить).

Поскольку у меня задача не про адреса а про идентификацию клиентов по их guid (причем зачем-то требуют гуиды по всем уровням - а сами там будут сверять что даю все объекты с одной ветки) то нет смысла прикручивать БСПшное управление контактами, которое не решает мою задачу, а гемору хватит с ним.

только вот не решил - дома наверное имеет смысл в отдельный справочник вынести (как таблицу HOUSE) и привязать через подчинение к адресным объектам (из таблицы ADROBJ)

Для Ферреро потребовалось прикрутить недавно. Мне проще самому через справочники оказалось сделать.

Загрузил обе таблицы в справочники. Из ADROBJ создал дерево.

(18) вот-вот.. у нас ттот же поставщик )
видимо они единственные кто к ФИАСу привязался )

в итоге вы тоже решили сделать иерархический справочник из ADROBJ.. а дома? и что хранить в клиенте - код (GUID) дома (а уж из него на лету по иерархии получать все коды родителей)?

и пользователи вводят независимо адрес и независимо выбирают ФИАС объекты?

кстати - сколько времени примерно может потребоваться чтобы сделать справочники, импортнуть и сделать интерфейс для пользователя? )

В таблице HOUSE нет некоторых домов. И хранить иногда вместо ссылки на дом -  просто номер дома приходилось.

Разбираться с ФИАС пришлось в авральном порядке. По этому времени ушло не так много, но можно было сделать все лучше чем получилось. В основном время ушло на то, чтобы разобраться с структурой ADROBJ. Там есть статус активности. Если его не учитывать дерево не получается. Если активности нет значит данные устарели или изменились.

В конце проекта помог операторам заполнить адреса по ФИАСу.
По индексу находил сначала все дома, по домам находил улицы по улицам населенные пункты города и районы. и т.д. все что выше. Потом по номеру дома находил сам дом и заполнял весь адрес.

P.S.
Из домов принадлежащих данной улице.

таблица домов какая-то громадная - конечно. в нашем регионе 1.3 млн записей.. Все хранишь в 1С?

т.е. ты автоматом расставил по данным из контактной инфы ссылки на справочник ФИАС?

В нашем регионе 300 тысяч. Более северный добавил с 20 тысячами. На остальные регионы забил. Контрагентов мало, а справочник домов большой.
Да.

там если его весь загружать - в пустую базу - то база в 2 Гб становится - это если все регионы России загружать - загружает правда долго, загружал частями по регионам несколько раз. Но выборка шла быстрая - нас устроило :)