Прячем счета из плана счетов

Если некоторым пользователям нужен доступ только к определенным счетам, а видимость данных по другим счетам при этом крайне нежелательна, на помощь приходит RLS

Зачем это нужно.

Самый простой пример — в базе хранятся данные по зарплате (с разбивкой по сотрудникам, т.е. не сводно), и главный бухгалтер или руководитель хочет чтобы 70-й счет мог видеть только расчетчик. Еще пример — менеджер смотрит остатки на складах по «оборотке» только по 10-му счету или по 41.01, остальные счета для него можно скрыть. Да мало ли у кого какие запросы 🙂

Порядок действий.

1) Добавляем в конфигурацию независимый непериодический регистр сведений «НедоступныеСчета» с двумя измерениями (ведущее, отбор, запрет незаполненных значений):

Пользователь — составной тип (СправочникСсылка.ГруппыПользователей, СправочникСсылка.Пользователи)
Счет — тип (ПланСчетовСсылка.Хозрасчетный) или другой план счетов?

2) Пишем для пользовательских ролей для права «Чтение» примерно такое ограничение:

ТекущаяТаблица ГДЕ (НЕ ТекущаяТаблица.Ссылка В (ВЫБРАТЬ
      НедоступныеСчета.Счет
ИЗ
      РегистрСведений.НедоступныеСчета КАК НедоступныеСчета
ГДЕ
      (НедоступныеСчета.Пользователь = &ТекущийПользователь
      ИЛИ НедоступныеСчета.Пользователь В (&ГруппыТекущегоПользователя))))
      И (НЕ ТекущаяТаблица.Ссылка В  (ВЫБРАТЬ
                 ТекущаяТаблица.Ссылка
          ИЗ
                ПланСчетов.Хозрасчетный КАК ТекущаяТаблица ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НедоступныеСчета КАК НедоступныеСчета
      ПО ТекущаяТаблица.Код ПОДОБНО "" + НедоступныеСчета.Счет.Код + ".%"
 ГДЕ
       (НедоступныеСчета.Пользователь = &ТекущийПользователь
       ИЛИ НедоступныеСчета.Пользователь В (&ГруппыТекущегоПользователя))))

3) Приложенной обработкой или вручную добавляем в наш регистр ограничение по счетам для отдельных пользователей или для целых групп. Потом заходим под этими пользователями и смотрим план счетов. Счета добавленные в регистр должны исчезнуть. Кстати при большом количестве пользователей и групп обработка нехило подтормаживает, видимо запросик можно пооптимизировать, но лень 🙂

При данном подходе необходимо учитывать множество нюансов:

1) Права «складываются» для разных ролей, т.е. если пользователю доступно несколько ролей, каждой из которых в свою очередь доступно чтение плана счетов, то ограничение на чтение нужно прописывать для каждой роли, иначе если прописать ограничение только для одной роли, пользователь все равно будет видеть все счета, т.к. на другую роль ограничений не наклыдывается.

2) Принадлежность пользователя группе определяется при запуске приложения при инициализации параметров сеанса, поэтому если для группы есть ограничение по счетам, а пользователя только что поместили в эту группу, то ограничение начнет действовать только при следующем перезапуске пользователем 1С.

3) Если выбрать в качестве недоступного счета «корневой» счет, то все его субчета также становятся недоступными, хотя для своих нужд можно изменить текст запроса в соединении (ПО ТекущаяТаблица.Код ПОДОБНО «» + НедоступныеСчета.Счет.Код + «.%»). Также изменив немного текст запроса можно реализовать обратную логику «доступны только указанные счета», но мне нужно было именно так.

4) Ну и самое главное нужно осознавать, что без тщательного тестирования нельзя внедрять подобные решения, т.к. логика работы многих механизмов в различных конфигурациях может запросто нарушиться! Возможно придется во многих запросах добавить слово «РАЗРЕШЕННЫЕ» и т.д. В общем, я Вас предупредил 🙂

Удачи!

51 Comments

sound 13.04.2012 at 07:22

Если некоторым пользователям нужен доступ только к определенным счетам, а видимость данных по другим счетам при этом крайне нежелательна, на помощь приходит RLS

Перейти к публикации

Reply ↓
hulio 13.04.2012 at 07:22

Блиииин, вот я идиот … Почему я раньше не догадался накладывать ограничения не на регистр бухгалтерии, а на план счетов???

Автору плюс за идею ))))

Reply ↓
Raminus 13.04.2012 at 09:03

Очень интересное решение, автору плюс, однозначно!

Reply ↓
sound 13.04.2012 at 14:14
Вот еще немного повторюсь про RLS, смежная так сказать тема, все собирался оформить как статью, но все руки не доходили, хотя в комментариях на форуме уже 2 раза писал. Идея не новая, просто также как вариант решения для динамического изменения прав на справочники для пользователей и групп:

1) Сделал регистр сведений «ДоступКОбъектам», с двумя измерениями

ОбъектМетаданных (тип Строка)

Пользователь (составной тип СправочникСсылка.ГруппыПользователей, СправочникСсылка.Пользователи)

и 4 ресурса булевского типа: Чтение, Добавление, Изменение, Удаление

2) Сделал 4 шаблона в основной роли (ДоступКОбъектам_Чтение, ДоступКОбъектам_Изменение и т.д.), которая есть у всех, вот текст одного, остальные по аналогии:

ДоступКОбъектам_Чтение:
```
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ГДЕ ((НЕ &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ИЛИ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
РегистрСведений.ДоступКОбъектам КАК ДоступКОбъектам
ГДЕ
(ДоступКОбъектам.Пользователь = &ТекущийПользователь ИЛИ ДоступКОбъектам.Пользователь В (&ГруппыТекущегоПользователя))
И ДоступКОбъектам.ОбъектМетаданных = #Параметр(1)
И ДоступКОбъектам.Чтение))
```
Показать
3) Потом ограничиваю у основной рабочей роли пользователей доступ, например, к справочнику «СтатьиЗатрат» (это где RLS):
```
#ДоступКОбъектам_Чтение(«»»СтатьиЗатрат»»»)
```
4) Захожу в режиме предприятия, открываю регистр «ДоступКОбъектам» и в режиме реального времени и добавляю туда

ОбъектМетаданных = «СтатьиЗатрат» (строка пишется либо вручную, либо лучше сделать обработку по редактированию прав)

Пользователь = «Все пользователи» (выбираю предопределенную группу и разрешаю всем только читать)

потом кому-то можно писать, кому то удалять и т.д. Причем можно ограничивать и группам и пользователям, удобно однако 🙂

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

Ссылки на форум где это уже писал: тут и тут

Буду рад если кому-то поможет.

Всем удачи!

Reply ↓
neal 14.04.2012 at 10:53

Автор, а что показывают отчеты типовые отчеты «Оборотно-сальдовая ведомость» и «Анализ субконто»!? Интересно посмотреть картинки, особенно Анализ субконто по Субконто «Физлица». Такую идею в голове рассматривал, но не стал реализовывать, так как считаю что это не будет работать должным образом. Ограничения должны накладываться в первую очередь на регистры, а не на аналитику. Может такой подход кому то и подойдет, у кого это используется — напишите отзывы.

Reply ↓
neal 16.04.2012 at 07:19

(6) HameleonA, проверил, сделал ограничение на плане счетов «Хозрасчетный ГДЕ Хозрасчетный.Ссылка <> ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПерсоналомПоОплатеТруда)» в типовой БП 2.0, и действительно типовые отчеты вроде корректно работают, видимо из-за того что все отчеты построены на виртуальных таблицах.

Но возможность просмотреть по человеку сколько ему было начислено все же остается, написав запрос с использованием двух таблиц «РегистрБухгалтерии.Хозрасчетный» и «РегистрБухгалтерии.Хозрасчетный.Субконто» (это не виртуальные таблицы), в результате в поле счет будет «<Объект не найден> 14:ba6a0df1e75b44914a846a2bfe80b623)», а в поле значение субконто будет указан сотрудник.

Рассматривая задачу закрытия ЗП от пользователей, все же есть отличия между данным подходом, и подходом где отсутствует аналитика на 70 счете, а учет ведется к примеру в ЗУП — при втором подходе, данные в отчетах выглядят более логично, так как отсутствие оборотов по какому то счету, для тех кто анализирует деятельность предприятия в целом, может вызывать много вопросов.

Автору плюс за то что эту идею оформил в статью. И как пожелание — дополнительные скриншоты типовых отчетов (с примером ограничения по какому либо счету) оказались бы полезными.

Reply ↓
sound 16.04.2012 at 09:53

(4) artbear, сам осознаю что реализация не самая изящная, обычно в публикациях стараюсь указывать на косяки, а на этот раз что-то забыл, в общем по пункту 1 критику принимаю. По пункту 2, если кроме типовых обороток юзаются другие отчеты то да, все спрятать при таком подходе не удастся. Возможно придется еще делать механизм для физлиц как в ЗУПЕ. Кстати в ЗУПе реализация шаблонов ограничений уж совсем, ну если и не сложная, то во всяком случае нечитабельная, взять хотя бы шаблон «ОбщееУправлениеДоступом», кто разбирался с ним, надеюсь, меня поймет 🙂

(7) neal, у меня как раз 2-й подход, то есть расчеты ведутся в ЗУПе и выгружаются в бухгалтерию «колхозом», а данным подходом я просто по просьбе гл. бухгалтера закрыл доступ к некоторым счетам отдельным категориям пользователей (кладовщикам), но решил что и для 70-го счета подойдет, извиняюсь если ввел кого-то в заблуждение. Запросом реально можно вытащить информацию, но о существовании таких отчетов многие пользователи просто не догадываются 🙂

Получается что данный подход можно/нужно рассматривать в комбинации с какими-то другими ограничениями.

Reply ↓
sound 16.04.2012 at 09:57

(4) А кстати ПОДОБНО юзать не обязательно, можно ограничиться конкретным счетом:

ПО ТекущаяТаблица.Ссылка = НедоступныеСчета.Счет

Reply ↓
AlexO 16.04.2012 at 10:57

Подход слишком сложен и ненадежен. Не в плане «автор не разобрался», а в плване самой реализации RLS — что-то где-то забыли, что-то где-то криво работает, кому-то разрешили в другой роли — столько всего, что вся «плюсовость» такого подхода при постоянном юзании сводится к нулю.

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

А для разовой реализации «у меня работает, и завтра я увольняюсь» — вполне ))

Reply ↓
sound 16.04.2012 at 11:03

(10) AlexO, поддерживаю 🙂

Reply ↓
AlexO 16.04.2012 at 11:07

+ (11) сам RLS может такого начудить, что все будет закрыто даже тем, кому «разрешено» (роли там перехлестнулись или просто тонкости работы RLS, которые при сложных запросах не отлавливаемы, кроме как переписывать сам запрос), да и если накидать такие огр

Reply ↓
sound 16.04.2012 at 11:14

(12) Ок, уговорили:

Новички и просто не знакомые с RLS даже на уровне типовых RLS-ных запросов — НЕ ПРИМЕНЯТЬ НИ В КОЕМ СЛУЧАЕ!

Reply ↓
sound 16.04.2012 at 11:16

Теперь остается ждать плаксивые комментарии новичков, которые уже внедрили подобное решение и наколотили себе шишек 🙂

Reply ↓
AlexO 16.04.2012 at 11:27

(11)

не в обиду пишу, сам намучился однажды исправлять RLS после того, как один программист прослушал курсы про RLS и наделал, как ему показалось, «типовых» ограничений на справочники и документы — вся база встала колом, 2/3 документов перестали открываться вовсе, остальные — открывались через раз по непонятной схеме (RLS «рулит»).

И сам пока с такой дикой ституацией не столкнулся — был более лоялен к применению и развертыванию «все на RLS».

И запросы, на первый взгляд, были «как типовые» и вроде «правильные» — но когда там соединяется таблица одного регистра с таблицей другого регистра, а там — с третьим, все это в одном запросе, и проконтролировать, какое решение в результате для объекта будет — пока не начнешь работать практически невозможно, да и смысла нет, т.к. причину — где в какой таблице неправильно — не найдешь при таком раскладе.

А потом еще и тормоза выскочили такие, что отчеты, раньше формировавшиеся за 1 минуту, теперь — 15-20 минут.

Решение применил кардинальное — все удалил в топку.

Reply ↓
sound 16.04.2012 at 11:44

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

P.S. Кстати 1-й раз решился на статью, пусть и маленькую 🙂

Reply ↓
AlexO 16.04.2012 at 11:53

(14)

единоразово и в узких рамках, если все делать по статье — заработает с высокой долей вероятности ))

Вот если будут расширять дальше на более чем один отчет/документ/объект копированием/вставкой в другие запросы без понимания принципов работы RLS и последствий — вот тут беда, вот тут и начинается свистопляска.

В чем и проблема с RLS — оно не работает по принципу «сложения прав», а либо да, либо — нет (а как у ней там наложатся условия, кто проследит?), либо есть разрешение, либо — нет, и самое трудное — понять, где и в какой роли/праве/условии отрабатывает запрет. И все это при отсутствии вменяемых инструментов отладки RLS-запросов.

Reply ↓
sound 16.04.2012 at 12:06

(17) AlexO, вижу, что мое мнение с Вашим совпадает, полностью согласен со всем вышеперечисленным.

Я в ЗУПе постоянно борюсь с этими ограничениями, сотрудники (одно физлицо) из одной организации переходят в другую, а там другие расчетчики, они хотят «только свои данные», а экономисты головной организации хотят соответственно видеть консолидированные данные, и если ограничения по сотрудникам еще работают более менее так как мне нужно, то когда дело доходит до налогов, то тут порой возникают очень трудноотыскиваемые запарки, особенно «нравится» копаться в ЗУПовских километровых запросах и понимать кому там какого доступа не хватает или наоборот «лишка».

Reply ↓
neal 16.04.2012 at 12:19

Кстати в тему RLS в последней версии 1С:Документооборот подход изменился в корне, и нацелен на повышение производительности, да и помоему разбираться проще, теперь в роли запрос совсем краткий, а все разрешения прописаны в регистрах. Правда думаю объем базы может вырасти значительно.

Reply ↓
sound 16.04.2012 at 12:36

(19) neal, у меня Документооборот внедрен, но все его функции сводятся примерно к такому «все письма в одном месте», то есть можно сказать заюзан по минимуму и реализацию ограничений, честно скажу, даже не смотрел, надо будет поразбираться. Вот за ЗУП могу сказать, что для одного только определения принадлежности пользователя группе в запросе используются отдельные подзапросы, не очень кстати читабельные, хотя для той же цели в Бухгалтерии КОРП есть параметр сеанса ГруппыТекущегоПользователя, и запросы на порядок короче и понятней, не понятно почему также не сделать и в ЗУПе, наверно потому что «если солнышко всходит на востоке и заходит на западе, то ничего трогать не нужно» :).

Вот то, что я описал в (3) у меня юзается на 4-х справочниках, хотя тоже понимаю, что не самая красивая реализация.

Reply ↓
AlexO 16.04.2012 at 12:38

(18)

да-да, и все это еще при том, что, отчасти — из-за отсутствия суммирования настроек RLS (для новичков ремарка: в RLS нет доступного для проверки суммирования прав подобно тому, что есть в ролях — «если одна роль запрещает, а другая разрешает — то разрешено», RLS применяется к записи БД сразу и целиком все, что есть, без «логической» последовательности запросов RLS, и в этом её непредсказуемость), отчасти (собственно, это следствие первого ограничения) — что применить можно только один запрос, и, следовательно, чтобы поставить еще одно условие на событие (чтение-запись), нужно менять старый запрос.

Так что самое первейшее и наиважнейшее правило RLS — делать ограничение/запрос «один объект — одна роль», не больше.

Ну, а «нулевое» правило пользования RLS — не пользовать его глубоко без опыта и набитых шишек ))

Reply ↓
AlexO 16.04.2012 at 12:39

(19) neal,

«прописаны в регистрах» — это в коде? Потому как RLS без роли назначить нельзя в принципе ))

Reply ↓
AlexO 16.04.2012 at 12:43

(20)

есть можно сказать заюзан по минимуму и реализацию ограничений

— это как раз второе правило пользования RLS — «всегда использовать ограничения прав по-минимуму и только самое необходимое» )

запросы на порядок короче и понятней, не понятно почему также не сделать и в ЗУПе

хотя вот в УПП при переходе от 1.2 к 1.3 запросы RLS были кардинально переписаны — причем не в сторону улучшения читабельности…

Так что, если сделают что-то с RLS и в ЗУП — то не в сторону упрощения, увы…

Reply ↓
AlexO 16.04.2012 at 12:49

Т.е. что изменилось в запросах УПП: если раньше там были «кошмарные трех-четырехэтажные», но все-таки разбираемые запросы на уровне «ЛОЖЬ-ИСТИНА-ЛОЖЬ-ЛОЖЬ-ИСТИНА-ЛОЖЬ» и можно было «выплыть» наверх из подзапросов и проследить, как «эхо наше отзовется», т.е. если начальное значение будет таким, то что будет на выходе у RLS, то теперь — все усложнилось в разы: запросы все такие же многоэтажные, но уже сравниваются не «истина» или «ложь» в явном виде, а значения кучи таблиц (а какие там эти значения подцепляет — поди разберись) разных регистров настроек, да еще некоторые вообще закрыты для явного просмотра содержимого. И вот сидишь и смотришь, гадаешь, запускаешь, и ждешь, а что получится…

Reply ↓
AlexO 16.04.2012 at 13:08
Вот нашел на мисте пример дурости и непонимания основ и нюансов 1с:
```
МойДокумент ИЗ Документ.МойДокумент КАК МойДокумент
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МойДокумент.Ссылка КАК Ссылка,
МойДокумент.Ответственный КАК Ответственный
ИЗ
Документ.МойДокумент КАК МойДокумент) КАК ВложенныйЗапрос
ПО МойДокумент.Ссылка = ВложенныйЗапрос.Ссылка
ГДЕ ВложенныйЗапрос.Ответственный = &ТекущийПользователь
```
— товарищ утверждает, что якобы получает для RLS данные с текущей формы, данные «до изменения», и сравнивает их с целью разрешить текущий ввод на форме документа или отменить.

Это при том, что в платформе 1с в принципе нет разделения на «старые» и «новые» данные (а только на «данные на форме, не записано» (и это не «фича» платформы, а следствие промежуточного хранения в оперативной памяти, к самой платформе и её функциональности не имеющее вообще никакого отношения, ну да, кроме как сделали чтение текущих данных объекта; т.е. даже можно сказать — в 1с подобного разделения на уровне БД (чтобы, как положено, с контролем, проверками, откатами, сравнением и т.д.) и нет — есть только «данные в базе», и эти данные единственно верны и легитимны (конечно, опять же в рамках платформы 1с — со всеми её непроверками «судьбы» записи в БД: удачно записана, неудачно, куда и как, полностью, неполностью, записана… Т.е. все просто: запись отослана «на запись» в БД? — да. — тогда она априори записана верно и в полном объеме, и можно её пользовать для дальнейших целей)) и «данные в базе», к первым RLS не имеет вообще никакого доступа — потому как он в принципе ограничивает записи БД, а не данные в памяти (текущие на форме); далее, запрос сделан к ТАБЛИЦАМ ДОКУМЕНТОВ (он-то думает, что к текущей, которая в памяти в этот момент, но это необязательно — кто знает, при каких отборах и манипуляциях с документами уже в базе у него данное событие — и данный RLS, — сработают, и что при солидной выборке документов вообще вгонит в ступор 1с), так еще ко всему перечисленному в запросе к записям таблицы документа в БД через <дурость и> вложенный запрос добавляются соседние записи ЭТОЙ ЖЕ ТАБЛИЦЫ того же самого документа.

Но товарищ утверждает, что познал истину (как многие и многие на мисте, причем с солидным стажем «узкого» программиирования), и у него все здорово работает. Без вложенного запроса не работает, а со вложенным — работает. Хотел расписать свою теорию «почему работает», но что-то не расписал…

Т.е. он, конечно, что-то такое получает в RLS из
```
МойДокумент ИЗ Документ.МойДокумент
```
но что это за данные, откуда они (с какого момента времени редактирования документа сняты), и насколько соответствуют желаемым «данные, которые ввел пользователь, и видит их перед собой на экране» — неизвестно никому, кроме платформы, и то, станут ей известны при выполнении ))

Reply ↓
tim_taler 18.04.2012 at 13:26

Без обид, но в очередной раз изобретен неустойчивый велосипед с одним колесом, едущий до первой кочки.

очевидно, что неидимость элемента плана счетов не есть невидимость движений по нему — расшифровка, какой-нить

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

вместо внятного «70» будет светиться «объект не найден». Хотя спасает, конечно, от половины пользователей —

с нулевой квалификацией, которые ни шага лево-право от заученной мантры.

ЗЫ-ОФФ: в честной компании нечего оклады скрывать! 🙂

Reply ↓
sound 18.04.2012 at 13:47

(26)

Хотя спасает, конечно, от половины пользователей

— будем считать, что так и есть.

в честной компании

— а что и такие существуют? 🙂

Reply ↓
cpo-it 07.06.2012 at 10:40

спасибо

Reply ↓
sound 07.06.2012 at 11:07

(28) cpo-it, если пользователю доступна лишь одна роль «Бухгалтер», то для этой роли на чтение плана счетов нужно установить ограничение доступа к данным (как на картинке в описании). Попробуйте сделать все сначала по инструкции, по идее там дана исчерпывающая рекомендация.

P.S. Если честно я бы не советовал Вам использовать данную технологию, т.к. у нее очень уж много нюансов.

Reply ↓
glek 12.06.2012 at 09:44

Идея, конечно, интересная. Но. Информация по складам/товарам/контрагентам нормально фильтруется типовыми механизмами. Ограничение по ЗП мы накладывали удалением субконто со счета ЗП (разумеется это касается сугубо УПП): изменений меньше, работает быстрее, чем с РЛС, и настраивать проще ))). Плюс за идею

Reply ↓
WKBAPKA 12.06.2012 at 09:49

идея бредовая… если просто наложить RLS на план счетов, ничего не получиться… нормального результата не будет

первое: итоги в ОСВ будут с учетом скрытых счетов ох, как это будет сбивать с толку

второе: расшифровки, например, карточка счета, анализ счета и т.п. лихо покажет корреспонденции по скрытым счетам

третье: если нужно что то скрыть надежно, RLS нужно накладывать на сам регистр бухгалтерии… т.к. для регистра бухгалтерии RLS будет работать только для измерений, достаточно добавить одно измерение, например, ПроводкаПоЗП с типом булево, внести небольшое изменение в набор движений регистра и написать на RLS простое ограничение… и будет счастье… а можно пойти еще дальше, сделать справочник или перечисление с разделами учета, типа, ЗП, Дебиторы, Кредиторы, соответственно добавить измерение и накладывать на него ограничение, и тогда уже можно играться правами как хочешь…

Reply ↓
WKBAPKA 12.06.2012 at 09:50

(30) glek,

есть более простой и изящный способ скрыть данные, не удаляя субконто…

Reply ↓
WKBAPKA 12.06.2012 at 09:53

(17) AlexO,

о чем вы? если накладывать ограничение, нужно просто подходить к этому грамотно… приоритетнее всегда права у которых прав больше…

Reply ↓
glek 12.06.2012 at 10:14

(32) WKBAPKA, Поделитесь, если не жалко ))

Reply ↓
WKBAPKA 12.06.2012 at 10:24

т.к. для регистра бухгалтерии RLS будет работать только для измерений, достаточно добавить одно измерение, например, ПроводкаПоЗП с типом булево, внести небольшое изменение в набор движений регистра и написать на RLS простое ограничение…

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

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

Reply ↓

WKBAPKA 12.06.2012 at 10:35

Счет661 = ПланыСчетов.Хозрасчетный.РасчетыПоОплатеТруда;
Если (Проводка.СчетДт.Родитель = Счет661) ИЛИ (Проводка.СчетКт.Родитель = Счет661) Тогда
Проводка.ПроводкаПоЗП = Истина;
Иначе
Проводка.ПроводкаПоЗП = Ложь;
КонецЕсли;

Показать

Reply ↓

WKBAPKA 12.06.2012 at 10:39

(6) HameleonA,

да вы шо? а если внимательно присмотреться к итогам ОСВ вот засада получиться!

Reply ↓
WKBAPKA 12.06.2012 at 10:43

(8)

artbear, сам осознаю что реализация не самая изящная, обычно в публикациях стараюсь указывать на косяки, а на этот раз что-то забыл, в общем по пункту 1 критику принимаю. По пункту 2, если кроме типовых обороток юзаются другие отчеты то да, все спрятать при таком подходе не удастся. Возможно придется еще делать механизм для физлиц как в ЗУПЕ. Кстати в ЗУПе реализация шаблонов ограничений уж совсем, ну если и не сложная, то во всяком случае нечитабельная, взять хотя бы шаблон «ОбщееУправлениеДоступом», кто разбирался с ним, надеюсь, меня поймет 🙂

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

Reply ↓
WKBAPKA 12.06.2012 at 10:45

(21) AlexO,

если у пользователя две роли, у одной наложено ограничение на некоторый объект, у другой роли нет и не написано ГДЕ Ложь, тогда ограничения работать не будут… читаем желтую книжечку

Reply ↓
sound 13.06.2012 at 09:33

Вот уж не думал, что многих так цепанет 🙂

(31) WKBAPKA, мне уже если честно слегка поднадоело оправдываться в комментариях, прочитав которые, кстати, можно для себя сделать вывод о целесообразности применения данного подхода в том или ином виде.

Повторяю: так не спрятать по нормальному ничего!

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

Ваш голос я увидел, позиция ясна.

Reply ↓
WKBAPKA 13.06.2012 at 10:01

(40)

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

Основная опасность данного подхода, это мнимая безопасность и обычный бухгалтер, с набором обычных стандартных бух. отчетов, со всеми ограничениями, легко получит необходимую ему информацию. Т.е. тем самым не решается главная цель — скрыть данные от посторонних глаз!

Reply ↓
WKBAPKA 13.06.2012 at 10:04

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

в том то и дело, что написано вот как:\r

