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

12.12.19

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

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Обработка для автоматической установки даты запрета редактирования:
.epf 7,49Kb
26
26 Скачать (1 SM) Купить за 1 850 руб.

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

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

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

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

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

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

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

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

См. также

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

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

14400 руб.

29.04.2020    35245    113    152    

77

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

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

28000 руб.

20.03.2018    76624    280    76    

305

Закрытие периода Оптовая торговля Розничная торговля Кассовые операции Учет доходов и расходов Бухгалтер Платформа 1С v8.3 Бухгалтерский учет 1C:Бухгалтерия 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:CRM ПРОФ, КОРП 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 1С:ERP. Управление холдингом Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Гостиничный бизнес Пищевая промышленность Россия Бухгалтерский учет Бюджетный учет Налоговый учет ЕНВД ЕСХН ИП, ПБОЮЛ, КФХ Налог на прибыль НДС УСН ПСН (патентная система налогообложения) Платные (руб)

Внешняя обработка для ведения в электронной форме КУДиР в 1С - книги учёта доходов и расходов для предприятий на УСН, ПСН, ЕСХН. Заполнение раздела 1 - "доходы и расходы" из журнала документов вашей ИБ (любой конфигурации 1С:Предприятие 8). Формирование отчета Кассовая книга КО-4 по данным раздела 1.

6990 руб.

15.03.2016    118739    301    158    

285

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

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

2400 руб.

15.07.2017    64388    157    49    

154

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

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

5880 руб.

12.03.2014    134551    81    97    

108

Закрытие периода Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Бухгалтер Пользователь Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Менеджер забывает перемещать товар между складами, а в УТ отключен контроль остатков ? Бухгалтер готов застрелиться при закрытии месяца и выравнивании отрицательных остатков по складам и фирмам ? Используй автоматическое перемещение товаров между складами и организациями для 1С УТ 11.

5000 руб.

30.05.2019    29851    33    10    

37

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

Закрытие месяца в конфигурации 1С:Управлении нашей фирмой — это очень важная задача, которую необходимо выполнять на постоянной основе. Однако, как зачастую бывает, важные и регулярные задачи могут быть упущены из виду. В связи с этим, нами было разработано решение для автоматического закрытия месяца в 1С:УНФ для оптимизации данного процесса.

3600 руб.

30.09.2022    8551    21    0    

21

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

Внешняя обработка, позволяющая произвольным образом заполнять документ "Корректировка регистров" Предназначена для использования в конфигурациях "Управление торговлей 11", "Управление небольшой фирмой", "ERP Управление предприятием", а также в других конфигурациях, в состав которых входит библиотека стандартных подсистем (БСП) версии 2.2+ и указанный выше документ.

2400 руб.

13.07.2015    51715    175    29    

127
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. dock 45 12.12.19 15:02 Сейчас в теме
Эм... а чем не устраивает типовой механизм БСП ?
Вместо "произвольная дата" ставишь "Предыдущий день"/"Конец прошлой недели"/"Конец прошлого месяца/квартала/года", настраиваешь отсрочку в днях...
По факту - то же самое, что и делает твоя обработка. Но с учетом разделов, пользователей и т.п.
корум; +1 Ответить
2. gero 60 12.12.19 15:46 Сейчас в теме
(1)
Если коротко, то ничем.

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

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

С моей обработкой удобно: поставил ДЗР на год вперед и не думаешь, как бы не навредить учету: если что-то нужно скорректировать, установил требуемую дату и через 15 минут ДЗР в следующем году - "само" установится рег. заданием. Когда бывает тупка, когда неожиданно вылазит, что период закрыт, но это гораздо лучше, чем краснеть перед Глав. бухом.
ИХМО, разумеется.
3. dock 45 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 60 12.12.19 17:34 Сейчас в теме
(3)
Как-то много написано. И местами не к месту, например:

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

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

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

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

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

Я ни в коем случае не говорю про троллинг, но это он
5. dock 45 12.12.19 18:53 Сейчас в теме
(4) нет, это не троллинг, это холивар! :) Холивар веселее и беспощаднее!

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


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

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


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


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

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


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

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

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

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

- - - -

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

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


З.Ы. пока писал возник очень серьезный вопрос: что будет, если пользователь для самого себя изменит значение дополнительного реквизита "КоличествоДнейДляПереносаДатыЗапрета"?
нужно провести эксперимент, что вообще может ограниченный пользователь сделать со своей "учеткой" :)
6. gero 60 13.12.19 12:11 Сейчас в теме
(5)
Если холивар это другое дело)

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

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

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

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

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

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

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

ЗЫ. У меня не получилось дать доступ по дням. см скрин.
ЗЫ2. Рег задание, про которое ты писал я не нашел :( Подскажешь?
Прикрепленные файлы:
11. gero 60 16.12.19 17:18 Сейчас в теме
(6)
Учитывая, что есть возможность редактирования доп. реквизита "КоличествоДнейДляПереносаДатыЗапрета" сотрудниками не "Админами" рекомендую использовать заплатку: использование условий видимости или доступности. Можно использовать сравнение реквизита Подразделение или Комментарий, например:
Прикрепленные файлы:
7. dhurricane 13.12.19 12:44 Сейчас в теме
(3)
Типовой механизм точно также использует регламентное задание, точно также по наступлении требуемой даты запрещает доступ...
Небольшое уточнение. Если не ошибаюсь, в БСП вовсе не используется регламентное задание. В информационной базе храниться именно относительная дата запрета, а абсолютная дата уже высчитывается "на лету" во время проверки.
8. gero 60 13.12.19 13:14 Сейчас в теме
(7)
Значит верно, что я его не смог найти.

Но если я правильно понимаю, абсолютная дата привязана к некой другой дате. Т.е. раз так она в любом случае будет "относительной", а не "абсолютной". ИМХО, разумеется.
9. dhurricane 13.12.19 13:33 Сейчас в теме
(8) Не совсем понял вопрос про абсолютную дату, если конечно это вопрос. :-)

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

А можете установить "Предыдущий день". Это уже относительная дата. Для нее в момент контроля сначала вычисляется абсолютная дата относительно текущей, а затем уже дата объекта контроля будет сравниваться с вычисленным значением.
10. gero 60 13.12.19 14:06 Сейчас в теме
(9)
Да, всё так. Согласен.

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

dock, утверждал, что там можно сделать. Или я его неправильно понял.
14. dock 45 25.12.20 01:53 Сейчас в теме
(10) с тем что можно установить произвольный период - я ошибся.
dhurricane в (9) правильно говорит об "относительной" и "абсолютной" дате
На текущий момент можно установить "относительную" дату с отсрочкой для всех "Конец прошлого года/квартала/месяца/недели". А вот для "Предыдущий день" нельзя...
12. TerveRus 24.12.20 13:06 Сейчас в теме
(3)
Из моей практики сопровождения ЗУП 3 (тот же механизм применим и для БУХ 3, ERP, УТ 11 - версия БСП в этих конфигурациях более-менее одинаковая).

А вот это чистое вранье. Так и надо было писать, что речь про ЗУП 3, потому что ни в БП ни в УТ автоматической установки даты запрета никогда не было.
С чего такой вывод, что это стандартный функционал БСП? С какой версии БСП он пошел?
13. dock 45 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 45 25.12.20 12:48 Сейчас в теме
(17) минимальный - "Конец прошлой недели"
15. dock 45 25.12.20 01:56 Сейчас в теме
(3)
"Предыдущий день" - отсрочка 10 дней и отсрочка 15 дней.

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

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

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

P.P.S. Terve!R и тебе благодарочка - напомнил о теме.
19. gero 60 27.01.21 18:00 Сейчас в теме
Оставьте свое сообщение