Автоматическая установка даты запрета редактирования

12.12.19

Задачи пользователя - Закрытие периода

–

Обработка для автоматической установки даты запрета редактирования позволяет в автоматическом режиме или вручную устанавливать дату заперта редактирования у пользователя (ей).

Скачать исходный код

	Наименование	Файл	Версия	Размер
	Обработка для автоматической установки даты запрета редактирования: .epf 7,49Kb 21	.epf		7,49Kb	21	Скачать

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

Обработка заполняет регистр сведений "ДатыЗапретаИзменения" для предотвращения изменения данных в закрытых периодах. Работает как по заданию, так и вручную. Построена на использовании дополнительного реквизита. Его следует добавить у справочника «Пользователи» и назначить у тех пользователей, которым будет назначаться изменение Д.З.Р. Необходимо, что бы его имя было указано как в модуле обработки: КоличествоДнейДляПереносаДатыЗапрета. Его заполнение можно сделать обязательным, а для тех пользователей, которым не попадают под понятие закрытого периода установить заведомо большое значение.

На прилагаемых рисунках виден путь для настройки и подключения

Несмотря на то, что обработок на данную тему расположено множество, эта отличается простотой и тем, что можно закрывать будущие периоды. Особенно, хорошо для администраторов и пользователей, которым надо дать «только просмотр». Разумеется, не помогает для работы со справочниками, но для документов походит.

Обработка предназначена для работы в типовых конфигурациях и на основе БСП. Рекомендована для подключения к дополнительным обработкам. Но может использоваться как внешняя.

Работоспособность проверялась на платформе версии "8.3.16.1063", релизе конфигурации ЕРП "2.4.10.89", но уверен, что будет работать и версии 8.2 и в любой типовой конфигурации, использующей УФ.

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

дата запрета редактирования; закрытый период

–

См. также

Анализ расхождений выручки НДС и Налога на прибыль в декларациях (БП 3.0 ПРОФ и КОРП, КА 2, ЕRP)

Анализ учета Закрытие периода Платформа 1С v8.3 Бухгалтерский учет 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Налог на прибыль НДС Платные (руб)

Каждый бухгалтер не раз сталкивался с требованием от налоговой инспекции пояснить расхождения в показателях декларации по Налогу на прибыль («Доходы от реализации» + «Внереализационные доходы») и налоговой базой по НДС за год. Являются ли ошибкой подобные расхождения? Как пояснить налоговой их причину? Отчет «Анализ расхождений выручки НДС и Налога на прибыль в декларациях» поможет найти все расхождения.

7200 руб.

21.10.2017 83935 258 167

254

Ускоренное проведение документов (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020 27908 82 146

Помощник закрытия месяца

Закрытие периода Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

В современных конфигурациях УТ 11, КА 2, ERP 2 и их аналогах присутствует механизм закрытия периода. Но при ошибках учета закрыть период корректно становится практически невозможно! Давайте попробуем разобраться, как можно устранить ошибки и закрыть корректно месяц!

9000 руб.

20.03.2018 70265 267 58

293

Обработка "Списание доходов будущих периодов" и расширение

Учет доходов и расходов Закрытие периода Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Решение регламентирует учет доходов будущих периодов(ДБП) в организации: сохраняет подробную информацию о объекте ДБП. По окончании месяца на основе введенной информации формируются проводки списания ДБП, отчеты для бухгалтерского и налогового учета. Подходит как для различных версий Бухгалтерии 8.3, так и для ERP и КА.

5500 руб.

09.10.2020 18829 41 18

Автоматическое закрытие месяца в УНФ

Закрытие периода Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Закрытие месяца в Управлении нашей фирмой — это очень важная задача, которую надо выполнять регулярно. Как обычно, все важное и регулярное делать мы почему-то забываем =)

3600 руб.

30.09.2022 7314 13 0

Исправление ошибки закрытия месяца "Обнаружены ненулевые остатки по суммам при нулевом остатке по количеству в регистре себестоимости по организации". УТ 11.4,УТ 11.5, КА 2.4,КА 2.5, ERP 2.4, ERP 2.5, КА 2 Казахстан, Управление торговлей 3 для Казахстана

Закрытие периода Корректировка данных Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Закрытие месяца - важный процесс в современных конфигурациях, таких как УТ 11.4, УТ 11.5, КА 2.4, КА 2.5 ERP 2.4,ERP 2.5, КА 2 Казахстан, УТ 3 Казахстан регламентные операции влияют на расчет себестоимости, и ошибки в данном расчете не дают картины деятельности организации.

2400 руб.

27.10.2021 22542 302 35

Исправление ошибки закрытия месяца "Обнаружены отрицательные остатки по количеству в регистре себестоимости по организации" для 1С:УТ, КА и ERP

Закрытие периода Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Закрытие месяца - важный процесс в современных конфигурациях, таких как УТ 11.4, УТ 11.5, КА 2.4, КА 2.5 ERP 2.4,ERP 2.5, регламентные операции влияют на расчет себестоимости, и ошибки в данном расчете не дают картины деятельности организации.

3000 руб.

26.01.2023 8886 81 4

Помощник исправления развернутого сальдо по видам запасов и ГТД

Закрытие периода Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Платные (руб)

Обработка позволяет исправить развернутое сальдо по видам запасов, которое осталось после штатной обработки перепроведения документов. Подходит для конфигураций: УТ 11, КА 2, ERP

2400 руб.

15.07.2017 62639 144 45

140

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. dock 44 12.12.19 15:02 Сейчас в теме

Эм... а чем не устраивает типовой механизм БСП ?
Вместо "произвольная дата" ставишь "Предыдущий день"/"Конец прошлой недели"/"Конец прошлого месяца/квартала/года", настраиваешь отсрочку в днях...
По факту - то же самое, что и делает твоя обработка. Но с учетом разделов, пользователей и т.п.

2. gero 59 12.12.19 15:46 Сейчас в теме

(1)
Если коротко, то ничем.

Однако, если нужно для пользователей установить разный срок правки документ задним числом? Для Склада 10 дней, для Бухгалтерии 15?
Сам же написал, что даты в стандартной привязаны к стандартным интервалам, а это не всегда удобно.

А как в стандартной запретить сегодняшние документы, например? А пользователям имеющим админские права, работать под одной учеткой в Конфигураторе, а под другой в Предприятии? Или быть настолько аккуратными, что никогда не ошибаться? Я вот точно не такой)).

С моей обработкой удобно: поставил ДЗР на год вперед и не думаешь, как бы не навредить учету: если что-то нужно скорректировать, установил требуемую дату и через 15 минут ДЗР в следующем году - "само" установится рег. заданием. Когда бывает тупка, когда неожиданно вылазит, что период закрыт, но это гораздо лучше, чем краснеть перед Глав. бухом.
ИХМО, разумеется.

3. dock 44 12.12.19 17:01 Сейчас в теме

(2)

Однако, если нужно для пользователей установить разный срок правки документ задним числом? Для Склада 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) как отразится на работе типового механизма? что будет, если типовыми средствами настроен доступ по разделу/группе пользователей (или даже для всех пользователей), а обработкой по конкретному пользователю ? Не получится ли, что группе закрыто, а пользователю открыто? а "увидеть" это я смогу, только зайдя в список пользователей ?

4. gero 59 12.12.19 17:34 Сейчас в теме

(3)
Как-то много написано. И местами не к месту, например:

"Однако, если нужно для пользователей установить разный срок правки документ задним числом? Для Склада 10 дней, для Бухгалтерии 15?
это разграничение по пользователям/разделам - типовой механизм. Твоя обработка этого и не делает."
я пишу про пользователей, а ты добавляешь про разделы. Зачем?

К чему писать про какие-то приказы? Это имеет отношение к теме разговора? Я не понимаю.

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

И да, доп. реквизит заполняется не у каждого пользователя, у только у тех, которые выходят из сущности <Для всех пользователей>.

Кстати, вопрос про текущие (сегодняшние) документы пока открыт.

Я ни в коем случае не говорю про троллинг, но это он

5. dock 44 12.12.19 18:53 Сейчас в теме

(4) нет, это не троллинг, это холивар! :) Холивар веселее и беспощаднее!

1)

Для Склада 10 дней, для Бухгалтерии 15?

"Склад" и "Бухгалтерия" - это имена пользователей ? Т.е. предложенный механизм управления ДЗР рассчитан только на конкретного пользователя ? Никаких групп пользователей, никаких разделов учета?

2)

К чему писать про какие-то приказы? Это имеет отношение к теме разговора? Я не понимаю.
Я пишу про админа с админскими правами, ты ловко продолжаешь писать про пользователя с админскими правами и указываешь на какую-то гипотетическую лень.

Приказ/регламент - это как "снять" с админа/программиста вообще проблему управления ДЗР. При этом не давать полные права простым пользователям.
Ведь мало кто бывает настолько аккуратным, что бы никогда не ошибаться. И единственный способ не ошибиться самому, это передать выполнение работы другому!

А пользователям имеющим админские права, работать под одной учеткой в Конфигураторе, а под другой в Предприятии? Или быть настолько аккуратными, что никогда не ошибаться? Я вот точно не такой)).

С моей обработкой удобно: поставил ДЗР на год вперед и не думаешь, как бы не навредить учету: если что-то нужно скорректировать, установил требуемую дату и через 15 минут ДЗР в следующем году - "само" установится рег. заданием.

И да, доп. реквизит заполняется не у каждого пользователя, у только у тех, которые выходят из сущности <Для всех пользователей>.

Доп. реквизит добавляется сущности "пользователь". :)
Т.е. я правильно понимаю, если у пользователя доп. реквизит не заполнен, то это пользователь попадает в категорию <Для всех пользователей>?

4)

Кстати, вопрос про текущие (сегодняшние) документы пока открыт.

Правда я пока не могу представить себе ситуацию, для чего нужно закрывать текущие (сегодняшние) документы. С чем же тогда работать ? :)

- - - -

Пока я для себя не выяснил: В чём всё-таки "бонус"/ "фишка"?

- В типовом механизме нет автоматического изменения ДЗР ?
так нет, имеется и прекрасно работает...
- Предложенный механизм "упрощает" работу ?
так ведь добавляется еще один реквизит, управление ДЗР переносится еще и в справочник "Пользователи". Т.е. больше действий, больше контроля - не вижу упрощения.
- Повышается безопасность? можно передать управление ДЗР другому пользователю ?
"чужую" учетку можно изменять только с полными правами... а в типовом механизме есть отдельная роль с правом изменения ДЗР.
- расширяется типовой функционал ?
насколько я понял, предложенный функционал рассчитан на управление ДЗР только в разрезе пользователей.
т.е. на лицо не расширение, а ограничение типового функционала :)

З.Ы. пока писал возник очень серьезный вопрос: что будет, если пользователь для самого себя изменит значение дополнительного реквизита "КоличествоДнейДляПереносаДатыЗапрета"?
нужно провести эксперимент, что вообще может ограниченный пользователь сделать со своей "учеткой" :)

6. gero 59 13.12.19 12:11 Сейчас в теме

(5)
Если холивар это другое дело)

Прошу, прочти 1. Там есть половина ответов на твои вопросы.

1.Да. Это гипотетические пользователи. Никаких групп.

2.Про полные права - я не писал, что нужно давать их пользователям. Свой ответы про приказ ты не развернул, к сожалению. Я про то, зачем ты вообще стал писать о нём. Не для объёма же?

3.Это понял верно.

4.От меня и других админов. Можно поставить начальству. Получиться а-ля "только просмотр". Об этом тоже написано выше

Про выводы:
Налицо упрощение функционала: Скажем строгий ГлавБух говорит: вот Петрову разрешаю исправлять документа в течении 10 дней. А вот Васечкин плохой, ему только 5. И в этом ограничении, есть значительное упрощение.

Про твоё ЗЫ: Провел. Удивительно. Есть доступ. Даже электронную почту может менять. Пароль пусть меняет, для этого даже оснастка специальная есть. Но почту ни-ни.
Кроме того может много что, и даже открывать чужие на просмотр, хотя не со всеми реквизитами.
И да, если поменяет реквизит "КоличествоДнейДляПереносаДатыЗапрета" рег. задание изменит ему ДЗР, но я думаю, что мы убедим его это не делать.
Не ожидал, за это спасибо.

ЗЫ. У меня не получилось дать доступ по дням. см скрин.
ЗЫ2. Рег задание, про которое ты писал я не нашел :( Подскажешь?

Прикрепленные файлы:

11. gero 59 16.12.19 17:18 Сейчас в теме

(6)
Учитывая, что есть возможность редактирования доп. реквизита "КоличествоДнейДляПереносаДатыЗапрета" сотрудниками не "Админами" рекомендую использовать заплатку: использование условий видимости или доступности. Можно использовать сравнение реквизита Подразделение или Комментарий, например:

Прикрепленные файлы:

7. dhurricane 13.12.19 12:44 Сейчас в теме

(3)

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

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

8. gero 59 13.12.19 13:14 Сейчас в теме

(7)
Значит верно, что я его не смог найти.

Но если я правильно понимаю, абсолютная дата привязана к некой другой дате. Т.е. раз так она в любом случае будет "относительной", а не "абсолютной". ИМХО, разумеется.

9. dhurricane 13.12.19 13:33 Сейчас в теме

(8) Не совсем понял вопрос про абсолютную дату, если конечно это вопрос. :-)

В стандартной обработке установки даты запрета Вы можете установить конкретную дату, например, 13.12.2019. Это и есть обозначенная мной абсолютная дата. Во время контроля дата объекта будет сравниваться именно с этой датой.

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

10. gero 59 13.12.19 14:06 Сейчас в теме

(9)
Да, всё так. Согласен.

Я про то, что писалось в (1) когда используешь отсрочку, то получаешь конкретную глубину для конкретного пользователя. Скажем, Петрову можно корректировать документы, за последние 10 дней.

dock, утверждал, что там можно сделать. Или я его неправильно понял.

14. dock 44 25.12.20 01:53 Сейчас в теме

(10) с тем что можно установить произвольный период - я ошибся.
dhurricane в (9) правильно говорит об "относительной" и "абсолютной" дате
На текущий момент можно установить "относительную" дату с отсрочкой для всех "Конец прошлого года/квартала/месяца/недели". А вот для "Предыдущий день" нельзя...

12. TerveRus 24.12.20 13:06 Сейчас в теме

(3)

Из моей практики сопровождения ЗУП 3 (тот же механизм применим и для БУХ 3, ERP, УТ 11 - версия БСП в этих конфигурациях более-менее одинаковая).

А вот это чистое вранье. Так и надо было писать, что речь про ЗУП 3, потому что ни в БП ни в УТ автоматической установки даты запрета никогда не было.
С чего такой вывод, что это стандартный функционал БСП? С какой версии БСП он пошел?

13. dock 44 25.12.20 01:47 Сейчас в теме

(12) "автоматической установки даты запрета никогда не было" с этим полностью согласен, автоматически не устанавливается - нужно настраивать.
В БСП используется "относительная дата".
Для настроек "Конец прошлого..." можно установить дату отсрочки. Вот для "Предыдущий день" нельзя установить дату отсрочки.

Проверил до версии БСП 2.1.1.22 от 12.10.12 (первая версия БСП 2.1) - функционал присутствует. Еще дальше в прошлое уже не стал лезть. Во всех последующих версиях БСП (2.2, 2.3, 2.4, 3.0, 3.1) - практически без изменений.
Проверил в БП 3.0 - функционал присутствует: заходим в окно "Редактирование даты запрета", жмем на "Больше возможностей >>" и выбираем из выпадающего списка ...

17. TerveRus 25.12.20 09:14 Сейчас в теме

(13) то есть самое малое можно автоматически двигать на конец прошлого месяца?
Странно, что не сделали на конец любого периода.
Обычно требуется держать дату запрета в несколько дней назад - с этим вот и проблема, поэтому каждый изобретает велосипед.

18. dock 44 25.12.20 12:48 Сейчас в теме

(17) минимальный - "Конец прошлой недели"

15. dock 44 25.12.20 01:56 Сейчас в теме

(3)

"Предыдущий день" - отсрочка 10 дней и отсрочка 15 дней.

поправочка - для относительной даты "Предыдущий день" отсрочку установить нельзя :(

16. dock 44 25.12.20 02:55 Сейчас в теме

Отменный холивар получился! Всем участникам моё почтение и благодарность. Автору отдельное спасибо за прекрасный повод получше разобраться с ДЗР.
Для себя подведу итог по опубликованной обработке.
1) плюсы:
- более гибкое управления ДЗР в разрезе пользователей: есть возможности, которые не покрывает типовой функционал;
- возможность запретить изменения "в будущем": прекрасный лайф-хак "защитить себя" от случайных ошибок - а-ля "только просмотр";
2) минусы:
- "рушится" типовой функционал ДЗР в разрезе групп пользователей / разделов учета (в моей сфере это критично);
- имеется недочет в безопасности: пользователь самому себе может поправить дату запрета;
- гипотетически могут возникнуть проблемы с регламентным заданием для внешней обработки.

Мои ошибки/заблуждения, которые были исправлены в ходе обсуждения.
1) Типовой механизм ДЗР использует регламентное задание. - С чего это я вообще взял то ???
2) Для "относительной" даты "Предыдущий день" можно установить отсрочку. - К сожалению, нельзя. Только для "Конец прошлого ..."
Если кого-то нечаянно ввёл в заблуждение - прошу прощения.

P.S. Про "приказы" - это я хотел обратить внимание, что некоторые "проблемы" решаются не только кодом, но и "бюрократией".

P.P.S. Terve!R и тебе благодарочка - напомнил о теме.