Помнится, даже сама 1С не раз меняла хранение контактной информации контрагентов в своих конфигурациях.
А где бы вы хранили, если бы писали типовые? А если не типовые, а свою конфу? И почему?

имхо так правильнее

рс

Вопрос имхо на редкость глуп. Правильнее хранить там, где это будет работать.

(3) Ты традиционно в своем репертуаре. Спасибо за твой абсолютно бесполезный комментарий.

(1) Чем правильнее? Так же неудобнее докручивать форму?

(0) опять этот недоучка Печенкин с тупейшими топиками

по 10.3 - привычнее... особенно после того, как намаялся с ними в ТЧ справочника..

(4) Да пожалуйста. Всегда рад дать правильный ответ.

(7) +особенно, после того, как намаялся с ними в ТЧ справочника в УТ 11..

(3) Самое удивительное, что оно везде работает.
В типовых от 1С КИ работала и в регистрах сведений и в табличной части справочников.
ИМХО, твой ответ не сильно умнее вопроса...

Адрес не постоянный, надо иметь историю изменения значений, допустим для печать документов за прошлый период.
В РС есть возможность среза, упрощая доступ к данным.

закрывайте ветку.

в чем суть переноса КИ в справочник?
разделение прав доступа

В (0) не выставлен критерий правильности, тема перерастет в ... :)

(11) Так я это и имел ввиду. Сама постановка "где правильнее" - на редкость глупа. Там, где программист реализовал, там и правильнее (если конечно всё работает, как положено).

(11) в табличной части не круто хранить. При получении объекта ты получишь ещё кучу ненужных данных(картинки, адреса, ответственные менеджеры).

(11) "и в табличной части справочников".. смотрел как работает в табличной части справочников в ут 11?.. и их невероятно тупую реализацию с хранением как реквизитов КИ, так и их хмл представления?.

Контактная информация контрагента делится на 2 вида
Инфа о компании- она статична,  история по ней не нужна- справочник
Инфа о ЛПР- она уже меняется и отслеживать измнеения важно. с точки зрения СРМ, это регистр

В общем- как обычно, кг/ам

(12) Ну проблема как бы решаема. Хранить историю изменений адресов в РС.

(20) Зачем создавать справочник со значениями и хранить историю в регистре? Есть какой-нибудь прирост скорости или уменьшение объема базы?

(21) Я имею в виду хранить в ТЧ справочника, а не новый создавать. (Как в УТ 11 сделано)

(18) оО и какая же контактная информация статична? фирма не может сменить адрес/телефон/почту?

Смешные вы какие...

Если конфа - ваша личная самописка "с нуля", то храните - как хотите. Для большинства случаев вполне подойдет РС - оно и проще и понятнее программисту (хотя и сложнее для понимания пользователя).

Если ваша нетленка написана на основе БСП, то, ИМХО, правильнее использовать подсистему КИ из БСП.
А там КИ хранится в табличных частях объектов - владельцев КИ.
Оттуда же (из БСП) следует использовать механизмы хранения истории изменений КИ. Там это сделано при попмощи добавления реквизита табличной части КИ "ДействуетС". Это к (12) и (20).

(24)"правильнее использовать подсистему КИ из БСП"
Да, я так и сделал в своей, которая на основе БСП.

Я до адресов в УТ 11 не доходил. БСП не изучал.
Какой практический выхлоп от этого?

(26) >> Какой практический выхлоп от этого?

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

(27) да я понял что 1с делает правильно в своей БПС. Везде должна быть стандартизация. Но почему выбрали этот стандарт?

(12) Дельная мысль.
Тогда почему в типовых в табличной части?

(29) ХЗ, может из-за форм?

Адресов или телефонов может быть несколько.

У Пользователя может быть запрет на изменение контрагента, но должен быть доступ на изменение контактной информации (например телефонов)

(28) >> Но почему выбрали этот стандарт?

Ответ от 1С:
Что бы права доступа на контактную информацию совпадали с правами доступа на сам объект. То есть контактная информация - неотъемлемая часть самого объекта...

(31) есть права на просмотр и редактирование отдельных реквизитов

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

(32) Соглашусь с 1С в этом вопросе, не стоит все детализировать до атомов.

(31) >> У Пользователя может быть запрет на изменение контрагента, но должен быть доступ на изменение контактной информации

Крайне редкий случай. Особенно если внимательно вдуматься в постановку задачи.
В 99% случаев при ведении учета таким образом возникают требования, что этот пользователь с такими странными правами, мог и еще пару реквизитиков править. И это становится головняком для разработчика.

(34) в типовой УТ 10.3 набор записей записывается только вместе с контрагентом (если из формы редактирование)

(32) на работе у меня есть права на просмотр данных клиентов, но нет доступа к КИ. Наша СБ не согласна с 1с.

(36) У меня в паре организаций как раз так используется.
Реквизиты контрагента менять запрещено.
А контактную информацию пользователи заносят.

(36)"Крайне редкий случай."
Не знаю, не знаю. В прошлой конторе было три роли пользователей и директор хотел чтоб у каждой роли были свои права на доступ(чтение и запись) к данным контрагента. И более того свои удобные формы для редактирования/ввода этих данных.
Вот тогда я помню намучался с этим РС Контактная информация в УТ 10-ой.

(38) >> Наша СБ не согласна с 1с

Вполне допускаю. 1С далеко не идеальна.
Но ваш случай всё таки скорее редкость. И встречается, как правило, только в базах где ведётся CRM, и контактная информация действительно может быть более ценной, чем просто информация о контрагентах. Но в таких базах и голой БСП-ной подсистемы КИ тоже будет мало. А в 99% случаев КИ всё таки вторична и не так ценна как база контрагентов (имея базу контрагентов, найти нужную КИ проще).

(40) Я же не сказал, что это вообще невозможный случай.
Конечно же где-то такое наверняка требуется и это требование обосновано. Я высказывался о своём личном опыте, который говорит мне о том, что обоснованным такие требования можно назвать крайне редко.

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

Рома, когда ты поймешь, что в реальной жизни в целом и в разработке ПО в особенности не бывает единственно правильных ответов на все времена?

(37) И че? На контрагента-то прав нет.

(43) К чему эти общефилософские ответы, не несущие никакой практической пользы?
Типа "Делать нужно так, как правильно", "Использовать нужно то, что в ТЗ", "Единственно верного ответа не существует"... и т. д.
Даже в этой ветке уже накидали несколько вещей, влияющих на выбор и только у тебя с Fish абсолютно невозможно ничего сказать по поводу выбора варианта без полного досконального поставленного кем-то ТЗ, в котором, видимо, просто тупо будет написано, что именно использовать.

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

Могу сказать, что мой ответ в табличной части.
В силу накопленного опыта и всех известных за и против.
И да, конечно же, если мне сказали бы, например, что нужно в документе хранить телефон, по которому звонили контрагенту, то, конечно же, я бы выбрал подчиненный справочник.

(43) Имхо, никогда. Для того, чтобы это понять, нужно быть хотя бы немного программистом.

(48) та не, он как раз на 100% кодер - думает о том КАК сделать, вместо ЧТО и ЗАЧЕМ. Потому, что КАК - ему ближе, а для ЧТО и ЗАЧЕМ надо думать и заказчика допрашивать до тех пор, пока из него смысл не польется.

(46) Да вся МиСта — это общефилософские вопросы, когда что-то известно, что-то нет.
И почему-то на вопрос "А че у меня программа говорит, что номер документа не уникален?" никто из адекватных товарищей не начинает уточнять молекулярное окружение автора, а сразу пишет, что сто к одному, что нумерация сбилась.

(49) Как я знаю уже 15 лет. И что знаю. И зачем. Мне просто интересно, что думают другие.

(49) Ты не знаешь, зачем общестатистическому заказчику, которых 99%, контактная информация?

(52) Открой секрет - зачем?

(49) Не соглашусь. Опытный программист, зная ЧТО и ЗАЧЕМ, выбирает "КАК сделать" оптимальное решение из различных вариантов. А недопрограммист (или просто кодер) будет искать ответ на вопрос "как ПРАВИЛЬНО сделать", без привязки к ситуации, и потом уже будет лепить это своё "правильно" где нужно, и где не нужно, только потому, что так "правильно".

(54) а я разве не это же самое сказал?

(54) (49) красивый русский язык ).

(54) Оптимально <> Правильно?

убег за попкорном. кому еще взять?

(58) мне сладкий. Не цветной.

(57) Нет. Решение может быть правильным, но не оптимальным.

(57) define: оптимально

пля, да у терминов "правильно" и "оптимально" нет точного определения, о чем вы спорите?

(62) Блин. Первая ссылка в яндексе на слово "правильно", ввела в шок :))

(62) Во, правильно, убирайте с Fish термины "правильно" и "оптимально" из лексикона, у них же нет точного определения :))

(63) оо.. в яндекс браузере онное идет второй строкой, а вот  IE - первой))

(64) А я не согласен, что у этих терминов в программировании нет точного определения.

Думаю в регистре будет все же удобней хранить (не буду спорить на счет правильности или оптимальности), например потому, что в регистре можно хранить КИ для разных объектов, вот в УПП например тип измерения ОБъект в РС КИ: СправочникСсылка.КонтактныеЛица, СправочникСсылка.ФизическиеЛица, СправочникСсылка.Пользователи, СправочникСсылка.КонтактныеЛицаКонтрагентов, СправочникСсылка.Контрагенты, СправочникСсылка.Организации, СправочникСсылка.ЛичныеКонтакты

(66) Пообщайся с Лефмихалычем, мне пофиг на эту хрень.

(66) ну, ты можешь быть не согласен - у нас свободная страна, но определение от этого не появится.

(69) Оно есть.

(70) и ты даже можешь его привести?

(66) Где правильнее хранить контактную информацию контрагентов?

(71) Выбирай, какое нравится: http://moyslovar.ru/slovari/vse/slovo/правильный

(72) См (3).

(74) перечитал 66 потом 3..

+(67) Кроме этого у РС ключ - это комбинация измерений, а у справочника только ссылка, то есть элемент справочника можно связать только с одной записью, а запись регистра с несколькими.

(73) эти определения опираются на правила и нормы. Только вот в программировании нет ни правил, ни норм, на которые можно было бы опираться для построения правильной архитектуры. Та же петрушка и со словом "оптимально"

(72) ну, в табличной части конечно. Там ухже и история есть. А в регистре еще и историю надо самому приделывать.

(78) Лучше в блокноте.

(79) в двух. Чтобы бэкап был. Иначе не надежно

(78) а если у тебя нет бсп??

(80) Зеркалирование через копирку.

(77) В программировании проще: правильное решение - это решение, которое даёт результат, ожидаемый заказчиком.
А вот оптимальное решение уже должно помимо правильности, удовлетворять и другим критериям, которые зависят от множества факторов, но в каждом конкретном случае, они, тем не менее, вполне определённые.

(80) и каждый положить в отдельный сейф, желательно в разных помещениях :)

(83) "решение, которое даёт результат, ожидаемый заказчиком" - это решение, соответствующее ТЗ. К правильности не имеет отношения. У "оптимально" нет конкретного определения, так же, как и у "правильно", в контексте разработки ПО.
В контексте, например, строительства, определения есть, т.к. там и правила и законы известны. А в разработке ПО полная анархия, т.к. этому виду человеческой деятельности даже ста лет нет - мы просто еще не набили шишек достаточно, чтобы выявить эти законы и правила. По этому в разработке не бывает ни абсолютно правильных, ни абсолютно оптимальных решений.

(0) А это смотря для каких целей её хранить (если вообще её надо хранить).
Без конкретной задачи вопрос несколько бессмысленен.
Кстати, отсутствует вариант - в реквизите (в реквизитах).

(23) Эта информация никак не влияет, да и не нужно это отслеживать, а вот изменение  ЛПР места работы достаточно сильно может сказаться на заказах

ОФФ. Только программисты так умеют - раздуть из простого и понятного вопроса сложный неразрешимый филосовский спор.
Один в (3) пукнул в лужу и понеслось вынюхивание всех тонкостей аромата.

ИМХО, автор ветки задал вполне корректный вопрос, который было бы лучше сформулировать так:
"Поделитесь своим опытом и профессиональным мнением о плюсах и минусах конкретных способов хранения КИ".

А вся остальная филосовская лирика, которую тут развели  Fish и Лефмихалыч , какой-то бред, который присущ какому-нибудь желторотому программисту, который искренне верит в существование единственно верных и правильных решений, а не взрослым и опытным мастодонтам 1С.

(88) это залп главным калибром..

(85) Открою тебе секрет: в ЛЮБОМ языке программирования, есть и свои правила и нормы, и никакой "анархии" :)

(86)>> Без конкретной задачи

Задача вполне конкретно поставлена: "если бы писали типовые".

>> для каких целей её хранить

