УТ 10,3
Как можно указать несколько адресов доставки в карточке контрагента
если при создании новой - с предпоеределенным значением - Адрес доставки - ругается что Запись с такими ключевыми полями существует.


создавать множество элементов справочника ВидыКонтактнойинформации - с наименованием типа "Адрес доставки" "Адрес доставки1" "Адрес доставки2" - не айс ..

(0) Ну получается без допила никак.

ну вот как допилить с наименьшим сопротивлением ?
вижу вариант
- сделать новое измерение типа - ДатаВремяСозданияЗаписи
- создать новую подписку на событие - которое будет передзаписью - устанавливать все что надо.

не ?

контактные лица контрагента есть в 10.3?

(3)
да -есть

вообще, раз несколько адрес доставки - это логистический контрагент. А в справочнике "Контрагенты" - не логистические сущности. Там - скорее контрагенты для взаиморасчетов. А расчеты с адресами не связаны, потому и не взлетает. Нужна отдельная от "взаиморасчетных" контрагентов сучность.

(4) ну, вот в них и храни адреса.

+(5) ну, или изобретай отдельный справочник, в котором будешь хранить адреса доставки контрагентов.

(6)
над отд справочником думал
не удобно ..
т.к. адреса есть в кладре .. и надо переделывать обработку по редактированию адресов РС

(4)
опять таки - там есть фио, телефоны, должность ..
те там нет полей для адреса.

(8) пля, ну, тоже мне проблема! Сделай - тжпрограммист :)
Тебе в любом случае делать - либо новый справочник и к нему присобачивать контактную информацию, либо просто присобачить контактную информацию к контактным лицам.

(9)
не красиво будет и то - что все адресные механизмы завязаны на РС Контактнаяинформация.в т.ч. и адреса доставок.
получиться - что есть 1 адрес доставки в одном месте базы (в РС) и несколько адресов доставок в др месте (например, в спр)

(10) какая религия мешает тебе хранить в РС.КонтактнаяИнформация адреса для справочника КонтактныеЛица?

11
никакая. с такого ракурса не думал.

Можно напулить туда уникальный идентификатор в качестве доп. разделителя

(12) ну, дык, ты это... подумай...

вот так (13) не стоит делать.
Я когда-то давно так сделал. Было плохо.

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

(14)
проверил. там можно хранить только 1 адрес доставки
т.е. чтобы параметр видАдреса - был постоянным.

(15)(16) А что не взлетело?

(14)
те я создал 1 адрес доставки для конт лица
записал.
потом создаю еще один с указанием видадреса - как у предыдущего. записал.
при этом отредактировалось первое значение

(13)
в какой реквизит /ресурс/измерение РС Контактная инфо пихать этот доп разделитель.

(15)
подробнее
в чем траблы вылезли ?

(19) создай много контактных лиц, что ли...

(0)
>>>>создавать множество элементов справочника ВидыКонтактнойинформации - с наименованием типа "Адрес доставки" "Адрес доставки1" "Адрес доставки2" - не айс


Почему не айс? Сколько таких адресов будет? 2? 3? 30?

(19) каждый адрес доставки - это отдельное контактное лицо

(22)
до 12 ответили.

(20) это было лет 8 назад, я не помню уже. Но помню, что зарекся.

(22)
с тем же успехом можно и в конт информации - спр виды контак инфо = дублировать вид = контактная инфомация.

(25)
вот тож чую что ничего лишнего добавлять не надо ..
но чуйку к делу не пришьешь .

(24) а когда появится 13й, придется звать программиста и выпускать обновление, да? Гениально же, правда?

+(25) одна проблема была в том, что дубли стали экспоненциально расти и неконтролируемо. Но были и еще.

(26) это глупое решение потому, что ВидКИ - это совсем другая сущность.

(24) Тогда здесь (5) лучший подход.