Когда обязательно нужен функционал подчиненных справочников?
Добрый день.
Смотрю в текущую ERP. Справочник "Договоры контрагентов" не подчинен ни "Организации", и ни "Контрагенту". Хотя в БП 2.0 вроде был подчинен контрагентам.
Установив "проверять заполнение" для произвольного реквизита справочника, я получаю ту же обязательность заполнения, что и у реквизита "Владелец". В форме документа при выборе элемента справочника в поле, тоже можно прописать отбор для этого произвольного реквизита справочника.
В чем тогда отличительная особенность поля "Владелец" и механизма подчиненных справочников?
Есть ли случаи когда обязательно надо задавать Владельца?
Я не вижу таких случаев, и преимуществ использования этого реквизита - тоже.
Смотрю в текущую ERP. Справочник "Договоры контрагентов" не подчинен ни "Организации", и ни "Контрагенту". Хотя в БП 2.0 вроде был подчинен контрагентам.
Установив "проверять заполнение" для произвольного реквизита справочника, я получаю ту же обязательность заполнения, что и у реквизита "Владелец". В форме документа при выборе элемента справочника в поле, тоже можно прописать отбор для этого произвольного реквизита справочника.
В чем тогда отличительная особенность поля "Владелец" и механизма подчиненных справочников?
Есть ли случаи когда обязательно надо задавать Владельца?
Я не вижу таких случаев, и преимуществ использования этого реквизита - тоже.
По теме из базы знаний
Найденные решения
(13)Ну про термины СУБД стоит говорить, чтобы понимать почему использование владельца никаких wow эффектов и не даст.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.
По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.
2. Возможно указать, подчинение владельцу не по элементам, а по группам, или и так и этак, если владелец у вас иерархический справочник. И не придется делать никаких "элементарных" действий.
3. Не надо делать "элементарные" действия проверки заполнения
4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.
5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.
6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.
7. Связи параметров выбора и отбор также наглядно делаются по владельцу
8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.
Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.
Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.
По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.
2. Возможно указать, подчинение владельцу не по элементам, а по группам, или и так и этак, если владелец у вас иерархический справочник. И не придется делать никаких "элементарных" действий.
3. Не надо делать "элементарные" действия проверки заполнения
4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.
5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.
6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.
7. Связи параметров выбора и отбор также наглядно делаются по владельцу
8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.
Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.
Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
А владелец - это всегда один справочник: если "Контрагенты" - так "Контрагенты" для всех элементов "Договоров".
Соответственно, при программном обращении в коде надо/не надо проверять - на какой вид метаданных ссылается "Владелец"?
В чем тогда отличительная особенность поля "Владелец" и механизма подчиненных справочников?
ИМХО в том, что поле может иметь разные типы (например, содержать ссылки на справочники "Контрагенты", "Партнеры", "Наши фирмы" и т.д. в зависимости от конфигурации).
А владелец - это всегда один справочник: если "Контрагенты" - так "Контрагенты" для всех элементов "Договоров".
Соответственно, при программном обращении в коде надо/не надо проверять - на какой вид метаданных ссылается "Владелец"?
(1) на мой взгляд - подчинение прежде всего необходимо при работе юзера; так например при заполнении документа, вначале выбирается Контрагент, а поле Договор при нажатии на три точки автоматом покажет только договоры ранее заполненного Контрагента;
Этот же сценарий реализуется для Дополнительных характеристик - Номенклатуры; Допустим например у номенклатуры Сапоги - есть Характеристика "Размер", при попытке юзера заполнить характеристики - у Сапоги, в списке выбора будет исключительно "Размер"
ПВХ - также использует Владелец для своего функционала
Этот же сценарий реализуется для Дополнительных характеристик - Номенклатуры; Допустим например у номенклатуры Сапоги - есть Характеристика "Размер", при попытке юзера заполнить характеристики - у Сапоги, в списке выбора будет исключительно "Размер"
ПВХ - также использует Владелец для своего функционала
Случаев, когда нельзя обойтись без владельца нет. Обычный foreign key + not null на соотв. реквизит. Тип связи 1...n.
Только усе это тогда придется ручками настраивать, включая упомянутый вами отбор.
Удобства для подчиненного справочника в том, что система многое сделает за вас, например, создаст индексы с учетом владельца, соотв. ограничения и т.п.
А вот зачем убрали подчинение в ERP это интересно, если узнаете поделитесь.
Только усе это тогда придется ручками настраивать, включая упомянутый вами отбор.
Удобства для подчиненного справочника в том, что система многое сделает за вас, например, создаст индексы с учетом владельца, соотв. ограничения и т.п.
А вот зачем убрали подчинение в ERP это интересно, если узнаете поделитесь.
(5)Спасибо. Понятно, "раздельный/совместный" учет договоров в рамках холдинга - "Партнеры" и их структур - "Контрагенты". В общем-то, с точки зрения банальной эрудиции, и, скажу страшное, даже управленческого учета, договор всегда заключается с конкретным контрагентом, а уж партнер он или его дочка можно было бы и программно управленцам показывать...
Но ладно, полагаю очередная идея о том как разделить регламентированный и управленческий учет странным образом.
Но ладно, полагаю очередная идея о том как разделить регламентированный и управленческий учет странным образом.
(9)Не думаю. В договоре всегда есть стороны, его заключающие. И главной аналитикой всегда являются высокие договаривающиеся стороны.
Даже, если этот договор заключен устно и юр. силы не имеет.
Общее же количество аналитик зависит только от чувства меры: партнер, организация, подразделение, вид договора, да даже страна местонахождения ...
Например, если у Билайна имеется 100500 дочек, причем некоторые двойные или даже тройные "агенты", то все равно все договора должны иметь единую точку входа - эту саму дочку.
Именно им выставляются счета, именно по ним отслеживаются условия поставок в разрезе договоров и т.д. и т.п.
А учет великого партнера никуда не девается, он сидит на уровень выше.
Например, именно туда можно пожаловаться на дочку, решить вопрос с гарантиями, можно считать по ним кредиторку и дебиторку и т.п.
Просто у нас разное понятие об иерархии - я полагаю, что партнеры в ней находятся выше контрагентов с их договорами.
Кстати, никто не мешает партнеру одновременно выступать и как контрагенту (не путать с отключением раздельного ведения учета по партнерам и контрагентам).
Даже, если этот договор заключен устно и юр. силы не имеет.
Общее же количество аналитик зависит только от чувства меры: партнер, организация, подразделение, вид договора, да даже страна местонахождения ...
Например, если у Билайна имеется 100500 дочек, причем некоторые двойные или даже тройные "агенты", то все равно все договора должны иметь единую точку входа - эту саму дочку.
Именно им выставляются счета, именно по ним отслеживаются условия поставок в разрезе договоров и т.д. и т.п.
А учет великого партнера никуда не девается, он сидит на уровень выше.
Например, именно туда можно пожаловаться на дочку, решить вопрос с гарантиями, можно считать по ним кредиторку и дебиторку и т.п.
Просто у нас разное понятие об иерархии - я полагаю, что партнеры в ней находятся выше контрагентов с их договорами.
Кстати, никто не мешает партнеру одновременно выступать и как контрагенту (не путать с отключением раздельного ведения учета по партнерам и контрагентам).
(10) Да ладно??? Вот в этом главная ошибка бухгалтеров - они мыслят только в юридической плоскости...
А все, что ты написал - это вообще никакого отношения к БУ не имеет.
А все, что ты написал - это вообще никакого отношения к БУ не имеет.
Просто у нас разное понятие об иерархии - я полагаю, что партнеры в ней находятся выше контрагентов с их договорами.
Поржал.
(10)
Например, если у Билайна имеется 100500 дочек, причем некоторые двойные или даже тройные "агенты", то все равно все договора должны иметь единую точку входа - эту саму дочку.
С фига ли?
А учет великого партнера никуда не девается, он сидит на уровень выше.
С фига ли? Партнер может сидеть и ниже. Торговые точки. У одного контрагента несколько торговых точек (адресатов заказов и доставок), а вот точка расчета - да, одна. Перестань мыслить бухгалтером, начни мыслить продавцом.
(2) Спасибо за ответ.
Но я не увидел конкретных преимуществ использования Владельца.
Указанные вами foreign key + not null и тип связи - это термины СУБД, я бы не стал их рассматривать с точки зрения прикладного программиста.
"Все это придется ручками настраивать" - а что автоматом делается для Владельца? На ум приходит только флаг "проверять заполнение" ? который взвести для произвольного реквизита - не великий труд. Да и отбор в формах по владельцу сам по себе не работает, его так же надо прописывать.
Но я не увидел конкретных преимуществ использования Владельца.
Указанные вами foreign key + not null и тип связи - это термины СУБД, я бы не стал их рассматривать с точки зрения прикладного программиста.
"Все это придется ручками настраивать" - а что автоматом делается для Владельца? На ум приходит только флаг "проверять заполнение" ? который взвести для произвольного реквизита - не великий труд. Да и отбор в формах по владельцу сам по себе не работает, его так же надо прописывать.
(13)Ну про термины СУБД стоит говорить, чтобы понимать почему использование владельца никаких wow эффектов и не даст.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.
По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.
2. Возможно указать, подчинение владельцу не по элементам, а по группам, или и так и этак, если владелец у вас иерархический справочник. И не придется делать никаких "элементарных" действий.
3. Не надо делать "элементарные" действия проверки заполнения
4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.
5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.
6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.
7. Связи параметров выбора и отбор также наглядно делаются по владельцу
8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.
Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.
Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
Еще раз - если пойти на принцип, то можно, проделав не большую, но никому не нужную работу обойтись без подчинения владельцу.
По поводу "преимуществ":
1. Автоматически создаются индексы с ведущем полем по владельцу. Это может сильно ускорить запросы и отборы по оному.
2. Возможно указать, подчинение владельцу не по элементам, а по группам, или и так и этак, если владелец у вас иерархический справочник. И не придется делать никаких "элементарных" действий.
3. Не надо делать "элементарные" действия проверки заполнения
4. При автоматическом создании формы у вас там появится понятный владелец, а не придется что-то делать ручками.
Да, крайне сомнительное преимущество, тем более, что обычно возникает желание это поле как-то на форме переименовать, но таки есть.
5. Поле Владелец - у вас стандартный реквизит справочника и не надо создать свой.
6. На форме элемента - владельца автоматом появится кнопка к переходу справочнику его договоров.
7. Связи параметров выбора и отбор также наглядно делаются по владельцу
8. Не надо хранить сакральное знание о том, что этот справочник, является вспомогательным. Т.к. обязательность реквизита об этом вам ничего не скажет.
Вообще-то 8 пункт IMHO самый важный, нам в руки дают инструмент самодокументирования программы, который не устаревает при любом изменении объекта. Редкая возможность.
Вот, скажем, в ERP убрали владельца и я сразу запутался, что является первичной сущностью для данного справочника - он вдруг зажил своей независимой жизнью. И без доступа к коду, понять насколько это решение верно я уже не могу.
(21) Обычная БП 3.0.133.17, платформа 8.3.20.2184
Пометил контрагента на удаление.
2 договора этого контрагента тоже пометились на удаление (надо обновить список).
С 1-го договора снял пометку на удаление.
С помощью Администрирование - Удаление помеченных объектов удалил контрагента.
Оба договора, помеченный на удаление и нет, удалились.
Пометил контрагента на удаление.
2 договора этого контрагента тоже пометились на удаление (надо обновить список).
С 1-го договора снял пометку на удаление.
С помощью Администрирование - Удаление помеченных объектов удалил контрагента.
Оба договора, помеченный на удаление и нет, удалились.
Главное преимущество использования подчинённых Справочников состоят в том, что при открытии формы Владельца автоматически на форме появляется возможность посмотреть подчинённые без необходимости доработки форм (на обычной и управляемой) и на любом типе клиента.
Поэтому подчинённые справочники хорошо использовать когда нужны именно готовые формы отбора. Например, это список файлов к справочнику.
Но если требуется более глубокие настройки, то его можно не использовать
Поэтому подчинённые справочники хорошо использовать когда нужны именно готовые формы отбора. Например, это список файлов к справочнику.
Но если требуется более глубокие настройки, то его можно не использовать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот