Коллеги, добрый день.
у кого ЗУП 3.1 КОРП и настроен РЛС по Организациям, Физ.лицам нет ли проблем с нехваткой прав при формировании статистического отчета П4?
Пример:
в справочнике Организации: ЦО, Филиал1
Сотрудник Иванов переведен из ЦО в Филиал1 в июне.
Остальные сотрудники с момента приема числятся в Филиал1
Пользователю разрешен доступ к Филиал1. Все остальные организации запрещены.
По физ лицам стоит "Разрешены все".
Пользователь формирует отчет П4 за 9 месяцев и получает ошибку нехватки прав.
Если по организациям установить "разрешены все", то отчет формируется.
Думал, что нужно давать права на все организации и ограничивать доступ по группам физ лиц... но та же история.. если хоть одна группа доступа физ лиц недоступна (даже никак не связанная с сотрудниками из Филиал1), то получаем нехватку прав.
Возникает вопрос.. только у меня так или это ошибка отчета. В зарегистированных ошибках не нашел.
Просьба откликнуться использующих КОРП версию ЗУП 3.1.
ЗУП 3.1.8.155 (та же беда на более ранних релизах).
(1) У меня ЗУП 3.1.8.216 КОРП. В случаях, когда запрос ограничен по РЛС(Москва, Питер, Ростов), то перед Запрос.Выполнить().Выгрузить() добавляю УстановитьПривелигерованныйРежим(Истина); Тогда РЛЗ локально отключен внутри функции получения данных.
Полноценное ограничение доступа по подразделениям в программе не поддерживается. Согласно законодательству расчет НДФЛ и взносов следует вести в целом по физ. лицу, независимо от его перемещений между подразделениями.
Примечание
По этой же причине не имеет смысла давать доступ только к определенному филиалу (обособленному подразделению, выделенному на отдельный баланс), не дав при этом доступа к головной организации. С точки зрения учета НДФЛ и взносов такое обособленное подразделение не отличается от «обычного» подразделения организации.
Для реализации в программе таких ограничений следует использовать доступ с точностью до физических лиц. В качестве групп доступа физических лиц следует использовать группы вида «Сотрудники подразделения 1», «Сотрудники подразделения 2» и т. п. При этом для возможности работы с сотрудниками, перемещающимися между подразделениями, может потребоваться включать их в группы вида «Сотрудники подразделений 1 и 2». Права на такие группы придется обеспечить для групп доступа, пользователи которых работают с каждым из этих подразделений.
ясно почем у вас так?
Думал, что нужно давать права на все организации и ограничивать доступ по группам физ лиц... но та же история.. если хоть одна группа доступа физ лиц недоступна (даже никак не связанная с сотрудниками из Филиал1), то получаем нехватку прав.
К сожалению ЗУП и Подразделения это тот случай когда не получиться сесть сразу на два стула. В 3.1.8 разработчики "смягчили" решение подобных задач добавив отборы подразделений в списки.
(9) я считаю это не есть недоработки - просто рогатки законодательства настолько сложны(а часто и противоричевы), что имеем то, что имеем.
в цитате написано же почему так сделано, да и физлицо в течение месяца может "шарахаться"
по подразделениям перемещениями и жесткое РЛС приведет, по крайней мере, к недопониманию сотрудников кадровых и расчетных служб.
(10) Там проблемы на уровне архитектуры (нет измерений в регистрах). НДФЛ тут как отмазка, ну не считает расчетчик или кадровик не провдит кадровые приказы по другому филиалу и что, в чем проблема. В конфигурации много кода где используется
УстановитьПривилегированныйРежим
и можно было с этим работать, если продумать архитектуру регистров. У нас расчетчики считаю отдельно каждый свой филиал и ничего как-то закрывают НДФЛ и взносы. Да у них доступ полный, но они считаю каждый свой филиал и не лезут в другой. Но есть в двух филиалах расчетчики у которых нет полного доступа, чтоб программа работала пришлось допиливать.
А доступ на уровне физлиц)). Они сами вообще думаю как с этим работать? Кто будет следить за группами физлиц? Кадровик?
Я уж про тормоза рлс вообще промолчу.
Большое спасибо за ответ.
Насчет "объединенных" групп доступа по физ лицам уже сам дошел. Но все равно спасибо за подтверждение из документации.
В примере я упростил, исказив исходные данные.. доступ к головной организации разрешен во всех группах доступа. Например НДФЛ считается, используя заработок перемещенных сотрудников во всех филиалах, так же без проблем строится отчет по страховым взносам.
А вот в для П-4 запросу почему то не хватает прав.. причем права нужны даже на филиалы (организации) с которыми сотрудники текущей организации отчета вообще никак не связаны.
Хотелось бы именно от пользователей КОРП версии услышать есть ли такие проблемы с П-4 или нет.
Для того чтобы строился отчет по страховым взносам у пользователя должны быть права на головную организацию и на все филиалы в которых в текущем году работали сотрудники текущей организации отчета.. если перемещений много, то получается что в КОРП версии вообще нужно разрешать все организации пользователям, а управлять доступом через группы доступа физ лиц.
Но в таком случае пользователи видят отчеты, в которых не используются физ лица, по тем организациям которые они видеть не должны.
На данный момент получается, что приходится постоянно мониторить кадровые переводы между обособленными подразделениями и ЦО. И если, например из Филиала5 переведен сотрудник в Филиал6, то нужно в группе доступа расчетчика Филиала6 давать доступ к Филиалу5.
И у переведенного физ лица устанавливать группу доступа "Филиал 5, Филиал6".
У нас филиальная структура. После эксплуатации пришел к выводу что:
1. Доступ у всех должен быть головной организации, иначе ошибки, если давать только доступ к филиалу.
2. На данный момент обошел созданием своих ролей (в них RLS и без, т.к. в некоторых регистрах только головная организация, тут без RLS, либо стандартные роли в RLS используется головная, а не организация, тут свой RLS), доработкой некоторых модулей.
3. Во многих отчетах используется СКД, а не чистый запрос. Данные для запрос скд собираются кодом. Чаще всего в запросе скд нет условия (где), и возможно не всегда есть конструкция РАЗРЕШЕННЫЕ. Запросы в скд построены так что получаются все данные, а уже дальше отбором скд часть отсеивается (понятно что отбор скд при формировании запроса к SQL накладывает ГДЕ, но все же).