[bolobol]

Ещё вопрос.

Сделал логирование действий пользователя в документ с табличными частями. Основные реквизиты документа - стандартные реквизиты объекта логирования (номер, код, регистратор, проведен и т.п.), табличная часть Измерений/Реквизитов/Ресурсов содержит описание изменения Измерений/Реквизитов/Ресурсов объекта логирования, вычисляемым по метаданным, заполняется в три колонки - Имя, Старое значение и Новое. Т.е. - логируются только изменения. ТЧ изменений в табличных частях объекта логирования - пять колонок - ИмяТЧ, НомерСтроки, ИмяРеквизита, СтароеЗначение, НовоеЗначение.

По подписке ко всем регистрам сведений, документам, справочникам на "ПередЗаписью", выполняется выборка записанной версии, сравнение с Источником, запись изменений. Но рассмотрим случай с регистром сведений - перед записью срабатывает по два раза:
1. очистка существующих записей по отбору - сравнение существующих записей с пустым набором
2. запись нового набора - сравнение пустого набора с новым набором

Таким образом, получаю два документа - спёрли все зописи по отбору И записали новый набор. По логике задачи, мне нужен один документ - что _изменили_, т.к. невозможна ситуация только стирания старых записей и отказа в записи нового набора. Но возможны ситуации - только стирания И только записи нового набора, т.е. нельзя гарантировать, что после логирования стирания возникнет обязательно логирование записи. Подскажите, как быть. Как же решить задачку-то?

Спасибо ))

[logist]

По подписке ко всем регистрам сведений, документам, справочникам на "ПередЗаписью", выполняется выборка записанной версии, сравнение с Источником, запись изменений. Но рассмотрим случай с регистром сведений - перед записью срабатывает по два раза:
1. очистка существующих записей по отбору - сравнение существующих записей с пустым набором
2. запись нового набора - сравнение пустого набора с новым набором

Таким образом, получаю два документа - спёрли все зописи по отбору И записали новый набор. По логике задачи, мне нужен один документ - что _изменили_, т.к. невозможна ситуация только стирания старых записей и отказа в записи нового набора. Но возможны ситуации - только стирания И только записи нового набора, т.е. нельзя гарантировать, что после логирования стирания возникнет обязательно логирование записи. Подскажите, как быть. Как же решить задачку-то?

Спасибо ))

А спереть стандартное версионирование из какой-то типовой религия не позволяет?

.Если существующие записи есть то:
..Если это ПЕРЕЗАПИСЬ (Новые записи <> пусто) - сравнение, очистка, запись новых, и запись изменений.
..Иначе - очистка существующих.
.Иначе - записать новые записи.

[bolobol]

А спереть стандартное версионирование из какой-то типовой религия не позволяет?

Да. Там версионирование на хранилище значений реализовано, не совсем понятно как из хранилища получить информацию кто поменял это или что именно поменяли в том-то. Да и не видел (может, что плохо смотрел) версионирования изменений регистров. Да и не понятно, зачем проверять дважды изменения: во время записи (а нужно ли версионировать, если ничего не изменилось) И во время поиска изменений, т.к. в хранилище там суётся объект целиком.

.Если существующие записи есть то:
..Если это ПЕРЕЗАПИСЬ (Новые записи <> пусто) - сравнение, очистка, запись новых, и запись изменений.
..Иначе - очистка существующих.
.Иначе - записать новые записи.

Вот то-то и оно, что для регистров - всегда два вызова: из набора в пустой набор И из пустого набора в новый. Всегда изменения, а значит - нет решения задачи.

[logist]

а значит - нет решения задачи.

Мне кажется постановка такой задачи несколько глуповата.
Большинство записей в регистры делают документы, а те регистры в которые идет запись на прямую относятся в основном к настройкам и параметрам, и доступ к их изменению должны иметь люди, действия которых, в данном случае, не требуют логирования.

[bolobol]

Мне кажется постановка такой задачи несколько глуповата.
Большинство записей в регистры делают документы, а те регистры в которые идет запись на прямую относятся в основном к настройкам и параметрам, и доступ к их изменению должны иметь люди, действия которых, в данном случае, не требуют логирования.

Особенно регистр сведений ЛицевыеСчетаРаботниковОрганизации в бухгалтерии, в ЗУП. Как говорил наш любимый шеф, .. .., слон кажется маленьким только издалека и лёгким, только если он чужой ))

[logist]

Особенно регистр сведений ЛицевыеСчетаРаботниковОрганизации в бухгалтерии, в ЗУП.

Если кто-то боится что деньги уйдут не туда, то это проблема не 1С.
В конце концов можно сделать документ, так как это реализовано в УПП.

[bolobol]

Если кто-то боится что деньги уйдут не туда, то это проблема не 1С.

Но мы и не проблемы 1С обсуждаем, а проблемы пользователей 1С. Я, просто, знаю этот приём - использование ломаной логики, как-то так называется ))

В конце концов можно сделать документ, так как это реализовано в УПП.

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

[logist]

А как Вы себе представляете этот универсальный чудо-документ внесения записи в нужный регистр сведений?

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

[bolobol]

"Корректировка записей регистров" как-то выполняет свои функции.

И ведь правда... документ этот выглядит как таблица регистра, причём любого и нескольких даже. Я обкурю этот вариант, спасибо за наводку!

А с фиксацией факта изменения набора записей регистра сведений с ..было.. на ..стало.. - всё глухо, да?