Установка даты запрета изменения данных БЕЗ УСТАНОВКИ МОНОПОЛЬНОГО доступа (для БП 1.6)

Опубликовал Валерий Гайдабура (director04) в раздел Администрирование - Системное

Данная обработка позволяет устанавливать дату запрета изменения данных пользователями, БЕЗ УСТАНОВКИ МОНОПОЛЬНОГО режима (то бишь без изгнания пользователей, работающих с информационной базой).
Проверена на БП 1.6 (1.6.17.4)

За основу взята штатная обработка конфигурации БП 1.6. Изменения минимальны.

Необходимость данных изменений возникла, в связи с позицией группы разработки БП (или вопреки ей), что установка даты запрета, может быть проведена только после гарантированного изгнания ВСЕХ пользователей базы данных (обуславливается тем, что изменения вступают в силу после перезапуска 1С текущим пользователем системы).

В моей организации это порядка 70 человек единовременно. Во время квартальной отчетности изгнание их из базы данных среди белого дня - сравни самоубивству...... Вот и пришлось изобретать велосипед.

Если кого заинтересует - прошу любить и жаловать.

PS:Спасибо - это много, достаточно плюсика!

Скачать файлы

Наименование Файл Версия Размер
Установка даты запрета изменения данных
.epf 20,77Kb
02.10.09
248
.epf 20,77Kb 248 Скачать

См. также

PowerTools от 1 000
Комментарии
1. Saw (Re:аниматор) 21.08.09 09:49 Сейчас в теме
>обуславливается тем, что изменения вступают в силу после перезапуска 1С текущим пользователем системы

смысл устанавливать если действия после перезапуска 1С пользователем?

дата запрета будет установлена, но пользователь не перезапуская сеанс может и поменять закрытый период
2. Валерий Гайдабура (director04) 3440 21.08.09 10:07 Сейчас в теме
(1) Именно такой смысл имеется в конфигурации ЗУП 2.5. Это там организовано именно так и ни как иначе. Спорить можно до зеленых соплей. Если не нравится - можно пользоваться штатной. Но, если нравится, то:
допустим в базе данных работает куча бухов и уйти домой (всвязи с квартальным отчетом) скоро не собирается. Но кто-то самый умный уже закончил отчетность и желает выставить запрет.
У администратора три варианта:
- собачиться с отстающими и выгонять их из базы (пользуясь штатной обработкой)
- оставаться на работе до ухода последнего двоешники (буха)
- установить дату запрета данной обработкой (и на следующее утро дата начнет уже действовать)

Выбирать вам.
3. Saw (Re:аниматор) 21.08.09 10:52 Сейчас в теме
> ... и на следующее утро дата начнет уже действовать)

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

если ночью не работают, то наверное имело бы место закрывать автоматически ночью тогда, есть же механизм регламентных заданий.

а есть бухгалтера которые не выходят, сеанс может висеть не сколько дней и когда же у него наступит утро?
4. Валерий Гайдабура (director04) 3440 21.08.09 11:15 Сейчас в теме
(3) Ну уважаемый, если у вас все так запущено, то вам действительно противопоказана данная обработка..... Выбирайте пункт 1-й
5. Saw (Re:аниматор) 21.08.09 11:38 Сейчас в теме
(4) у нас все ОК, продуман механизм закрытия, а вот с вашим решением будут косяки (накосячат во время так называемого закрытия, а утром и не исправят), просто хочу сказать что бесполезная обработка, вот и всё.

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

оставил свое мнение, без рецензии. асталависта!
6. Gamm (Gamm) 13 21.08.09 12:33 Сейчас в теме
Для корректной работы данного алгоритма, необходима прописать периодическую процедуру на клиенте которая каждые 3 минуты если были изменения обновляет параметр сеанса с Границами запрета.
7. Dmitry Chernykh (dim0n_la) 91 23.08.09 13:53 Сейчас в теме
Была похожая проблема.
Убирал монопольный режим установки даты запрета.
Для контроля был создан регистр сведений, который содержал список пользователей с обновленной датой запрета.
При установке даты запрета регистр необходимо очистить.
Далее в подписке на событие организованной для даты запрета (в БУ это "ПередЗаписьюДокументаДатаЗапретаРедактирования") нужно добавить проверку, есть ли пользователь в данном списке.
Если нет запускаю процедуру установки даты запрета для конкретного пользователя. дальше идет все своим чередом, т.е. проверяется дата запрета и в зависимости от нее проводится или не проводится документ.
Как вариант реализации. Просто тогда показалось, что будет лучше так, чем нагружать систему каждые несколько минут считывать параметрсеанса пользователя, которые итак очень медленно работают.
sidorov8; +1 Ответить
8. kitt al;dskjf;ldasjkf (kitt) 319 01.09.09 02:46 Сейчас в теме
Те кто не видит смысла в данной обработке, не забывайте что бывает распределенка основанная на организациях. То есть каждый филиал это отдельная организация. И когда нужно установить дату запрета в филиалах (то есть на работающих в главной базе сотрудниках это никак не отразиться, у них другая организация) то всё равно нужно чтобы сотрудники главной базы выходили, хотя они тут не сном, ни духом.
9. kitt al;dskjf;ldasjkf (kitt) 319 01.09.09 02:55 Сейчас в теме
А разработчиков типовой БП нужно долго бить молотком по пальцам, за алгоритм, при котором дата запрета изменения данных считывается только один раз за сеанс работы.
mtv:); munster; +2 Ответить
10. Алексей (Alav) 13 04.10.09 23:22 Сейчас в теме
А почему просто нельзя зайти в РС и установить ручками. И выгонять никого не надо
11. Наталья (valya977) 4 28.12.09 06:33 Сейчас в теме
Спасибо очень пригодилась,особенно в общепите!
12. Галина Злобина (gala2009) 3 07.10.11 18:32 Сейчас в теме
13. Андрей Макаров (XOCTEP) 111 05.05.14 11:00 Сейчас в теме
Спасибо, после конвертации работает на 2.0