Где в 1с упп администрирование

Обновлено: 04.07.2024

Переходить с УПП на другие системы уже сейчас или тянуть до последнего: оцениваем варианты

Фирма «1С»‎ планирует завершить поддержку конфигурации «Управление производственным предприятием»‎ (УПП) весной 2026 г. и рекомендует предприятиям переходить на современные ERP-решения. В них реализован накопленный опыт и учтены требования рынка. Тогда как в отраслевых решениях УПП не повышается уровень автоматизации, а также удобства работы пользователей.

Крупным и средним компаниям рекомендуется переход с 1С:УПП на 1С:ERP типовое или отраслевое.

Пользователям отраслевых продуктов на основе 1С:УПП советуют переходить на ERP-решения, опубликованные в информационном письме №25625.

Небольшим компаниям без производства или с простым производством стоит рассмотреть «1С:Комплексная автоматизация». Когда, например, не нужны маршрутные карты, планирование производства, серийный учет, учет выработки сотрудников; когда нет потребности в учете ремонтов оборудования, нет сложных процессов бюджетирования, и не нужен учет по МСФО.

Переходить сейчас или тянуть до последнего

В нашей стране много компаний, работающих на УПП, поэтому задача перехода популярна. К ней относятся по-разному: кто-то предпочитает заблаговременно готовиться к новым реалиям и уже сейчас меняет информационную систему, ну а кто-то будет запрыгивать в уходящий поезд. Ведь некоторые компании собираются сидеть на УПП до последнего и внедрять ERP, только когда УПП совсем снимут с поддержки.

Считаем, допустимо оставаться на отраслевом УПП, если к программному решению применяются нестрогие законодательные требования или требования, не подверженные частым изменениям. Но в случае если предприятие работает в сильно зарегулированной отрасли — костыльные решения будут постоянной головной болью и большой статьей издержек.

Отраслевая специфика имеет особенности, по которым периодически выходят обновления. В производстве и продаже алкоголя — это, например, учет акцизных марок, по которому каждое изменение в формах, сроках и прочих требованиях реализуются через обновления учетной системы, то есть через отраслевой модуль современной ERP. Если ликероводочный завод останется на УПП, ему придется самостоятельно реализовывать все эти изменения в соответствии с требованиями законодательства, постоянно дописывая свой программный продукт. Фирма «1С»‎ после снятия с поддержки отраслевого решения УПП не будет выпускать обновления в части отраслевого модуля при каких-либо изменениях.

Рассмотрим молочную промышленность. Здесь специфика в том, что учет выпускаемой продукции производится как в основных, так и в дополнительных единицах измерения, пересчитываемых через коэффициент. Параметры выпуска продукции имеют связь с качественными показателями сырья, например, % жира, % белка, что необходимо для правильного расчета списания сырья на выпуск продукции. Все эти элементы надо как-то «перетаскивать»‎ обменами из УПП в 1С:Бухгалтерия (стандартную или отраслевую). В любом случае придется писать с нуля эти обмены.



Жить в иллюзии экономии

Что дешевле: постоянно писать обновления к отраслевой УПП или один раз внедрить ERP? При моментной оценке, конечно, написанная интеграция стоит дешевле, чем внедрение ERP, но эту интеграцию в дальнейшем придется поддерживать. А если мы будем оценивать затраты не в моменте, а в перспективе нескольких лет, то внедрение 1С:ERP окажется даже дешевле. Для предприятий, деятельность которых строго регулируется государством, цена внедрения ERP может оказаться ниже, чем стоимость владения костыльным решением с написанной интеграцией в перспективе 3-х лет.

