Есть ЗУП 3.1
Выгружаю из нее начальный образ для периферии. Периферия в данном случае - удаленное подразделение. Обязанности у удаленного подразделения невеликие - вносить наряды. Прав на "аудит" базы - еще меньше.

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

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

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

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

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

Какие еще могут быть варианты более оптимальные для наименее кровавого решения задачи?

Просто анализировать объект при записи и выкидывать тех получателей куда он ехать не должен.

Поиск в Гугле по ПриОтправкеДанныхПодчиненному

Профессиональная разработка в системе 1С:Предприятие. Гуглится лего, второй том, страница 486

Процедура ПередЗаписью()
Узел = ПланыОбмена.УдаленныеСклады.НайтиПоКоду("Оптовый"); Объект.ОбменДанными.Получатели.Удалить(Узел); КонецПроцедуры


(3) Много вхождений. (2) проще.

(4)Чего много?

На сколько я вас понял, коллеги, (3) уточнение к (2) ?

(5) Точек вхождения где нужно правки вносить.

(6) Нет.

(7) а, я понял, регистрация не равно отправка..

Спасибо

(7)Подписка на событие?

+(9)Это кстати решает проблему(1) и отвечает на вопрос(3) из (0)

Ох ты ж ничоси!!! И писать ничего не нужно!
http://prntscr.com/ixwxsb

Ааааа!!! Как туда добраться? При настройке обмена РИБ можно указать только организации, выбрать подразделение не получается.. http://prntscr.com/ixx081

Ну так погугли в конфигурации "ИспользоватьОтборПоПодразделениям", в чём проблема? :)

Отсутствие выбора подразделения может быть связано с настройкой работы с обособленными подразделениями.

(12) Да гуглил конечно же.. Ссылок масса, все на проверку значения

Регистрация обособленного подразделения не сделала видимой группу настроек подразделений..
Копаюсь в коде ((

Какой в *опу RLS в периферийной базе, когда проще туда не отправлять ненужные данные?

На форме настройки обмена есть группа ГруппаНастройкиВыгрузкиДанныхПоПодразделениям, содержащая в себе элементы управления настройкой синхронизации по подразделениям.

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

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

А я уж было обрадовался, что не придется корежить конфу..

(15) дык я ж русским по белому пишу "Тоже отпало".
Просто перечислял что отпало и почему, чтобы не было лишних вопросов "а это пробовал? А че не пробовал?"

(17) Много букв. Я дочитал только до того момента, где ты под номером один (в КД) отбросил эту идею. А идея неплоха, между прочим.

(15) "не отправлять ненужные данные" - это тоже, знаете ли, не всегда выход.

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

Или, например, исправили документ "из центра", учетные регистры "поплыли" и стало возможным сформировать такой документ, который "в центре" породит ошибку. Проблема...нужно как-то это контролировать, выявлять и устранять - RLS нужен и/или двунаправленный обмен.

(19) Из этих примеров что-то понятнее не стало, зачем в периферийной базе нужен РЛС

(18)Да, плюсы и минусы есть у каждого подхода. Сейчас вот пытался с нахрапа взять идею из (2)
Много нюансов выплыло.. Хотя изначально она казалась довольно простой в реализации.

(20) Из этих примеров становится понятным, что в обмен нужно включать достаточно большой объём данных, не имеющих непосредственное отношение к подразделению, но необходимых для выполнения озвученной задачи. И, соответственно, по этим данным, так или иначе, необходимо ограничивать доступ в подчиненном узле.

(22) "по этим данным, так или иначе, необходимо ограничивать доступ в подчиненном узле" // Зачем к ним ограничивать доступ пользователей, если они нужны для выполнения пользователями каких-то функций в инфобазе?

Веселье получается при перегрузке документа "Начисление зарплаты". Пока не беру РС, РР, РН.. Просто документ..

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

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

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

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

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

Это только на глаз.. При стольких проверках интересно сколько будет выполняться обмен..

(24) а все вот эти вышеописанные потуги на какой конфиге?

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

Т.е. я к тому, что если у вас в самом деле присутствуют обособленные, то не портите себе нервы - купите КОРП.

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

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

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

(26) В чем проблема-то? Он колотит документы в своей базе, они поступают в главную базу.

(26) удаленное - оно и есть обособленное без выделенного баланса.

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

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

Но тема интересная. Надо будет на досуге покопаться в 3.1 и посмотреть, что там есть готового под такую задачу. Что-то подозреваю должно быть

(28) сейчас подразделений 2
ВД: Сельхоз, не известно заранее в следующем году в каком еще поселке появится бухгалтер. Не известно как там будет с интернетом.

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

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

(29) Взламывать типовое я и не собирался. Как максимум - дополнить расширением.

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

(31) Думал об этом. Это сильно облегчило бы мне, но тогда вместо 1 документа им придется оформлять документов от 5 до 12. В зависимости от того на какую организацию делают расчет. Это пусть и незначительное, но увеличение трудозатрат. Странная автоматизация))

(32) сделка то будет ходить как положено. И гб спокойна, если в начислении кто то лишний, то в филиал не улетит

(33) Сделка да. Я изначально шаблоны оформил так что по каждому подразделению отдельный документ ввода данных для расчета зп.

Но есть еще документы начисления. Их придется оформлять не мало.

(34) если подразумевается, что в центральной базе начисление идет на все подразделения в общую ТЧ, то РЛС, скорей всего, не поможет.

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

Все известные мне примеры практической работы с начислением ЗП в центре для удаленных подразделений = заполнить без всякого РИБ некую шаблонную форму Табеля и передать ее для обработки в голову. А из головы получить в обратку возможно Ведомость по подразделению, но не факт, что даже ее дают (персональные данные, однако, с тайнами в схеме мотивации), но обязательно отдать расчетные листки, причем, персонально (сейчас это в электронной почте работает)

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

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

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

А записи регистра нужны для распечатывания расчетного листка работника. То есть для ознакомления работника с информацией сколько он заработал.

(38) Перейдут

"для просмотра информации о начислениях сотрудников" // Зависит от прикладного кода. Если он в поля регистратора не лезет, то проблем нет.
В Рознице 1, например, движения чеков ККМ по регистру остаткам товаров мигрируют без регистраторов (самих чеков).

Ну да, смотря как запросы написаны и обработчики результата..
Гляну ка что у нас в расчетных листках.

Ты сделай проще - грохни в узле регистраторы без контроля ссылок и пощелкай нужные в работе формы / отчеты на предмет ошибок

(42) Да, точно, так будет быстрее и точнее. Спасибо, попробую

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