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

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

А чем тебе не устраивает менять статус у характеристики?

И почему ты думаешь, что произойдет ошибка? Если есть проверка на "изменена"="Истина" - можно избежать конфликта блокировок

напрашивается для "регистрации" использовать записи "регистра". А у вас как регистрация задумана? Как изменение значения в реквизите элемента?

(0) версионирование?

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

(5) про регистр изменения согласен, лучше так.
А можно ли сделать так, чтобы была одна запись на одну номенклатуру в регистре, и при изменении номенклатуры или характеристики в этой записи изменялся статус?
Просто характеристика может быть привязана в нескольким номенклатурам (характеристика не обычная, а необычная:) т.о. при изменении одной характеристики в регистре должна быть изменено 3 записи (изменен статус)).

Делаю костыли для выгрузки на сайт номенклатуры, нужно выгружать только измененные (время от времени), но изменение характеристики тоже толжна влиять на выгрузку номенклатуры.

(0) а чем план обмена не мил?

(6) А зачем такая замута с характеристиками?
(7)+1

(6) я специально сделал оговорку о любой сложности логике в подписке на событие. Подписка по одному событию может сделать любое количество в наборе записей. Но если отключена авторегистрация объектов в плане обмена, то достаточно выполнить его принудительную регистрацию в подписке и все. Тут все зависит от числа _значимых_ статусов у объектов.

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

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

(9) а можно ссылку на пример или где подробнее можно прочитать как это сделать?

(11) сходу не соображу даже о чем пример... ссылку на пример когда и как настроить выполнение каких-то действий в базе через подписку на событие?

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

(13) через подписку рассказывать не буду - там без картинок не покажешь, а картинки можно в книжке посмотреть...
По самому регистру я бы сделал общее описание в таком виде:

- РС делать периодическим, т.к. очень высока вероятность, что история изменения статуса номенклатуры будет нужна при разборе полетов.
- Значение текущего статуса в регистр писать через Ресурс.
- Измерение по элементу Номенклатура.

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

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

При успешной выгрузке, очевидно, устанавливаем на текущие элементы новый статус Сброс со временем выполнения выгрузки.

з.ы. Нечто подобное практически делал, неоднократно, но уже давно, поэтому алгоритм считаю рабочим, но примера готового под руками нет.