В типовых решениях БП, УПП от 1С нет возможности простому пользователю быстро ответить на вопрос — кто и когда «потрогал» документ в базе? Ответ на вопрос «зачем?» (риторический, зачастую) хотелось бы получить от автора этого изменения, да вот незадача — поиск этого человека по журналу регистрации для бухгалтера в восьмерке — это высший пилотаж.
Задался целью — дать возможность гл. буху, в один щелчок мыши в документе увидеть, кто же это сделал.
Решение основано на хранении ссылок на авторов в дополнительных реквизитах документов, подписках на событие записи/проведения. Доступ к ифнормации об авторах изменеий через нажатии кнопки на форме документа («Доп. реквизиты» в БП, «Свойства» в УПП)
Не требует вмешательства в типовую конфигурацию поставщика, внедряется в конфу как отдельная поставка.
Подчеркиваю, решение крайне простое само по себе и достатчоно удобно. Достаточно для случаев нормальной корпоративной работы в малых фирмах. Не подходит для случая, если отдельные «продвинутые пользователи» стремятся и умеют скрывать скрыть следы своей работы (например, свойства документа можно изменить через групп. обработку).
Работает в БП 2.0, УПП 1.3, другие не проверял.
Конфигурация содержит в себе.
— 1 перечисление «Действие с объектом»
— 1 обработку «АвторыДокументовСозданиеРеквизитов»
— 4 подписки на события
После установки на поддержку, запустите обработку АвторыДокументовСозданиеРеквизитов.
Поизведите тест записи/изменения любого документа.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Простейшая универсальная реализация ответа на вопрос — кто создал/изменил/провел/распровел документ в базе 1С8 БП, УПП
Перейти к публикации
Все гениальное просто!
+ за идею!
Однозначно + за идею, только свойства не хранят историю, по мне так лучше завести регистр сведений в котором хранить дату, документ, действие с документом в виде перечисления например, и пользователя. Конечно без изменения конфы тут уже не обойтись, но на обновления это влиять не будет, а для главбуха отчетик на основе регистра наваять, работать будет намного быстрее журнала регистрации.
(2) Alex Star,
Согласен, истории по большому счету нет. Моему клиенту достаточно.
А даже если история есть, пользователь зачастую идет в отказ.
Дескать, «я ничего не менял/просто нажал ОК». Тут уже поможет только версионирование.
Но вся соль в простоте и невмешательстве в конфигурацию.
почему нельзя ставить больше одного плюса??? 🙂
идея — супер — реализую у себя такое.
в принципе часто достаточно информации «кто последний трогал документ»
и ранее я сталкивался со следующей реализацией:
в каждом(!) документе добавлены реквизиты «ПоследнийРедактор», «ДатаПоследнегоРедактирования»
и соответствующими подписками они заполнялись.
со всеми вытекающими последствиями для дальнейшей поддержки.
(собственно конфа та была основательно переколбашена и на прямую не обновлялась)
вобщем подход автора всячески поддерживаю — рано или поздно к таким решениям приходят все
кому приходится поддерживать доработанные ранее конфигурации.
Идея неплохая. Только В УПП есть отчет «История изменения объектов», чем он не устраивает?
Но + поставил
Использование отчета в УПП не устраивает :
— требует включенного версионирования объектов
— не удобен в работе. Пока выберешь нужный документ, у ГБ уходит порядка минуты.
Зачем дублировать информацию, которая уже есть в журнале регистрации? примсер обработки, которая поключается как внешняя печатная форма и распечатывает ЖР по ссылке:
Если уж обрабатывать изменения вобъетах -то смотреть и изменния в реквизитах как например -добавить еще одно свойство что было изменнно: Изменения: Дата документа 12.03.12 12:12:12=> 14.03.12 01:01:01
Скорость, ребята, скорость получения информации…
Заюзал отчет по журналу регистарции, указанный i132.
Пока пишу это сообщение, все еще нет ответа от него, кто же потрогал документ?
Спасибо за идею. Плюс. Согласна с комментариями. С журналом регистрации работать долго, особенно когда база очень большая. А в этом случае пользователь сам быстро и просто сможет посмотреть кто и когда изменил документ.
(2) Лог записывается в свойствах документа — за это и плюсуют, а свойства документов и так хранятся в регистре сведений.
Решений через дополнительный регистр сведений, или на ИнфоСтарт много, на свойствах первое.
Ваше решение не говорит обо всех кто сказал «Мяу» -а только о последнем «гавкнувшем»
Все верно. Все минусы подмечены верно. Плюсы описаны выше.
Идея и реализация крайне просты. Моему клиенту истории в один шаг было вполне достаточно.
Тапками не кидайте.
(11) (10) i132, Да, вы правы, свойства хранятся в регистре, но в этом регистре нет периода 🙁 … и нередко бывает что «главбух» замечает косяки, когда редактирует данный объект, соответственно в свойствах уже тот кто косяк и заметил
Решение спорное, но идея хороша. Плюс за изящное использование стандартных механизмов нестандартным способом.
На УТ 10.3 тоже идет
Хм, отличная идея. Главный плюс — невмешательство в типовую конфу. Да и прикрепить можно к любой (или почти любой) конфигурации
Да, славная идея.
Хорошая идея, верно все гениальное просто
(13)Согласен. Мысль не стандартная, но…