Имя: Пароль:
1C
 
Где правильнее хранить контактную информацию контрагентов?
0 PR третий
 
10.03.16
11:58
1. Свое мнение 53% (8)
2. В регистре сведений 33% (5)
3. В табличной части 13% (2)
4. В подчиненном справочнике 0% (0)
5. В характеристиках плана видов характеристик 0% (0)
Всего мнений: 15

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

В регистре сведений
2 Московский
 
10.03.16
11:59
рс

В регистре сведений
3 Fish
 
10.03.16
12:00
Вопрос имхо на редкость глуп. Правильнее хранить там, где это будет работать.

Свое мнение
4 PR третий
 
10.03.16
12:01
(3) Ты традиционно в своем репертуаре. Спасибо за твой абсолютно бесполезный комментарий.
5 PR третий
 
10.03.16
12:02
(1) Чем правильнее? Так же неудобнее докручивать форму?
6 shuhard
 
10.03.16
12:02
(0) опять этот недоучка Печенкин с тупейшими топиками

Свое мнение
7 франц
 
10.03.16
12:03
по 10.3 - привычнее... особенно после того, как намаялся с ними в ТЧ справочника..

В регистре сведений
9 Fish
 
10.03.16
12:03
(4) Да пожалуйста. Всегда рад дать правильный ответ.
10 франц
 
10.03.16
12:05
(7) +особенно, после того, как намаялся с ними в ТЧ справочника в УТ 11..
11 Dmitrii
 
гуру
10.03.16
12:05
(3) Самое удивительное, что оно везде работает.
В типовых от 1С КИ работала и в регистрах сведений и в табличной части справочников.
ИМХО, твой ответ не сильно умнее вопроса...
12 Jonny_Khomich
 
10.03.16
12:07
Адрес не постоянный, надо иметь историю изменения значений, допустим для печать документов за прошлый период.
В РС есть возможность среза, упрощая доступ к данным.

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

Свое мнение
13 Карупян
 
10.03.16
12:07
в чем суть переноса КИ в справочник?
разделение прав доступа
14 GenaCh
 
10.03.16
12:07
В (0) не выставлен критерий правильности, тема перерастет в ... :)
15 Fish
 
10.03.16
12:08
(11) Так я это и имел ввиду. Сама постановка "где правильнее" - на редкость глупа. Там, где программист реализовал, там и правильнее (если конечно всё работает, как положено).
16 Jonny_Khomich
 
10.03.16
12:08
(11) в табличной части не круто хранить. При получении объекта ты получишь ещё кучу ненужных данных(картинки, адреса, ответственные менеджеры).
17 франц
 
10.03.16
12:09
(11) "и в табличной части справочников".. смотрел как работает в табличной части справочников в ут 11?.. и их невероятно тупую реализацию с хранением как реквизитов КИ, так и их хмл представления?.
18 HeKrendel
 
10.03.16
12:12
Контактная информация контрагента делится на 2 вида
Инфа о компании- она статична,  история по ней не нужна- справочник
Инфа о ЛПР- она уже меняется и отслеживать измнеения важно. с точки зрения СРМ, это регистр
19 HeKrendel
 
10.03.16
12:12
В общем- как обычно, кг/ам

Свое мнение
20 mTema32
 
10.03.16
12:13
(12) Ну проблема как бы решаема. Хранить историю изменений адресов в РС.
21 Jonny_Khomich
 
10.03.16
12:16
(20) Зачем создавать справочник со значениями и хранить историю в регистре? Есть какой-нибудь прирост скорости или уменьшение объема базы?
22 mTema32
 
10.03.16
12:18
(21) Я имею в виду хранить в ТЧ справочника, а не новый создавать. (Как в УТ 11 сделано)
23 Timon1405
 
10.03.16
12:19
(18) оО и какая же контактная информация статична? фирма не может сменить адрес/телефон/почту?
24 Dmitrii
 
гуру
10.03.16
12:20
Смешные вы какие...

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

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

Свое мнение
25 mTema32
 
10.03.16
12:21
(24)"правильнее использовать подсистему КИ из БСП"
Да, я так и сделал в своей, которая на основе БСП.
26 Jonny_Khomich
 
10.03.16
12:23
Я до адресов в УТ 11 не доходил. БСП не изучал.
Какой практический выхлоп от этого?
27 Dmitrii
 
гуру
10.03.16
12:27
(26) >> Какой практический выхлоп от этого?

Во-первых, всё придумано, написано и украдено до вас. Не надо изобретать своих велосипедов с квадратными колесами. В самописку интеграция подсистемы КИ делается гораздо быстрее, чем вы сами напишете с нуля.
Во-вторых, если предполагается какая-либо интеграция (обмен данными) с любыми типовыми конфигурациями от 1С (которые сейчас все включают в себя БСП), то не надо будет изобретать свои безумные алгоритмы по конвертации КИ из ваших таблиц в 1С-овские (или наоборот).
28 Jonny_Khomich
 
10.03.16
12:29
(27) да я понял что 1с делает правильно в своей БПС. Везде должна быть стандартизация. Но почему выбрали этот стандарт?
29 PR третий
 
10.03.16
12:29
(12) Дельная мысль.
Тогда почему в типовых в табличной части?
30 mTema32
 
10.03.16
12:34
(29) ХЗ, может из-за форм?
31 Alexor
 
10.03.16
12:37
Адресов или телефонов может быть несколько.

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

В регистре сведений
32 Dmitrii
 
гуру
10.03.16
12:39
(28) >> Но почему выбрали этот стандарт?

Ответ от 1С:
Что бы права доступа на контактную информацию совпадали с правами доступа на сам объект. То есть контактная информация - неотъемлемая часть самого объекта...
33 Локи-13
 
10.03.16
12:39
(31) есть права на просмотр и редактирование отдельных реквизитов
34 PR третий
 
