Добрый день.

Смотрю в текущую ERP. Справочник "Договоры контрагентов" не подчинен ни "Организации", и ни "Контрагенту". Хотя в БП 2.0 вроде был подчинен контрагентам.
Установив "проверять заполнение" для произвольного реквизита справочника, я получаю ту же обязательность заполнения, что и у реквизита "Владелец". В форме документа при выборе элемента справочника в поле, тоже можно прописать отбор для этого произвольного реквизита справочника.

В чем тогда отличительная особенность поля "Владелец" и механизма подчиненных справочников?
Есть ли случаи когда обязательно надо задавать Владельца?
Я не вижу таких случаев, и преимуществ использования этого реквизита - тоже.
---
Ну про термины СУБД стоит говорить, чтобы понимать почему использование владельца никаких wow эффектов и не даст.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.

По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.

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

3. Не надо делать "элементарные" действия проверки заполнения

4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.

5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.

6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.

7. Связи параметров выбора и отбор также наглядно делаются по владельцу

8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.

Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.

Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
---
Исторически так сложилось. Подчиненный справочник "перетек" еще из седьмой версии. Потом оставили для обратной совместимости. Обычное дело
---
В чем тогда отличительная особенность поля "Владелец" и механизма подчиненных справочников? ИМХО в том, что поле может иметь разные типы (например, содержать ссылки на справочники "Контрагенты", "Партнеры", "Наши фирмы" и т.д. в зависимости от конфигурации).

А владелец - это всегда один справочник: если "Контрагенты" - так "Контрагенты" для всех элементов "Договоров".

Соответственно, при программном обращении в коде надо/не надо проверять - на какой вид метаданных ссылается "Владелец"?
---
А владелец - это всегда один справочник: если "Контрагенты" - так "Контрагенты" для всех элементов "Договоров". Откуда такой бред???
---
Откуда такой бред??? Из клюшек, откуда же еще? :-)
---
В клюшках нет составных типов )))
---
на мой взгляд - подчинение прежде всего необходимо при работе юзера; так например при заполнении документа, вначале выбирается Контрагент, а поле Договор при нажатии на три точки автоматом покажет только договоры ранее заполненного Контрагента;
Этот же сценарий реализуется для Дополнительных характеристик - Номенклатуры; Допустим например у номенклатуры Сапоги - есть Характеристика "Размер", при попытке юзера заполнить характеристики - у Сапоги, в списке выбора будет исключительно "Размер"
ПВХ - также использует Владелец для своего функционала
---
поле Договор при нажатии на три точки автоматом покажет только договоры ранее заполненного Контрагента Уверен, что автоматом?
---
Согласен что автоматом не работает.
У меня при на форме документа при выборе подчиненного справочника не было связи с владельцем "автоматом", пришлось у реквизита-подчиненного-справочника указать Владельца в СвязиПараметровВыбора.
---
Точно так же связь можно установить с любым реквизитом, а не только с Владельцем.
---
Случаев, когда нельзя обойтись без владельца нет. Обычный foreign key + not null на соотв. реквизит. Тип связи 1...n.
Только усе это тогда придется ручками настраивать, включая упомянутый вами отбор.

Удобства для подчиненного справочника в том, что система многое сделает за вас, например, создаст индексы с учетом владельца, соотв. ограничения и т.п.

А вот зачем убрали подчинение в ERP это интересно, если узнаете поделитесь.
---
Рискну предположить, что убрали из-за архитектуры Контрагент - Партнер.
---
Тогда, более-менее, понятно. Надо бы глянуть на типы реквизитов, жаль нет под рукой ERP.
 Спасибо.
---
Как-то так:
---
Спасибо. Понятно, "раздельный/совместный" учет договоров в рамках холдинга - "Партнеры" и их структур - "Контрагенты". В общем-то, с точки зрения банальной эрудиции, и, скажу страшное, даже управленческого учета, договор всегда заключается с конкретным контрагентом, а уж партнер он или его дочка можно было бы и программно управленцам показывать...
Но ладно, полагаю очередная идея о том как разделить регламентированный и управленческий учет странным образом.
---
договор всегда заключается с конкретным контрагентом вы путаете понятие "юридический договор" и понятие "договор как аналитика".
---
Не думаю. В договоре всегда есть стороны, его заключающие. И главной аналитикой всегда являются высокие договаривающиеся стороны.
Даже, если этот договор заключен устно и юр. силы не имеет.

