В одной из задач мой Заказчик давно просил добавить во все справочники, документы и регистры сведений такие реквизиты, как "Автор" и "Дата создания" – для фиксации «кто» и «когда» создавал соответствующие объекты. В 1С 8.2.14 наконец-то появилась замечательная возможность создавать общие реквизиты, и решение их использовать для этой функциональности пришло само собой естественным образом.

Но есть и другая сторона вопроса - эти поля надо как-то заполнять при создании объектов/записей. Решение «в лоб» - делать это в формах элементов/записей в событиях типа ПриСозданииНаСервере, но это очень трудоёмко и не универсально. У нас очень много "мелких" справочников, для которых формы элементов просто отсутствуют, т.к. автоматические формы системы вполне удовлетворяют нас.

В попытках найти более универсальное решение на форумах 1С посоветовали создать подписку на событие ОбработкаЗаполнения. Идея хорошая, но при практической реализации выяснились следующие подводные камни.

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

Решено было взять для этого событие ПередЗаписью. В нём с помощью выражения ЗначениеЗаполнено(Источник.Ссылка) можно проверить имеем ли дело с новым объектом. Всё хорошо пока имеем дело с объектными данными (документ, справочник, план видов характеристик), но при работе с записями регистра сведений это не работает.

При подписке на то же событие в процедуре обработки в качестве Источника передаётся РегистрСведенийНаборЗаписей, и насколько я вижу, по нему никак нельзя определить - новую ли мы запись сохраняем, или уже существующую. Что оказалось ещё более забавно, так это то, что событие ПередЗаписью вызывается даже при удалении записей. Хотя, конечно, это всё следствия слегка "чудаковатого" объектного механизма работы с записями регистров в 1С.

Как разрешить данную проблему?

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

Ну и ещё такой нюанс был замечен. Если в качестве источника подписки задать составной тип данных и отметить скажем справочники и документы, то из списка событий для подписки уже нельзя выбрать ПередЗаписью - хотя сигнатура процедуры обработки одна и та же получается. Вобщем-то не беда - можно сделать несколько однотипных процедур подписки в модуле и "натравить" их на ещё одну рефакторизированную универсальную процедуру


, но тут всё больше и больше теряем в универсальности. Хотя разработчикам уже большое спасибо за саму возможность подписки на события - помогает очень сильно!

Вобщем, буду рад услышать любые предложения «по теме».

Очень большое спасибо за все ответы и советы.

Прежде всего, идея с версионированием (кто когда и главное какие поля менял) очень понравилась, т.к. у руководства уже проскакивала мысль об этом как-то. К сожалению, из-за большого потока текущей работы, перехожу на 8-ку с 7-ки относительно медленно и БСП к своему стыду ещё не разу не открывал и не изучал. Насколько я понимаю, там просто есть готовые куски кода, которые как блоки можно к себе в конфу затянуть? Если кто может направить меня конкретно что игде посмотреть и взять для реализации моей функциональности - буду очень благодарен.

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

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

Подход с подпиской не работает для регистров ещё по одной причине - при копировании нет возможности отследить эту операцию и автора из исходного сообщения "перебить". События ПриКопировании для регистра сведений просто не существует!

Решил сделать "неуниверсально" через формы, но проблема всё равно осталась. По сути, задача свелась к следующей: как в форме записи регистра сведений определить, что происходит процесс копирования? В расширениях формы нашел только некое свойство ЗначениеКопирования, но что-то оно не работает.

shurikvzЯ бы поменял чуть чуть логику работы. Если я правильно понял у вас сейчас все представлено в таком виде:
ОбщийРеквизит1 (строка или спр. пользователи) - автор
ОбщийРеквизит2 (дата) - дата создания
ОбщийРеквизит3 (строка или спр. пользователи) - кто внес последнее изменение
ОбщийРеквизит4 (дата) - дата последнего изменения

Оно самое.

shurikvzесли переделаете на регистр сведений, то надо оставить только два ресурса:
Ресурс1 (строка или спр. пользователи) - автор
Ресурс2 (дата) - дата

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

Т.е. Вы клоните к тому, что надо сделать подписку на событие ПриЗаписи для справочников/документов/ПВХ/регистров и тупо скидывать в наш специальный новый "регистр регистрации" действия по записи - я Вас правильно понял?

Смею заметить, что поле "АвторСоздания" нам необходимо как поле в ряде списков. Например, у нас есть Опросник клиента (на базе ПВХ), и нас интересует видеть сразу в списке кто и когда интервьюировал клиента - там могут быть разные записи с одним и тем же вопросом, но разными ответами в разные даты, да ещё и сделанные разными пользователями. Плюс там же реализован специализированный механизм разделения данных, построенный на наличии поля "Автор" в таблице.

shurikvzа при проведении документа в событии ПриЗаписи() у вас возникло какое-то исключение (по каким-то причинам: отказ = истина), получается сделаная ранее в событии ПередЗаписью() запись будет неверной, поскольку реально то документ не записался и изменений внесено не было, а у вас будет как будто кто-то что-то поменял.

Вы говорите о проблеме когда документ делает проводки по регистрам? Документов, выполняющих проводки по регистрам, нет :)

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

shurikvzЧестно говоря мне сложно вот так представить архитектуру вашей системы, поэтому на глаз если допустимо - то дублируйте функционал: в общие реквизиты записываете только автора/дату создания, а РС используете для хранения-просмотра истории кто когда менял.

Так всё равно для регистров не получается определить какой из 3-х вариантов сейчас идёт - создание новой записи, копирование или правка существующей. Если всё делать тупо в ПриЗаписи, то выходит, что автор и дата создания будут перезаписываться при правке - что неправильно.

Не совсем понимаю что значит "КоличествоЗаписейПоДанномуОбъектуВРС" - как его определить? И прошу ещё раз учесть, что пишется универсальное решение, которое можно прицепить к любому регистру. По крайней мере, желательно так сделать.

Если под "КоличествоЗаписейПоДанномуОбъектуВРС" понимается какая-то функция на базе запроса, то в общем виде там тоже та ещё работа для общего случая. Надо в подписке на событие как-то узнать с каким регистром мы сейчас имеем дело, потом для него из метаданных вытащить поля-измерения, потом по ним создать запрос, который и вернёт количество записей. Так?

shurikvzТо что выше было сказано - относилось к документам и справочникам. И под РС в алгоритме имелся ввиду РС "Версии объектов", где хранятся данные о том кто и когда внес изменения.

Да, вот бы такую штуку для РС ещё построить. Я так понимаю, в БСП поэтому отслеживание изменений только для документов и справочников сделано - для регистров это "мёртвый номер". По сути, структура такого "регистра регистраций" концептуально строится из 3-х полей - Объект / Пользователь / Дата, но вот что записать в поле Объект для записи РС..?

Как вариант можно было выборку по ЖР делать вместо этого регистра регистраций. Обратился с выборкой по нужному объекту - и получил 0, 1 или N записей о факте изменения. Но и там загвоздка - в поле "Данные" при правке записей РС ничего не заносится. В отличие от справочников, по которым ссылку на объект выудить можно.

А никто не смотрел в сторону ПлановОбмена? Может, их можно приспособить для этих целей? В свойствах ПО по кнопочке Состав открывается перечень объектов, по которым можно изменения отслеживать. РС там тоже есть.

shurikvzДля записей же регистров сведений - я нормального способа не вижу. Тут вам следует прислушаться к совету Сисой .

Хорошо, допустим. Но, во-первых, проблемные РС правятся всегда "обычными" а не "ответственными" пользователями, так что по этому критерию уже пролетаем.

И во-вторых. Если скажем есть набор характеристик клиента - например, анкета, которая сейчас на базе ПВХ и РС отлично делается, то что, её в документ теперь какой-то засунуть надо? Особенность нашей анкеты в том, что на один и тот же вопрос можно получить несколько разных ответов в разное время - на основании этого отслеживается характер и динамика изменений предпочтений клиента. Плюс интервьюировать клиента будут разные менеджеры на протяжении всей жизни работы базы. Тогда как, всё это в табличную часть документа пихать?? И учтите, что тут необходимо разделение данных - менеджер должен видеть только свой круг вопросов, по которым он общался с клиентом. Немного маньячно - понимаю, но организация наша не КГБ называется :). Хотя в такой организации данных есть серьёзный резон, запланированный руководителем, и я в этом его поддерживаю.

shurikvzВам конечно виднее, что значит "Анкета", но в моем понимание это именно "документ". И почему вы решили что он должен быть один? Вот именно что в разное время разные ответы - каждый новый опрос это новый документ, который и делает запись в периодический РС подчиненный регистратору.

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

В любом случае на типовые конфы, в т.ч. и БСП, смотрим и пытаемся перенять лучшее из них что подходит нам.