10.03.16
12:40
(31) Тоже неплохо.
Но в таком случае так можно всего контрагента расчленить на всякие ИНН, телефоны, адреса и прочие поля, которые кто-то может заполнять, а кто-то нет.
И потом, сложно объяснить пользователю, что поменял что-то в контактной информации в контрагенте, а потом нажал отмену не означает, что ты отменил изменения в контактной информации.
35 PR третий
 
10.03.16
12:41
(32) Соглашусь с 1С в этом вопросе, не стоит все детализировать до атомов.
36 Dmitrii
 
гуру
10.03.16
12:43
(31) >> У Пользователя может быть запрет на изменение контрагента, но должен быть доступ на изменение контактной информации

Крайне редкий случай. Особенно если внимательно вдуматься в постановку задачи.
В 99% случаев при ведении учета таким образом возникают требования, что этот пользователь с такими странными правами, мог и еще пару реквизитиков править. И это становится головняком для разработчика.
37 ObjectRelation Model
 
10.03.16
12:45
(34) в типовой УТ 10.3 набор записей записывается только вместе с контрагентом (если из формы редактирование)
38 Jonny_Khomich
 
10.03.16
12:46
(32) на работе у меня есть права на просмотр данных клиентов, но нет доступа к КИ. Наша СБ не согласна с 1с.
39 Alexor
 
10.03.16
12:49
(36) У меня в паре организаций как раз так используется.
Реквизиты контрагента менять запрещено.
А контактную информацию пользователи заносят.
40 mTema32
 
10.03.16
12:52
(36)"Крайне редкий случай."
Не знаю, не знаю. В прошлой конторе было три роли пользователей и директор хотел чтоб у каждой роли были свои права на доступ(чтение и запись) к данным контрагента. И более того свои удобные формы для редактирования/ввода этих данных.
Вот тогда я помню намучался с этим РС Контактная информация в УТ 10-ой.
41 Dmitrii
 
гуру
10.03.16
12:52
(38) >> Наша СБ не согласна с 1с

Вполне допускаю. 1С далеко не идеальна.
Но ваш случай всё таки скорее редкость. И встречается, как правило, только в базах где ведётся CRM, и контактная информация действительно может быть более ценной, чем просто информация о контрагентах. Но в таких базах и голой БСП-ной подсистемы КИ тоже будет мало. А в 99% случаев КИ всё таки вторична и не так ценна как база контрагентов (имея базу контрагентов, найти нужную КИ проще).
42 Dmitrii
 
гуру
10.03.16
12:55
(40) Я же не сказал, что это вообще невозможный случай.
Конечно же где-то такое наверняка требуется и это требование обосновано. Я высказывался о своём личном опыте, который говорит мне о том, что обоснованным такие требования можно назвать крайне редко.
43 Лефмихалыч
 
10.03.16
12:57
Это бы зависело от имеющихся на руках требований к хранению контактной информации.

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

Свое мнение
44 PR третий
 
10.03.16
13:07
(37) И че? На контрагента-то прав нет.
45 PR третий
 
10.03.16
13:12
(43) К чему эти общефилософские ответы, не несущие никакой практической пользы?
Типа "Делать нужно так, как правильно", "Использовать нужно то, что в ТЗ", "Единственно верного ответа не существует"... и т. д.
Даже в этой ветке уже накидали несколько вещей, влияющих на выбор и только у тебя с Fish абсолютно невозможно ничего сказать по поводу выбора варианта без полного досконального поставленного кем-то ТЗ, в котором, видимо, просто тупо будет написано, что именно использовать.
46 Лефмихалыч
 
10.03.16
13:14
(45) к тому же, к чему и твои общефилософские вопросы. Правильного ответа на вопрос: "где хранить контактную информацию" не существует.
Эти варианты без конкретных требований не стоят букв, из которых состоят. Потому, что требования в каждом конкретном случае могут быть такими, что все эти варианты - просто красивая теория, которая на практике ни кому не впёрлась.
47 PR третий
 
10.03.16
13:14
Могу сказать, что мой ответ в табличной части.
В силу накопленного опыта и всех известных за и против.
И да, конечно же, если мне сказали бы, например, что нужно в документе хранить телефон, по которому звонили контрагенту, то, конечно же, я бы выбрал подчиненный справочник.

В табличной части
48 Fish
 
10.03.16
13:16
(43) Имхо, никогда. Для того, чтобы это понять, нужно быть хотя бы немного программистом.
49 Лефмихалыч
 
10.03.16
13:20
(48) та не, он как раз на 100% кодер - думает о том КАК сделать, вместо ЧТО и ЗАЧЕМ. Потому, что КАК - ему ближе, а для ЧТО и ЗАЧЕМ надо думать и заказчика допрашивать до тех пор, пока из него смысл не польется.
50 PR третий
 
10.03.16
13:22
(46) Да вся МиСта — это общефилософские вопросы, когда что-то известно, что-то нет.
И почему-то на вопрос "А че у меня программа говорит, что номер документа не уникален?" никто из адекватных товарищей не начинает уточнять молекулярное окружение автора, а сразу пишет, что сто к одному, что нумерация сбилась.
51 PR третий
 
10.03.16
13:23
(49) Как я знаю уже 15 лет. И что знаю. И зачем. Мне просто интересно, что думают другие.
52 PR третий
 
10.03.16
13:24
(49) Ты не знаешь, зачем общестатистическому заказчику, которых 99%, контактная информация?
53 Dotoshin
 
10.03.16
13:29
(52) Открой секрет - зачем?
54 Fish
 
10.03.16
13:30
(49) Не соглашусь. Опытный программист, зная ЧТО и ЗАЧЕМ, выбирает "КАК сделать" оптимальное решение из различных вариантов. А недопрограммист (или просто кодер) будет искать ответ на вопрос "как ПРАВИЛЬНО сделать", без привязки к ситуации, и потом уже будет лепить это своё "правильно" где нужно, и где не нужно, только потому, что так "правильно".
55 Лефмихалыч
 
10.03.16
13:32
(54) а я разве не это же самое сказал?
56 Мэс33
 
10.03.16
13:32
(54) (49) красивый русский язык ).
57 Dotoshin
 
10.03.16
13:33
(54) Оптимально <> Правильно?
58 франц
 
10.03.16
13:33
убег за попкорном. кому еще взять?
59 Мэс33
 
10.03.16
13:33
(58) мне сладкий. Не цветной.
60 Fish
 
10.03.16
13:36
(57) Нет. Решение может быть правильным, но не оптимальным.
61 Лефмихалыч
 
10.03.16
13:37
(57) define: оптимально
62 Лефмихалыч
 
10.03.16
13:38
пля, да у терминов "правильно" и "оптимально" нет точного определения, о чем вы спорите?
63 Fish
 
10.03.16
13:39
(62) Блин. Первая ссылка в яндексе на слово "правильно", ввела в шок :))
64 PR третий
 
10.03.16
13:40
(62) Во, правильно, убирайте с Fish термины "правильно" и "оптимально" из лексикона, у них же нет точного определения :))
65 франц
 
10.03.16
13:42
(63) оо.. в яндекс браузере онное идет второй строкой, а вот  IE - первой))
66 Fish
 
10.03.16
13:43
(64) А я не согласен, что у этих терминов в программировании нет точного определения.
67 Dotoshin
 
10.03.16
13:44
Думаю в регистре будет все же удобней хранить (не буду спорить на счет правильности или оптимальности), например потому, что в регистре можно хранить КИ для разных объектов, вот в УПП например тип измерения ОБъект в РС КИ: СправочникСсылка.КонтактныеЛица, СправочникСсылка.ФизическиеЛица, СправочникСсылка.Пользователи, СправочникСсылка.КонтактныеЛицаКонтрагентов, СправочникСсылка.Контрагенты, СправочникСсылка.Организации, СправочникСсылка.ЛичныеКонтакты

В регистре сведений
68 PR третий
 
10.03.16
13:44
(66) Пообщайся с Лефмихалычем, мне пофиг на эту хрень.
69 Лефмихалыч
 
10.03.16
13:47
(66) ну, ты можешь быть не согласен - у нас свободная страна, но определение от этого не появится.
70 Fish
 
10.03.16
13:48
(69) Оно есть.
71 Лефмихалыч
 
10.03.16
13:48
(70) и ты даже можешь его привести?
72 франц
 
10.03.16
13:49
(66) Где правильнее хранить контактную информацию контрагентов?
73 Fish
 
10.03.16
13:49
(71) Выбирай, какое нравится: http://moyslovar.ru/slovari/vse/slovo/правильный
74 Fish
 
10.03.16
13:50
(72) См (3).
75 франц
 
10.03.16
13:52
(74) перечитал 66 потом 3..
76 Dotoshin
 
10.03.16
13:52
+(67) Кроме этого у РС ключ - это комбинация измерений, а у справочника только ссылка, то есть элемент справочника можно связать только с одной записью, а запись регистра с несколькими.
77 Лефмихалыч
 
10.03.16
13:53
(73) эти определения опираются на правила и нормы. Только вот в программировании нет ни правил, ни норм, на которые можно было бы опираться для построения правильной архитектуры. Та же петрушка и со словом "оптимально"
78 hhhh
 
10.03.16
13:53
(72) ну, в табличной части конечно. Там ухже и история есть. А в регистре еще и историю надо самому приделывать.
79 NcSteel
 
10.03.16
13:55
(78) Лучше в блокноте.
80 Лефмихалыч
 
10.03.16
13:56
(79) в двух. Чтобы бэкап был. Иначе не надежно
81 франц
 
10.03.16
13:57
(78) а если у тебя нет бсп??
82 NcSteel
 
10.03.16
13:58
(80) Зеркалирование через копирку.
83 Fish
 
10.03.16
13:59
(77) В программировании проще: правильное решение - это решение, которое даёт результат, ожидаемый заказчиком.
А вот оптимальное решение уже должно помимо правильности, удовлетворять и другим критериям, которые зависят от множества факторов, но в каждом конкретном случае, они, тем не менее, вполне определённые.
84 Dotoshin
 
10.03.16
14:00
(80) и каждый положить в отдельный сейф, желательно в разных помещениях :)
85 Лефмихалыч
 
10.03.16
14:07
(83) "решение, которое даёт результат, ожидаемый заказчиком" - это решение, соответствующее ТЗ. К правильности не имеет отношения. У "оптимально" нет конкретного определения, так же, как и у "правильно", в контексте разработки ПО.
В контексте, например, строительства, определения есть, т.к. там и правила и законы известны. А в разработке ПО полная анархия, т.к. этому виду человеческой деятельности даже ста лет нет - мы просто еще не набили шишек достаточно, чтобы выявить эти законы и правила. По этому в разработке не бывает ни абсолютно правильных, ни абсолютно оптимальных решений.
86 Rie
 
10.03.16
14:09
(0) А это смотря для каких целей её хранить (если вообще её надо хранить).
Без конкретной задачи вопрос несколько бессмысленен.
Кстати, отсутствует вариант - в реквизите (в реквизитах).

Свое мнение
87 HeKrendel
 
10.03.16
14:10
(23) Эта информация никак не влияет, да и не нужно это отслеживать, а вот изменение  ЛПР места работы достаточно сильно может сказаться на заказах
88 Dmitrii
 
гуру
10.03.16
14:10
ОФФ. Только программисты так умеют - раздуть из простого и понятного вопроса сложный неразрешимый филосовский спор.
Один в (3) пукнул в лужу и понеслось вынюхивание всех тонкостей аромата.

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

А вся остальная филосовская лирика, которую тут развели  Fish и Лефмихалыч , какой-то бред, который присущ какому-нибудь желторотому программисту, который искренне верит в существование единственно верных и правильных решений, а не взрослым и опытным мастодонтам 1С.
89 франц
 
10.03.16
14:12
(88) это залп главным калибром..
90 Fish
 
10.03.16
14:13
(85) Открою тебе секрет: в ЛЮБОМ языке программирования, есть и свои правила и нормы, и никакой "анархии" :)
91 Dmitrii
 
гуру
10.03.16
14:14
(86)>> Без конкретной задачи

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

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

Вот в типовых для каких целей предусмотрено хранение КИ?
Представьте, что вы пишите тиражное решение, которое будут использовать очень разные клиенты. И кому-то из них КИ нафиг не впёрлась, а кто-то её тщательно фиксирует.
92 Лефмихалыч
 
10.03.16
14:15
(90) ты живешь во лжи
93 Rie
 
10.03.16
14:15
(88) И регистр сведений, и табличная часть, и подчинённый справочник - это всего лишь другая таблица с внешним ключом.
Так что с точки зрения программирования - тут дело вкуса (и решаемой задачи).
Можно хранить в той же таблице - если контактной информации много не требуется.
94 PR третий
 
10.03.16
14:16
(86) Там еще много каких вариантов отсутствует.
Например, в текстовом файле на диске или в интернете.
Потому что это уже варианты для дебилов, у которых в жизни никогда нет ничего определенного и всегда возможно все, пока кто-то за них не примет решение, как сделать и не напишет это в ТЗ.
95 Fish
 
10.03.16
14:16
(92) Нет, я целых 5 лет изучал эти правила и нормы в университете :))
96 Лефмихалыч
 
10.03.16
14:17
(88) феерическая расстановка точек
97 PR третий
 
10.03.16
14:17
(88) + 100500
Только по поводу поделитесь, не поделитесь, а скорее мне просто интересны мысли других.
То есть не практической цели ради.
98 Rie
 
10.03.16
14:17
(91) Потому 1С и дала возможность программирования, что "универсального решения" нет. УТ, БП, ЗУП - все типовые. Но разные.
99 Dotoshin
 
10.03.16
14:19
(95) На самом деле эти правила и нормы называются синтаксис и алгоритмы.
100 Rie
 
10.03.16
14:20
(94) "В интернете", "во внешнем наборе данных" - варианты для дебилов? То есть, интегрированные системы не рассматриваются в принципе?
Мне вот как раз вариант с внешним набором данных - очень симпатичен. Для вполне конкретной задачи.
101 Fish
 
10.03.16
14:20
(99) От этого они не перестают быть правилами и нормами, которые, в том числе, и определяют оптимальное решение для каждого конкретного языка.
102 Лефмихалыч
 
10.03.16
14:21
(99) ага, давай, расскажи, каким синтаксисом и алгоритмами надо руководствоваться, чтобы найти правильный способ хранения контактной информации.
103 Лефмихалыч
 
10.03.16
14:21
рукалицо
104 Dmitrii
 
гуру
10.03.16
14:21
(98) Ну сейчас 1С во все типовые интегрирует БСП.
А в БСП вполне конкретное и четкое решение. Табличные части и никаких РС.
105 PR третий
 
10.03.16
14:22
(93) Ну да конечно :))
Попробуй-ка сделай ключ для записи регистра сведений средствами 1С.
Или попробуй сделай редактирование данных, не хранящихся в самом объекте, вместе с объектом.
Или в отчете выбери что-то через точку, когда это не реквизит объекта.

Вот, кстати, почему никто не выбрал четвертый вариант?
Это второй по привлекательности убыванию вариант, который выбрал бы я :))
А всего-лишь потому, что в СКД можно выбирать поля через точку. Сразу. Без допиливания.
106 Dotoshin
 
10.03.16
14:23
(102) Никакими. Нужно руководствоваться здравым смыслом.
107 PR третий
 
10.03.16
14:24
(100) Для типовых конфигураций?
108 Fish
 
10.03.16
14:24
(102) "каким синтаксисом и алгоритмами надо руководствоваться" -  В рассматриваемой теме, естественно, это будет синтаксис, алгоритмы и объекты языка 1С. И никакой анархии.
109 Лефмихалыч
 
10.03.16
14:24
(106) а здравый смысл - это такая штука, которая во всех случаях одинаковая или он от контекста зависит?
110 Rie
 
10.03.16
14:24
(104) Не во все. Только в российские.
Но для российских - имеет смысл как раз использовать БСП и не мучиться с выдумыванием собственных способов хранения КИ, если это не требуется по каким-то другим причинам.
111 Dmitrii
 
гуру
10.03.16
14:25
(105) >> почему никто не выбрал четвертый вариант?

Подсистема КИ в БСП описывает подключение к характеристикам данных о КИ из ТЧ.
Мне лично не совсем понятно для чего ты это выделил в отдельный пукт.
112 PR третий
 
10.03.16
14:25
(109) Конечно, зависит.
Плюхнуться мордой в грязь под начавшимся перекрестным обстрелом — это норм.
То же самое на асфальте в Москве — не очень.
113 Dotoshin
 
10.03.16
14:25
(109) Он не может зависеть от контекста, он либо есть, либо его нет:)
114 Лефмихалыч
 
10.03.16
14:26
(108) ну, так перечисли конкретно, чем именно надо руководствоваться в данном случае? Что именно в синтаксисе языка 1С содержит основание для выбора правильного решения? Какие именно волшебные алгоритмы содержат такие основания?
115 Rie
 
10.03.16
14:27
(105) А есть необходимость это всё пробовать?
Либо, как было очень верно замечено, используешь типовое решение - БСП. Либо речь идёт о специфической задаче - тогда какой именно задаче?
116 Лефмихалыч
 
10.03.16
14:27
(112) как видишь, у некоторых здравый смысл зашит в ПЗУ (113)
117 франц
 
10.03.16
14:27
тьфу на реализацию КИ в ТЧ.. особенное на реквизит "ЗначенияПолей".
118 франц
 
10.03.16
14:27
(117) + на так называемое "типовое с использованием БСП"..
119 Fish
 
10.03.16
14:29
(114) Ты опять имхо перепутал понятия: синтаксис и алгоритмы нужны для того, чтобы реализовать правильное решение. А вот для оптимального, помимо синтаксиса, нужно ещё много чего учесть. Например, для файлового и серверного варианта оптимальные решения будут разными даже на одной платформе 1С.
121 Dotoshin
 
10.03.16
14:30
(116) Да уж лучше в ПЗУ, чем вообще без него :)
122 PR третий
 
10.03.16
14:31
(111) А, точно, характеристики же можно натравить на ТЧ.
123 Fish
 
10.03.16
14:31
(117) А что в нём не нравится конкретно?
124 Лефмихалыч
 
10.03.16
14:32
Слив засчитал, господа. Фиш и Дотошин.

Мой постулат: "правильного решения нет и быть не может, т.к нет правил, которым должно соответствовать решение, чтобы быть правильным"
Ваш ответ: "правила есть - это синтаксис и алгоритмы"
Дальше я спросил: "что в синтаксисе и какие алгоритмы дают правильный ответ на сабж"
Я уточнил: "что именно в ситаксисе 1С и какие алгоритмы дают основания для правильного ответа"
В результате потекла бадяга про здравый смысл и оказалось, что это Я что-то там путаю, хотя сами понятия синтаксиса и алгоритмов в дискуссию ввели вы.
125 франц
 
10.03.16
14:33
(123) а ты конкретно видел эту структуру?
130 PR третий
 
10.03.16
14:38
(129) Все Чебоксары из-за тебя забанят :))
131 Dotoshin
 
10.03.16
14:38
(124) Куда то вас не в ту сторону несет уважаемый Лефмихалыч. Где я говорил, что есть правила, на основании которых можно принять решение о способе хранения КИ?
132 PR третий
 
10.03.16
14:39
Странно, вроде в (0) простой вопрос с простыми известными критериями и даже назначение озвучено.
Ан нет, опять понеслось переливание из пустого в порожнее :))
133 Лефмихалыч
 
10.03.16
14:40
(131) см (99). Ну, или ты ляпнул, не прочитав ветку выше 95-го поста.
134 Лефмихалыч
 
10.03.16
14:42
(132) вопрос про типовые бессмысленный, т.к. для типовых есть решение от вендора - БСП. Для не типовых все зависит от требований, являющихся основанием для разработки этих типовых и общего какого-то решения нет и быть не может.
135 франц
 
10.03.16
14:43
(132) в (0) не простой вопрос.. там есть вариант как "типовые".. так и "а свою конфу"... для своей конфы использовать типовой БСП с ТЧ - дурь и блажь..
для "своей конфы" - выбирать на основании задачи: если конкретный проект, то делать под требования ТЗ; если создание аналога БСП для работы с КИ - то уже анализ и синтез...
136 PR третий
 
10.03.16
14:44
(134) Ты как Apple.
Все телефоны, кроме Iphone бессмысленны, потому что есть Iphone.
Да, да, пожалуйста, только успокойтесь, нет телефонов кроме Iphone, все остальное бессмысленно :))
137 PR третий
 
10.03.16
14:45
(135) Да ты че :))
Я вот в Почте России биллинг на БСП писал и не считаю, что надо было с нуля заколбасить.
138 Лефмихалыч
 
10.03.16
14:45
(136) бред. Такого я не говорил вообще и из моего поста это не следует. Перечитай.
139 франц
 
10.03.16
14:49
(138) да, он, похоже, видит только то, что хочет видеть)) давай лучше попкорном поделюсь)) (137) и ты за ради КИ потащил БСП? или лукавишь, и у тебя помимо КИ были и другие требования?.. и, что можешь сказать за реквизит "ЗначенияПолей", если на то пошло...
140 PR третий
 
10.03.16
14:56
(139) Конечно не только за ради КИ.
Про ЗначенияПолей ничего не могу сказать, не думал на эту тему. А что там?
141 Fish
 
10.03.16
15:00
(125) Мало того, что видел, но и работаю с ней.
142 франц
 
10.03.16
15:02
(140) если не за ради КИ, то выбор БСП понятен. Но, в этом случае говорить про выбор ТЧ для КИ как бы моветон. Потому как, ты как истинный поклонник Эппла ещь то, что дают)).. про ЗначениеПолей - дублирование данных.... (141) тебя, как любителя правильности и оптимальности, не раздражает дублирование информаации?
143 Fish
 
10.03.16
15:03
(142) Меня - нет, т.к. при доработке типовых оптимальнее использовать существующее решение, чем перелопачивать половину конфигурации :)
144 Fish
 
10.03.16
15:04
(142) Ну по поводу "дублирования" данных. А ты так и не понял, для чего это дублирование сделано? Как раз для оптимальности :)
145 PR третий
 
10.03.16
15:05
(142) >>Но, в этом случае говорить про выбор ТЧ для КИ как бы моветон.
Так а какое отношение сабж имеет к БСП в Почте России?

>>про ЗначениеПолей - дублирование данных....
И че? В 1С дохрена мест, где идет избыточность и дублирование данных и это нормально и правильно.
146 Ranger_83
 
10.03.16
15:08
В отдельной базе можно.
Обращаться к нужной инфе только при необходимости.

Свое мнение
147 PR третий
 
10.03.16
15:09
(146) Я считаю, вообще не хранить, а оформлять по необходимости запрос в паспортный стол.
148 франц
 
10.03.16
15:12
(143) тут вообще-то не про типовые.. как бы)) (144) а вот первое мое желание, когда увидел эту "оптимизацию" было выдернуть руки оптимизатору... а из словесного потока здесь пройдет только "дебилы".. (145) ты уж определись: если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов"; если про выбор объекта 1С при создании своей конфы - то, выбирать (правила выбора я описал выше)..
149 PR третий
 
10.03.16
15:15
(148) >>если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов"
Я же написал в (0) "А где бы _вы_ хранили, если бы писали типовые?".
150 франц
 
10.03.16
15:16
(149) ты уж потрудись перечитать свое 0. если трудно, то приведу цитату из 0 "а свою конфу".. которую я тебе уже приводил в (135)
151 Ranger_83
 
10.03.16
15:17
(147)в паспортном столе не вся инфа.А вот  сервис от 1С по ИНН доставляет
152 PR третий
 
10.03.16
15:18
(150) Я говорю конкретно про "если говорим за типовую, то "едим то, что есть, и 1С-у виднее, чем кормить адептов";".
153 франц
 
10.03.16
15:21
(152) ты уже конкретно сам не понимаешь, что говоришь. По крайней мере, меня запутал, что в итоге ты хочешь сказать.
154 Fish
 
10.03.16
15:26
(148) А если не типовые, то опять же, зачастую оптимальнее строить свою конфу на основе БСП, поэтому вопрос о том, где лучше хранить КИ, отпадает сам собой. Всё зависит от конкретной задачи.
155 Карупян
 
10.03.16
15:27
Есть еще 3 вариант. В реквизитах справочника, как в 77
156 Карупян
 
10.03.16
15:28
Обычно куча КИ не нужна, все равно ее в запросах просто так не вытянешь. Ибо где-то нужно предопределенные виды ки хранить
157 франц
 
10.03.16
15:28
(154) эээ... астав да...  БСП, ровно как и типовая - это то, что дали, и нужно кушать "как есть" и без обсуждений типа "правильно, оптимально"..
158 Карупян
 
10.03.16
15:29
(157) Ты одноэсник или кто?
159 PR третий
 
10.03.16
15:29
(156) >>Обычно куча КИ не нужна
Посмеялся :))
160 франц
 
10.03.16
15:29
(158) эээээ... к чему вопрос?..
161 Карупян
 
10.03.16
15:33
(159) Как ты несколько телефонов введешь, что с ТЧ, что с Регистром?
Будешь плодить Виды КИ: Тел1, Тел2
162 Карупян
 
10.03.16
15:33
В бухе так вообще нет "других" видов КИ
163 PR третий
 
10.03.16
15:34
(161) Вот именно.
А в случае реквизитов просто тупо никак. Адын телефон. И все.
164 Fish
 
10.03.16
15:34
(157) Ты всё-таки не понимаешь термин "оптимально". А он, помимо прочего, включает в себя ещё и трудозатраты на разработку, которые БСП позволяет существенно сократить. Ты же не пишешь новую ОС для каждого отдельного заказчика?
165 Fish
 
10.03.16
15:35
(161) " Как ты несколько телефонов введешь, что с ТЧ" - посмотри, как это в БСП реализовано.
166 Карупян
 
10.03.16
15:35
(163) Оба варианта неюзабельны для такого сценария
167 Карупян
 
10.03.16
15:35
(165) Нет под рукой. Расскажи как
168 Fish
 
10.03.16
15:37
(167) Для каждого вида КИ (телефон) можно сколько хочешь телефонов завести.
169 Карупян
 
10.03.16
15:38
(168) А какой будет основной для печати?
170 Карупян
 
10.03.16
15:39
В ЕРП 2 нельзя ввести несколько телефонов для партнера
171 франц
 
10.03.16
15:42
(164) ой, все....молись дальше на 1С... зы. да будет тебе известно, что я знаю что такое "трудозатраты", ибо это хлеб, которым  я питаюсь.. (167) через анальное отверстие, как еще.. например, в ут 11 можно накропать кучу всяких разных КИ в ТЧ (программно), а потом открыть форму элемента Контрагента и охренеть от всей этой кучи..
172 франц
 
10.03.16
15:43
(170) ыыыы.. так это, ЕРП на БСП)) добавить можно, сколько хочешь)) программно) и все это вывалится в форме партнера))
173 Карупян
 
10.03.16
15:47
(172) Это будут разные виды КИ: Тел1, Тел2.
И такая петрушка будет у ВСЕХ партнеров. а мне нужно только у одного
174 Fish
 
10.03.16
15:47
(171) " я знаю что такое "трудозатраты", ибо это хлеб, которым  я питаюсь.." - ну тогда для тебя оптимальнее увеличить трудозатраты, а не уменьшить, раз у тебя от них оплата зависит. А когда оплата зависит от результата - то оптимальнее не изобретать велосипеды :))
175 Fish
 
10.03.16
15:50
(173) Нет. Вид КИ будет всего один. "Телефон". Ставишь галочку "разрешить ввод нескольких значений" в справочнике Виды КИ, и вперёд.
176 франц
 
10.03.16
15:51
(174) мне оптимально уменьшить трудозатраты, так как я работаю на прибыль, а не зарплату..
177 Fish
 
10.03.16
15:53
(176) Ну тут надо ещё учитывать способность разобраться в типовом решении. Если она есть, то использование БСП снижает трудозатраты, если же её нет - то увеличивает. Поэтому я и говорил, что понятие "оптимально" в программирование зависит от множества факторов, но при этом вполне определённых.
178 Fish
 
10.03.16
15:54
+(177) Но опять же, всё зависит от конкретной задачи. Использование БСП тоже не всегда оправдано.
179 Fish
 
10.03.16
15:56
+(178) Но на то, собственно и программист (если он действительно программист, а не кодер) - чтобы смочь оценить все факторы, и выбрать оптимальный вариант решения, а не следовать какому-то одному шаблону.
180 Garykom
 
гуру
10.03.16
16:00
Опрос в тему.

Где правильно хранить КИ контрагентов?:
1. В голове
2. В записной книжке
3. На одноразовых листочках-записках
4. В телефоне (своем/корпоративном)
5. В компе (своем/корпоративном)
6. Нигде
181 франц
 
10.03.16
16:02
(179) так, тебе и пытались сказать, что нет шаблонных "правильно и\или оптимально"...что нужно выбирать под требования...
182 Fish
 
10.03.16
16:03
(181) Я об этом ещё в (3) написал :)))
183 франц
 
10.03.16
16:04
(182) а потом упорно пытался доказать, что "правильно" и "оптимально" можно определить однозначно..
184 Fish
 
10.03.16
16:05
(183) Зная конкретные требования - можно определить однозначно. А для сферической КИ в вакууме - нельзя. Внимательней читать надо.
185 Fish
 
10.03.16
16:07
+(184) Но, опять же, то, что будет оптимально для одного программиста, вовсе не обязательно будет таковым для другого, т.к. надо учитывать ещё и уровень знаний.
186 франц
 
10.03.16
16:08
(185) т.е, все же, нельзя определить однозначно)).. и, почему рассматривается оптимальность\правильность только с точки зрения программиста?))
187 Garykom
 
гуру
10.03.16
16:08
Поэтому чтобы не было споров КИ нужно хранить в отдельном веб-сервисе

А из 1С только юзать этот сервис
188 франц
 
10.03.16
16:10
(187)  а отдельный веб-сервис  на чем реализовать? а если веб-сервис на 1С, то какой объект использовать?))
189 Fish
 
10.03.16
16:11
(186) "все же, нельзя определить однозначно" - Можно. Но с учётом ВСЕХ факторов.
"почему рассматривается оптимальность\правильность только с точки зрения программиста" - а потому что заказчика интересует только ожидаемый результат. А оптимален он или нет с точки зрения, где хранится КИ - его волнует меньше всего. Для него есть совсем другие критерии оптимальности.
190 Garykom
 
гуру
10.03.16
16:11
(188) фишку не понали, там можно несколько моделей сделать и хранения и записи/получения данных

т.е. хотется вернет отдельно телефоны в массиве, а хочется просто 1 строкой все номера через запятую или основной номер
191 франц
 
10.03.16
16:15
(189) почему-то хочется сказать "оставьте демагогию, КО".. ну, да ладно, не буду этого говорить))
192 Александр Б
 
10.03.16
16:16
Потому что обмен.

В табличной части
193 Fish
 
10.03.16
16:18
(191) А в чём демагогия? Тема про то, где лучше хранить КИ. Ответ прост: всё зависит от конкретной задачи. Универсального решения нет и быть не может. У каждого варианта есть свои плюсы и минусы, которые можно перетирать бесконечно.
Но как только заказчик начнёт мне, как разработчику, указывать, где я должен по его мнению хранить КИ - то будет послан, т.к. это тупо не его дело.
194 франц
 
10.03.16
16:21
(193) опять прокол... заказчика нельзя посылать.. у заказчика можно только уточнять требования))
195 Fish
 
10.03.16
16:22
(194) " заказчика нельзя посылать" - почему это нельзя? Легко.
196 Fish
 
10.03.16
16:23
+(195) А в некоторых случаях даже необходимо :)
197 Dmitrii
 
гуру
10.03.16
16:39
(195) (196) Послать заказчика с проектом на пару лямов только из-за контактной информации?...
Наверное, можно. Но, ИМХО, как-то глупо.
С заказчиком договариваться надо. И если заказчик выдвигает какие-то жесткие требования к способам хранения КИ, то логично было бы предположить, что эти требования чем-то обоснованы. Т.к. в 99% случаев заказчику глубоко фиолетово то, как именно ты это реализуешь.

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

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

И хватит уже втирать тут всем о том какой ты там правильный.
198 Dotoshin
 
10.03.16
16:41
(194) Вот скажи пожалуйста, как ты думаешь, если ты например стоматологу будешь указывать каким бором(или как там у них сверло называется) он должен твой зуб сверлить, что тебе ответят?
199 франц
 
10.03.16
16:49
(198) вот скажи пожалуйста, причем тут стоматолог?..  и, почему тебя возмущает необходимость уточнения требований?
200 Fish
 
10.03.16
16:49
(197) Послать заказчика с указанием где хранить КИ <> отказаться от проекта. И насчет существования "правильных" решений - это не ко мне, а к ТС.
А решений я сам реализовывал и встречал чужих (как в типовых, так и в самописках) достаточно много. Но опять же, обсуждать плюсы и минусы конкретного решения без описания конкретной задачи - имхо глупо и бессмысленно, т.к. для одних задач одно и то же решение может быть неприемлемым, а для других - оптимальным. А вы продолжаете обсуждать сферические КИ в вакууме.
201 Dmitrii
 
гуру
10.03.16
16:50
(198) некорректный пример.

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

Если стоматолог, не дебил, то он для начала поинтересуется о причинах наличия конкретных требований к инструменту. И только в том случае, если он поймет, что мои требования ничем не обоснованы и простая блажь, он пошлёт меня в пешее эротическое или тупо обманет, сказав, что делает, как я прошу, а сам всё выполнит так, как правильно.
202 Dmitrii
 
гуру
10.03.16
16:53
(200) Какой ты однако душный ))))
Нет конкретных задач. Представь на секундочку, что ты пишешь некое тиражное решение. И вести учет в нём будут очень и очень разные пользователи. Одним КИ вообще нафиг не нужна, а другим - наоборот - необходимо вести её во всех подробностях с кучей видов/типов и еще нужна история.
203 Fish
 
10.03.16
16:54
(199) Потому что аналогия: Заказчику нужна прежде всего удобная форма для ввода КИ, потом (уже опционально) ему нужно как-то её использовать - тупо выводить в списке, в печатные формы, осуществлять поиск по КИ и т.д. и т.п. А где при этом (в каком объекте конфигурации) она хранится, его абсолютно не должно волновать, если ты смог реализовать все его хотелки, которые тебе озвучили.
204 франц
 
10.03.16
16:56
(203) биля... у тебя заказчиком может выступить ИТ компания, которая разрабатывает свое тиражное решение, где упор в твои бесценные знания БСП и или реализация КИ в ут 10.3 в хрен им не уперлась... и ясно тебе говорять "Хотим КИ в регистре", и дают структуру регистра. ТОЧКА... посылай их..
205 Dmitrii
 
гуру
10.03.16
16:57
(203) В приведенном тобою примере в 99% случаев заказчик и не станет выдвигать конкретных требований к способу реализации.
Ты же собрался посылать заказчика, если он такие требования вдруг выдвинет. Хотя было бы логично поинтересоваться на чём эти его требования основаны - зачем ему надо именно так сделать, а не как-то по-другому.
206 Fish
 
10.03.16
16:58
(202) Я уже писал выше, что для тиражного решения, БСП подходит на мой взгляд лучше всего. Могу пояснить:
1. Максимум универсальности.
2. Удобство работы для программиста.
3. Удобное хранение данных, позволяющее осуществлять обмены с другими типовыми решениями).
Думаю, достаточно.
207 франц
 
10.03.16
16:59
(204) + был у меня такой дебил, которому я дал полную структуру под задачу.. эта сц_ука реализовала так, как он понимал задачу, а не так, как мне нужно было.. в итоге, хрен он когда еще от меня получит задачу... ну, и деньги тоже..
208 Fish
 
10.03.16
16:59
(204) Ты всё-таки не читатель. Попробуй перечесть (178).
209 франц
 
10.03.16
17:01
(206) 1. по универсальности у меня уже отрыжка пошла.. в универсальных решениях нет необходимости в пределах одной записи дублировать данные. 2. оставлю без комментариев. 3. это ваще "удобное хранение" при получении объекта потащит за собой и ТЧ с адресами.. а как же тут быть с масштабируемостью и производительностью?.. а?
210 Dotoshin
 
10.03.16
17:02
(199) Это просто аналогия. Меня ни разу не возмущает необходимость уточнения требований, но указания заказчика, каким инструментом я должен пользоваться, как минимум удивляют. Какая разница, как я сделаю, если результат будет отвечать его требованиям?
211 Fish
 
10.03.16
17:07
(205) Ты тоже не понял моего примера. И я не буду интересоваться, на чём основаны его требования к реализации. Я буду интересоваться тем, что ему в конечном итоге нужно от этой КИ (раз уж мы о ней). А там я уже сам приму решение, как мне это лучше сделать, причем моё решение вполне может и совпасть с пожеланиями заказчика. Но если я сочту это неоптимальным - то я попытаюсь объяснить заказчику, почему надо делать по-моему. И либо он согласится, либо нет. Но в обоих случаях он будет послан со своими указаниями по поводу реализации. У него могут быть лишь пожелания.
212 франц
 
10.03.16
17:08
(211) ыыыыы.. смешной ты....  ээ, не, не смешной, категорично правильный - вот точное слово..
213 PR третий
 
10.03.16
17:19
Когда мне попадаются кандидаты типа Fish, посылаю их нахрен, независимо от квалификации.
Потому что у них любое простейшее задание типа добавление реквизита в справочник разовьется в полноценный проект часов на 200 с вероятностью успеха 50%, типа либо будет либо нет.
214 Dmitrii
 
гуру
10.03.16
17:20
(212) Да звездобол он.

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

К чему все эти понты...
215 франц
 
10.03.16
17:20
(213) ты программистов допускаешь к самостоятельному общению с заказчиком??
216 PR третий
 
10.03.16
17:23
(215) Да, а что?
Но вообще речь не про это, а про то, что если я человеку скажу добавь реквизит X в справочник Y, а он мне начнет уточнять миллион деталей и требовать ТЗ, то будет послан незамедлительно.
Потому что это тогда уровень стажера, причем крайне тупого, который не только не приносит пользу, но еще и вяжет по рукам и ногам, то есть вредит.
217 франц
 
10.03.16
17:25
(216) да, как то это неправильно)) чистые программисты в 100% случаев начинают втирать заказчику что есть правильно в этой жизни, и почему он (заказчик) не прав))
218 PR третий
 
10.03.16
17:29
(217) А я не беру на работу чистых программистов.
У меня сейчас даже стажеры проходят школу общения с клиентом и как сделать задачу под ключ, а не сделал что попало и взятки гладки.
А иначе неизбежно начинается поведение типа как у Fish и приходится вправлять мозги, а оно мне нужно?
219 Rie
 
10.03.16
17:47
Ну вот и стало понятно, откуда берутся тупые вопросы вроде (0)...
220 Rie
 
10.03.16
17:49
(216) Для добавления реквизита X в справочник Y нужно кого-то нанимать? Или это просто такой неудачный пример?
221 PR третий
 
10.03.16
17:50
(220) Ради одной задачи не стоит конечно.
Но задача-то не одна.
Глупец, лишенный способности посмеяться над собой вместе с другими, не сможет долго выносить программирование. Фредерик Брукс-младший