1с история изменений документа добавить

Обновлено: 06.07.2024

Работа в программном комплексе 1С осуществляется как одним человеком, так и группой людей. Соответственно, существует необходимость проверки вносимых в документы изменений. Речь идет о том, чтобы посмотреть кто, когда и какие корректировки вносил в определенный объект данных. Даже если пользователь всего один, но при этом абсолютный новичок, он может совершать ошибки. И в данном случае также необходима возможность просмотра истории изменений. Как и где это можно сделать в 1С рассмотрим в статье.

Механизмы отслеживания изменения данных в базах 1С
Настройки хранения история изменений
Просмотр истории изменения в документе
Сравнение версий объекта данных
Переход на предыдущую версию
Как включить версионирование в различных решениях 1С
Как узнать кто менял документ с помощью журнала регистрации
Как узнать с какими объектами данных работал пользователь?
Групповое изменение данных (ГИД)
Просмотр ранее измененных реквизитов

1. Механизмы отслеживания изменения данных в базах 1С

В рассматриваемом программном продукте существуют 3 механизма, которые помогают отследить корректировки:

журнал регистрации;
платформенный механизм истории данных;
версионирование

Для того чтобы каждый из этих механизмов правильно работал необходимо изначально провести настройки.

2. Настройки хранения история изменений

Стоит отметить, что настройку можно включить как для всего объекта данных, так и выборочно для каких-то его частей. Например, только для реквизитов. Тем самым экономится место объема сохраненных данных. Для того, чтобы сохраненные корректировки не занимали места больше, чем сами объекты, с которыми производилась эта работа, необходимо грамотно настраивать механизм версионирования. В противном случае произойдет замедление работы всей программы. Включить сам механизм может либо сотрудник предприятия, работающий в системе, либо разработчик в конфигураторе.

Для того чтобы настроить хранение истории изменений, следует перейти в левом меню в раздел «Администрирование», далее в раздел «Общие настройки» и затем «История изменений».

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

Чтобы эту историю внедрить в Вашу конфигурацию, необходимо:

Длина наименования 150, Длина кода 20, Тип Кода Строка.
Реквизиты Справочника:
Пользователь - Тип:СправочникСсылка.Пользователи
GUID_Объекта - Тип:Строка, Длина: 36
ДатаИзменения - Дата, Состав даты: Дата и время
Табличная часть "Изменения" справочника, содержит Реквизиты:
Реквизит - Тип:Строка, Длина:200
ЗначениеДо - Тип: Строка, неограниченная
ЗначениеПосле - Тип: Строка, неограниченная

Создать ФормуСписка и ФормуЭлемента Справочника, в форме элемента сделать её только для просмотра.

В общем модуле, который выполняется на клиенте, либо создав новый, разместить экспортируемую процедуру:

И в нужном документе/справочнике в модуле объекта вконце процедуры ПередЗаписью() размещаем следующее:

4. На форме документа/Элемента объекта метаданных документа/справочника, для которого необходимо отслеживать историю изменений, можно разместить кнопку "История изменений", которая будет отбирать из справочника только те элементы которые по данному документу/справочнику. Для этого разместим кнопку на командной панели(ну или где Вам угодно) и в обработчике нажатия на кнопку написать следующее:

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

Специальные предложения

Почему не оформлено как подсистема? (О том, что баян - промолчу)

(1) Извините новичек еще, первая публикация. Сам написал это еще ы 2009 году, решил щас поделиться, может кому пригодиться.

(4) Бывают такие большие документы, где производсится изменений более чем 99999, а ограничение табличной части есть 99999 строк, для этого и есть данная проверка, он записывает один элемент истории и создает другой элемент, где указываются оставшиеся изменения после 99999. Надеюсь внятно разъяснил)) (на практике встретил, пришлось добавить данное условие ибо не дает тогда записать такие большие документы. )

(5) Извиняюсь за орфографическую ошибку)))

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

(6) А выполнение на клиенте это и есть гуд! Так как на сервер объект не передашь ибо мутабельное значение, и на сервере не сможешь проверить какие на данный момент времени перед записью значения в объекте, а какие еще пока хранятся в базе, чтобы выявить изменения вносимые текущим юзером.
Для этого предусматривается разграничение прав на данный справочник, всем абсолютно юзерам даются права на добавление, просмотр и ввод по строке. (ни каких изменений в истории никто не сможет сделать, а это уже хорошо).
Если ты имел ввиду про дополнительный обработчик, который на стороне клиента, ну это не 8.2 с тонким клиентом чтоб так беспокоится, на 8.1 он итак очень "толстый" и сильно не "напрягает" клиент.

(7) с такими объемами как вы описываете (и с какими я работал) база дохнет довольно быстро. По крайней мере у нас документы правлись по 5-10 раз на дню, и документы и документоооборот немаленькие. Держать эту информацию в базе ИМХО нецелесообразно, хотя бы потому что сам просмотр изменений вызывается крайне редко по отношению к вводу документов и получениям данных из базы.

по поводу сервера - например XML-сериализацию еще никто не отменял. поищи на просторах интернета примеры проведения документов на сервере в привелигированых модулях. у нас в разных базах реализовано 3 схемы хранения истории изменений: XML, отдельная sql-база, отдельная 1С-база, в зависимости от объема рабочей базы и частоты изменений используем одну из них. вся обработка истории проходит на сервере со всеми вытекающими плюсами (с использованием привилегированных модулей).

опять же - "чтобы быстро(по одному щелчку мыши) и любой компентентый юзер мог просмотреть историю" это совершенно не зависит от расположения данных

плюс: "Бывают такие большие документы, где производсится изменений более чем 99999" 99999 раз получать размер тч, тем более на клиенте - ну не есть это гут. совсем не есть.

"на 8.1 он итак очень "толстый"" во-первых все зависит от конфы, а во-вторых зачем еще утолщать и так очень толстое.

(9) Я тебя не заставляю пользоваться моим примером реализации, хочешь пиши свой :) . У нас данная история не используется для всех документов и справочников, а для основных, где как раз такая детальная история и необходима. Работает данная история уже довольно долго и база не сдохла. :) и не сдохнет!
Я не заметил сильного "заторможения" работы при записи документов от обычной записи.
Я конечно понял что Вы имели ввиду что это не идеал и далеко это не так, ну я не кого не принуждаю его использовать, просто поделился, меня данный вариант устраивает. При томуж очень просто в кончоле отчетов накидать отчет по изменениям для руководства :-Р

(11) Один из смыслов оставлять комменты тут - это как раз указать автору на негативные стороны выставленного решения. а вы как-то неадекватно на конструктивную критику реагируете. по поводу "хочешь - пиши свой" - смотри пост (9) - там сказано что у меня уже написано и работают 3 различных механизма хранения истории изменений.

Заметьте - я не написал что обработка плохая или никому не нужная - я указал на минусы, которые присутствуют в её реализации, потому как тема актуальная еще со времен клюшек. И как всегда в механизмах регистрации изменений хочется задать вопрос (хотя ответ очевиден :D ): берем документ с 5000 строк, удаляем первую строку и имеем 5000 записей об изменении. верно? или я что-то упустил?

(13) Конструктивная критика принята :)

берем документ с 5000 строк, удаляем первую строку и имеем 5000 записей об изменении. верно? или я что-то упустил?

Почти угадал :)
Один элемент справочника "Изменение документов" и с табличной частью как минимум строк 4999, но и более, все зависит от количества реквизитов в ТЧ измененного документа и как они изменились по отношению к значениям которые хранились в записи на строку выше. )))

(15) хех. болезнь. у меня в механизме в xml реализован контроль удаления строк, но он тож далек от идеала и никак не помогает при изменении порядка строк ((( но хоть что-то. уже легше. . а так хотелось.

в 13 я имел ввиду записи об изменениях - т.е. то что видит пользователь при анализе, а не количество записей в бд.

Общая информация

Начнем с общей теоретической информации о том, что такое история данных и как она устроена.

Описание и возможности

История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.

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

Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:

записывать версию данных;
получать данные определенной версии;
удалять данные определенной версии;
получать разницу между двумя версиями одного объекта;
прочие полезные возможности.

На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:

общие реквизиты;
константы;
справочники;
документы;
бизнес-процессы;
задачи;
регистры сведений;
планы обмена;
планы счетов;
планы видов характеристик;
планы видов расчетов;
расширения конфигурации.

Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.

Устройство механизма

История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.

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

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

стандартных реквизитов;
реквизитов объектов;
реквизитов табличных частей;
измерений регистров сведений (без возможности отключения);
ресурсов регистров сведений.

Использование механизма

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

Управление использованием истории данных

Дата публикации 05.10.2021

Использован релиз 1.6.25

Для того чтобы отслеживать, кто и когда внес изменения в справочники и документы, в программе используется версионирование данных (раздел: Настройки – Общие настройки – История изменений). По умолчанию эта возможность отключена.

С помощью кнопок "Установить когда сохранять версии" и "Установить срок хранения версий" выберите порядок сохранения и срок хранения версий (рис. 3). При необходимости для отдельных справочников и документов установите свой порядок и сроки хранения версий в соответствующих колонках (рис. 4).

После включения версионирования появляется возможность посмотреть историю изменений документов и элементов справочников – выделите в списке документ или элемент справочника и по кнопке "Еще" выберите команду "История изменений" (рис. 5). По кнопке "Открыть версию" будет сформирован отчет о значении реквизитов документа или элемента справочника в выбранной версии. Выделив две и более версии, по кнопке "Сравнить версии" можно сформировать отчет о сравнении значений всех реквизитов выбранных версий документа или элемента справочника. По кнопке "Перейти на версию" значение реквизитов документа или элемента справочника будут заменены на значения реквизитов из выбранной версии.
Обратите внимание, отследить изменение версий объектов можно только с момента включения версионирования. Изменения, сделанные до включения, не появятся.

Для того чтобы информация об изменениях была доступна в чате, установите флажок "Чат, история изменений и видеозвонки" (раздел: Настройки – Еще больше возможностей – CRM) (рис. 6).

Читайте также: