Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5)
Давать кому то базу как бы не очень правильно. Надо предоставить им доступ к базе для работы, а не давать саму базу.
Делаете копию на момент проверки. Механизмом RLS отключаете видимость организаций к которым у аудитора не должно быть доступа.
В случае каких проверок вы предоставляете базу данных? Ну кроме аудиторской.
То одну им базу отдаешь, как бы не связанную с другими, а то весь расклад.
Давать кому то базу как бы не очень правильно. Надо предоставить им доступ к базе для работы, а не давать саму базу.
А как быть со всяческими проверками?
Делаете копию на момент проверки. Механизмом RLS отключаете видимость организаций к которым у аудитора не должно быть доступа.
В случае каких проверок вы предоставляете базу данных? Ну кроме аудиторской.
(9)
Где я работал в довольно крупных холдинговых организациях никогда аудиторам никаких баз не отдавали. Оборудовали рабочие места или предоставляли удалённый доступ.
На сколько помню в перечень того что предоставляется налоговикам базы данных не входят.
Так исторически сложилось у городских аудиторов
Где я работал в довольно крупных холдинговых организациях никогда аудиторам никаких баз не отдавали. Оборудовали рабочие места или предоставляли удалённый доступ.
Налоговая, ФСБ.
На сколько помню в перечень того что предоставляется налоговикам базы данных не входят.
(21) Они просят, руководство разрешает отдать. Но у нас такие отношения с ними, что нам от них скрывать нечего.
У нас ERP толпа пользователей (одновременно работает 40-60) и если настроить RLS по куче измерений , то тормоза будут адцкие. А на полных правах все летает.
Для нормальной работы RLS я свои роли создал, со своими шаблонами, более упрощенными под нашу специфику.
У нас ERP толпа пользователей (одновременно работает 40-60) и если настроить RLS по куче измерений , то тормоза будут адцкие. А на полных правах все летает.
Для нормальной работы RLS я свои роли создал, со своими шаблонами, более упрощенными под нашу специфику.
(22)
Мы то же не скрываем. Просто отдать куда то базу как то не осмотрительно. У нас пусть приходят смотрят данные которые им нужны для их работы. А так отдашь, а там будут базу ломать, везде нос свой совать, кто нибудь потом домой возьмёт, дома поработать, там сынка в интернет выложит случайно и тд. Да и аудиторы должны в первую очередь в первичку смотреть и в документальное оформление, а уже потом в базе это проверять.
Они просят, руководство разрешает отдать. Но у нас такие отношения с ними, что нам от них скрывать нечего.
Мы то же не скрываем. Просто отдать куда то базу как то не осмотрительно. У нас пусть приходят смотрят данные которые им нужны для их работы. А так отдашь, а там будут базу ломать, везде нос свой совать, кто нибудь потом домой возьмёт, дома поработать, там сынка в интернет выложит случайно и тд. Да и аудиторы должны в первую очередь в первичку смотреть и в документальное оформление, а уже потом в базе это проверять.
(28) Все равно тормозит. Мое мнение: там шаблон кривой или плохо платформа с ним работает.
Например если настроить рлс только по организации и убрать из шаблона роли все проверки , кроме как по организации, то работать начинает в разы (иногда 15-кратное увеличение производительности) быстрее.
А по поводу слива базы: не моя проблема, кто разрешил отдать, тот пусть и переживает.
Например если настроить рлс только по организации и убрать из шаблона роли все проверки , кроме как по организации, то работать начинает в разы (иногда 15-кратное увеличение производительности) быстрее.
А по поводу слива базы: не моя проблема, кто разрешил отдать, тот пусть и переживает.
Вариант: несколько организаций в одной БД
плюсы - обновляется единая конфигурация. общие контрагенты, расчетные счета
минусы - если необходимо разграничение доступа по организациям - придётся включать "доступ на уровне записей"
Вариант: каждая организация в своей БД
плюсы - нет проблем с разграничением доступа, всегда можно отдать одну БД кому нибудь на сопровождение
минусы - нужно обновлять каждую БД отдельно
плюсы - обновляется единая конфигурация. общие контрагенты, расчетные счета
минусы - если необходимо разграничение доступа по организациям - придётся включать "доступ на уровне записей"
Вариант: каждая организация в своей БД
плюсы - нет проблем с разграничением доступа, всегда можно отдать одну БД кому нибудь на сопровождение
минусы - нужно обновлять каждую БД отдельно
(14) куплены для каждой. Даже от имени каждой ;) и куча ключей :(
И есть и купи продай и между ними и совместное (т.е. на одну сделку может от разных организаций по частям товар отписываться и услуги) и номенклатура на 100% общая.
ЗУП - большинство сотрудников общие
И есть и купи продай и между ними и совместное (т.е. на одну сделку может от разных организаций по частям товар отписываться и услуги) и номенклатура на 100% общая.
ЗУП - большинство сотрудников общие
Плюсы общей базы:
+ общая справочная база
+ сводная отчетность
+ нет проблемы обмена данными
Плюсы раздельных баз:
+ удобство масштабирования и администрирования, полная свобода про разнесению нагрузок и по серверам (могут находиться вообще в разных местах и иногда это может быть важно)
+ многие проблемы связанные с разделением прав доступа решаются автоматически, путем разделения доступа к базам
+ нет проблем при "подвижном" бизнесе, когда например могут сказать - "завтра это юр-лицо идет своим путем, к нам больше не относится и вообще у него будет свой ИТ отдел и сервера"
В реальной жизни выбор сильно зависит от приоритетов холдинга/корпорации и его собственников, уже сложившейся культуры управленческого учета, уже внедренных продуктов и бизнес-процессов.
ЗЫ. Вопрос удобства обновлений - спорный, поэтому не упомянут. Есть разные ситуации для обеих вариантов.
+ общая справочная база
+ сводная отчетность
+ нет проблемы обмена данными
Плюсы раздельных баз:
+ удобство масштабирования и администрирования, полная свобода про разнесению нагрузок и по серверам (могут находиться вообще в разных местах и иногда это может быть важно)
+ многие проблемы связанные с разделением прав доступа решаются автоматически, путем разделения доступа к базам
+ нет проблем при "подвижном" бизнесе, когда например могут сказать - "завтра это юр-лицо идет своим путем, к нам больше не относится и вообще у него будет свой ИТ отдел и сервера"
В реальной жизни выбор сильно зависит от приоритетов холдинга/корпорации и его собственников, уже сложившейся культуры управленческого учета, уже внедренных продуктов и бизнес-процессов.
ЗЫ. Вопрос удобства обновлений - спорный, поэтому не упомянут. Есть разные ситуации для обеих вариантов.
(34)
Был такой пример. База была БП2, одна. Создали план обмена По организации - выгрузили - отдали им переферийную. (Предварительно отвязали от РИБ). Не знаю насколько такое решение правильное. Потом были некоторые сложности при первых попытка обновления новой базы. Но дальше вроде норм.
Может такой вариант для передачи базы кому то подойдет?
Правда не смотрела есть ли в типовой БП3 такой план обмена.
+ нет проблем при "подвижном" бизнесе, когда например могут сказать - "завтра это юр-лицо идет своим путем, к нам больше не относится и вообще у него будет свой ИТ отдел и сервера"
Был такой пример. База была БП2, одна. Создали план обмена По организации - выгрузили - отдали им переферийную. (Предварительно отвязали от РИБ). Не знаю насколько такое решение правильное. Потом были некоторые сложности при первых попытка обновления новой базы. Но дальше вроде норм.
Может такой вариант для передачи базы кому то подойдет?
Правда не смотрела есть ли в типовой БП3 такой план обмена.
По поводу типовых RLS - кто их видел, тот в цирке не смеется. Для мало-мальски нагруженных баз они не имеют права на жизнь.
Но это не значит, что RLS вообще - не решение. Нетиповые RLS можно сделать очень эффективно.
Отлично работает вариант, когда объекты доступа пользователя вычисляются на старте и пихаются в параметры сеанса вида "ФиксированныйМассив". Тогда сами RLS сводятся к банальным условиям на вхождение. Ессно, это эффективно работает только при ограниченном количестве объектов доступа. Но в подавляющем большинстве случаев так оно и есть - подразделения, склады, виды деятельности и т.п. Их обычно много не бывает.
Но это не значит, что RLS вообще - не решение. Нетиповые RLS можно сделать очень эффективно.
Отлично работает вариант, когда объекты доступа пользователя вычисляются на старте и пихаются в параметры сеанса вида "ФиксированныйМассив". Тогда сами RLS сводятся к банальным условиям на вхождение. Ессно, это эффективно работает только при ограниченном количестве объектов доступа. Но в подавляющем большинстве случаев так оно и есть - подразделения, склады, виды деятельности и т.п. Их обычно много не бывает.
(41)РИБы, если есть готовый План обмена по Организации в типовых, делаются за 15 мин. Но скорость процесса выгрузки конечно зависит от размера базы.
А вот выгрузить не все... Чем выгрузить, как фильтровать, где разграничить доступ...? Как то не быстрее. Если только уже есть готовый инструмент.
А вот выгрузить не все... Чем выгрузить, как фильтровать, где разграничить доступ...? Как то не быстрее. Если только уже есть готовый инструмент.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот