Самый простой способ - вынести в журнале счета на форму поле ответственный и настроить отбор по нему. Чуть сложнее - то же самое программно через расширение.
Использование механизма РЛС в бухгалтерии не рекомендуется.
Самый простой способ - вынести в журнале счета на форму поле ответственный и настроить отбор по нему. Чуть сложнее - то же самое программно через расширение.
Использование механизма РЛС в бухгалтерии не рекомендуется.
Именно в БП не рекомендуется использование RLS. Был негативный опыт? Можете поделиться?
Я лично делал в 3 разных базах разделение в RLS по ролям (пользователям) номенклатуру, Контрагентов, бухгалтерских счетов, периодов отчетов и прочее...
С отрицательными последствиями не сталкивался. Просто нужно не "рубить" всё а только то что надо и тогда в отчёт попадают все суммы...
Менеджеры в бухгалтерии не используют бухгалтерские отчёты (а рлс не работает в отчетах вообще, а не только в бухгалтерских).
Если измерение регистра не содержит ограничений по рлс, отчет формируется полностью (а чаще всего должен быть убран из интерфейса).
Отчеты "для директора" писали по принципу перечень основных клиентов/номенклатуры/сотрудников прочие и итого. Это задача обратная РЛС.
Основные и прочие могут вести разные менеджеры(которые в РЛС пользуются только своим).
15.
user633533_encantado
1114.01.21 11:47 Сейчас в теме
RLS в бухгалтерских базах бессмысленна, так как база предназначена для работы бухгалтера, который должен видеть все проводки, а значит и всю их аналитику.
Максимум что там можно это настроить доступ на уровне организаций (и еще по мелочи на отдельные объекты), так как организация является общей аналитикой всех проводок.
В случае счетов на оплату типовой функционал тоже дает ограничить только на уровне организации. Но можно создать роль с ограничением по ответственному.
RLS в бухгалтерских базах бессмысленна, так как база предназначена для работы бухгалтера, который должен видеть все проводки, а значит и всю их аналитику.
Но почему то многие просят чтобы, например, бухгалтер который ведёт ОС и МНА не видел аналитику по ЗП (кто сколько получил)...
Другой пример: Менеджер который выписал счёт должен видеть оплату по нему, но не должен видеть взаиморасчеты с контрагентами других менеджеров. Кстати не всегда менеджеры работают в "торговых конфигурациях" а используют "бухгалтерию" (небольшие фирмы или "не типичные", т.е. не "супермаркеты" или "оптовые базы").
Но почему то многие просят чтобы, например, бухгалтер который ведёт ОС и МНА не видел аналитику по ЗП (кто сколько получил)...
Это как, запретить ему смотреть оборотносальдовую ? Или открывать карточки счета из уже сформированного отчета. Это не осуществимо из-за принципа двойной записи.
ОС и НМА могут запросто увеличивать свою стоимость за счет затрат на оплату труда.
По сути вы не ограничили доступ к данным, а просто ограничили доступ к некоторым справочникам
Задача: Нельзя смотреть "кто сколько получил" - ВЫПОЛНЕНО
Критерий работоспособности (НЕ ПОЛОМАЛ): Суммы участвуют во всех отчетах.
ИТОГ: Задача выполнена, работоспособность не пострадала, клиент доволен.
З.Ы. Можно конечно было рассказать: "Типовой функционал не позволяет... Если вы заплатите ХХ лимонов, то через YY месяцев мы Вам всё сделаем..." (И "перепахать" пол конфигурации)
29.
user633533_encantado
1115.01.21 10:06 Сейчас в теме
(25) Нет, при нормальной реализации доступа на уровне записей пользователь не смотрит на поля типа "объект не найден", а не видит данных вообще. Аналогично доступу по организации в той же бухгалтерии.
То, что у вас это костыль, поскольку для регистров бухгалтерии нормальная реализация не возможна, по причинам которые я уже описал.
RLS в бухгалтерских базах бессмысленна, так как база предназначена для работы бухгалтера, который должен видеть все проводки, а значит и всю их аналитику.
Необходимо уточнить, что в версии 1с 6 был механизм журналов, который перекочевал в 7 ку ввиде клда операции и даже мутировл до кода операции в торговле. В бюджетном учете был аналогичный механизм мемориальных ордеров. Но СКД в принципе не объединяет закрытые рлс
ссылки в пустую, а итоги (даже если назначить на плане счетов реквизит мемориальный ордер и использовать его в проводках) не могут быть ограничены только выбранным мемориальным ордером.
Но отчет журнал-главная вместо шахматки(которая все равно потеряла актуальность в связи с автоматизация по причине большого количества субсчетов, которые выводить вместе с группами счетов всех уровней нечитабельно и невозможно обработать в екселе) по таким мемориальным ордерам вполне пригоден как универсальный бухгалтерский отчет, позволяющий и РЛС и детализацию.
Т.е. РЛС в бухгалтерии как таковой предполагает мемориально-ордерную (а не журнально-ордерную) систему учета.
Проблема в том, что архивные данные противоречат концепции 1с. 1с не переносит данные за закрываемый период в другой аналоничный набор таблиц (чеки в рознице это исключение, которое только подтверждает правило).
Тем не менее мы видим остатки на начало периода в отчетах, хотя сам предыдущей период не показан.
Так и с РЛС.
Вариант "видеть только указанные" недостаточно, как недостаточно оборотно-сальдовая без начальных остатков.
Должен быть еще вариант"разрешенное в деталях, все остальное одной строкой и итого". Хотя бы опционально.
И классический вариант только разрешенные без итого, аналогичный простому журналу документов.
В мемориально-ордерной системе каждая цифра попадает в один и только один мемориальный ордер. Какой именно, можно настроить или прописать, но пользователь другого ордера этой суммы не увидит.
Костыль имхо тут в другом. Субконто в проводках всегда поле составного типа, а мы все знаем (надеюсь что я не права) что поле составного типа делает левые соединения со всеми таблицами, входящими в тип. Ну не будет же в каждом отчете анализу субконто подключать все виды субконто.
Как и добавлять в таблицу счета фактуры для поля основание две колонки - тип основания и само основание.
Т.е. как вариант, служебный справочник основания со всеми документами, хранящий представление, тип и ссылку и использование этого справочника вместо всех документов оснований для просмотра представления (если совсем все плохо) Да это некрасиво, но нагрузку на чтение базы должно снизить.