Общий реквизит и разделение данных - можно ли задать список? #681760

Подскажите, пожалуйста, по механизму разделения данных по общим реквизитам. Верно ли я понимаю, что разделитель-параметр сеанса проверяется "на равенство", и, используя этот механизм, невозможно задать ограничение списком? То есть можно отобрать, допустим, все документы какого-то одного подразделения, а по списку подразделений нельзя?

нет.

нет - неверно понимаю или нет - нельзя список?

общ. реквизит не для отборов создавался, а отбирать можно в списке как для любого др. реквизита

если верить официальной литературе, общ.реквизит создавался для разделения данных. фактически - отбор, но, как я понимаю, по жесткому равенству (в отличие от RLS, где можно прописать какие угодно отборы, в том числе на вхождение в список)

Обрисую задачу, чтобы было понятнее, почему возник вопрос. Нужно сделать так, чтобы пользователи видели только документы "разрешенных" подразделений. Рассматриваем разные механизмы для решения той задачи. У большинства "разрешенное" подразделение одно, поэтому и разделение по общему реквизиту могло бы подойти (хотя останется вопрос с перемещением). Но у некоторых есть несколько разрешенных подразделений. В этом случае механизм разделения данных не подойдет совсем, или есть способы его обмануть?

при открытии устанавливай в списке отбор по реквизиту в списке (настраивай в РС)- я так делал для клиента, общ. реквизит такой же как другие. но через отчеты вытащат инфу точно РЛС не нужно ?

как раз склоняемся к RLS. на отборах уже было сделано - много проблем, нужно в каждый отчет, в каждую расшифровку тащить этот отбор. Вот сейчас выбираем между разделением по общему реквизиту и RLS.

"настраивай в РС" - как расшифровывается РС?

в регистре сведений, но это если через отбор реализация.

конфа какая?

ЗУП

т.е. 8.2 значит 1. общий реквизит может быть только примитивного типа 2. не все регистры расчёта можно включить в состав

"1. общий реквизит может быть только примитивного типа" - это не дает, вполне дает создать реквизит ссылочного типа и даже Хранилище значения. "2. не все регистры расчёта можно включить в состав" - все имеющиеся в типовом ЗУПе дает включить.

описка "1. общий реквизит может быть только примитивного типа" - вполне дает создать реквизит ссылочного типа и даже Хранилище значения.

добавил и сохранил? открой теперь схему компановки отчёта ВыработкаРаботников, это для примера да даёт-то даёт )

компоновки*

Штатный RLS по физ. лицам не подходит?

видела на такой совет на инфостарте, надо потестировать, как там отработает при приеме нового / перемещении между подразделениями / совмещении (когда работает в двух подразделениях)

физлицо может быть в нескольких подразделениях

+ пардон, добавила и сохранила* )

не страшно )))) у меня пока база висит на реструктуризации, не поясните словами, в чем именно засада с ссылочным общим реквизитом и регистрами расчета?

там не во все временные таблицы общий реквизит добавляется, и когда хочешь её использовать вылетает дамп

вернее в одну не добавляется, хотя проверь, может исправили этот баг

в результате этот отчёт надо сразу удалять из конфы, иначе обновить нельзя, но и после этого даже незначительное обновление ну очень медленно идёт

о да, и правда падает в дамп

на самом деле проблема здесь гораздо глубже - сотрудник может в течение месяца переходить из одного подразделения в другое. Другое дело в том, что по окончанию месяца сотрудник может фигурировать только в одном документе "начисление заработной платы". Как решение по документам - только писать свое RLS, в котором будет учитываться подразделение на дату документа. Но, есть такие документы как начисление премии, в которых премия начисляется в целом за месяц, вне подразделений. Так что проблема, мне видится, тяжело решаема. Я у себя на одном из предприятий сделал RLS по физ. лицам - при проведении кадровых изменений меняется группа доступа в зависимости от подразделения - так что на конец месяца сотрудника может юзать только тот у кого на эту группу имеется право доступа. Но у меня нет внутренних совместителей.

все регистры с флажком период действия надо исключать

wertyu, Artful Den - большое спасибо за помощь! сохраню страничку )

видимо у ТС выбора нет, только RLS, с общим реквизитом в отчётах "дырки" будут

думаю, позже более внимательно посмотрю вариант с группами физ.лиц, Ваш опыт был бы бесценным подспорьем

так она в "Мои темы" останется

вопрос только в том, самому ли RLS по подразделениям рисовать или использовать типовой по физлицам

внутренние совместители есть?

простите, убегаю, Вы не против вернуться к обсуждению завтра?

по RLS самый спец - это vde69 )

Самая большая засада будет в том, что подразделение сотрудника в документах нужно стыковать с подразделением на дату документа. Но это не решит вопроса с отчетами. Да, не забывайте, что есть такие документы, где нет сотрудников - например СведенияОДоходахФизлиц (2НДФЛ), где Сотрудника с его подразделениями нет в принципе...

будут вопросы - обращайтесь

спасибо, непременно и с большим удовольствием!

посмотрела на типовые ограничения по физлицам, поэкспериментировала... В общем, увы, типовой функционал нам не подойдет. Очень часто идут массовые перемещения из региона в регион. Как только у физлица меняется группа доступа, у расчетчика прежней группы пропадают все документы, в которых это физлицо фигурировало. Плодить группы "регион 1 + регион 2" не резон. Плюс при переводе в середине месяца первую половину должен обсчитать расчетчик Региона1, а вторую - Региона2. Придется мутить с RLS и периодическим регистром сведений "пользователь-регион"

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

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

еще вопрос. Если сейчас у всех документов и так есть реквизит "Организация", мы добавляем общий реквизит "организация". Получается у каждого документа будет 2 реквизита "организация"? Нужно будет скопировать значения в общий реквизит и сделать (например, в подписках на события), чтобы организация также писАлась в новый реквизит, а только потом уже включать разделение?

Третий момент. Правильно, что разделение данных общими реквизитами делит базу на "области", и например, значение предопределенного элемента в разных областях может различаться? Это нам не подойдет. Можно ли на общих реквизитах сделать, чтобы в одной базе одновременно, например, бухгалтерия видела документы всех организаций, а продавцы видели только документы своего филиала? Есть ли типовая конфа, в которой можно покурить эту тему? и как там это работает?

Итак?

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

Одно это ограничение уже обязывает нас использовать только RLS. Получается, что если у нас один директор на 2 филиала из 8, то на общих реквизитах не сделаешь, чтобы он видел информацию только по 2 филиалам из 8, потому что параметр сеанса можно устанавливать только на равенство конкретной ссылке, а не списку значений?

да, в этом случае рекомендуется делить на отдельные базы

Общие реквизиты не для этого создавались. Режим "Независимо и совместно" - для служебного использования, не для работы. Во все индексы всех таблиц добавляется в начало общий реквизит. Если у тебя не стоит отбора на него, то невозможно использовать ни один индекс. Результат - система лежит мёртвая.

Спасибо. Буду делать ограничения доступа по организациям на RLS. Гемор конечно - нужно в каждый документ, в каждую роль добавить шаблон запроса. В каждый запрос добавить слово "Разрешенные". Опять же непонятно, если в документе-основании одна организация, а в самом документе другая организация, тогда в поле ввода будет выводиться "объект не найден..." Наши недалекие пользователи с ума сойдут от увиденного... Какие еще действия надо произвести?

Насколько критично скажется создание механизма RLS на базе с 700 пользователями и достаточно интенсивной работой?

ощутимо замедлит работу. если уж делать РЛС, то рекомендации такие: 1) использовать простые шаблоны с условием на равенство или на вхождение в массив значение (сделать параметр сеанса с типом ФиксированныйМассив) 2) один пользователь = 1 роль с РЛС

по первому пункту: ГДЕ Организация В(&ОрганизацииДляДоступаКДокументам) Куда еще проще. А по второму пункту не понял. Мне нужно создать 700 ролей?

1) да. ОрганизацииДляДоступаКДокументам - это должен быть параметр сеанса с типом ФиксированныйМассив. Нужно, чтобы не использовать соединения с другими таблицами в шаблоне рлс. 2) нет. пользователю должна быть назначена только одна роль с РЛС, т.е. назначать например роли Бухгалтер и Кадровик, если в обеих есть РЛС - это плохо с точки зрения производительности, т.к. условия из обеих ролей будут дописываться через ИЛИ

по второму пункту - так не прокатит. Есть роль "Минимальный набор прав". Он есть у всех. А далее уже раздаются роли, бухгалтер, главный бухгалтер, кладовщик, продавец и тд. Одной ролью для пользователя не обойтись

еще раз акцентирую на "только одна роль с РЛС", ролей без РЛС можно добавить несколько

Как это сделать? Какой тогда смысл в RLS, если есть, например, 2 роли у пользователя - одна с RLS, а другая без RLS, они накладываются друга на друга, в итоге RLS не работает, потому что срабатывает доступ из роли, в которой нет RLS?

Еще раз - не должно быть ситуации, когда все пункты присутствуют: 1) у пользователя нет роли для доступа к объекту без РЛС 2) у пользователя есть более 1 роли для доступа к этому объекту с РЛС

если будет более 2-х ролей, то база сразу ляжет? Насколько критично?

Нет подходящих индексов под условие, написанное через ИЛИ. Возможны неоптимальные планы запросов со всеми вытекающими... И это на базе с 700 пользователями...

Хорошо. Как тогда организовать структуру, в которой, например, продавец должен видеть расходные накладные только своего филиала, а кладовщик НЕ должен видеть их ВООБЩЕ. Роль отождествляется с должностью. Первый вариант: В каждую роль, которая обладает правом редактирования накладной, нужно добавить ограничение на чтение. Один человек может совмещать должности, а следовательно ему могут быть одновременно назначены несколько ролей. Получается ситуация с падением производительности, от которой мы хотим уйти. Второй вариант: Я делаю роль "минимальный набор прав" с ограничением только на чтение этого документа и раздаю эту роль всем. Т.е. выполняется условие, что "читать" могут все, но видеть могут только отдельные пользователи. НО, чтобы дать право на просмотр, нужно будет обязательно включить галку на чтение. В итоге приходим к ситуации, как в первом случае. Третий вариант. Все пользователи видят все виды документов. В этом случае, мы уходим от понятия роль = должность. И будет грубо говоря 2-3 роли Полные права, минимальные права, расширенные права. Это не совсем нам подходит.

мне кажется стоит подумать о разделении баз по филиалам (РИБ или другой способ - неважно). Вы в любом случае в чем-то проиграете: либо в производительности единой базы, либо в появлении накладных расходов на обмен данными

Самое смешное, что сейчас как раз таки базы разделены, и идет проект по слиянию баз в одну единую. Поэтому встал вопрос с разделением видимости. Время на различные выгрузкизагрузкиобменысведения и тд тратится несоизмеримо больше. Грубо говоря отдел трейд-ин приходуют машины во все базы, а продает только из одной. При этом есть консолидированные отчеты, перемещения из базы в базу и тд

тогда путь один - тщательно разрабатывать систему прав доступа. я бы наверное думал в сторону нарезки ролей на каждый объект метаданных / группы объектов (по аналогии с УТ 11) В этом случае усложняется создание профилей доступа: каждая комбинация совмещения должностей = профиль Но зато выполняется . Причем пункт 2 в нужно еще разбить на подпункты ЧТЕНИЕ, ПРОСМОТР, ИЗМЕНЕНИЕ, УДАЛЕНИЕ

мда... полгода надо будет заниматься копипастом шаблоном...

шаблонов*

лучше уж так, чем в процессе эксплуатации постоянно укрупненные роли переписывать

Возможно. Но у нас планируется обрезка базы и с нового года будет почти пустая база с остатками. Скорее всего не так критично будет влияние РЛС. Однако за полгода можно сделать кучу других более нужных проектов. А через 3 года работы, когда уже будет большой объем данных, все уже может поменяться 100 раз и фирма 1с еще что-нибудь придумает. Эти же общие реквизиты допилит до идеала и тд.