Решив оставить учет в УПП, предприятия будут вынуждены прибегать к топорным методам, чтобы сдавать отчетность из не обновляемых отраслевых решений, или делать выгрузку в Бухгалтерию и сдавать отчетность оттуда. Кто будет реализовывать эти топорные методы? Скорее всего, не найдется по-настоящему хороших подрядчиков, готовых выполнять подобные проекты. Любой уважающий себя франчайзи, выбирая между заказами: «пилить»‎ костыли для УПП или внедрять ERP, остановится на последнем, потому что при этом франчайзи получит классные кейсы и высокие позиции в рейтинге «1С»‎ по внедренным решениям. А команда проекта приобретет опыт и разовьет компетенции по современным релизам. Не будет сильных компаний, согласных штамповать костыльные решения. Значит, предприятия, которые в первой волне не перейдут на ERP и попытаются сохранить их текущую учетную систему, в дальнейшем будут работать с фрилансерами, программистами одиночками.

Обратимся к истории. Была когда-то популярная система Бухгалтерия 2.0, и многие предпочли остаться на ней, когда вышла Бухгалтерия 3.0 на современной технологической платформе. Фирма «1С»‎ заявила: все изменения законодательства будут реализованы только на тройке. «Ну, ладно» — посчитали во многих компаниях и не спешили с переходом на 3.0, пока наконец «петух не клюнул»‎. А случилось это, когда ввели обязательные онлайн-кассы. В Бухгалтерии 2.0 была невозможна реализация онлайн-касс из-за ограничений платформы. Тут начался бум переходов на 1С:Бухгалтерия 3.0.

Все, кто останутся на УПП, потому что «так удобно», «так привычно»‎, и начнут городить костыли для сдачи отчетность, в будущем станут заложниками ситуации. Если в законодательстве произойдет нововведение по примеру онлайн-касс, компании окажутся абсолютно неготовыми к новым требованиям. У них может быть критически мало времени на маневры при изменениях учета или отчетности. Да и к тому моменту будет уже потрачено много денег в попытках сохранить УПП. Суммы, сопоставимые с половиной, а то и с полной стоимостью проекта внедрения ERP. Но потом-то все равно придется переходить на современную систему. Опыт показывает: каждые 2-3 года что-нибудь да меняется. IT-сфера развивается стремительно, поглощая все больше отраслей, меняются формы отчетности, учета. Гос. учет в различных видах затрагивает все больше сфер жизнедеятельности, и никак нельзя надеяться на то, что в ближайшее время не произойдет изменений, требующих адаптации программных продуктов к ним. Подстраиваться под новые требования законодательства и рынка будут только продукты современного поколения ERP.



Обходные решения?

Некоторые заказчики говорят: «У нас есть УПП и отраслевой модуль к ней. Допустимо ли остаться на УПП, все-таки мы еще 5 лет можем на ней работать, и приобрести отраслевой модуль от ERP? Он ведь продается отдельно?»‎. Да, модуль продается отдельно. Но нужно учитывать, что все отраслевые модули от ERP бесшовно интегрируются только с ERP, чтобы при слиянии представлять для заказчика единую учетную систему. Манипуляции с параллельным использованием разных продуктов (УПП + отраслевой модуль ERP) — это лишь иллюзия нормальности, потому что дописывание или как бы подтягивание одной системы до уровня другой, более современной — дается только сложными интеграциями.

Ограничения в УПП

Работа с УПП уже сейчас носит ряд неудобств: там много моментов, которые либо невозможно сделать совсем, либо нужно выполнять вручную. Пример: заполнение отчета 6-НДФ. Изменение к самой форме 6-НДФЛ учтено в УПП, а вот автоматическое заполнение этой формы в УПП не реализовано. И если количество сотрудников компании исчисляется десятками, еще можно, скажем, посидеть круглые сутки и выходные, чтобы сделать эту работу руками. Крупные предприятия физически не могу заполнять эти формы по каждому сотруднику вручную. Поэтому такие предприятия, работающие с УПП, как минимум ЗУП выносят наружу. Оставаясь на УПП или УПП отраслевом решении, надо однозначно выносить наружу ЗУП и Бухгалтерию, то есть внедрять эти 2 продукта, затем писать интеграцию с ними и вручную допиливать изменения в предметной области.

В 1С:ERP появился блок «Бюджетирование», представляющий собой конструктор, с которым можно построить систему планирования по любому блоку, не только по финансовому. Это может быть и планирование ресурсов, и затрат, и обеспечения. Новый функционал открыл огромное количество возможностей в учетной системе. Такой сущности в принципе не было в УПП, то есть там нет даже задатков для этого функционала.

Обращайтесь к нам, eсли хотите узнать больше об отличиях УПП и ERP. Поможем разобраться: можно ли на вашем предприятии продолжить работу с УПП или уже сейчас стоит переходить на другие решения.

Автор статьи: Елена Лоренцова - коммерческий директор компании «СИТЕК».
Дата публикации статьи: 31.05.2021 г.

Подпишитесь на нашу рассылку
и получите еще больше статей от экспертов по 1С!


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

Предисловие

Сначала я просто хотел написать небольшую статью о том, как мы разносили базы по службам, но в ходе углубления в этот процесс мы добавляли всякие разные штуки (мониторинг служб, потом мониторинг пользователей внутри 1С, потом прикрутили заббикс, и, наконец, пришли к CI/CD на базе 1С). В итоге я понимаю что пихать это в одну статью будет слишком — решил разделить на несколько. Ну а название навеяно циклом статей "сети для самых маленьких", которые принесли мне много приятных минут и к которым я отсылаю всех, кто "хочет изучить сети". Итак, мы приступаем!

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

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

Какие у нас были сложности:

  1. Подвисшая база тянула за собой перезапуск службы, а значит страдали невинные (пользователи других баз)
  2. Было тяжело понять кто сегодня "герой дня" — какая база заняла все ресурсы
  3. Обновление релизов — обновление одной тянуло за собой автоматическое обновление всех баз на этой службе
  4. Ручное подключение баз пользователям, ручное изменение в случае переездов
  5. Мониторинг
    И только сейчас я понимаю что это была только вершина айсберга.

Акт первый, действие нулевое

Небольшое отвлечение на основные постулаты, осознание которых далось большой кровью и болью.

  1. Старые версии 1С (до 8.3.11+) имеют просадку по производительности при работе в виртуализированной среде. (Источник — Гилев и собственные тесты)
  2. Кластер есть, но с ним все крайне не просто. Возможно его доработают потом, но пока он в основном для галочки. (источник — собственный опыт)
  3. При выборе процессора смотрите только на частоту. Процессор в 6 ядер по 3,4Ггц порвет в куски процессор на 20 ядер по 2Ггц. Проблема в том, что 1С вообще ничего не знает про параллельные вычисления. По сути это работает так — у нас есть определенное число воркеров для каждой службы, их раскидывают по процессорам, и если в каком то воркере пользователь запустил какой-то тяжелый отчет то в системе будет загружено только одно ядро процессора. Именно то, на котором работает воркер с запущенным заданием… Для БД ситуация кстати ровно обратная. (источник — Гилев, собственный опыт, опыт коллег)
  4. Не используйте логи в "новом" формате (запись в SQLLite) — вы очень быстро столкнетесь с тем, что производительность этого решения еще хуже чем файлового варианта. (Источник — собственный опыт, опыт коллег).
    По подсказкам из комментариев есть вариант вынести логи на отдельный инстанс.
    В 8.3.12 обещали логи в нормальный скуль.
  5. 1С оооочень не любит IPv6. На всех серверах с 1С лучше сразу понижать приоритет IPv6 до минимума. (Источник — Гилев, собственный опыт)
  6. Используйте для виртуальных серверов виртуальные сетевые карточки E1000. С остальными проблема по производительности (Источник — Гилев, но на собственном опыте не подтвердилось, хотя особо и не тестили)
  7. Обслуживание баз дает хороший прирост производительности, особенно периодический пересчет итогов, а так же обслуживание индексов SQL (Источник — собственный опыт, Гилев)
  8. Поиск причин падения 1С сродни поеданию неочищенного кактуса. Выяснить что-то толком можно только через боль, унижения и страдания. (Источник — собственный опыт)
  9. Нет ни одного официального образа ни под один гипервизор. Про докер я вообще молчу. (Источник — сайт 1С)
  10. Программная лицензия для сервера привязывается к — сюрприз, сюрприз — серийному номеру процессора (и еще огромному количеству параметров сервера). В эпоху повсеместной виртуализации ход потрясающий. Поясняю — активировали сервер, переехали на другую ноду, перезагрузили машину — 1С не запуститься. Расчехляйте новый активационный код. (Источник — собственный опыт, болтливая техническая поддержка 1С =))
  11. 1С — это учетная система, а не отчетная. Хотите много нормальных жирных отчетов и быстро — выводите это за рамки 1С. (Источник — собственный опыт)
  12. У 1С есть два неоспоримых достоинства, за счет которых она будет процветать еще долго:
    • стоимость самого продукта/разработчиков
    • скорость разработки
      и к сожалению для российского бизнеса они являются первоочередными. А зачастую и единственными, на что вообще смотрят. (Источник — печальная реальность)
  13. Никогда не используйте файловую шару как место под хранилище конфигураций 1С. Только службу. Иначе маты со стороны разработки о упавшем черт знает когда хранилище станут вашим неизменным спутником по жизни. (Источник — собственный опыт, опыт коллег)

