У нас есть справочник номенклатура.
Хочу добавить возможность утверждения номенклатуры.
Есть два варианта:
1. Добавить реквизит "Утвержден" (Булево)
2. Добавить РегистрНакопления с измерением Номенклатура и ресурсом Количество (если подтвержден, конечный остаток = 0, если нет, то = 1, т.е. при записи будет добавляться +1, при подтверждении будет -1)

Интересно, что будет жрать больше ресурсов? Снятие и запись элемента справочника или добавление записи в регистр накопления?

с точки зрения объектного проектирования
утверждение не является свойством

а есть атрибут некоторого видения ситуации.

так что - РС. + добавить дату утверждения+ кто утвердил

(80) утверждение, это какой то новый объект метаданных? я что то пропустил?

(42) как все запущено то.

Да вы там чо. Ебанулись все?

(79)
1. Записываем элемент справочника, который генерит документ, который добавляет движение +1
2. Создаем документ "Подтверждение", которые добавляет движение -1.
Суть в том, что огромный массив быстрее обрабатывается, если берется не вся номенклатура, а только та по которой есть остатки по РН. (Мы исключаем вариант РН, где есть записи только о той номенклатуре, которая не утверждена, т.к. при утверждении нам нужно будет удалять запись).
Флаг в самом элементе, будет быстро работать, но нам всегда придется перезаписывать сам элемент - это не есть гуд.

(85) запись в скобках - мы исключаем РН - там должно быть РС

(85) 1. Записываем элемент справочника, который генерит документ, который добавляет движение +1
    2. Создаем документ "Подтверждение", которые добавляет движение -1.


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

Вы вот все такие молодцы, советы даете, а никаких обоснований нет. РС типа лучше для хранения истории, но массив инфы, который будет браться из БД по срезу последних будет значительно больше чем то, что будет браться по конечному остатку из РН.
Т.е. в РС я буду выполнять отбор уже по полученной информации из БД, а в РН я буду получать такую инфу без всяких отборов -> РН быстрее. Разве нет?
Я РН выбираю, потому что он будет работать быстрее чем РС. Если это не так, обоснуйте, а не просто ... пилите Шура, пилите.

Реквизит не подходит, потому что нет никакой истории.

(88) нет, обосновываю:
1. Запись
в РС пишется в одну таблицу, в РН - в две, быстрее РС
корректность данных, в РН можно случайно записать остатки равные 2,3,... - как их интерпретировать?
2. Чтение
в РС срез последних это выборка максимальных периодов РС, соединенная с самим РС
в РН это скорее всего объединение (можно и через полное соединение) итогов предыдущего периода с движениями по текущему периоду (при этом CASE расход это или приход) - скорость вряд ли быстрее

основная "байда" - корректность данных, имхо

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

(91) смотри, согласовываем номенклатуру, потом разсогласовываем, потом первый документ удаляем. в случае с РС - все ок, в случае с РН - "не получилось"

(91) почему для всех, есть же параметры, а запретить неправильные данные можно - но опять же это увеличит время выполнения

(91), facepalm

три строчки кода и 100 сообщений обсуждения.

Ну вы ж все видите,  Ayvengo у нас 85 левела))) Должно о чем-то говорить)

да пусть делает, раз такой упертый. нам то что за печаль. увидим где нить это решение, вспомним автора матюками ))

(92) вот вы привыкли документы задним числом редактировать. У меня только сторно.
(93) параметры - это только ограничение самого списка номенклатуры, или нет?
(94) в чем фэйспалм? чем же твоя идея лучше или нет идеи?
(97) да не делаю я еще, я просто размышляю и делаю вывод, что на форуме сидят тролли, которые не могут дать обоснованный ответ. вот и все. Есть, конечно, исключения.. но что-то очень мало адекватных постов. Да, может я и сам не так адекватен, но я никуда не уперся, я обосновываю свою точку зрения, вы - нет.
(95) строчек кода вообще нет. мы структуру обсуждаем. и что в итоге выйдет, если использовать рс или рн

(98),
>(94) в чем фэйспалм? чем же твоя идея лучше или нет идеи?

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

ВЫБРАТЬ
   СтатусНоменклатурыСрезПоследних.Статус
ИЗ
   РегистрСведений.СтатусНоменклатуры.СрезПоследних(, Номенклатура = &Номенклатура) КАК СтатусНоменклатурыСрезПоследних

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

(98),
>(95) строчек кода вообще нет. мы структуру обсуждаем. и что в итоге выйдет, если использовать рс или рн

Я про то, что задача решаемая за 5 минут обсуждается второй день.

я пока не понял, но мне кажется, что идея про РН -- это такой сверхтонкий троллинг

бизнес процессы уже предлагали?

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

(103) твоя идея по мнению(0) херня - нет РН ))

(104) :) да я в общем-то ветел мнение ТС по этому поводу на совершенно законных основаниях:
1. настаивать и доказывать чего-либо не входит в мои планы
2. регистр накопления для хранения булевского признака - это высочайшей пробы быдлокод

Чего-то про стандартные категории объектов никто не вспомнил. А за регистр накопления я бы сразу с работы гнал...

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

А если необходимо например хранить дату утверждения , да и еще кто утвердил ? На РС все это удобно делается , и опять же лучше делать отдельным документом , бардака намного меньше будет .
Реквизит смысла не имеет ,в (106) правильно отмечено - самый простой (но минимально функциональный) вариант - стандартные категории , и переписывать ничего не надо .
РН для таких задач - изврат извратов :)

(107) Да не особо и громоздкий , и можно стандартные процедуры использовать . Но функционал конечно минимальный .

(108) А че дата? Дату тоже можно в РН запихнуть в виде измерения. При утверждении закрывать предыдущее состояние и дату, а при разутверждении - делать приход. Ну и последовательность замутить, а то мало ли..

(110) Бррр...
Ты еще в подчиненный справочник придумай дату запихнуть :)

(111) Подчиненный справочник с реквизитом-хранилищем, содержащим таблицу с историей изменений. Ок.

(99) видимо ты нифига не понял. Как я тебе параметр задам, если у меня статусы для этих 100т номенклатуры в РС этом хранятся?
(104) ну почему сразу херня ... у меня такой вопрос, почему в УНФ нет БП и задач? Видимо они свое пережили :)
(108) напиши запрос для РС, где измерение номенклатура, ресурс утвержден (булево). Нужно вытащить только не утвержденную номенклатуру.

(99) Я так понимаю, у автора задача - получить всю номенклатуру в определённом статусе.

Дополнительный реквизит хранить с использованием ПВХ Свойства объектов

(113) Не силен в снеговике, но:
"напиши запрос для РС, где измерение номенклатура, ресурс утвержден (булево). Нужно вытащить только не утвержденную номенклатуру." простой запрос с ВТ срезпоследних с условием на ресурс
+ чистов объяснял в одном из вебинаров по регистрам устройство РН и РС. Посмотри, почувствуй разницу.

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

в отчетах удобней отбор делать по реквизиту.

> (99) Я так понимаю, у автора задача - получить всю номенклатуру в определённом статусе.

И в чем проблема? Соединяем регистр сведений с таблицей номенклатуры и получаем чудеса

Хорошо посмеялся. Я предложу писать в текстовый файл и с него читать.

А фигли ТС до сих пор тут размышляет? уже сделал бы 2 варианта реквизит и РС и сравнил бы уже давно на отладке.
Если не нужна история а статус то реквизит. Иначе РС.
Если важно скрость сделай и сравни Это займет 2 часа маскимум.

(113) А чего там сложного то ? Соединение никто не отменял

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

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

Похоже, ребята, вы не въехали в то о чем я пишу и по моему даже не собираетесь. Какое соединение со справочником, если сведения о том, что номенклатура утверждена хранится в РС.
(119) номенклатура, это хреновый пример, лучше подойдет - справочник события.

(124), какая разница где хранится?

че-то перемудрил

(124) По моему ты не читаешь ответы в своей ветке.

Кто видит разницу?

"ВЫБРАТЬ
|    ВложенныйЗапрос.Измерение1
|ИЗ
|    (ВЫБРАТЬ
|        РегистрСведений1СрезПоследних.Измерение1 КАК Измерение1,
|        РегистрСведений1СрезПоследних.Ресурс1 КАК Ресурс1
|    ИЗ
|        РегистрСведений.РегистрСведений1.СрезПоследних КАК РегистрСведений1СрезПоследних) КАК ВложенныйЗапрос
|ГДЕ
|    НЕ ВложенныйЗапрос.Ресурс1"

"ВЫБРАТЬ
|    РегистрНакопления1Остатки.Измерение1,
|    РегистрНакопления1Остатки.Ресурс1Остаток
|ИЗ
|    РегистрНакопления.РегистрНакопления1.Остатки КАК РегистрНакопления1Остатки"

Может быть, я, конечно, ошибся в запросе с РС, поправьте.

(128), нафига вложенный запрос?

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

(129) - (130) твой вариант запроса?

|ВЫБРАТЬ
|        РегистрСведений1СрезПоследних.Измерение1 КАК Измерение1,
|        РегистрСведений1СрезПоследних.Ресурс1 КАК Ресурс1
|    ИЗ
|        РегистрСведений.РегистрСведений1.СрезПоследних КАК РегистрСведений1СрезПоследних
|ГДЕ НЕ РегистрСведений1СрезПоследних.Ресурс1

(130) а на счет условий, советую глаза открыть :)

(132) у тебя есть таблица с колонками Период, Номенклатура и Утверждено
01.07.2012 19:00 - Ном1 Истина
01.07.2012 19:01 - Ном1 Истина
01.07.2012 19:02 - Ном1 Истина
01.07.2012 19:03 - Ном1 Ложь
01.07.2012 19:04 - Ном1 Истина
01.07.2012 19:05 - Ном1 Истина
Какой результат будет, если воспользоваться твоим запросом?

(134), ничего не вернет, в таблице нет не утвержденной номенклатуры

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

(137) мне левое соединение зачем со справочником делать? я не понимаю, просто. покажи пример.
(135) ошибаешься, думаю, что вернет как раз то 19:03 время. проверь, а если воспользуешься вариантом с вложенным запросом .. ничего не получишь. Хотя может я ошибаюсь?

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

(135) хотя все правильно я думаю... я вспомнил почему у меня с вложенным запросом запара...

      ВЫБРАТЬ
   РегистрСведений1СрезПоследних.Измерение1,
   РегистрСведений1СрезПоследних.Ресурс1
ИЗ
   РегистрСведений.РегистрСведений1.СрезПоследних(, Не Ресурс1) КАК РегистрСведений1СрезПоследних

Теперь надо выяснить, что будет быстрее работать с 1млн записей.
Это:
"ВЫБРАТЬ
|    РегистрНакопления1Остатки.Измерение1,
|    РегистрНакопления1Остатки.Ресурс1Остаток
|ИЗ
|    РегистрНакопления.РегистрНакопления1.Остатки КАК РегистрНакопления1Остатки"

или

|ВЫБРАТЬ
|        РегистрСведений1СрезПоследних.Измерение1 КАК Измерение1,
|        РегистрСведений1СрезПоследних.Ресурс1 КАК Ресурс1
|    ИЗ
|        РегистрСведений.РегистрСведений1.СрезПоследних КАК РегистрСведений1СрезПоследних
|ГДЕ НЕ РегистрСведений1СрезПоследних.Ресурс1

Самый базовый вариант

ВЫБРАТЬ
   Номенклатура.Ссылка,
   УтвержденнаяНоменклатураСрезПоследних.Номенклатура,
   УтвержденнаяНоменклатураСрезПоследних.Утвержден
ИЗ
   Справочник.Номенклатура КАК Номенклатура
       Левое СОЕДИНЕНИЕ РегистрСведений.УтвержденнаяНоменклатура.СрезПоследних(&Дата, ) КАК УтвержденнаяНоменклатураСрезПоследних
       ПО Номенклатура.Ссылка = УтвержденнаяНоменклатураСрезПоследних.Номеклатура


Выдаст утвержденную на данный момент номенклатуру

Точнее номенклатуру которая когда либо утверждалась :)
Добавляем условие по Утвержден Истина , и и получаем нужное

(141) он и без лишнего соединения это выдаст :)

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

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

(144) прикинь к 1 млн записей номенклатуры, подрубать статусы... мне кажется - это слишком много ресурсов сожрет. Поэтому логичнее будет как-то без соединения со справочником работать :) Да и условие задаваемое в РС оно накладывается на таблицу, которая из бд уже вытащена, не так ли? (я просто спрашиваю)

Соединение двух массивов по 300 000 элементов , занимает несколько секунд .

Кроме того скорость исполнение запроса (если уж совсем криво не делать) , по любому в разы быстрее чем вывод в печатную форму или заполнение ТЗ например из запроса .

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

(145) У тебя весь миллион утверждается ?
Если сотрудник будет физически тратить на утверждение элемента номенклатуры хотя бы пять секунд (не бездумно а слегка включив мозг) , это займет 280 человеко-часов :)

(146) сейчас у меня справочник номенклатуры генерится, и могу сказать, что на 100000 записей РН выдает результат мгновенно, если в результате запроса 10 позиций - а это как раз нормально, т.к. 999990 записей совершенно не нужно отрабатывать. А вот РС выдает результат через 2-3 секунды.

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

(148) Если строить запрос непосредственно к РС (или РН , без разницы), то можно попасть :)
И скорость исполнения запроса все равно на порядки меньше чем его последующая обработка , не важно с соединением или без .

Например менеджеру потребовалось посмотреть не утвержденные новинки , твои действия ? Да еще и поступившие в последние три дня ? Ни в РН ни в РС записей о них еще нет , запрос без соединения ничего не вернет .

(150) если делать соединение, то скорость будет равна - это да. Но вот если тебе просто надо получать всегда  только не утвержденную, тут стоит задуматься :) У меня это не номенклатура - это событие. просто почему то решил сделать пример на номенклатуре, т.к. всем она ближе, чем тот объект, что у меня :)
(151) регистр накопления, остатки просто, РН мой как раз для этого и сделан, что бы видеть не утвержденные. Если нет остатка, значит утверждена. Таким образом, если уж очень нужно, то можно вытащить и утвержденную - сделав соединение и увидев нулевой остаток ;)

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

Если в РН нет остатка то по какому элементу ? Все равно для тотального контроля надо соединение делать , начав от "печки" - справочника .

(153) я согласен с тем, что для полного просмотра надо делать соединение, но мне не нужны закрытые события или утвержденная номенклатура в этом отчете ;) Поэтому РН выигрывает, т.к. он банально делает все быстрее ;) Только что все сгенерилось и я проверил. РН меньше секунды, РС 2-3 секунды на 100т записей из которых мне нужно видеть только 10 ;)

(154), значит что-то ты не так в запросе написал

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

"ВЫБРАТЬ
|    РегистрНакопления1Остатки.Измерение1,
|    РегистрНакопления1Остатки.Ресурс1Остаток
|ИЗ
|    РегистрНакопления.РегистрНакопления1.Остатки КАК РегистрНакопления1Остатки"


|ВЫБРАТЬ
|        РегистрСведений1СрезПоследних.Измерение1 КАК Измерение1,
|        РегистрСведений1СрезПоследних.Ресурс1 КАК Ресурс1
|    ИЗ
|        РегистрСведений.РегистрСведений1.СрезПоследних КАК РегистрСведений1СрезПоследних
|ГДЕ НЕ РегистрСведений1СрезПоследних.Ресурс1

http://dl.dropbox.com/u/31492005/Тест%20РН/1Cv8.1CD - РН
http://dl.dropbox.com/u/31492005/Тест%20РС/1Cv8.1CD - РС
http://dl.dropbox.com/u/31492005/Консоль%20запросов%208.2.epf - консоль запросов, если нету :)

(157) У тебя уже сейчас база с РН занимает на 40 % больше места , кода захочешь например добавить менеджера утвердившего разница станет еще значительней . А когда у тебя остатки начнут по периодам накапливаться ....

(158) она больше потому что там документов больше и соответственно записей в регистре :) Иначе говоря, больше истории чем с РС ;) ДЛя более лучшего теста создал 100000 записей в РН +1 и 999990 записей -1 Поэтому и больше ;)

(156) В зависимости от даты. Если нужна история (а она нужна), то при получении любого значения предыдущего периода получишь пересчет итогов на дату получения.
А РС будет работать точно так же.

Решение с РН хуже т.к.
1. Не очевидно и хуже поддерживается (топикстартер сменит работу и иметь длительные противоестественные отношение с его продуктом придется кому-то другому)
2. Больше рисков (топикстарпер может хоть все зубы давать, а то, что РН будет закрываться в 0, и там не будет неположенных значений, но 100% гарантии нет)
3. Если уж речь идет про объем, то решение на РН будет занимать больше места. Вместо 1 таблицы будет 3 + таблица остатков будет постоянно расти (за счет пересчета итогов, а если не считать итоги, то см. 160) + 1с выпустит очередной релиз и опять будут в итогах храниться нули (была такая беда, правда в релизе 8.1) и весь выигрыш по скорости теряется.

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

(159) Предупреждать надо! Нажан выпольнит на орбаботку и пошло молотить элементы :)

(161) +100
Кроме того , большучее значение что именно ТС собирается делать с информацие по утверждению потом.
Строить списки утвержденных
Строить списки не утвержденных
Выводить в экранную форму элемента справочника
Проверять при проведении документа отгрузки

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

Как вариант использования избыточной информации
1. Текущее значение в справочнике +
2. История в РС
Плюс
Ускорит отборы (реквизит справочника)
Минус
Хранение данных в 2 местах - треубется решить вопрос одновременности внесения изменений + решение коллизий.

(161) вот если 1с будет в итогах хранить нули, вдруг надумает, тогда да.. смысла в РН нет. Да, объем в итоге будет больше, т.к. там на 1 таблицу больше? Но это не так критично. Потому что:
1. Объем справочника будет постоянно увеличиваться, соответственно работа с РС будет постоянно занимать больше и больше времени ... сперва 1 млн, потом 2 млн, 3 млн записей .. хотя это лет за 10 работы. такое будет, думаю. И к этому времени уже база сменится несколько раз. Но все-равно РН работает значительно быстрее, хоть и жрет больше места :)

Такое ощущение, что автор просто не осилил РС, вот его на РН так и зациклило. :)

(166) Неа , представляешь сколько итогов РН будет хранить на несколько миллионов записей накопленных за несколько лет , и как это будет выбираться . А если добавить доболнительные ресурсы ...

Сейчас посмотрел в рабочей базе на скуле .
Запрос к остаткам по списку в пару сотен товаров из ТЧ документа , и такой же запрос к РС по качественным удостоверениям товара (похоже на утверждения только тянутся не булевы значения а строковые), при общей номенклатуре 35 000 .

Запрос к РН действительно быстрее , на 0.14 секунды , с практической точки зрения ничтожная разница . А геммороя заметно меньше . Кроме того сам РС достаточно громоздкий - периодика , менеджеры , строковый ресурс , крайний срок партии

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

(169) Кстати да , запись в РС значительно быстрее , ибо нет пересчета итогов , да и просто тупо информации меньше пишется .

В общем (112)  :))

Эх ... на самом деле скорость записи не особо играет роль в том, что мне нужно сделать. Да и она не будет заметна, т.к. помимо этой записи будут еще делаться другие.
(168) тут тест немного нечестный, наверное, т.к. количество записей, которые нужно увидеть больше чем с РС?
Хотят тут я бы сказал так, если количество записей ничтожно мало, то РН выигрывает, если количество записей превышает какое-то неведомое значение, то РС становится быстрее. Я тоже потихоньку начинаю склоняться в сторону РС, осталось директора убедить, он программист 1сный .. любит необычные решения :)
РН плюсы по сравнению с РС:
1. Скорость получения информации по всем не утвержденным элементам справочника выше
минусы по сравнению с РС:
1. Большой объем места (т.к. таблиц больше)
2. Ненадежность РН, т.к. в один прекрасный момент нужно будет пересчитать итоги - это так?
3. Незначительно снижена скорость при утверждении.
Кто еще что-нибудь добавит? :)

(171) С этого и надо было начинать . Делай как хочет директор , в качестве необычного решения , предложи ему вариант починенного справочника , усугубленный как в (112)  :)

(172) не люблю я так, я хочу взвесить все за и против.

(172) а этот вариант в принципе есть в стандартной подсистеме - называется версионирование :D

А так
1. Не факт , если при записи нового элемента номенклатуры , зразу записывать в РС , булево значение НЕТ , а потом уже утверждать , то можно строить запрос непосредственно к РС , и скорост выборки не утвержденных возрастет

Как будет происходить утверждение , пакетно , или по элементно менеджером , на каком основании утверждается товар

(174) Самое тормосзное что есть в стандартных подсистемах , отключили первым делом и написали свое :)

Ну чтож, выложил все плюсы и минусы, подождем-с :)

(173) Ты так и не обьяснил что будешь делать потом с информацией по утвержденным и не утвержденным ,см (164)

(178) для каждого пользователя получать список событий, которые он должен отработать. Я еще не придумал как буду делать адресацию, в принципе ничего особенного - просто под роль адресация. Адресация будет храниться в элементе справочника, думаю имеет смысл добавлять измерение - Адресация, что бы еще быстрее все читалось :) Таким образом, скорость получения информации из РН будет совсем незначительно выше.

(179) тогда точно РС