8.х Настройка доступа на уровне записей

Тема в разделе "Общие вопросы "1С:Предприятие 8"", создана пользователем Despod, 12 янв 2009.

  1. TopicStarter Overlay
    Despod
    Offline

    Despod

    Регистрация:
    31 окт 2007
    Сообщения:
    15
    Симпатии:
    0
    Баллы:
    1
    В зарплате реализовали штатный механизм доступа на уровне записей и с нового года я решил его применить.
    Структура следующая. Сервер SQL + Сервер 1С + Сервер терминал. Несколько разных филиалов считают зарплату только по себе. Чтоб не лезли к другим все разделено по физ лицам и подразделениям.
    Все пользователи сидят под правами расчетчик регламентированой зарплаты(те что с ограничеными правами)+пользователь.

    Есть центральный офис, в нем пользователь с полными правами, и на него не действуют никакие ограничения.
    Филиалы пытаются провести документ Расчет ЕСН, в нем примерно 800 сотрудников. На проведение этого документа уходит около 8 часов, под полными правами 3 мин.

    Скажите это нормально?
  2. uza
    Offline

    uza 1С, VBA (EXCEL), VB (.NET + WEB)

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Нет, это не нормально. Но это есть.
    Настройка "тонких" прав штатными средствами 1Ски, увы, тормозит.
  3. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Там запрос получается некислый из-за использования РЛС.
    Для оптимизации необходимо переписывать его.
  4. TopicStarter Overlay
    Despod
    Offline

    Despod

    Регистрация:
    31 окт 2007
    Сообщения:
    15
    Симпатии:
    0
    Баллы:
    1
    Так кто то с этим как то борется? Есть ли методы(не включающие переписывания всей типовой конфигурации и покупка более мощных серверов). Оптимизация SQL, обновление платформы, использование каких либо внешних компонент или чтонибудь в этом роде?

    Мне вот интересна сама политика 1С, зачем они этот не кислый запрос пишут? Разве нельзя, заявив о том что они реализовали эту феньку, сделать ее по человечески?
  5. uza
    Offline

    uza 1С, VBA (EXCEL), VB (.NET + WEB)

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    А вот вы себе как представляете сделать такой механизм? Когда пишешь базу, одну, конкретуную, то под эту базу закладываешь механизмы доступа, но это механизмы доступа на уровне приложения.
    А тут вам дают некий универсальный механизм, т.е. механизм доступа на уровне базы данных. Это разные вещи. Поймите правильно.

    Я понимаю что извращение, чтобы филиалы/подразделения сами себе ЗП считали (в моей практике всегда ЗП считал филлиалам центр (Москва/Питер) а в филиалы отправляли уже готовые расчеты) придумали не вы.
    Но в вашем случае, ИМХО, надежней и наверное проще было бы сделать ФИЗИЧЕСКИ разные БД под зарплату, и соотв. сливать результаты в одну (на сколько надежно вы уверенны в том, что особо радивый манагер из филлиала А не при каких обстоятельствах не получит доступ к данным о премиальном фонде такого же менеджера, но филлиала Б)? Кулхацкеров то их по Росси много ;)
  6. TopicStarter Overlay
    Despod
    Offline

    Despod

    Регистрация:
    31 окт 2007
    Сообщения:
    15
    Симпатии:
    0
    Баллы:
    1
    Судя из первых постов я сделал вывод, что можно переписать эти запросы так, чтоб они работали эфективней. Я конечно могу влезть в во все эти настройки, переписать и наслаждаться, но тут два но
    1) переписывать придется многое
    2) Обновления что то уж слишком частые, и обновлять каждый месяц конфу и переносить туда "тонны" изменений не особо хочется.

    В нашем случае филиал это целый завод, у каждого завода своя специфика расчета зп, куча табелей рабочего времени, по 5-7 кадровых перемещений и т.д. Расчитать центру это в принципе невозможно.
    Во первых часть первички находится на бумажных носителях и нет возможности занести это в программу(например 2 кадровых перещения в пределах дня) и стоит учитывать это на карандаше, во вторых расчетчики в филиалах в больших количествах около 10, в центральном 1.

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

    Перспективы не радают.

Поделиться этой страницей