()
Однако, если нужно для пользователей установить разный срок правки документ задним числом? Для Склада 10 дней, для Бухгалтерии 15?
это разграничение по пользователям/разделам - типовой механизм. Твоя обработка этого и не делает.
Для Склада 10 дней, для Бухгалтерии 15?
"Предыдущий день" - отсрочка 10 дней и отсрочка 15 дней.
Сам же написал, что даты в стандартной привязаны к стандартным интервалам, а это не всегда удобно.
по факту, в твоей обработке реализован только один типовой интервал - "предыдущий день"
А пользователям имеющим админские права, работать под одной учеткой в Конфигураторе, а под другой в Предприятии?
Эм... это тут причем ? "Админские" права вообще должны быть только у админа/программиста: обычный пользователь с полными права это... это "лень настраивать права" :)
"Право на изменение ДЗР" - уже давно является типовой ролью. ДЗР уже может изменять пользователь БЕЗ полных прав.
поставил ДЗР на год вперед ...
Опять таки, в чем отличие от типового механизма ? Типовой механизм точно также использует регламентное задание, точно также по наступлении требуемой даты запрещает доступ...
Из моей практики сопровождения ЗУП 3 (тот же механизм применим и для БУХ 3, ERP, УТ 11 - версия БСП в этих конфигурациях более-менее одинаковая).
1) Настройка ДЗР по разделам учета и группам пользователей.
2) Для "кадровиков" - "Предыдущий месяц" с отсрочкой 5 дней. 5 дней для закрытия кадровых документов
3) Для "расчетчиков" - "Предыдущий месяц" с отсрочкой 10 дней (выплата ЗП 10-го числа)
4) У "главного расчетчика" - права на изменение ДЗР. Для исключительной ситуации: "кадровику" требуется внести изменения после 5-го числа. Доступ дается конкретному пользователю согласно служебной записки. Доступ "открывает" "главный расчетчик".
Сие изложено в приказе, все пользователи ознакомлены. "Админ" один раз настроил доступ по разделам и группам пользователей и забыл. Далее полностью на ответственности "главного расчетчика" - причем пользователь в изменение заходит 1-2 раза в год, что бы открыть доступ конкретному пользователю, согласно служебной записки. Все остальное - "на автомате".
Ни в коем случае я не собираюсь как-то осуждать автора.
Но! если уж появился явный "велосипед", то он должен выполнить хотя бы одно условие: 1) Быть более удобным, чем типовой 2) Иметь свои уникальные фишки, которых нет в типовом механизме. 3) Не "ломать" типовой механизм, либо полностью его заменять.
ИМХО, текущая же обработка не выполняет ни одного из условий:
1) удобней? проще?
а) нужно создать доп. реквизит, у каждого пользователя установить количество дней. Повторюсь -
у каждого!!!
("а для тех пользователей, которым не попадают под понятие закрытого периода установить заведомо большое значение.")
б) для автоматизации, требуется настроить запуск обработки по расписанию... не возникало проблем с безопасностью ? ;) в БСП есть механизмы, которые "слегка" противятся запуску внешних обработок по расписанию.
в) дата запрета, я так понимаю, будет видна только в списке пользователей. В типовой обработке по управлению ДЗР я вообще что нибудь увижу?
2) уникальные фишки? : "можно закрывать будущие периоды." - что подразумевается под "будущими периодами" ? чем отличается от "предыдущий день" + отсрочка ?
3) как отразится на работе типового механизма? что будет, если типовыми средствами настроен доступ по разделу/группе пользователей (или даже для всех пользователей), а обработкой по конкретному пользователю ? Не получится ли, что группе закрыто, а пользователю открыто? а "увидеть" это я смогу, только зайдя в список пользователей ?