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

И второй вопрос креативное начальство внезапно решило отказаться от использования ячеистого склада и заодно от ордерной схемы. Убрать лишние документы. Как аргументированно убедить начальство в бредовости идеи?

На второй вопрос лучше создать отдельную ветку

>Подскажите пожалуйста есть задача раскрасить строки динамического списка в зависимости от числа строк табличной части связанного документа
СписокПриПолученииДанныхНаСервере

Зачем при получении данных? Чем условное оформление не угодило?
Количество строк вывести в отдельный регистр сведений.

(2) Даже если раскрашивать через условное, служебное поле, которое будет участвовать в условии, разумно было бы заполнять ПриПолученииДанныхНаСервере()

(0) Насколько помню, никаких проблем с расширением данного события не было.

(3) а не проще внести изменение в текст запроса динамического списка и не лохматить серверные вызовы?

(4) Соединить таблицу на несколько сот тысяч объектов еще с одной такой же, хотя с большой долей вероятности список даже прокручиваться не будет?

(5) чего? С регистром сведений новым?

(6) Как минимум.

В случаях, когда в динамическом списке требуется отображение вспомогательных колонок, по которым не требуется отбирать (в том числе через механизмы поиска), сортировать и группировать, и ЗАТРУДНИТЕЛЬНО, НЕЭФФЕКТИВНО или НЕВОЗМОЖНО выполнить получение данных с помощью основного запроса, рекомендуется воспользоваться обработчиком ПриПолученииДанныхНаСервере таблицы управляемой формы.
https://its.1c.ru/db/v8std/content/732/hdoc

(7) Про флаг "Динамическое считывание данных" в курсе для чего он и как работает?

(8) НЕЭФФЕКТИВНО. Создавать отдельный РС на каждое условное оформление - это, конечно, образец эффективности.

(9) лучше 1 раз посчитать количество, чем 100 пользователей будут всю эксплуатацию системы каждый раз при пролистывании списка делать отдельные запросы к количеству строк ТЧ

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

(11) вот это здраво, доп РС - доп мусор, который будет храниться вечно

(12) типовой регистр сведений дополнительных сведений на 1 млн документов займет 50 мб, это лучше чем потом постить ветки что тормозит форма списка

(0) зачем трем стеллажам адресное хранение и ордерная схема при рознице?

(0) Никогда не понимал логики менеджеров "давайте раскрасим список - заказано, наверное заказано, в пути, из пути, пришло, ушло, всё норм, не норм".
Выглядит как попугай дикий.

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

(0) 1. условное оформление
2. реализация адресного хранения и ордерного в типовой УТ/ERP настолько извратная что да, лучше или отказаться или написать свое

(0) И второй вопрос креативное начальство внезапно решило отказаться от использования ячеистого склада и заодно от ордерной схемы. Убрать лишние документы. Как аргументированно убедить начальство в бредовости идеи?
.
от ордерной схемы - вполне можно не юзать, смотря для чего оно нужно.
а отказываться от ячеестого склада (безонтносительно если к реализации в типовых 1С) - ну хз что там у вас за склад, ситуация и прочее. вполне возможно что и ячеестый склад не нужен, желаешь если обсудить подробнее предметно - стукайся в скайп Zlopun.
.
простой заменой ордерного может быть упрощенная схема когда в документах товародвижения количественные показатели типа
план,факт,учет (делал у себя так на клюшках). в том же УНФ нагло передрали идею у меня (как сказал бы Маня). Например, у нас УНФ и неордерный склад. там можно включить режим для поступления ТМЦ например, когда два занчения "количество по документу" и "количество по факту" ну и принимать к учету "по документу" или "по факту", а разницу - куда хоь, туда и девай, хоть обосабливай виртуально отдельно, хоть списывай сразу.

(0) ПриПолученииДанныхНаСервере доступно с версии платформы 8.3.10 У вас платформа и режим совместимости соответствуют?