Вот в типовых для каких целей предусмотрено хранение КИ?
Представьте, что вы пишите тиражное решение, которое будут использовать очень разные клиенты. И кому-то из них КИ нафиг не впёрлась, а кто-то её тщательно фиксирует.

(90) ты живешь во лжи

(88) И регистр сведений, и табличная часть, и подчинённый справочник - это всего лишь другая таблица с внешним ключом.
Так что с точки зрения программирования - тут дело вкуса (и решаемой задачи).
Можно хранить в той же таблице - если контактной информации много не требуется.

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

(92) Нет, я целых 5 лет изучал эти правила и нормы в университете :))

(88) феерическая расстановка точек

(88) + 100500
Только по поводу поделитесь, не поделитесь, а скорее мне просто интересны мысли других.
То есть не практической цели ради.

(91) Потому 1С и дала возможность программирования, что "универсального решения" нет. УТ, БП, ЗУП - все типовые. Но разные.

(95) На самом деле эти правила и нормы называются синтаксис и алгоритмы.

(94) "В интернете", "во внешнем наборе данных" - варианты для дебилов? То есть, интегрированные системы не рассматриваются в принципе?
Мне вот как раз вариант с внешним набором данных - очень симпатичен. Для вполне конкретной задачи.

(99) От этого они не перестают быть правилами и нормами, которые, в том числе, и определяют оптимальное решение для каждого конкретного языка.

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

рукалицо

(98) Ну сейчас 1С во все типовые интегрирует БСП.
А в БСП вполне конкретное и четкое решение. Табличные части и никаких РС.

(93) Ну да конечно :))
Попробуй-ка сделай ключ для записи регистра сведений средствами 1С.
Или попробуй сделай редактирование данных, не хранящихся в самом объекте, вместе с объектом.
Или в отчете выбери что-то через точку, когда это не реквизит объекта.

Вот, кстати, почему никто не выбрал четвертый вариант?
Это второй по привлекательности убыванию вариант, который выбрал бы я :))
А всего-лишь потому, что в СКД можно выбирать поля через точку. Сразу. Без допиливания.

(102) Никакими. Нужно руководствоваться здравым смыслом.

(100) Для типовых конфигураций?

(102) "каким синтаксисом и алгоритмами надо руководствоваться" -  В рассматриваемой теме, естественно, это будет синтаксис, алгоритмы и объекты языка 1С. И никакой анархии.

(106) а здравый смысл - это такая штука, которая во всех случаях одинаковая или он от контекста зависит?

(104) Не во все. Только в российские.
Но для российских - имеет смысл как раз использовать БСП и не мучиться с выдумыванием собственных способов хранения КИ, если это не требуется по каким-то другим причинам.

(105) >> почему никто не выбрал четвертый вариант?

Подсистема КИ в БСП описывает подключение к характеристикам данных о КИ из ТЧ.
Мне лично не совсем понятно для чего ты это выделил в отдельный пукт.

(109) Конечно, зависит.
Плюхнуться мордой в грязь под начавшимся перекрестным обстрелом — это норм.
То же самое на асфальте в Москве — не очень.

(109) Он не может зависеть от контекста, он либо есть, либо его нет:)

(108) ну, так перечисли конкретно, чем именно надо руководствоваться в данном случае? Что именно в синтаксисе языка 1С содержит основание для выбора правильного решения? Какие именно волшебные алгоритмы содержат такие основания?

(105) А есть необходимость это всё пробовать?
Либо, как было очень верно замечено, используешь типовое решение - БСП. Либо речь идёт о специфической задаче - тогда какой именно задаче?

(112) как видишь, у некоторых здравый смысл зашит в ПЗУ (113)

тьфу на реализацию КИ в ТЧ.. особенное на реквизит "ЗначенияПолей".

(117) + на так называемое "типовое с использованием БСП"..

(114) Ты опять имхо перепутал понятия: синтаксис и алгоритмы нужны для того, чтобы реализовать правильное решение. А вот для оптимального, помимо синтаксиса, нужно ещё много чего учесть. Например, для файлового и серверного варианта оптимальные решения будут разными даже на одной платформе 1С.

(116) Да уж лучше в ПЗУ, чем вообще без него :)

(111) А, точно, характеристики же можно натравить на ТЧ.

(117) А что в нём не нравится конкретно?

Слив засчитал, господа. Фиш и Дотошин.

Мой постулат: "правильного решения нет и быть не может, т.к нет правил, которым должно соответствовать решение, чтобы быть правильным"
Ваш ответ: "правила есть - это синтаксис и алгоритмы"
Дальше я спросил: "что в синтаксисе и какие алгоритмы дают правильный ответ на сабж"
Я уточнил: "что именно в ситаксисе 1С и какие алгоритмы дают основания для правильного ответа"
В результате потекла бадяга про здравый смысл и оказалось, что это Я что-то там путаю, хотя сами понятия синтаксиса и алгоритмов в дискуссию ввели вы.

(123) а ты конкретно видел эту структуру?

(129) Все Чебоксары из-за тебя забанят :))

(124) Куда то вас не в ту сторону несет уважаемый Лефмихалыч. Где я говорил, что есть правила, на основании которых можно принять решение о способе хранения КИ?

Странно, вроде в (0) простой вопрос с простыми известными критериями и даже назначение озвучено.
Ан нет, опять понеслось переливание из пустого в порожнее :))

(131) см (99). Ну, или ты ляпнул, не прочитав ветку выше 95-го поста.

(132) вопрос про типовые бессмысленный, т.к. для типовых есть решение от вендора - БСП. Для не типовых все зависит от требований, являющихся основанием для разработки этих типовых и общего какого-то решения нет и быть не может.

(132) в (0) не простой вопрос.. там есть вариант как "типовые".. так и "а свою конфу"... для своей конфы использовать типовой БСП с ТЧ - дурь и блажь..
для "своей конфы" - выбирать на основании задачи: если конкретный проект, то делать под требования ТЗ; если создание аналога БСП для работы с КИ - то уже анализ и синтез...

(134) Ты как Apple.
Все телефоны, кроме Iphone бессмысленны, потому что есть Iphone.
Да, да, пожалуйста, только успокойтесь, нет телефонов кроме Iphone, все остальное бессмысленно :))

(135) Да ты че :))
Я вот в Почте России биллинг на БСП писал и не считаю, что надо было с нуля заколбасить.

(136) бред. Такого я не говорил вообще и из моего поста это не следует. Перечитай.

(138) да, он, похоже, видит только то, что хочет видеть)) давай лучше попкорном поделюсь)) (137) и ты за ради КИ потащил БСП? или лукавишь, и у тебя помимо КИ были и другие требования?.. и, что можешь сказать за реквизит "ЗначенияПолей", если на то пошло...

(139) Конечно не только за ради КИ.
Про ЗначенияПолей ничего не могу сказать, не думал на эту тему. А что там?

(125) Мало того, что видел, но и работаю с ней.

(140) если не за ради КИ, то выбор БСП понятен. Но, в этом случае говорить про выбор ТЧ для КИ как бы моветон. Потому как, ты как истинный поклонник Эппла ещь то, что дают)).. про ЗначениеПолей - дублирование данных.... (141) тебя, как любителя правильности и оптимальности, не раздражает дублирование информаации?

(142) Меня - нет, т.к. при доработке типовых оптимальнее использовать существующее решение, чем перелопачивать половину конфигурации :)

(142) Ну по поводу "дублирования" данных. А ты так и не понял, для чего это дублирование сделано? Как раз для оптимальности :)

(142) >>Но, в этом случае говорить про выбор ТЧ для КИ как бы моветон.
Так а какое отношение сабж имеет к БСП в Почте России?

>>про ЗначениеПолей - дублирование данных....
И че? В 1С дохрена мест, где идет избыточность и дублирование данных и это нормально и правильно.

В отдельной базе можно.
Обращаться к нужной инфе только при необходимости.

(146) Я считаю, вообще не хранить, а оформлять по необходимости запрос в паспортный стол.

(143) тут вообще-то не про типовые.. как бы)) (144) а вот первое мое желание, когда увидел эту "оптимизацию" было выдернуть руки оптимизатору... а из словесного потока здесь пройдет только "дебилы".. (145) ты уж определись: если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов"; если про выбор объекта 1С при создании своей конфы - то, выбирать (правила выбора я описал выше)..

(148) >>если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов"
Я же написал в (0) "А где бы _вы_ хранили, если бы писали типовые?".

(149) ты уж потрудись перечитать свое 0. если трудно, то приведу цитату из 0 "а свою конфу".. которую я тебе уже приводил в (135)

(147)в паспортном столе не вся инфа.А вот  сервис от 1С по ИНН доставляет

(150) Я говорю конкретно про "если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов";".

(152) ты уже конкретно сам не понимаешь, что говоришь. По крайней мере, меня запутал, что в итоге ты хочешь сказать.

(148) А если не типовые, то опять же, зачастую оптимальнее строить свою конфу на основе БСП, поэтому вопрос о том, где лучше хранить КИ, отпадает сам собой. Всё зависит от конкретной задачи.

Есть еще 3 вариант. В реквизитах справочника, как в 77

Обычно куча КИ не нужна, все равно ее в запросах просто так не вытянешь. Ибо где-то нужно предопределенные виды ки хранить

(154) эээ... астав да...  БСП, ровно как и типовая - это то, что дали, и нужно кушать "как есть" и без обсуждений типа "правильно, оптимально"..

(157) Ты одноэсник или кто?

(156) >>Обычно куча КИ не нужна
Посмеялся :))

(158) эээээ... к чему вопрос?..

(159) Как ты несколько телефонов введешь, что с ТЧ, что с Регистром?
Будешь плодить Виды КИ: Тел1, Тел2

В бухе так вообще нет "других" видов КИ

(161) Вот именно.
А в случае реквизитов просто тупо никак. Адын телефон. И все.

(157) Ты всё-таки не понимаешь термин "оптимально". А он, помимо прочего, включает в себя ещё и трудозатраты на разработку, которые БСП позволяет существенно сократить. Ты же не пишешь новую ОС для каждого отдельного заказчика?

(161) " Как ты несколько телефонов введешь, что с ТЧ" - посмотри, как это в БСП реализовано.

(163) Оба варианта неюзабельны для такого сценария

(165) Нет под рукой. Расскажи как

(167) Для каждого вида КИ (телефон) можно сколько хочешь телефонов завести.

(168) А какой будет основной для печати?

В ЕРП 2 нельзя ввести несколько телефонов для партнера

(164) ой, все....молись дальше на 1С... зы. да будет тебе известно, что я знаю что такое "трудозатраты", ибо это хлеб, которым  я питаюсь.. (167) через анальное отверстие, как еще.. например, в ут 11 можно накропать кучу всяких разных КИ в ТЧ (программно), а потом открыть форму элемента Контрагента и охренеть от всей этой кучи..

(170) ыыыы.. так это, ЕРП на БСП)) добавить можно, сколько хочешь)) программно) и все это вывалится в форме партнера))

(172) Это будут разные виды КИ: Тел1, Тел2.
И такая петрушка будет у ВСЕХ партнеров. а мне нужно только у одного

(171) " я знаю что такое "трудозатраты", ибо это хлеб, которым  я питаюсь.." - ну тогда для тебя оптимальнее увеличить трудозатраты, а не уменьшить, раз у тебя от них оплата зависит. А когда оплата зависит от результата - то оптимальнее не изобретать велосипеды :))

(173) Нет. Вид КИ будет всего один. "Телефон". Ставишь галочку "разрешить ввод нескольких значений" в справочнике Виды КИ, и вперёд.

(174) мне оптимально уменьшить трудозатраты, так как я работаю на прибыль, а не зарплату..

(176) Ну тут надо ещё учитывать способность разобраться в типовом решении. Если она есть, то использование БСП снижает трудозатраты, если же её нет - то увеличивает. Поэтому я и говорил, что понятие "оптимально" в программирование зависит от множества факторов, но при этом вполне определённых.

+(177) Но опять же, всё зависит от конкретной задачи. Использование БСП тоже не всегда оправдано.

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

Опрос в тему.

Где правильно хранить КИ контрагентов?:
1. В голове
2. В записной книжке
3. На одноразовых листочках-записках
4. В телефоне (своем/корпоративном)
5. В компе (своем/корпоративном)
6. Нигде

(179) так, тебе и пытались сказать, что нет шаблонных "правильно и\или оптимально"...что нужно выбирать под требования...

(181) Я об этом ещё в (3) написал :)))

(182) а потом упорно пытался доказать, что "правильно" и "оптимально" можно определить однозначно..

(183) Зная конкретные требования - можно определить однозначно. А для сферической КИ в вакууме - нельзя. Внимательней читать надо.

+(184) Но, опять же, то, что будет оптимально для одного программиста, вовсе не обязательно будет таковым для другого, т.к. надо учитывать ещё и уровень знаний.

(185) т.е, все же, нельзя определить однозначно)).. и, почему рассматривается оптимальность\правильность только с точки зрения программиста?))

Поэтому чтобы не было споров КИ нужно хранить в отдельном веб-сервисе

А из 1С только юзать этот сервис

(187)  а отдельный веб-сервис  на чем реализовать? а если веб-сервис на 1С, то какой объект использовать?))

(186) "все же, нельзя определить однозначно" - Можно. Но с учётом ВСЕХ факторов.
"почему рассматривается оптимальность\правильность только с точки зрения программиста" - а потому что заказчика интересует только ожидаемый результат. А оптимален он или нет с точки зрения, где хранится КИ - его волнует меньше всего. Для него есть совсем другие критерии оптимальности.

(188) фишку не понали, там можно несколько моделей сделать и хранения и записи/получения данных

т.е. хотется вернет отдельно телефоны в массиве, а хочется просто 1 строкой все номера через запятую или основной номер

(189) почему-то хочется сказать "оставьте демагогию, КО".. ну, да ладно, не буду этого говорить))

Потому что обмен.

(191) А в чём демагогия? Тема про то, где лучше хранить КИ. Ответ прост: всё зависит от конкретной задачи. Универсального решения нет и быть не может. У каждого варианта есть свои плюсы и минусы, которые можно перетирать бесконечно.
Но как только заказчик начнёт мне, как разработчику, указывать, где я должен по его мнению хранить КИ - то будет послан, т.к. это тупо не его дело.

(193) опять прокол... заказчика нельзя посылать.. у заказчика можно только уточнять требования))

(194) " заказчика нельзя посылать" - почему это нельзя? Легко.

+(195) А в некоторых случаях даже необходимо :)

(195) (196) Послать заказчика с проектом на пару лямов только из-за контактной информации?...
Наверное, можно. Но, ИМХО, как-то глупо.
С заказчиком договариваться надо. И если заказчик выдвигает какие-то жесткие требования к способам хранения КИ, то логично было бы предположить, что эти требования чем-то обоснованы. Т.к. в 99% случаев заказчику глубоко фиолетово то, как именно ты это реализуешь.

(193) >> А в чём демагогия?

В том, что тема про то, где лучше хранить КИ, а ты разводишь демагогию на тему существования каких-то там сферических "правильных" или "неправильных" решений.
Тупо расскажи нам о своём видении плюсов и минусов тех решений, которые ты сам реализовывал (или встречал чужие).
Да, да, да - эта ветка о таких вот плюсах и минусах, которые можно перетирать бесконечно.

И хватит уже втирать тут всем о том какой ты там правильный.

(194) Вот скажи пожалуйста, как ты думаешь, если ты например стоматологу будешь указывать каким бором(или как там у них сверло называется) он должен твой зуб сверлить, что тебе ответят?

(198) вот скажи пожалуйста, причем тут стоматолог?..  и, почему тебя возмущает необходимость уточнения требований?

(197) Послать заказчика с указанием где хранить КИ <> отказаться от проекта. И насчет существования "правильных" решений - это не ко мне, а к ТС.
А решений я сам реализовывал и встречал чужих (как в типовых, так и в самописках) достаточно много. Но опять же, обсуждать плюсы и минусы конкретного решения без описания конкретной задачи - имхо глупо и бессмысленно, т.к. для одних задач одно и то же решение может быть неприемлемым, а для других - оптимальным. А вы продолжаете обсуждать сферические КИ в вакууме.

(198) некорректный пример.

>> что тебе ответят?

Если стоматолог, не дебил, то он для начала поинтересуется о причинах наличия конкретных требований к инструменту. И только в том случае, если он поймет, что мои требования ничем не обоснованы и простая блажь, он пошлёт меня в пешее эротическое или тупо обманет, сказав, что делает, как я прошу, а сам всё выполнит так, как правильно.

(200) Какой ты однако душный ))))
Нет конкретных задач. Представь на секундочку, что ты пишешь некое тиражное решение. И вести учет в нём будут очень и очень разные пользователи. Одним КИ вообще нафиг не нужна, а другим - наоборот - необходимо вести её во всех подробностях с кучей видов/типов и еще нужна история.

(199) Потому что аналогия: Заказчику нужна прежде всего удобная форма для ввода КИ, потом (уже опционально) ему нужно как-то её использовать - тупо выводить в списке, в печатные формы, осуществлять поиск по КИ и т.д. и т.п. А где при этом (в каком объекте конфигурации) она хранится, его абсолютно не должно волновать, если ты смог реализовать все его хотелки, которые тебе озвучили.

(203) биля... у тебя заказчиком может выступить ИТ компания, которая разрабатывает свое тиражное решение, где упор в твои бесценные знания БСП и или реализация КИ в ут 10.3 в хрен им не уперлась... и ясно тебе говорять "Хотим КИ в регистре", и дают структуру регистра. ТОЧКА... посылай их..

(203) В приведенном тобою примере в 99% случаев заказчик и не станет выдвигать конкретных требований к способу реализации.
Ты же собрался посылать заказчика, если он такие требования вдруг выдвинет. Хотя было бы логично поинтересоваться на чём эти его требования основаны - зачем ему надо именно так сделать, а не как-то по-другому.

(202) Я уже писал выше, что для тиражного решения, БСП подходит на мой взгляд лучше всего. Могу пояснить:
1. Максимум универсальности.
2. Удобство работы для программиста.
3. Удобное хранение данных, позволяющее осуществлять обмены с другими типовыми решениями).
Думаю, достаточно.

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

(204) Ты всё-таки не читатель. Попробуй перечесть (178).

(206) 1. по универсальности у меня уже отрыжка пошла.. в универсальных решениях нет необходимости в пределах одной записи дублировать данные. 2. оставлю без комментариев. 3. это ваще "удобное хранение" при получении объекта потащит за собой и ТЧ с адресами.. а как же тут быть с масштабируемостью и производительностью?.. а?

(199) Это просто аналогия. Меня ни разу не возмущает необходимость уточнения требований, но указания заказчика, каким инструментом я должен пользоваться, как минимум удивляют. Какая разница, как я сделаю, если результат будет отвечать его требованиям?

(205) Ты тоже не понял моего примера. И я не буду интересоваться, на чём основаны его требования к реализации. Я буду интересоваться тем, что ему в конечном итоге нужно от этой КИ (раз уж мы о ней). А там я уже сам приму решение, как мне это лучше сделать, причем моё решение вполне может и совпасть с пожеланиями заказчика. Но если я сочту это неоптимальным - то я попытаюсь объяснить заказчику, почему надо делать по-моему. И либо он согласится, либо нет. Но в обоих случаях он будет послан со своими указаниями по поводу реализации. У него могут быть лишь пожелания.

(211) ыыыыы.. смешной ты....  ээ, не, не смешной, категорично правильный - вот точное слово..

Когда мне попадаются кандидаты типа Fish, посылаю их нахрен, независимо от квалификации.
Потому что у них любое простейшее задание типа добавление реквизита в справочник разовьется в полноценный проект часов на 200 с вероятностью успеха 50%, типа либо будет либо нет.

(212) Да звездобол он.

Извини Fish.
Но я никогда не поверю, что из-за такого пустяка, ты пошлешь заказчика. Если заказчик скажет, что хочет именно так и именно таковы его требования, то ты либо сделаешь, как он скажет, либо сам будешь послан с разрывом контракта.

К чему все эти понты...

(213) ты программистов допускаешь к самостоятельному общению с заказчиком??

(215) Да, а что?
Но вообще речь не про это, а про то, что если я человеку скажу добавь реквизит X в справочник Y, а он мне начнет уточнять миллион деталей и требовать ТЗ, то будет послан незамедлительно.
Потому что это тогда уровень стажера, причем крайне тупого, который не только не приносит пользу, но еще и вяжет по рукам и ногам, то есть вредит.

(216) да, как то это неправильно)) чистые программисты в 100% случаев начинают втирать заказчику что есть правильно в этой жизни, и почему он (заказчик) не прав))

(217) А я не беру на работу чистых программистов.
У меня сейчас даже стажеры проходят школу общения с клиентом и как сделать задачу под ключ, а не сделал что попало и взятки гладки.
А иначе неизбежно начинается поведение типа как у Fish и приходится вправлять мозги, а оно мне нужно?

Ну вот и стало понятно, откуда берутся тупые вопросы вроде (0)...

(216) Для добавления реквизита X в справочник Y нужно кого-то нанимать? Или это просто такой неудачный пример?

(220) Ради одной задачи не стоит конечно.
Но задача-то не одна.