Общее же количество аналитик зависит только от чувства меры: партнер, организация, подразделение, вид договора, да даже страна местонахождения ...

Например, если у Билайна имеется 100500 дочек, причем некоторые двойные или даже тройные "агенты", то все равно все договора должны иметь единую точку входа - эту саму дочку.

Именно им выставляются счета, именно по ним отслеживаются условия поставок в разрезе договоров и т.д. и т.п.

А учет великого партнера никуда не девается, он сидит на уровень выше.
Например, именно туда можно пожаловаться на дочку, решить вопрос с гарантиями, можно считать по ним кредиторку и дебиторку и т.п.

Просто у нас разное понятие об иерархии - я полагаю, что партнеры в ней находятся выше контрагентов с их договорами.
Кстати, никто не мешает партнеру одновременно выступать и как контрагенту (не путать с отключением раздельного ведения учета по партнерам и контрагентам).
---
Да ладно??? Вот в этом главная ошибка бухгалтеров - они мыслят только в юридической плоскости...
А все, что ты написал - это вообще никакого отношения к БУ не имеет.
Просто у нас разное понятие об иерархии - я полагаю, что партнеры в ней находятся выше контрагентов с их договорами. Поржал.
---
Например, если у Билайна имеется 100500 дочек, причем некоторые двойные или даже тройные "агенты", то все равно все договора должны иметь единую точку входа - эту саму дочку. С фига ли?
А учет великого партнера никуда не девается, он сидит на уровень выше. С фига ли? Партнер может сидеть и ниже. Торговые точки. У одного контрагента несколько торговых точек (адресатов заказов и доставок), а вот точка расчета - да, одна. Перестань мыслить бухгалтером, начни мыслить продавцом.
---
Спасибо за ответ.
Но я не увидел конкретных преимуществ использования Владельца.
Указанные вами foreign key + not null и тип связи - это термины СУБД, я бы не стал их рассматривать с точки зрения прикладного программиста.
"Все это придется ручками настраивать" - а что автоматом делается для Владельца? На ум приходит только флаг "проверять заполнение" ? который взвести для произвольного реквизита - не великий труд. Да и отбор в формах по владельцу сам по себе не работает, его так же надо прописывать.
---
Но я не увидел конкретных преимуществ использования Владельца.
А зря, по нему можно отбирать подчиненные, по нему на форме в реквизите установить выбор по владельцу и т.д. и т.п.
---
Ну про термины СУБД стоит говорить, чтобы понимать почему использование владельца никаких wow эффектов и не даст.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.

По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.

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

3. Не надо делать "элементарные" действия проверки заполнения

4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.

5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.

6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.

7. Связи параметров выбора и отбор также наглядно делаются по владельцу

8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.

Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.

Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
---
Спасибо. Отмечу п.2 - про него я забыл, а это важный функционал.
---
Сообщение было скрыто модератором.
---
При удалении владельца автоматически удаляются подчиненные этому владельцу элементы других справочников.
---
В типовых нифига, если вы сами не написали обработину удаления, а так удаление просто напишет что есть ссылки на удаляемый объект
---
Проверьте сами. Я проверил: платформа 8.3.20.2184, версия БСП 2.4.4.52.
---
Проверил в обычной БП. При пометке на удаление контрагента его договора (подчиненные) не куда не уходят
---
Обычная БП 3.0.133.17, платформа 8.3.20.2184
Пометил контрагента на удаление.
2 договора этого контрагента тоже пометились на удаление (надо обновить список).
С 1-го договора снял пометку на удаление.
С помощью Администрирование - Удаление помеченных объектов удалил контрагента.
Оба договора, помеченный на удаление и нет, удалились.
---
Да согласен, перепроверил, так и есть, извиняюсь, ввел в заблуждение
---
ну и еще не по теме перестанете перестаньте назначать такую нищенскую награду это я топикастеру, не Вам
---
Главное преимущество использования подчинённых Справочников состоят в том, что при открытии формы Владельца автоматически на форме появляется возможность посмотреть подчинённые без необходимости доработки форм (на обычной и управляемой) и на любом типе клиента.
Поэтому подчинённые справочники хорошо использовать когда нужны именно готовые формы отбора. Например, это список файлов к справочнику.
Но если требуется более глубокие настройки, то его можно не использовать