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

нет.
http://v8.1c.ru/overview/Term_000000789.htm

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

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

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

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

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

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

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

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

конфа какая?

(10) ЗУП

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

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

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

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

компоновки*

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

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

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

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

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

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

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

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

(24) о да, и правда падает в дамп

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОлучается, у нас только один вариант - RLS?

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

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

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

Есть ли типовая конфа, в которой можно покурить эту тему? и как там это работает?

Итак?

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

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

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

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

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

Опять же непонятно, если в документе-основании одна организация, а в самом документе другая организация, тогда в поле ввода будет выводиться "объект не найден..."
Наши недалекие пользователи с ума сойдут от увиденного...

Какие еще действия надо произвести?

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

(50) ощутимо замедлит работу.
если уж делать РЛС, то рекомендации такие:

1) использовать простые шаблоны с условием на равенство или на вхождение в массив значение (сделать параметр сеанса с типом ФиксированныйМассив)

2) один пользователь = 1 роль с РЛС

(51) по первому пункту:
ГДЕ Организация В(&ОрганизацииДляДоступаКДокументам)
Куда еще проще.

А по второму пункту не понял. Мне нужно создать 700 ролей?

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

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

(53) по второму пункту - так не прокатит.

Есть роль "Минимальный набор прав". Он есть у всех.

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

Одной ролью для пользователя не обойтись

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

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

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

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

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

(59) Хорошо.
Как тогда организовать структуру, в которой, например, продавец должен видеть расходные накладные только своего филиала, а кладовщик НЕ должен видеть их ВООБЩЕ.

Роль отождествляется с должностью.

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

Второй вариант:
Я делаю роль "минимальный набор прав" с ограничением только на чтение этого документа и раздаю эту роль всем. Т.е. выполняется условие, что "читать" могут все, но видеть могут только отдельные пользователи. НО, чтобы дать право на просмотр, нужно будет обязательно включить галку на чтение. В итоге приходим к ситуации, как в первом случае.

Третий вариант.
Все пользователи видят все виды документов. В этом случае, мы уходим от понятия роль = должность. И будет грубо говоря 2-3 роли Полные права, минимальные права, расширенные права.
Это не совсем нам подходит.

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

(61) Самое смешное, что сейчас как раз таки базы разделены, и идет проект по слиянию баз в одну единую.

Поэтому встал вопрос с разделением видимости.

Время на различные выгрузки\загрузки\обмены\сведения и тд тратится несоизмеримо больше.

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

(62) тогда путь один - тщательно разрабатывать систему прав доступа.
я бы наверное думал в сторону нарезки ролей на каждый объект метаданных / группы объектов (по аналогии с УТ 11)

В этом случае усложняется создание профилей доступа:
каждая должность = профиль
каждая комбинация совмещения должностей = профиль

Но зато выполняется (57). Причем пункт 2 в (57) нужно еще разбить на подпункты ЧТЕНИЕ, ПРОСМОТР, ИЗМЕНЕНИЕ, УДАЛЕНИЕ

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

шаблонов*

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

Возможно. Но у нас планируется обрезка базы и с нового года будет почти пустая база с остатками.
Скорее всего не так критично будет влияние РЛС.
Однако за полгода можно сделать кучу других более нужных проектов.

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