dma_caviarАнатоЛойХорошо, если "Текущий офис" и "Отв.сотрудник текущего офиса" в "Заявке на канцтовары" - реквизит заголовка документа.
А если "Офис" и "Отв.сотрудник офиса" в "Бюджете заказа канцтоваров по офисам" - связанные реквизиты в строке документа?
В смысле, что делать если нужного поля нет в документе?
Тогда или добавляем это поле в этот документ как "виртуальное поле", ну чисто для наших нужд, т.е. в таблице документа его конечно нет. Или второй вариант - ну что-то же есть в документе, например ID заявки. А справочник тогда может называться "Справочник чего-то там... для заказа канцтоваров" и в нем обязательный параметр "ID заявки на канц. товары".

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

В варианте №4:
- перечень "Офисы";
- перечень "Сотрудники" с реквизитом "Офис".
- выбор значения в реквизит "Сотрудник текущего офиса" может быть реализован несколькими вариантами:
- а) Критерий "Сотрудник текущего офиса" без передачи входных параметров,
текущий офис определяется внутри "Алгоритма отбора" (допустим эта переменная в сессии пользователя);
- б) если БД в каждом офисе своя, то текущий офис может быть прописан в критерии Критерий "Сотрудник текущего офиса" без передачи входных параметров, но с параметром-константой:
значение из перечня - указан нужній офис;
без возможности смены значения при вызове.
в) критерий "Сотрудник офиса" c параметром "Офис".
Если "Офис" и "Сотрудник этого офиса" реквизиты одной строки в перечне строк документа, то для реквизита "Сотрудник этого офиса" в правиле для параметра критерия "Офис" будет указан реквизит "Офис" из этой же структуры....

ф-у-у-у-у-ф.
Всё, спать :)

ViPRos, меня возьмёте? :)

dma_caviarПо идее, если настройщику требуется наложить фильтр на какой-то существующий справочник, значит ему просто не хватает еще одного справочника (точнее выборки на основе этого справочника). К тому же эта выборка может еще где-нибудь понадобится, так уж лучше пусть этот код будет описан в одном месте, например в "Сотрудники текущего офиса", и будет использоваться потом в нескольких местах безо всяких фильтров. В противном случае все эти фильтры придется дублировать.
Я провтыкал основную идею: выборка есть именованное подмножество, которым неплохо бы оперировать ка цельным новым перечнем :)
Ждите вариант N5.. :) И где LSV, я из-за кого тут распинаюсь !? :)

ViPRosАнатоЛойViPRos, меня возьмёте? :)
ты далеко и только начинаешь трудный путь к обобщениям :)
Если далеко еще могу принять за аргумент, то с обобщениями не соглашусь. В этом топике я изначально затевал процесс проектирования, а не показать некую свою наработку. У каждого в наработках есть оригинальные решения и не очень, плюсы и минусы. Вопрос этого топика для меня был актуален лет 15 назад. Решение, в разработке ядра которого я кчааствовал, живет до сих пор. Вот только я уже лет 5 как аналитик в основном, и в других областях и с другими решениями. :)

iscrafmАнатоЛойЕсли далеко еще могу принять за аргумент, то с обобщениями не соглашусь. В этом топике я изначально затевал процесс проектирования, а не показать некую свою наработку
множество лишнего вместо банальной выборки с параметром.
Может быть.... А может и нет! :).
1. Что конкретно лишнее и почему?
или
2. "Вот конкретный вариант от меня, в нём меньше того и этого, а результат тот же!"

iscrafmЛишнее все то, что сверх банальной выборки с передаваемой в нее параметром, какой тип записей отбирать в нее. Подумайте сами, если все это можно сделать банально "where st = <значение параметра> ", к тому же индексированное и т.д., то в чем смысл делать столько лишнего? Что бы кому-то показать что каким то образом домайн все же может заработать, просто нужно смирится с кучей непонятно чего.
Боюсь сделать много лишних домыслов, чтобы от "настройки банальной выборки с передаваемой в нее параметром, какой тип записей отбирать в нее" перейти к "хранения этих настроек в РСУБД". Вас не затруднит простенькую структуру набросать?