gifts2017

Создание журнала регистрации, который хранится в отдельной базе

Опубликовал Кудерков Александр (appolon321) в раздел Администрирование - Журнал регистрации

Была потребность в организации учета изменения практически всех документов и справочников.
С процессом и результатом разработки хочу поделиться

Разработка велась для платформы 1С Предприятие 8.2. конфигурация Управление торговлей 10.3

Устав постоянно проводить следствие, кто, что и когда изменил в документе, справочнике, побудило меня разработать механизмы записи изменений практически всех документов и справочников конфигурации

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

Хотелось чтобы пользователь, сам себе отвечал на свои вопросы "Кто", "Когда" и "Что на что поменял".

Выбрал вариант хранения об изменении реквизитов объектов в отдельной базе.

  1. В рабочей конфигурации добавил два дополнительных регистра сведений: в один из  регистров сведений сливается на временное хранение информация об изменениях основных реквизитах объектов, во второй регистр сливается информация об изменениях основных реквизитах табличных частей объектов
  2. Добавил процедуры контроля изменения, как основных реквизитов, так и реквизитов табличных частей
  3. Добавил два подписчика событий: один подписчик контролирует на момент записи изменения в справочниках, второй следит за изменением в документах. В случае если выявляется какое-либо изменение, то информация об изменении регистрируется в одном из двух ранее созданных регистров
  4. Добавил регламентное задание, которое отрабатывает в рабочей базе с определённой периодичностью, и выгружает файлами в формате xml, изменения которые поднакопились в ранее созданных регистрах сведений. После удачной выгрузки записей регистров в файл, выгруженные записи убираются из регистров. В итоге объем информации, который храниться в этих двух регистрах незначительный
  5. Создана конфигурация, куда загружались файлы с информацией об изменениях реквизитов объектов
  6. В конфигурации журнала регистрации добавлено регламентное задание, которое загружает файлы с информацией об изменениях реквизитов объектов
  7. Так же решил из рабочей базы выгружать информацию из стандартного журнала регистрации, рабочей базы,  в базу "журнал регистраций"
  8. Отдельными пакетами куски журнала регистрации также выгружаются из рабочей базы и загружаются на стороне базы "журнал регистрации"
  9. На стороне рабочей базы, добавлена внешняя обработка при помощи которой из любого документа, справочника можно выбрать информацию об изменениях реквизитов
  10. Также в рабочей базе добавлена внешняя обработка которая выводить привычный вид журнала регистрации, но по данных базы "журнал регистрации" 

Плюсы разработки:

  1. количество спорных моментов сократилось
  2. пользователи самостоятельно могут проводить следствия и расследования

Минусы разработки:

  1. Хранение изменений всех справочников и документов, требует больших объемов на винтах.
  2. Винты, на которых хранится информация, должны быть скоростными
  3. При записи объектов запускаются дополнительные процедуры, которые хоть и незначительно, но замедляют работу пользователя
  4. При увеличении объема базы "Журнала регистрации", скорость формирования отчетов по изменениям реквизитов объектов снижается.

Надеюсь, мой опыт, может быть кому-нибудь быть полезен.

 

В данной разработке контролируется изменение только объектов типа "Документ" и "Справочник".


Многие идеи черпались на сайте infostart.ru 

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

Наименование Файл Версия Размер Кол. Скачив.
Конфигурация базы, где сохраняется журнал регистрации
.cf 68,53Kb
13.02.13
54
.cf 68,53Kb 54 Скачать
Обработка внешний журнал регистрации для рабочей конфигурации
.epf 15,17Kb
13.02.13
28
.epf 15,17Kb 28 Скачать
Обработка по выводу информации о изменениях реквизитов объектов для рабочей конфигурации
.epf 15,25Kb
13.02.13
30
.epf 15,25Kb 30 Скачать
Кусок конфигурации где все необходимые объекты и модули для интеграции в учетную базу
.cf 38,83Kb
13.02.13
33
.cf 38,83Kb 33 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Юрий Пермитин (YPermitin) 14.02.13 06:40
Интересное решение! Отлично!
2. Антон Чарушкин (hulio) 15.02.13 09:47
В свое время не стали заморачиваться и изобретать свои велосипеды. Взяли и купили Журнал изменений
Посмотрите, неплохая штука :)
3. Кудерков Александр (appolon321) 15.02.13 15:36
4. Кудерков Александр (appolon321) 15.02.13 15:37
(2) hulio, Самому было интересно как это можно реализовать.
5. aspirator 23 (aspirator23) 24.02.13 18:45
Интересная реализация.
Странно насчет того что медленно работают отчеты и нужны быстрые винты для внешнего журнала.
Может у тебя индексы в этой базе отключены/неработают/ненастроены?
6. Кудерков Александр (appolon321) 24.02.13 19:11
(5) aspirator23,
Попробую про индексировать несколько измерений, посмотрю насколько изменится скорость. Я так думаю что объем базы в первую очередь влияет на производительность.
7. andrey dyak (dyak84) 23.07.13 18:59
Спасибо. на выходных попробую вашу идею приобщить на шей базе размером 290 гб как будет работать обязательно отпишусь. Спасибо за идею. Так держать.
8. Alever (Alever) 30.10.13 09:47
Было бы еще интересно полностью отказаться от типового журнала регистрации я думаю, дабы облегчить рабочую базу. Причем может быть было бы наверное лучше у пользователей отобрать права на формирование обработок и дать их только нескольким ответственным лицам - мол если хочешь узнать - пиши служебку почему и по каким причинам - а ответственный бы уже формировал отчет(обработку) и скидывал результат. Ну это уже дела фирмы, а за идею кстати 5+ . В интернете если поискать, можно найти нечто подобное, но уже за денежку:
http://softonit.ru/component/jshopping/product/view/1/4.html
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа