ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Посмотрел все версии "журналов регистрации изменений" которые есть на сайте. Так как почти все платные и с закрытым исходным кодом или же функциональность меня не удовлетворила написал свою простую конфигурацию.
Основные характеристики:
1. Записывает изменения в документах и справочниках.
2. Журнал изменений сделан на основе справочника.
3. Регистрируются изменения в реквизитах и в записях табличных частей.
4. Подсистема очень простая и состоит всего лишь из:Справочника,Обработки,ОбщегоМодуля, Подписки на события и Регламентного задания.
История изменений реквизитов и табличных частей справочников, документов, независимых регистров сведений, возможность отката изменения, восстановление удаленных объектов, сбор статистики использования базы 1С. Альтернативный журнал регистрации.
Конфигурация LogiCH эффективно решает проблему хранения и анализа записей журналов регистрации. Разработка использует столбцовую СУБД ClickHouse, одну из самых быстрых Big Data OLAP СУБД. Любой анализ журнала можно выполнить в одном отчете, в котором доступны все возможности СКД с учетом ограничений RLS. Количество подключаемых баз не ограничено и не влияет на скорость построения анализа.
Журнал регистрации получения работниками расчетных листков (реестр получения расчетных листков), позволяющий подтвердить при проверке факт выдачи расчетного листка в соответствии со ст.136 ТК РФ.
В материале рассматривается сравнение двух инструментов для работы с журналом регистрации 1С: утилиты ibcmd и платформы Vector. Описаны их функциональные возможности, тестирование производительности и практическое применение для преобразования логов в формат JSON.
Поговорим про логирование в приложениях на базе 1С, рассмотрим проблемы, которые возникают при сборе информации из этих систем, и обсудим практический опыт применения внутренних и внешних инструментов для анализа логов.
Отличная обработка.
Есть пожелание:
1) при внесении изменений в табличной части (например, изменил колич. товара с 8 на 10), старое и новое значение количества в разных строках находятся. Т.е. выводит все реквизиты таб. части со старыми значениями и ниже все реквизиты таб. части с новыми значениями. Неудобно искать, что же изменилось. С реквизитами шапки документа синхронизация старых и новых значений происходит на ура (например, сумма документа).
2) Для более быстрого поиска измененных реквизитов можно было бы добавить галочку "Изменен" в таблице изменений.
(1) Быстрое определение изменений в табличных частях - это отдельная тема, и еще требует дальнейшей проработки. Пока реализовано на уровне записей - но можно подумать как их свернуть.
(2) Подсистема не фиксирует загрузки объектов, только их изменение в центре.
А как эта подсистема реагирует на УРИБ? Например, в филиале Создали Документ, исправляли и дополняли, но не провели. Документ отправился в центр. Там его провели. И он опять уходит в филиал. КАк это все отражается?
(4) На справочник нет никаких ограничений! Для хранения изменений он более оптимален по сравнению с регистрами сведения (за счет использования табличной части).
(7) Где то на инфостарте были измерены скорость работы с регистрами и справочником. Так в регистры сведений проигрывают по скорости записи/чтения справочникам. В регистрах идут проверки на уникальность записи, кажись так.
странно отрабатывается обновление (при нажатии кнопки "Обновить") в обработке "Журнал изменений". С самом журнали запись есть, а в обработке показывает с запозданием минут на 15.
Но уж получение данных из таблиц справочника точно медленнее, чем параметризованная виртуальная таблица регистра.
Да и сам принцип нехорош, мне кажется: справочники предназначены для хранения фиксированной, статичной информации, а динамика согласно идеологии 1С реализуется документами и всяческими регистрами. А всё новые и новые записи об изменениях это явно не то, что можно назвать статичными данными.
(10) Согласен в качестве общего подхода.
Но если записи лишь добавляются в табличную часть элемента, то , конечно, эта операция выполняется быстрее записи в регистр. К тому же при записи действует блокировка только на текущий элемент справочника , что тоже дает преимущество в многопользовательском режиме перед использованием регистра сведений.
(11) Не совсем понимаю, причём тут табличная часть справочника. Каждая запись регистрации означает элемент, а не строку табчасти, или я не прав? Для чего вообще в этом случае табличная часть может использоваться?
(13)
1. Запись в справочник идет быстрей.
2. В справочнике информация хранится эффективней (так как фактически расположена в двух таблицах). В регистре сведений приходится дублировать значения по множеству полей.
(15) хе хе, подозрения оправдались.
Поиграйтесь немного с журналом изменений, а потом попробуйте удалить хотя бы один объект, который зарегистрирован в журнале.
Если Вы ссылку на объект в реквизит пишите, то ее наверное при удалении объекта отрабатывать нужно?
Кстати, на мой взгляд при полном удалении объекта записи по нему должны сохраняться в базе.
Обработка просмотра изменений для пользователей будет не очень удобна. одна измененная строка в документе разбивается на неопределенное кол-во строк в таблице просмотра изменений. Многих будет вводить в ступор состояние "Строка удалена", "Строка добавлена" (ведь в реалиях никто строки не удалял и не добавлял).
Кстати, а почему сделана обработка? Ведь мы никаких действий, кроме просмотра, не выполняем.
(18) "Кстати, а почему сделана обработка? Ведь мы никаких действий, кроме просмотра, не выполняем."
С обработкой манипулировать легче. Да и функционал может расти со временем, кроме просмотра уже есть "Очистка журнала" например. :)
(12) это чтобы изменения однозначно привязать к конкретному объекту. Если на каждое изменение будешь делать элемент, то потом умаешься собирать всю информацию по одному изменениям одного объекта, а так дешево и сердито кол-во элементов в справочнике равно кол-ву документов.
(14) дык проверить недолго. 5 минут пишем обработку, час закачиваем информацию :)
(15) нормально все на справочнике должно вертеться. Проблем с блокировками быть вроде не должно. вывести из ТЧ данные не долго, сколько там строк в реалиях будет мах. 100-150
Тоже согласен, что лучше сделать через регистр сведений. при оч больших объемах справочник будет тормозить. я сделал что то подобное через регистр сведений, записей миллионы, и работает нормально. а вот как бы работал справочник при таком объеме???
(14) На мой взгляд , более правильно вести речь не об общем подходе ,
а о решении данной конкретной задачи. В ней , насколько я понял автора,
наиболее критична по времени - операция записи. Учитывая более
высокую скорость записи и отсутствие "тормозящих" блокировок ,выбор
справочника как объекта хранения данных представляется оправданным.
Можно также предположить , что "миллионы записей" существенно картину не
изменят.
(0) молодца! Классная вещь!
Единственно, что пока не нравится:
(18) "Обработка просмотра изменений для пользователей будет не очень удобна. одна измененная строка в документе разбивается на неопределенное кол-во строк в таблице просмотра изменений"
с этим согласен.... мне (думаю и многим другим) более эргономично представление в строку, тем более, что для удаленных строк "новое значение" не актуально.
Подскажите пож-та, что не так : после объединения с конф ЗиК
версии 8.1.8.76 потерян путь к функциям глобального модуля ,
например глЗначениеПеременной("глУчетнаяПолитикаПоПерсоналуОрганизации"),
каким образом исправить , т.к. оч хотелось бы внедрить этот сервис
Кстати, сразу пожелание. Надо фиксировать текущего пользователя, кто внес изменения. Если с БД работает человек 30 и у многих права взаимозаменяемы. То потом не разгрести - кто накосячил.
Пардон. Все в норме. Текущий пользователь регистрируется.
Можно добавить как пожелание к развитию фильтр по типам документов. Можно тупо группы сделать равные типам.
Добавлен механизм "Версионирование"
Механизм версионирования объектов используется для аудита изменений объектов информационной базы в разрезе времени и позволяет ответить на вопросы КТО, КОГДА и ЧТО изменил. В качестве версионируемых объектов могут выступать справочники и документы
Добавлен отчет "История изменения объектов".С помощью отчета можно сравнить любые две версии объекта друг с другом, а так же открыть любую версию объекта
Вчера объединили конфигурации - выложенную здесь и свою (УПП 1.1). Сегодня целый день юзеры в шоке: обработка клиент-банк не запускается, отчет Декларация по НДС не формируется, цвета надписей и фона поменялись:))) Ну ничего, программист денек поисправлял и все пучком:))
Удобная вещь. Еще бы добавить:
- анализ изменений в регистрах сведений (например, кто цену поменял)
- выбор объектов, для которых фиксировать изменения
Перебрав множество подобных разработок, остановились именно на этой, т.к. она бесплатна и не требует существенных изменений конфигурации.
Только были сделаны следующие доработки (тюнинг):
1. Справочник ЖурналРегистрацииИзмененияОбъектов, в ТЧ у реквизитов СтароеЗначение и НовоеЗначение тип вместо "Строка" стал составной "Строка,ЛюбаяСсылка", теперь можно просматривать ссылки ТЧ (бывает, что номенклатура имеет одинаковое наименование, но разный артикул).
2. Изменен функционал:
2.1. Если ТЧ Объекта строка сменила НомерСтроки, то в ЖурналРегистрацииИзмененияОбъекта делается одна запись: "Строка изменена", что существенно уменьшает рост БД, раньше делалось несколько записей по количеству реквизитов ТЧ, и еще "Строка добавлена","Строка удалена".
2.2. Реквизиты ТЧ Объекта были поделены на Ключевые И НеКлючевые, к НеКлючевым относятся реквизиты, имеющие простой тип(Число,Строка,Булево...). Если было изменение значения НеКлючевого реквизита, а значения Ключевых реквизитов не сменились, то в ЖурналРегистрацииИзмененияОбъекта делается запись "Строка изменена", раньше делалось несколько записей по количеству реквизитов ТЧ, и еще "Строка добавлена","Строка удалена".
3. Сменился Интерфейс обработки ЖурналИзменений, основные изменения коснулись просмотра ТЧ объекта.
4. От Подсистемы.РегистрацияИзмененийВОбъектах и РегламентныеЗадания.ОчисткаЖурнала отказались, за ненадобностью. Обошлись только ОбщимМодулем, ПодпискамиНаСобытие, Справочником и Обработкой.
И вот что получилось:
Прикрепить картинку почему-то не получилось. :(
Автору спасибо!!!
{Справочник.Товары.Форма.ФормаСписка(16,19)}: Переменная не определена (глСписокТипЦен)
Для Счетчик=0 по <<?>>глСписокТипЦен.Количество()-1 цикл
{Справочник.Товары.Форма.ФормаСписка(18,27)}: Переменная не определена (глСписокТипЦен)
НовСтрока.Колонка1 = <<?>>глСписокТипЦен.Получить(Счетчик).Значение;
{Справочник.Товары.Форма.ФормаСписка(44,114)}: Переменная не определена (глСписокТипЦен)
СтруктураЦен = РегЦены.ПолучитьПоследнее(ТекущаяДата(),Новый Структура("Товар, ТипЦен",Элемент.ТекущаяСтрока,<<?>>глСписокТипЦен.Получить(Счетчик).Значение));
{Справочник.Товары.Форма.ФормаСписка(21,54)}: Переменная не определена (глПользовательСистемы)
СпрТовВыборка = Справочники.СкладыВТоварах.Выбрать(,<<?>>глПользовательСистемы,,"Номер Возр");
{Справочник.Товары.Форма.ФормаСписка(159,45)}: Переменная не определена (глПользовательСистемы)
ЗапросСклада.УстановитьПараметр("Владелец",<<?>>глПользовательСистемы);
{Справочник.Товары.Форма.ФормаСписка(248,55)}: Переменная не определена (глПользовательСистемы)
СпрТовВыборка = Справочники.СкладыВТоварах.Выбрать(,<<?>>глПользовательСистемы);
При выборе товара выдает такую ошибку в чем причина не могу найти подскажите?
Вещь супер, но возникла проблема с удалением помеченных на удаление объектов.
Не удаляются объекты, пока ручками не удалишшь ссылочку в справочнике где регистрируются измененения. А это крайне не удобно.
Посему обращаюьсь к автору данной вещички с данной проблемой.
Есть какие наработки для устранения этого бага?
С чем может быть связана ошибка "Ошибка формата потока"
{Форма.Форма.Форма(122)}: Ошибка при вызове метода контекста (ЗначениеИзСтрокиВнутр)
стрТч.ДоИзменения=ЗначениеИзСтрокиВнутр(Выборка.СтароеЗначение);
по причине:
Ошибка преобразования
по причине:
Ошибка формата потока
спасибо за обработку, понятно, что "Версионирование" штатными средствами конфигурации более глобально, но слишком уж оно жрет пространство на диске - база растет не по месяцам, а прямо по дням, да и отчетов по визуализации данных версионирования не нашел. А этот механизм нормально прижился
Автор подскажите каствомк будет проходить работа с большими базами да них на SQL и огоромным количеством пользователей. Подвисать не будет. А можно как то организовать хранение етой базы в отдельной базе. Зарание спасибо за ответ.