Если некоторым пользователям нужен доступ только к определенным счетам, а видимость данных по другим счетам при этом крайне нежелательна, на помощь приходит RLS

Самый простой пример — в базе хранятся данные по зарплате (с разбивкой по сотрудникам, т.е. не сводно), и главный бухгалтер или руководитель хочет чтобы 70-й счет мог видеть только расчетчик. Еще пример — менеджер смотрит остатки на складах по «оборотке» только по 10-му счету или по 41.01, остальные счета для него можно скрыть. Да мало ли у кого какие запросы 🙂

так что, писали статью с примерами, как надо делать 😉

Reply ↓
WKBAPKA 13.06.2012 at 13:10

http://infostart.ru/public/139581/

чтобы не распылятся

Reply ↓
imagoman 13.06.2013 at 07:31

простое, элегантное решение. автор спасибо. плюс)

Reply ↓
b-dm 07.12.2015 at 16:15

ВЕЩЬ! Воспользуюсь при необходимости…прятать «зарплатные» счета — главная русская забава директоров!

Reply ↓
dmitry1c1991 19.07.2016 at 13:55

А не проще на чтение в ролях по прочим полям плана счетов просто прописать Хозрасчетный ГДЕ (Хозрасчетный.Код <> «ИсключаемыйКодСчета») ?

У меня так работает без проблем уже 5 лет .

Reply ↓
dmitry1c1991 19.07.2016 at 14:00

(4) artbear, А для чего там вообще юзается Подобно , если в регистре НедоступныеСчета есть ссылка на сам счет . Не понимаю для чего автор сделал в соединении условие «Подобно» , а не прямой ссылкой «по Хозрасчетный.Ссылка = НедоступныеСчета.Счет»

Reply ↓
sound 19.07.2016 at 17:30

(48) dmitry1c1991, ПОДОБНО там видимо было для того чтобы можно было в регистре прописать, скажем 76 счет (одна запись) и на все субсчета бы это тоже распространилось, хотя конечно потеря скорости налицо. Я уже столько критики тут «выслушал» и со многим согласился в своей неправоте, и уже это просто наверно тут висит как материал для рассуждений. И вообще публикации то уж 5-й год пошел. Я когда смотрю то что я в институте писал, мне вообще плакать охота, дак что теперь застрелиться чтоли :)))

Reply ↓
roofless 01.11.2017 at 11:21

(47) какая конфа? в БП 3.0 не взлетело так, в журнале проводок «объект не найден» а в осв и карточке счета всё показывается

Reply ↓
roofless 02.11.2017 at 07:57

(50) вроде нашел решение для этих типовых отчетов https://infostart.ru/public/556330/

Reply ↓
script 01.03.2018 at 17:27
Если РегистрСведений.НедоступныеСчета для измерения Пользователь оставить один тип значения пользователь и

в запросе сделать сравнение с счетом через вид сравнения «=» (равно) и такое же вид сравнения для пользователя, то запрос можно упростить до:
```
Хозрасчетный ИЗ ПланСчетов.Хозрасчетный КАК Хозрасчетный
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НедоступныеСчета КАК ЗапрещенныеБухСчета
ПО Хозрасчетный.Ссылка = ЗапрещенныеБухСчета.Счет
И (ЗапрещенныеБухСчета.Пользователь = &ТекущийПользователь)
ГДЕ ЗапрещенныеБухСчета.Пользователь ЕСТЬ NULL 
```
То все начинает нормально работать.

Reply ↓
user640247 03.06.2019 at 16:17

создала новые права и в правах «Пользователь»

наложила ограничения доступа к данным в самом плане счетов:

ОсновнойПланСчетов ГДЕ НЕ ОсновнойПланСчетов.Код ПОДОБНО «%70%»

В итоге в плане счетов не видно и в отчетах тоже.. вроде всё как надо…

Reply ↓

Прячем счета из плана счетов

Related Posts

51 Comments

Leave a Comment Отменить ответ