Доброе время суток ребята. Я решила сделать версионность объектов в 1с, хотела бы у вас спросить совета как это лучше сделать. В данный момент мне нужны только документы.
Я примерно представляю это так:
1) регистр сведений в котором мы будем хранить изменения. С ресурсом пользователь, объект, вид методанных (реквизит или табличная часть), тим записи (добавление, изменение) . Регистр периодический в пределах записи. Так же два ресурса как было и как стало.  
2) Все изменения заносить подпиской на событие перед записью. Заносить в регистр только измененные реквизиты.
3) И отчет по этому регистру какие изменения были.
Я понимаю что регистр вырастит до невероятных объемов. Документов в системе много. Средний пул документов в день примерно 1000-2000 документов.
Я думаю что это довольно нужная и интересная тема для обсуждения. Жду ваших комментариев.

P.S. Хотелось бы услышать от вас как упростить данную схему и сократить регистр.

Тема совершенно не интересна. Всё давно решено и раскрыто. Начиная с типовых (где есть версионирование) до статей на нимфосрате, в которых раскрывается вся сущность.

Открой для себя БСП

(1) Что то я не нашла не одной статьи, может я не правильно поиском пользуюсь?

(3) Судя по всему - неправильно.

Ну а если изменений много - то версионирование будет ресурсоемким. Обидно, но неизбежно.

(4) Если не трудно, скиньте пожалуйста ссылку.

Еще небольшая пометка, 1с стоит на платформе 8.1.

Версионирование объектов

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

? Сравнение произвольных версий объектов.

? Просмотр и откат к ранее сохраненной версии объекта.

Это описание подсистемы версионирования из БСП.

В УПП сделано очень хорошо

(7) Хм... БСП - для 8.2
Будет повод перейти.

Хотя, если переходить - то можно уже и на 8.3

(8) Перейти вряд ли получится. у нас полностью самописная конфигшурация. И она написана полностью на связях с внешними данными. Боюсь плохо будет при переходе.

главный недостаток типовой версионности - это получение не работающей версии (например из конфигурации удалили реквизит, или удалили элемент а ссылка осталась)

по этому я сейчас иду другим путем
1. для обьектов ввел понятие "черновик" в нем хранится новая версия обьекта.
2. создал БП приняте версии, по этому БП все черновики записываются по нормальному и удаляются
3. создал регистр "история" в него помещается исключительно хмл в котором есть как ссылки в виде гуида так и представление на момент создания. тем самым мы во первых избавляемся от тупизма когда жлемент переименовали и он изменился везде, во вторых мы не нарушаем ссылочную целостность.

недостатком является невозможность возврата к старой версии...

(13) А ты не бойся и попробуй. Страшных сложностей не предвижу.

(14) Это да. Хранение представлений - это гуд.

(14) Эврика! как я и забыла что можно писать xml в хранилище значений. Мне не нужно откатываться на старые версии. достаточно лишь следить за пользователями.

(14) получается что в хмл я могу записать реквизит ссылки и Значения ссылки а так же реквзит объекта и значение объекта.

(16) + Но в рабочей базе - еще более ресурсоемко.
Да и вообще я к версионированию в чистом виде отношусь с прохладцей. Очень редко оно нужно. Чаще нужно просто знать, кто чего где когда поменял. И не всегда с максимальной детализацией. А для этого достаточно продуманных записей в ЖР.

(17) типовой БСП и пишет хмл в регистр, тут все дело в формате этого самого хмл...

(19) у меня задача прикольная, я сделал что все материальные документы подписываются МОЛ и после подписи никто ничего не может поменять.

Народ взвыл, теперь приходится делать механизм при котором менять можно, но через подписи :)

(20) Я не разу не сталкивалась с БСП. Сейчас читаю документацию. А что сложного в этом формате? Просто получается у меня есть документ и реквизиты, в хмл записывать только измененные реквизиты. Получается что он будет очень простого типа.
Примерно так:
Реквизит1
   Значение1
Реквизит2
   Значение2
Табчасть
   Реквизит1
      Значение1
Ну и так далее.

(21) Ну, тут без вариантов. Если есть подписи, то нужно и версионирование с переподписыванием.

Нашла в бух 3.0 версионность, сейчас гляну как там реализованно.

(19) Во-первых, нагруженные системы не любят запись в ЖР кучи событий. Во-вторых, коврыять текстовые файлы на предмет "кто чего где когда" то ещё удовольствие, у нас в сезон этот ЖР по гигу в день добавляет.

(25) Я тебя умоляю. Каких кучи событий? Сначала повключают на максимальную детализацию, когда каждое движение в ЖР пишется, а потом жалуются - ЖР мол, отстой.

(0)я скачал готовую подсистему "версинирование объектов" и не знаю горя теперь. Любой объект можно версинировать, а можно не версинировать. Регистр можешь чистить без проблем. Легко ставится. Это проще, чем самой писать.

(0)не тратьте время. Ставьте готовую. И под себя её допишите.

(26) Нагруженные системы всегда куча событий, а тут предлагается ещё к ним что-то дополнительно в журнал писать.
А как писать в журнал не каждое движение, а через одно, я может отстал от жизни, но  - либо пишем всё, либо пишем ошибки и предупреждения?

(29) Я веду речь об "ошибки и предупреждения", а все остальное, чего надо - самому писать.

Сложно представить менее ресурсоемкую операцию ввода-вывода, чем запись в текстовый лог. Плюс это не в БД пишется. Сплошные профиты.

Плюс готовые средства анализа, как встроенные в платформу, так и в БСП. Если не вываливать в ЖР всякий ненужный шлак типа движений регистров, то всё довольно шустренько анализируется.