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

(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) Ради одной задачи не стоит конечно.
Но задача-то не одна.