Акт первый, действие первое

Первая короткая сценка из корпоративной жизни

На сцене — Админ (А), программист 1С (П1С) и представитель бизнеса (ПБ)
ПБ — У нас медленно работает программа!
А — у меня в системе все хорошо!
П1С — я все написал правильно, у меня на компьютере все работает быстро!
ПБ (робко и растерянно) — но она же долго…
А и П1С хором — у нас все хорошо, проблема на вашей стороне!

Проблемы всегда случаются не вовремя (с) (5-летний философ)

И вот в одно прекрасное солнечное утро (на самом деле это была глубокая зимняя ночь) мы поняли что завтра надо запустить новую базу. Завтра наступал тот прекрасный день, который уже много раз описывался тысячами авторов и имя ему — легион! Тьфу, простите, занесло. Имя этому дню был дедлайн. Час ночи, завтра на 200 компах должна запуститься новая база." Да не проблема, у нас же все компы в домене! Сейчас быстренько сделаем логин-скрипт и дело в шляпе!" подумаете вы. И будуте правы — так же подумали и мы. И сделали. Только, как обычно это бывает, погорели на мелочи — я в логон-скрипте я прописал %filename%.bat а коллега выложил %filename%.cmd.

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

Но мысль автоматизации этого процесса у меня в голове засела очень крепко и стал даже вырисовываться план внедрения.

В итоге мы пришли к следующей идеологии:

  • Все раздается через AD — создаются группы вида 1cbases-%версия платформы%-%имя базы% и туда силами хелпдеста добавляются пользователи, которым нужна база.
    • одна группа — одна база
    • 1cbases — это префикс по которому удобно искать группы
    • версия платформы 81, 82 и 83 (релиз не принципиален)
    • название базы соответствует имени файла с настройками

    Как мы это делали:

    1. Через групповые политики добавляется новое задание в планировщик (задача планировщика прописать пользователю путь к файлу подключения базы):
      • запускать от имени пользователя
      • событие — разблокировка компьютера
      • действие — запуск нашего скрипта
    2. Создаем нужные группы в АД и заполняем их пользователями
    3. Создаем нужные файлы для запуска самих 1С. Тут остановлюсь чуть поподробнее. Изначально мы долго мучили интернет своими запросами и нашли полное описание структуры файлов *.v8i. Но потом нашелся способ проще и гениальнее.
      • запускаем 1С
      • настраиваем подключение к базе
      • проверяем что все работает
      • кликаем правой клавишей по названию базы и выбираем пункт — "Сохранить ссылку в файл"
    1. Добавление баз теперь не было морокой — просто делали группу, добавляли файл с настройками — дальше все происходило автоматом
    2. Могли спокойно переносить базы куда угодно, просто меняя конфигурацию в файле с настройками подключения к базе (как показала практика — очень удобно)
    3. Сберегли обувь хелпдеску

    Акт первый, действие второе

    Вторая короткая сценка из корпоративной жизни

    И с этой стороны ни чуть не лучше… (с) печальный ослик Иа-Иа в свой собственный день рождения

    Вот представьте себе — сидите вы в удобном кресле, в одной руке чашка вкусного чая, в другой пышущая жаром и свежестью булочка из кулинарии ближайшего магазина, за окном приятно пахнет весной… И это, конечно же, самое подходящие время для звонка с проблемой! Коллега — Байконур, у нас %@па!

    Я — я так понимаю что стадию Хьюстона с проблемами мы уже успешно пролетели?
    Коллега — да. База %имя базы% подвисла, вообще не отвечает, ТОПы уже рвут и мечут. 3 раза мне уже звонили. Надо перезагружать службу.
    Я — так там же еще пачка баз на этой службе.
    Коллега — да, поэтому вторая половина ТОПов тоже рвет и мечет что их отключат.

    В итоге конечно все согласовали, перезапустили, но осадочек остался.

    1. В продуктовой среде мы должны следовать правилу — одна база — одна служба с разнесением по портам
    2. Запускаться службы должны исключительно из-под доменных учеток. Одна служба — одна учетка. Это удобно для раздачи прав на шары, доступ в скуль и прочее. Так же, если у вас внедрена RBAC то вы можете очень оперативно посмотреть куда имеет доступ конкретный экземпляр 1С
    3. Логи нужно вынести на отдельный диск и включить на эти папки сжатие (при разбитии по дням это очень сильно экономит место и ускоряет (незначительно) поиск по логам)
    4. Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера (в этом случае разработка вообще не волнуется на предмет того, где фактически находится сервер — физика, виртуальная машина в приватном облаке или вообще в публичном облаке)
    5. На каждую службу мы выделяем 500 портов для пользовательских соединений (наше внутреннее решение)

    Как мы это делали (для нового сервера. для уже существующего часть шагов не актуальны):

    1. Создаются учетки под каждую службу
    2. На машине, где они будут работать им выдаются права на "запуск как службе"
    3. Ставиться MS офис, обязательно с активацией по MAK-ключу
    4. Ставится sqlncli — утилита из набора MS SQL Native Client. На данный момент выше 2012 не появлялось
    5. Создается папка C:\Windows\SysWOW64\config\systemprofile\Desktop — в противном случае есть проблемы с выгрузками в Word/Excel
    6. Для Windows 2016 и 1С 8.1 нужно скопировать старую версию dll (В папке C:\Program Files\Common Files\System\Ole DB надо заменить два файла sqloledb.dll и sqloledb.rll взятых со старых серверов)
    7. Ставятся дополнительное ODBC драйверы, если нужно подключатся к MySQL/PostgreSQL

    Настройка папки для службы и логов:

    1. Создается папка на отдельном диске называется в формате 1CServer%basename% (в стандартном случае это делает сама служба, ибо у нее есть в настройках запуска путь к логам)
    2. Если внутрь каталога только что созданной службы переносятся данные из другого каталога (другой службы, другого сервера), то необходимо заменить владельцев (иначе служба не получит к ним доступа) с заменой владельца подконтейнеров
    3. Владельцем папки делается учетная запись службы
    1. Для того, чтобы в службах не было кроказябр
      • в cmd ввести команду chcp 1251
      • файл надо сохранить в ANSI кодировке
    2. Обязательно надо проверить на отсутствие дублирующих ключей в строке запуска — служба с ними не стартует.
    3. Для того, чтобы удалить службу, можно воспользоваться командой — sc delete «Имя заданное в переменной name»
    4. Добавить порты используемые 1С в разрешения в firewall
    5. Нужен всего один физический ключ на сервер — все службы будут активироваться им

    После проведения всех мероприятий в итоге мы пришли к:

    1. Базы можно спокойно перезагружать, не трогая другие базы
    2. Всегда можно найти "героя" — базу, которая съедает все ресурсы
    3. Любые работы с базой касаются только одной конкретной базы

    В следующих статьях я планирую рассказать (если эта статья народу зайдет):

    Права доступа в УПП. Общая информация о подсистеме администрирования пользователей

    Изображение

    а также внутреннее устройство механизмов прав доступа в конфигураторе.

    Вот список статей по правам доступа в УПП:

    1. Права доступа в УПП. Роли

    2. Права доступа в УПП. Профили

    3. Права доступа в УПП. Дополнительные права

    4. Права доступа в УПП. Добавление права на ТОЛЬКО ПРОСМОТР информации в информационной базе

    5. Права доступа в УПП. RLS. Общие сведения и настройка

    6. Права доступа в УПП. RLS. Общая схема реализации

    7. Права доступа в УПП. RLS. Шаблон ограничений доступа по организациям

    8. Права доступа в УПП. RLS. Настройка доступа к справочнику "Контрагенты"

    9. Настройки пользователей в УПП

    В последней статье был рассмотрен фунционал настроек пользователей и его устройство в конфигурации, поскольку он входит в единый интерфейс "Администрирование пользователей".

    Далее в статье подведем небольшой итог по перечисленному материалу, сформируем общую картину для функционала по администрированию пользователей.

    Интерфейс

    Среди многочисленных интерфейсов пользователей в УПП 1.3 мы можем выбрать "Администрирование пользователей":

    Изображение

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

    Подменю "Доступ на вровне записей" открывает доступ к общим опциям RLS, а также более детальной настройки прав в зависимости от объектов и групп объектов.

    Теперь рассмотрим общую схему взаимодействия объектов конфигурации, используемых при работе с интерфейсом "Администрирование пользователей".

    Объекты

    В статье " Права доступа в УПП. RLS. Общая схема реализации" была представлена схема для объектов, используемых для ограничений доступа на уровне записей в УПП. Сегодня приведем подобную схему, но уже для всего функционала, используемого в интерфейса "Администрирование пользователей".

    Ссылка для просмотра схемы в формате PDF

    Ссылка для скачивания схемы в формате PDF

    с доп. функционалом Mindjet Mind Manager (для просмотра нужно установить программу на компьютер)

    Некоторые детали пришлось опустить, иначе схема бы превратилась в рекламный щит =) Но общая логика в схеме сохранена.

    Отчет

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

    Изображение

    Отчет имеет несколько вариантов, по названиям которых можно понять их назначение:

    Изображение

    Так, например, с помощью варианта "Настройка прав доступа" можно получить информацию о текущей конфигурации ограничений на уровне записей для используемых объектов доступа (организаций, контрагентов и так далее). Варианты "Настройка дополнительных прав" используется для получения текущих настроек дополнительных прав доступа по пользователям.

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

    Настройки пользователей в УПП

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

    Изображение

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

    Режим 1С:Предприятие

    Откроем окно настрое пользователя (не важно какого). Увидим примерно следующее:

    Изображение

    Продемонстрируем влияние настроек на работу пользователя. Изменим настройку "Запретить открытие нескольких сеансов" в значение ИСТИНА. Затем, не закрывая текущий сеанс, попытаемся войти в программу под той же учетной записью. Система нам выдаст предупреждение и не закроет сеанс:

    Изображение

    Если мы вернем настройку в прежнее состояние, то запуск нескольких сеансов станет возможным.

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

    Режим конфигуратора

    Механизм настроек пользователей имеет достаточно простую реализацию. Используются всего два объекта в дереве конфигурации:

    1. План видов характеристик "НастройкиПользователей".
    2. Регистр сведений "НастройкиПользователей".

    Изображение

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

    Изображение

    Для элемента "Запретить открытие нескольких сеансов" плана видов характеристик "Настройки пользователей" установлен тип "Булево". При запуске программы производится проверка включения этой опции. Если значение для настройки по текущему пользователю установлено в ИСТИНА, тогда выполняется проверка наличия запущенных сеаносв этим пользователем.

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

    Самый интересный момент - это процедура "ПолучитьЗначениеПоУмолчанию". Первым параметром в нее передается текущий пользователь (ссылка на элемент справочника "Пользователи"), вторым - имя элемента плана видов характеристик "Настройки пользователей", для которого нужно получить значение. Вот так выглядит код обработчика этой функции:

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

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

    Читайте также: