Имя: Пароль:
1C
1С v8
Отличие созданного реквизита "Владелец" от свойства подчиненности справочников
0 FrostBite101
 
21.02.23
08:17
Добрый день, хотел уточнить по поводу свойства подчиненности у справочников. Есть ли какая-то принципиальная разница между создания своего реквизита "Владелец" и выставления подчиненности одного справочника другому. В обоих вариантах у нас есть реквизит, который указывает на владельца, созданный мной реквизит можно сделать обязательным и тогда отличий вообще не будет в план архитектуры. Да, при указании подчиненности открывается возможность использовать команды форма для перехода, а также создаются доп. индексы. Но команду для перехода можно "имитировать", динам. список с отбором. Также можно проиндексировать созданный реквизит "Владелец" и тогда даже одно индексное поле будет аналогична той, где используется подчиненность. Я понимаю, что при использовании подчиненности добавляется куда больше полей инд. полей. Так в чем в общем то вопрос... Когда мне стоит делать подчиненность, а когда собственный реквизит? В типовых конфигурациях чаще всего создается реквизит, а подчиненность используется куда реже.
1 Chai Nic
 
21.02.23
08:22
Создавать реквизит, совпадающий с предопределенными - жутко плохо. Не делай так.
2 FrostBite101
 
21.02.23
08:38
(1) Я прекрасно знаю, что делать так нельзя. Суть моего вопроса "Когда используется ТО, а когда ЭТО". Когда использовать подчиненность, а когда создать свой реквизит (без подчиненности)
3 АгентБезопасной Нацио
 
21.02.23
08:40
(2) кроме собственно структуры данных, есть еще структура метаданных в конфигурации. у которой либо включена подчиненность, либо нет.
4 FrostBite101
 
21.02.23
08:43
(3) Так я и спрашиваю когда используется один способ, а когда другой. Подчиненность выставляется в настройках метаданных объекта конфигурации, а реквизит я создаю сам.
5 FrostBite101
 
21.02.23
08:45
(4) В каком случае мне выставлять подчиненность в объекте справочника метаданных, а когда можно просто создать реквизит, типо "Владелец". - вот так может проще
6 Chai Nic
 
21.02.23
08:46
(2) Обычно не используют подчиненность, когда нужно скрыть от пользователей факт подчиненности объекта.
7 Kigo_Kigo
 
21.02.23
08:47
Ничего не понятно, но очень итересно, но осуждаю, дай пример
она подчиненость либо есть либо ее нет, если хочешь стандартными средствами к одному элементу набор элементов не пересекающихся с первым, то лучше использовать подчиненость
к примеру подразделения, их набор уникален для каждой организии
8 Fish
 
21.02.23
08:48
(4) Когда нужно использовать подчиненность - используют подчиненные. Если же подчиненность не нужна - то её не делают. Странный вопрос.
9 Kigo_Kigo
 
21.02.23
08:50
не так выразился
если хочешь стандартными средствами к одному элементу набор элементов не пересекающихся с первым* читать как
если хочешь стандартными средствами к одному элементу первого спр, набор элементов второго справочника(уникальный) тогда подчиненость нужна
тут даже при выборе реквизита стандартно указываешь связь и платформа сама отрабатывает отбор
10 FrostBite101
 
21.02.23
09:05
(9) Тоже самое можно сделать просто создав реквизит "Владелец" со ссылкой на владельца. Это точно такая же связь один ко многим. Все эти отборы автоматические тоже можно настроить. Тогда в чем принципиальное различие? В чем архитектурное обоснование использование того или другого.
11 Serg_1960
 
21.02.23
09:07
Принципиальная разница, имхо, только в одном: в терминах реляционных баз данных, между таблицами (справочник-владелец<-->подчиненный справочник) устанавливается связь "один-ко-многим" и эта связь "поддерживается" на уровне платформы 1С и сервера БД (в случае клиент-серверный вариант).
12 FrostBite101
 
21.02.23
09:18
(11) Вот пример в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так? Почему для банка и банк. счета было выбран реквизит, а для физ лица и банк. счета - подчинение?
13 Garykom
 
гуру
21.02.23
09:20
(0) пометка/удаление подчиненных при пометке/удалении владельца
14 Garykom
 
гуру
21.02.23
09:21
И да можно аналогично не использовать ТЧ у объектов, вместо этого создать новые "сущности" и привязать их "владельцем"
Но это изврат
15 Aleksey
 
21.02.23
09:23
(12) а разве банковский счет не подчинении физлицу? Т.е. 1с не умеет чтобы элемент был подчинении двум объектам методанных. Поэтому и банк реквизит
16 Garykom
 
гуру
21.02.23
09:24
Особенность системы/платформы 1С в куче дополнительных "лишних" сущностей/объектов и процедур/функций
Для "упрощения" и стандартизации разработки

Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результат = процедура
Или справочники/документы тоже разница небольшая, обязательные реквизиты по умолчанию Код и Наименование vs Дата и Номер
Ну и проведение документов -  по сути которое можно вручную реализовать для справочников
17 hockeyist
 
21.02.23
09:28
(16) Справочники и документы - это наше все. Не будь этого разделения, 1С не стала бы тем, чем она стала.
18 Garykom
 
гуру
21.02.23
09:30
(17) Это хрень если честно

Вместо разделения в Конфигураторе на всего две ветки-группы "Справочники" и "Документы"
Лучше бы сделали возможность произвольного создания своих "Групп"
И для каждого объекта метаданных выбор что это Справочник или Документ и свойства по умолчанию меняются
19 Garykom
 
гуру
21.02.23
09:31
(18)+ * и свойства/поведение по умолчанию меняются
20 hockeyist
 
21.02.23
09:32
(18) Вот и сделай свою систему с группами. И она никому не интересна будет. А справочники и документы "зашли". Потому что помогают неопытным разработчикам делать учетные системы
21 Serg_1960
 
21.02.23
09:32
(10) "Это точно такая же связь один ко многим." - да, "один ко многим", но не "точно такая же". Как я выше отметил, отличия на уровне поддержки.
(12) Опять таки всё дело в уровне поддержки. Программный уровень поддержки и/или на уровне конфигурации - более затратные методы, но они же более гибкие. Например, такая связь может быть изменена или может быть ситуативной. Что более оптимально - решают методисты. То же самый принцип подхода, имхо, что и в "константы или справочники" - постоянная информация или условно постоянная? (это риторический вопрос)
22 Garykom
 
гуру
21.02.23
09:33
Или вот Регистры накопления изврат тоже
Почему тогда не сделали разделение на три "сущности" "Регистр остатков", "Регистр оборотов" и "Регистр остатков и оборотов"
23 Garykom
 
гуру
21.02.23
09:33
(22)+ оно же в запросах один хрен раздельно!
24 FrostBite101
 
21.02.23
09:34
(13) вот это вот очень важное отличие, что-то типо каскадного удаления.
25 Garykom
 
гуру
21.02.23
09:34
(24) в других субд (в по сути на низком уровне в 1С) это решается ключами/триггерами
26 Garykom
 
гуру
21.02.23
09:36
(20) Дада. Неопытным.
А потом большие системы типа ERP выглядят как будто эти неопытные их и проектировали/писали
И чтобы разобраться приходится быть дико опытным и то куча матов что к чему и зачем
27 Garykom
 
гуру
21.02.23
09:38
Или вот почему в Конфигурторе до сих пор нет "своего фильтра по метаданным"?
По типу как отбор по подсистемам или захваченные из хранилище, но сам накидал что тебе надо в фильтр и видишь только их при установке своего фильтра!
Было бы сильно удобней при доработках
28 Fish
 
21.02.23
09:40
(27) Сделай подсистему "Мой фильтр" и сам накидывай в неё, что тебе надо. :)))
29 Serg_1960
 
21.02.23
09:41
Garykom предлагает вернуться к макроассемблеру?
"Кац предлагает сдаться"(с)
30 Лирик
 
21.02.23
09:41
(16) Выпилить все и оставить С+. :)
31 FrostBite101
 
