Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Подскажите как вернее решить задачу? РИБ. Ограничение видимости данных.

Подскажите как вернее решить задачу? РИБ. Ограничение видимости данных.
Я
   live in sky dreams
 
29.03.18 - 10:56
Есть ЗУП 3.1
Выгружаю из нее начальный образ для периферии. Периферия в данном случае - удаленное подразделение. Обязанности у удаленного подразделения невеликие - вносить наряды. Прав на "аудит" базы - еще меньше.

Возникла избитая задача. Ограничить видимость данных в удаленном подразделении. Вот чтобы видели только свои данные (документы своего подразделения) и не более того.

Надумал 3 варианта..

1) Менять правила обмена в КД. ПВД. Не выгружать инфу по признакам. Гемор + из обновления в обновление потом это таскать.. Отбросил эту идею.

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

3) Состряпать расширение для модуля (какого ?) чтобы документы, не относящиеся к определенному подразделению не выгружались. Звучит не так страшно в перспективе поддержки, но пока не нахожу такой модуль.. Еще ищу.

Какие еще могут быть варианты более оптимальные для наименее кровавого решения задачи?
 
 
   Otark
 
1 - 29.03.18 - 11:00
Просто анализировать объект при записи и выкидывать тех получателей куда он ехать не должен.
   Галахад
 
2 - 29.03.18 - 11:01
Поиск в Гугле по ПриОтправкеДанныхПодчиненному
   Otark
 
3 - 29.03.18 - 11:05
Профессиональная разработка в системе 1С:Предприятие. Гуглится лего, второй том, страница 486
 
Процедура ПередЗаписью() 
Узел = ПланыОбмена.УдаленныеСклады.НайтиПоКоду("Оптовый"); Объект.ОбменДанными.Получатели.Удалить(Узел); КонецПроцедуры

   Галахад
 
4 - 29.03.18 - 11:06
(3) Много вхождений. (2) проще.
   Otark
 
5 - 29.03.18 - 11:08
(4)Чего много?
   live in sky dreams
 
6 - 29.03.18 - 11:08
На сколько я вас понял, коллеги, (3) уточнение к (2) ?
   Галахад
 
7 - 29.03.18 - 11:10
(5) Точек вхождения где нужно правки вносить.

(6) Нет.
   live in sky dreams
 
8 - 29.03.18 - 11:23
(7) а, я понял, регистрация не равно отправка..

Спасибо
   Otark
 
9 - 29.03.18 - 11:27
(7)Подписка на событие?
   Otark
 
10 - 29.03.18 - 11:31
+(9)Это кстати решает проблему(1) и отвечает на вопрос(3) из (0)
 
 Рекламное место пустует
   live in sky dreams
 
11 - 29.03.18 - 11:37
Ох ты ж ничоси!!! И писать ничего не нужно!
http://prntscr.com/ixwxsb

Ааааа!!! Как туда добраться? При настройке обмена РИБ можно указать только организации, выбрать подразделение не получается.. http://prntscr.com/ixx081
   Serg_1960
 
12 - 29.03.18 - 11:55
Ну так погугли в конфигурации "ИспользоватьОтборПоПодразделениям", в чём проблема? :)

Отсутствие выбора подразделения может быть связано с настройкой работы с обособленными подразделениями.
   live in sky dreams
 
13 - 29.03.18 - 12:01
(12) Да гуглил конечно же.. Ссылок масса, все на проверку значения
   live in sky dreams
 
14 - 29.03.18 - 12:33
Регистрация обособленного подразделения не сделала видимой группу настроек подразделений..
Копаюсь в коде ((
   Cyberhawk
 
15 - 29.03.18 - 12:34
Какой в *опу RLS в периферийной базе, когда проще туда не отправлять ненужные данные?
   live in sky dreams
 
16 - 29.03.18 - 12:58
На форме настройки обмена есть группа ГруппаНастройкиВыгрузкиДанныхПоПодразделениям, содержащая в себе элементы управления настройкой синхронизации по подразделениям.

Видимость ее по умолчанию Ложь. ПриСоздании, ПриОткрытии формы видимость этой группы в истина не устанавливается нигде

Такое ощущение, что это или заготовка для будущих "функционалов" или отключенный кусок из КОРП, что скорее всего..

А я уж было обрадовался, что не придется корежить конфу..
   live in sky dreams
 
17 - 29.03.18 - 13:02
(15) дык я ж русским по белому пишу "Тоже отпало".
Просто перечислял что отпало и почему, чтобы не было лишних вопросов "а это пробовал? А че не пробовал?"
   Cyberhawk
 
18 - 29.03.18 - 14:22
(17) Много букв. Я дочитал только до того момента, где ты под номером один (в КД) отбросил эту идею. А идея неплоха, между прочим.
   Serg_1960
 
19 - 29.03.18 - 14:58
(15) "не отправлять ненужные данные" - это тоже, знаете ли, не всегда выход.

Вот, например, нужно оформить заказ покупателя и зарезервировать товар на складе. А если этот товар на том складе, чьи остатки не мигрируют в обмене и/или нет документов, формирующих эти остатки? Проблема... нужен RLS.

Или, например, исправили документ "из центра", учетные регистры "поплыли" и стало возможным сформировать такой документ, который "в центре" породит ошибку. Проблема...нужно как-то это контролировать, выявлять и устранять - RLS нужен и/или двунаправленный обмен.
   Cyberhawk
 
20 - 29.03.18 - 17:08
(19) Из этих примеров что-то понятнее не стало, зачем в периферийной базе нужен РЛС
   live in sky dreams
 
21 - 29.03.18 - 17:10
(18)Да, плюсы и минусы есть у каждого подхода. Сейчас вот пытался с нахрапа взять идею из (2)
Много нюансов выплыло.. Хотя изначально она казалась довольно простой в реализации.
   Serg_1960
 
22 - 29.03.18 - 17:20
(20) Из этих примеров становится понятным, что в обмен нужно включать достаточно большой объём данных, не имеющих непосредственное отношение к подразделению, но необходимых для выполнения озвученной задачи. И, соответственно, по этим данным, так или иначе, необходимо ограничивать доступ в подчиненном узле.
   Cyberhawk
 
23 - 29.03.18 - 17:31
(22) "по этим данным, так или иначе, необходимо ограничивать доступ в подчиненном узле" // Зачем к ним ограничивать доступ пользователей, если они нужны для выполнения пользователями каких-то функций в инфобазе?
   live in sky dreams
 
24 - 29.03.18 - 17:47
Веселье получается при перегрузке документа "Начисление зарплаты". Пока не беру РС, РР, РН.. Просто документ..

"Подразделение" из шапки нам информативности не прибавляет. В табличных частях документа есть реквизит "подразделение", вот его заполненность для нас более интересна.

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

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

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

1) Подразделение. Тут все ясно.
2) Если не нашли подразделение - ищем реквизит с типом Сотрудник и определяем принадлежность к подразделению.
3) Если не нашли сотрудник - ищем реквизит с типом Физ. лицо. Вот тут веселее.. Тут мы должны найти актуальных сотрудников, связанных с этим физлицом, определить подразделение этих сотрудников. И если подразделение нас устраивает - тогда допускаем к перегрузке.

Это только на глаз.. При стольких проверках интересно сколько будет выполняться обмен..
   Фрэнки
 
25 - 29.03.18 - 18:07
(24) а все вот эти вышеописанные потуги на какой конфиге?

ага. ЗУП 3.1, но не КОРП. Если по аналогии в функционале, различающемся в БП3 и в БП3-КОРП - могу только подтвердить, что проблема с использованием обособленных подразделений гораздо серьезней, чем кажется с беглого просмотра. Пришлось сразу купить КОРП, а уже после этого нормально ставить учет с использованием разных регистраций в налоговых органах.
Собственно, проблема не в том, что нужна какая-то особенная налоговая, а именно в том, что по коду разбросано в самых неожиданных местах ограничение функциональности, реализованной в версии КОРП, а затем отключенной при подготовке типовой.

Т.е. я к тому, что если у вас в самом деле присутствуют обособленные, то не портите себе нервы - купите КОРП.
   live in sky dreams
 
26 - 29.03.18 - 19:03
(25) Прям обособленных нет.
Есть удаленное подразделение на общем балансе, на бухгалтера которого возложена функция заводить сдельные наряды (данные для расчета заработной платы), заводить кадры этого подразделения и говорить сотрудникам кто из них сколько заработал. Печатать ведомости на выдачу.

гл бух очень не хочет чтобы этот бухгалтер видел остальные доки и начисления.

С первого взгляда задача не казалась сложной, пока не начал перебирать инструментарий ее решения))))))
   Cyberhawk
 
27 - 29.03.18 - 19:57
(26) В чем проблема-то? Он колотит документы в своей базе, они поступают в главную базу.
   Фрэнки
 
28 - 29.03.18 - 20:50
(26) удаленное - оно и есть обособленное без выделенного баланса.

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

Такие цели (ограниченный доступ пользователей) можно достичь другим способом, без заморочек со взломом типового содержимого конфигурации.
   Фрэнки
 
29 - 29.03.18 - 20:52
Но тема интересная. Надо будет на досуге покопаться в 3.1 и посмотреть, что там есть готового под такую задачу. Что-то подозреваю должно быть
   live in sky dreams
 
30 - 30.03.18 - 08:53
(28) сейчас подразделений 2
ВД: Сельхоз, не известно заранее в следующем году в каком еще поселке появится бухгалтер. Не известно как там будет с интернетом.

Сейчас связь в поселках и полях не устойчивая. Они сидят на 3G "свистках". rdp в таких условиях - наказание, там негородские скорости и качество.
Да и в головном могут просто свет рубануть на пол дня запросто. Или интернет пропадет. И внешнего IP на статике нет.
РИБ появился именно из этих соображений. Чтобы любой в любой момент времени не зависимо от интернета мог работать автономно.

Но интересно про "другой способ" узнать подробнее. В головном база на скуле, в принципе, если аккуратно, то можно RLS задействовать для решения задачи. Вы про на это намекали?

(29) Взламывать типовое я и не собирался. Как максимум - дополнить расширением.
   Йохохо
 
31 - 30.03.18 - 08:58
(24) они с радостью согласятся не указывать подразделение в тч, надо просто придушить перфекционизм чутка
   live in sky dreams
 
32 - 30.03.18 - 09:03
(31) Думал об этом. Это сильно облегчило бы мне, но тогда вместо 1 документа им придется оформлять документов от 5 до 12. В зависимости от того на какую организацию делают расчет. Это пусть и незначительное, но увеличение трудозатрат. Странная автоматизация))
   Йохохо
 
33 - 30.03.18 - 09:12
(32) сделка то будет ходить как положено. И гб спокойна, если в начислении кто то лишний, то в филиал не улетит
 
 
   live in sky dreams
 
34 - 30.03.18 - 09:22
(33) Сделка да. Я изначально шаблоны оформил так что по каждому подразделению отдельный документ ввода данных для расчета зп.

Но есть еще документы начисления. Их придется оформлять не мало.
   Фрэнки
 
35 - 30.03.18 - 09:42
(34) если подразумевается, что в центральной базе начисление идет на все подразделения в общую ТЧ, то РЛС, скорей всего, не поможет.

Но с другой стороны, если на РИБ будет выдаваться "испорченная версия" объекта, то этот объект ни в коем случае не должен возвращаться обратно. Типовое решение РИБ такие фокусы "из коробки" не даст.

Все известные мне примеры практической работы с начислением ЗП в центре для удаленных подразделений = заполнить без всякого РИБ некую шаблонную форму Табеля и передать ее для обработки в голову. А из головы получить в обратку возможно Ведомость по подразделению, но не факт, что даже ее дают (персональные данные, однако, с тайнами в схеме мотивации), но обязательно отдать расчетные листки, причем, персонально (сейчас это в электронной почте работает)
   Фрэнки
 
36 - 30.03.18 - 09:46
т.е. нюансы РИБ и ограничение данных в инструментальном смысле штука интересная. А вот в практическом, в контексте организации расчетов зарплаты для удаленных подразделений - это тупиковое решение, т.к. Пользователи в ней работать не смогут и не станут.
   Сияющий в темноте
 
37 - 30.03.18 - 09:52
Один документ для нескольких подразделений нельзя и даже бессмысленно,как бы вы его не ограничили,в подразделениях править его нельзя,причем даже свою часть,т.к.вернуться назад в общем случае могут две версии одного документа.
деление на части можно рассмотреть,но это очень сложный в реализации процесс,особенно,обработка возврата части в голову,когда ее нужно подстыковать в основной документ,заменив строки данного подразделения на то,что прилетело из удаленки
   live in sky dreams
 
38 - 30.03.18 - 10:48
Доки начисления ни в коем случае не меняются в периферии. Они туда приплывают как регистратор записей регистра, вынуждено.
Вот вопрос.. если для документа при попытке отправки передавать "Игнорировать", то записи регистра без регистратора перейдут в периферию (пусть даже с белибердой в поле регистратор) или нет? Достаточно ли будет этой кривой информации для просмотра информации о начислениях сотрудников?

А записи регистра нужны для распечатывания расчетного листка работника. То есть для ознакомления работника с информацией сколько он заработал.
   Cyberhawk
 
39 - 30.03.18 - 10:56
(38) Перейдут
   Cyberhawk
 
40 - 30.03.18 - 10:57
"для просмотра информации о начислениях сотрудников"// Зависит от прикладного кода. Если он в поля регистратора не лезет, то проблем нет.
В Рознице 1, например, движения чеков ККМ по регистру остаткам товаров мигрируют без регистраторов (самих чеков).
   live in sky dreams
 
41 - 30.03.18 - 11:06
Ну да, смотря как запросы написаны и обработчики результата..
Гляну ка что у нас в расчетных листках.
   Cyberhawk
 
42 - 30.03.18 - 11:08
Ты сделай проще - грохни в узле регистраторы без контроля ссылок и пощелкай нужные в работе формы / отчеты на предмет ошибок
   live in sky dreams
 
43 - 30.03.18 - 11:09
(42) Да, точно, так будет быстрее и точнее. Спасибо, попробую
   arsik
 
44 - 30.03.18 - 11:12
(43) Зачем вообще переносить документ "Начисление зарплаты"?
Он в подразделении ненужен. Просто добавь рассылку расчетных листков в центральной юазе.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует