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

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

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

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

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

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

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

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

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

Процедура РегистрацияОбъектаПередЗаписью(пОбъект)
 Если НЕ ЗначениеЗаполнено(пОбъект.Ссылка) Тогда
   пОбъект.СозданоКем = ПараметрыСеанса.Пользователь;
   пОбъект.СозданоКогда = ТекущаяДата();
 Иначе
   пОбъект.ИзмененоКем = ПараметрыСеанса.Пользователь;
   пОбъект.ИзмененоКогда = ТекущаяДата();
 КонецЕсли;
КонецПроцедуры  

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

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

бгыыыыыыы

дорогой дедушка мороз, это не спам, прочитай пожалуйста мое письмо до конца....
я сабж не читал, что ты продаешь? просто для задачи установить автора и дату в подписке букв раз в 20 больше, чем нужно

открой для себя журнал регистрации

(0) ты где курил?

(0) 1. Не используй регистр сведений, все умрет на большом количестве пользователей. По опыту говорю.
2. Добавь реквизиты в сами объекты и в подписке их заполняй.
3. Проблема с регистром сведений автоматически уходит :))

А еще открой для себя мануал. Там написано про ЭтоНовый()

(6) ну вот как теперь ДенисЧ будет ему СП продавать, а?

Регистр и Автор создания?
А это простите зачем?

(8) чтобы журнал регистрации не включать. В каких-то местах за это бьют по лицу, видать...

И кстати не совсем понятно. В теле я могу сам свою ссылку определить. И тогда весь механизм идет лесом.

Почему просто нельзя проверять автора?

Если НЕ ЗначениеЗаполнено(пОбъект.СозданоКем) Тогда
//Автора нет, значит кто первый тот и автор
   пОбъект.СозданоКем = ПараметрыСеанса.Пользователь;
   пОбъект.СозданоКогда = ТекущаяДата();
 Иначе
   пОбъект.ИзмененоКем = ПараметрыСеанса.Пользователь;
   пОбъект.ИзмененоКогда = ТекущаяДата();
 КонецЕсли;
КонецПроцедуры

(10) человек одно описалово на полстраницы создал а ты взял и код ему в 2 строчки написал, вот кто ты после этого )))

(10) а если там УП ?

(11) я тоже коменты в коде вставил :)

(12) УП это что? Убил Погиб?

Унылое поделие

Увидел Прослезился

А главное где автор?

Пошел разводить костер, чтобы потом поыпать голову пеплом

Уныло Пропал )

А, или нет - он ответ на первый пост пишет. Судя по (0), он товарищ обстоятельный и словоохотливый, так что это займет еще какое-то время ;)

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

Во-вторых, почему он обязательно что-то продавать должен?

В-третьих, человек он действительно обстоятельный. В 1-й пост написал действительно всё то, что имеет отношение к делу. Может, некоторые умники просто читать не хотят или не умеют? Ведь я ясно объяснил, что надо для записи регистра сведений определить - новую ли мы создаём, или текущую правим. Какой может быть "ЭтоНовый()"??! Вы что, с Луны свалились, или вообще основных принципов 1С не знаете, чем отличаются объектные и необъектные данные, такие, как регистр сведений?

Теперь менее эмоционально и тоже по сути.

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

Про регистры я тоже не совсем понял, но тут вроде как на готовые блоки по версионированию из БСП намекают? Ну из других уст я тоже слышал, что это красиво, но в реальных задачах при большом количестве действий/пользователей умирает всё.

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

И вот ещё какое удобство. Сейчас мы поля Автор/ДатаСоздания просто видим как реквизиты, и это выглядит супер, а в случае других решений что это будет? Обычный пользователь может вот так вот просто открыть ЛЮБОЙ элемент ЛЮБОГО справочника и увидеть это? Этим делом должен пользоваться руководитель - для него должно быть всё просто. Открыл элемент справочника - и сразу видно, какой сотрудник его создал и с кого спрашивать за работу с этим объектом.

Не фига себе писатель...

"какой сотрудник его создал и с кого спрашивать за работу с этим объектом."

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

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

ИМХО автор в справочнике нужен только для того, чтобы анально покарать за дубли, дабы пользователь прозрел, прежде чем заводить позицию. Да и то Журнал Регистрации прекрасно с этим справляется

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

Был случай, получил пользователь нагоняй, за исправление, приходит и спрашивает. "А когда это я его поменяла и зачем я это сделала?"

Зато теперь, при печати некоторых критических печатных форм программа спрашивает "Какого хрена?" если пользователь пытается распечатать дубликат документа. Дабы потом можно было в программе глянуть зачем печатали дубли

т.к. в конфе уже был реализован "руками" специальный механизм разделения данных - ужас.
Регистры у вас люди ручками редактируют или все же документ делает?
Историю авторства тоже хотите хранить( в чем отличие тогда от версионирования)?

Да, вроде бы с традиционных позиций - маразм немножко авторов сохранять. А если от количества "сделанных" объектов зависит зарплата сотрудника? Тогда общий реквизит "Автор" вроде как и ничего при каждом элементе, да? Если шефу нужен отчёт в конце рабочего дня о том, кто сколько элементов настрочил за день? Или отфильтровать их в обычном списке стандартными средствами и поработать с ними? Не находите, что общий реквизит - это самое то??

Я тоже сначала многому в этой идеологии удивлялся, но потом увидел, насколько РУКОВОДИТЕЛЬ прав и дальше всех нас зашёл в понимании процессов, которые он автоматизирует.

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

"Ручной" механизм разделения - да, может ужас, но (1) если стандартный не устраивает и (2) стандартный появился только в 8.2.14, а ранее надо было как-то жить?

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

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

"Если шефу нужен отчёт в конце рабочего дня о том, кто сколько элементов настрочил за день, то он бездарный тупой дебил."

Характер таких высказываний и используемый лексикон просто показывают уровень автора поста :)

Я же написал, что даже я, "продвинутый", и то всего не понимал. Шеф ушёл дальше многих из нас вперёд - и слава богу, что есть такой человек, глядя на которого, идейно и морально растёшь.

Всё, больше на посты типа "все - ублюдки" отвечать не буду - свою позицию уже высказал.

(28) Специфика этого (?) форума. Каждый знает больше автора.

(31) Делаем документ который двигает РС, и тогда задача сводится к типовой :)

(32) Так ты бы объяснил позицию руководителя. Сказал А говори и Б

(32)
Шеф за плечом стоит, читает?
Сочуствую...

Шеф далеко и даже скорее всего об этом общении на форуме никогда не узнает :)

Универсального решения не получиться.
Или для всех регистров сведений рисовать форму редактирования и писать код или делать движения только через документы (опять таки рисовать форму).
Когда удаляют запись из регистра - надо ли хранить информацию об удалении? Что удалили? До какого колена  хотите хранить историю?

По количеству документов: конечно все зависит от специфики, но согласитесь, когда начальник отдела продаж всем менеджерам кричит, а ну быстро создали по заказику на кого хотите(потом скажете "Клиент не оплатил"), а то мне к дирику идти отчитываться как отдел работает. (тогда еще смотрели на количество выставленных счетов) - тоже не нормально. Модно нынче KPI.

Совет с "Автора нет, значит кто первый тот и автор" не прокатил. При копировании записей не работает. А для регистров сведений события "ПриКопировании" вообще нет чтобы автора там в пустое значение поставить в таких случаях...

У нас очень много "мелких" справочников, для которых формы элементов просто отсутствуют, т.к. автоматические формы системы вполне удовлетворяют нас.

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

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

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

И в любом случае универсальное решение - лучше, чем тупое тиражирование. А вдруг нашлось бы?

С регистрами сведений не нашлось бы. Или документ, как в 1С:Логистика сделано, или формы.

С регистрами методом двухдневного тыка сам уже понял :)

Но всё равно проблема осталась. По сути, задача свелась к следующей: как в форме записи регистра сведений определить, что происходит процесс копирования?

В расширениях формы есть некое свойство ЗначениеКопирования, но что-то оно не работает.

ТабличноеПоле (TableBox)
ПередНачаломДобавления (BeforeAddRow)
Синтаксис:

ПередНачаломДобавления(<Отказ>, <Копирование>)

(28) "от количества "сделанных" объектов зависит зарплата сотрудника"
Адресок не подскажешь? Хочу к вам работу устроиться ;)

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

v8: Анализ работы пользователей с базой 1С Тут тоже вот KPI хотят считать.

+(47)Эпидемия однако

(44) как просто всё оказалось

абассака, минут 10 ржал..

Какая глупость про KPI. Вы бы хоть погуглили, прежде чем фигню писать

(51) Некоторые видят KPI как всего лишь цифровые показатели, формируемые на основе определенной мат. модели. Если исходить из этой предпосылки, то считаю (47) не фигней.

(44) Если это будет работать - уже хорошо. Как говорится, "на безрыбье...". Но всё равно получается, что формы всех списков регистров надо кастомизировать. Плохо, что нет подписки на интерфейсные события.

(46) "Из журнала регистрации читай данные <...> Не надо плодить сущности без необходимости."

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

(44) Попробовал - не смог получить доступ к новой записи из этого события. Элемент.ТекущиеДанные естественно даёт доступ только к текущей строке в списке, т.е. источнику копирования. В расширениях форм списка и записи для регистра сведений больше не нашёл никаких событий и свойств, которые позволяют отследить копирование записи.