21.02.23
09:41
(27) В едт вроде подобные отборы есть, ну или на крайний случай плагины)
32 НафНаф
 
21.02.23
09:43
(2) общая тенденция новых конфигураций - не использовать встроенную подчиненность. Например, ДоговорыКонтрагентов не подчинены справочнику Контрагенты, а имеют реквизит Контрагент.
33 Bigbro
 
21.02.23
09:47
(32) потому что контрагенты меняются как перчатки (юрлица) а договор с компанией продолжает работать.
34 hockeyist
 
21.02.23
09:50
(0) Можно использовать и так и так. Лично мне больше нравится вариант без использования платформенной подчиненности. Он нагляднее. Открываешь справочник Договоры, видишь реквизит Контрагент и все сразу понятно. А с платформенным механизмом все не так очевидно
35 Chai Nic
 
21.02.23
09:50
(16) "Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результа"
Оно нужно, если бы в 1с были "строгие" функции, которые не меняют вызывающий контекст. А так да. Всё можно делать функциями, без ущерба для.
36 Chai Nic
 
21.02.23
09:53
+(35) И у функций есть одна удобная побочка для отладки, их можно вызывать через табло и в отладчике. А процедуру нельзя.
37 hockeyist
 
21.02.23
09:53
+(34) Да, и совсем забыл. Свой механизм гибче. Платформа допускает только одного владельца
38 Serg_1960
 
21.02.23
09:54
(32) Имхо, если в конфигурации появляются справочники "Партнёры/контрагенты" и "Контрагенты/Контрагенты", то подчиненность тоже начинает зависать в воздухе. Возможно методисты со временем разродятся и появится иерархия с подчиненностью, скрестят ежа и ужа :)
39 Serg_1960
 
21.02.23
09:55
(уходя) Отличная тема, пятничная.
40 Garykom
 
гуру
21.02.23
09:57
(36) Недоделанность отладчика это отдельная вещь
41 НафНаф
 
21.02.23
10:04
(33) Договор так-то к юр. лицу относится. С другой стороны менять можно как обычный реквизит, так и Владелец - разницы никакой.
Вся разница в том, что если я помечу на удаление владельца, то пометятся и подчиненные. Возможно дело в правах доступа.
42 lodger
 
21.02.23
10:04
(38) "Партнёры/контрагенты" - это вызов времени такой. когда у твоего делового партнера на вывеске ГК Крутые Пупки, а когда начинаешь писать бумаги, то там ООО "Розовый пупочек" в точке А, его филиал в точке Б, ООО "Нежный пупочек" в точке А по другой части договора, ООО "Левая Пятка" по всем точкам принимает дела по ИТ-сфере. а всё вместе - это один партнер, ты с одним CEO договариваешься обо всех аспектах.
но вот каким раком это реализовано в инфраструктуре 1с это конечно мрачно =(
43 unregistered
 
21.02.23
10:09
(12) > в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так?

Потому что УНФ ведёт в первую очередь учёт Контрагентов, ФизЛиц и Организаций. Поэтому с точки зрения учёта важнее кому принадлежит банковский счет - какому контрагенту, физику или организации. В 99% случаев пользователя интересуют вопросы "Какие банковские счета есть у этого контрагента?" или "Чей это банковский счёт?", а не "Какие наши контрагенты имеют расчетные счета в этом банке?" или "В каком банке расчетный счет контрагента? (первичен контрагент, а не банк)".

Если бы авторы УНФ писали конфигурацию "Управление Центробанком РФ", то владельцем элемента БанковскиеСчета были бы элементы справочника Банки, а Контрагенты и ФизЛица - обычными реквизитами.

PS Выбор между установкой связи по владельцу или имитация этой связи через реквизит может быть обусловлен двумя причинами.
Во-первых, бытовой логикой задачи. Как в примере с банковскими счетами, где пользователю важнее какому контрагенту или физлицу принадлежит счёт, а не то в каком банке он открыт. С точки зрения пользователя Контрагент является владельцем счёта, а банк - всего лишь кредитная организация, предоставившая услугу ведения счёта.
Во-вторых, теми удобствами, которые предоставляет платформа в рамках связи по владельцу. Всегда проще воспользоваться тем, что уже есть и работает из коробки, чем имитировать это собственными инструментами.
44 АгентБезопасной Нацио
 
21.02.23
10:35
(20) ну делали же на клюшках систему учета на справочниках. Забавно было
45 Bigbro
 
21.02.23
10:42
мне лично видится разница лишь в том насколько часто вам требуется плоская выборка без учета владельца либо по нескольким владельцам либо замена владельца и так далее.
если это нужно часто то встроенный механизм подчинения с владельцем не особо нужен, проще реквизит.
46 Bigbro
 
21.02.23
10:44
в моем примере с договором - у вас центральным объектом является договор, как написано в (42), а какие там юрики реально висели получали отправляли документы в какие периоды - это уже нюансы, сегодня это одни завтра другие а владелец Вася Пупкин один и тот же и он наш постоянный и уважаемый клиент, с которым сотрудничаем уже десяток лет, и все нюансы нашего сотрудничества в договоре фиксированы. а контрагент в данном случае всего лишь реквизит по которому отправляем получаем деньги.
47 azernot
 
21.02.23
10:55
(0) >Когда мне стоит делать подчиненность, а когда собственный реквизит?
Ответ очень прост. Когда подчинённый элемент абсолютно не имеет смысла без владельца, вообще ни при каких обстоятельствах - делается подчинённость. А когда он в принципе может существовать и без владельца - это всего лишь реквизит.

Я могу себе представить банковский счёт (как элемент справочника) без ссылки на справочник Банки. Например, счет в зарубежном банке, реквизиты указываются текстом, также видел счёт с названием "Наличными курьеру" :) А вот абстрактный, неизвестно чей счёт в банке - нонсенс.
48 Anton1307
 
21.02.23
12:23
Если под понятием "Реквизит "Владелец" ты понимаешь именно реквизит с именем "Владелец" - ты не сможешь добавить такой реквизит.
Равно, как нельзя создать реквизиты "Наименование", "Код" и "ПометкаУдаления"
49 mistеr
 
21.02.23
12:49
(2) Предлагаю поставить вопрос по-другому. Когда НЕ стоит использовать подчиненность, а делать свой  реквизит?

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

P.S. Ладно, есть еще один исключительный случай. Когда ты мнишь себя архитектором 80 уровня и пытаешься изобразить на платформе 1С не учетную систему, а нечто экзотическое.
50 hockeyist
 
21.02.23
14:34
(49) Что такое учетная система по вашему?
51 Лирик
 
21.02.23
14:36
Весь функционал реализованный "Владельцем" можно реализовать собственным кодом (уникальность кодов, раздельную нумерацию, запрет незаполненного значения, отбор связанных списков и т.д.). Другой вопрос зачем, если есть штатный механизм. Посему согласен с (49).
52 mistеr
 
21.02.23
15:46
(51) Кроме каскадного удаления
53 mistеr
 
21.02.23
15:48
(50) Вопрос на монографию. :)
Это к Гению, он любит потрындеть на эту тему.
54 НафНаф
 
22.02.23
07:45
И минусом ко всему - владельцу нельзя присвоить определяемый тип
55 НЕА123
 
22.02.23
09:30
(0)
в 7 у справочников не было табличных частей (что, на мой взгляд, правильно).
подчиненный справочник - аналог табличной части.
56 АгентБезопасной Нацио
 
22.02.23
09:36
(55) там вообще не  было "частей" в лучшем случае - [одна] "часть", у доков. Не, конечно, решения были, но все равно лучше бы искаропки.
57 Chai Nic
 
22.02.23
09:39
(55) Табличная часть это удобно. Это позволяет использовать вторичную зависимость один ко многим без явного ссылочного объекта со всеми его особенностями.
58 НЕА123
 
22.02.23
09:40
(56)+1
я уже подзабыл... действительно, 1 ТЧ у дока. корячились. да.
59 НЕА123
 
22.02.23
09:41
(57)
ну... мало что можно у справика в ТЧ.
Оптимист верит, что мы живем в лучшем из миров. Пессимист боится, что так оно и есть.