Интересный вопрос, как всегда от меня )))).  Сильно не пинать, все же не 1С программист я. Это побочное явление)))
  В данном случае создал обработку, имеющую ТЧ, которая заполняется запросом. Цель обработки упростить работу операторов. Все действия обработки (в основном изменение статуса документа Событие, цвета строки обработки) пишу в Периодический РС, без регистратора.
   Работает это так:
1) Вывожу список всего, что есть.
2) Оператор "играется" с выведенными на форму параметрами, а также сортировками и отборами и получает удобный и нужный список.
3) В табличной части у оператора есть "для игры" только булева Отметка, проставив которую он(а) видит, что строчка покрасилась в желтый цвет (сигнал готова к дальнейшим действиям)
4) Оператор нажимает кнопку "Создать События", по которой на все желтые строки создаются и заполняются документы События, а в табличной части обработки появляются ссылки на эти События (можно просмотреть)
   Далее с Событиями "играют" уже другие отделы, при этом меняя реквизиты (в обработке при Обновлении заполняются поля заполненного реквизита и строчка меняет цвет на оранжевый).
5) Событию проставляют статус Завершено. Строка обработки меняет цвет на зеленый, показывает статус завершено...
   И это все у меня работает... НО мне не нравится... Список не обновляется динамически. И хоть использование моей обработки предполагается раз в месяц и загрузка всего списка занимает около двух минут, хотелось бы получить ликбез как бы вы реализовали что-то подобное на ОФ

Что значит "не обновляется"?
Поставь ему в настройках автообновление...

(1) У меня не динамическое поле, а ТЧ. Запросом и после запроса проставляя разные условия вывожу список. Автообновление не то.... Я и говорю о том, что НЕ Динамический список у меня))

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

Я не понимаю проблемы...

Или вообще встрой обработку в конфигурацию и сделай в ней динамический список и извращайся...

Список чего-то заполняется 2 минуты ?!
Это п...ц

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

(6) врешь же шь.. Кому нахрен нужен мульт доков в табличке на форме, что б его еще и цветом красить ?
Сказки.

(6) Не проснулся?
"выводить только те что соответствуют выбранному проценту"

(8)хорошо. Пусть будет отсев 95% доков от мульта. Операторы 50к строк гоняют в обработке и галочки ставят?...
Сказки.

(9) А если 99%
У меня была картина, когда выводилось ~10 000 доков. И таки да, их крутили и смотрели.

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

(11) Каждый месяц. События на клиентов. Галки не расставляли, но просматривали.

И отсев всегда, 99.9% а то иначе на мисте не поверят в миллион

Посмотрел в базе, у нас как раз ~10к реализаций в месяц. Попробовал полистать этот список, листая страницы через PgDown.
Немножечко охренел листать его, что бы хотя бы пару дней крутануть.
Че там кто расставляет желтым цветом... сказки.

(14) Как бы странным не казалось, но пользователи довольно часто что-то делают в списках с 5-10 тыс. строк. Хотя я тоже не понимаю как там что-то можно делать...

http://pics.rsh.ru/img/_nq7zeuu9.png

(15) ну вот, у меня "список" доков за месяц.
Его заипешься в журнале листать через листание страниц. Еще и глазками цвета  в нём различать и че-то творить ? И не пропустить при этои ?

И это, если верить ТС - 1% от его мульта. А если больше ? Так что, сказки в (0).


:)))))

На 7ке любая автоматизация начиналась с того что на каждое подразделение и (или) вид продукции делалась отдельная расходная накладная со своим счетом и возможно, с отдельной счет-фактурой. Чтобы были в разных журналах.
Возможно, в упп есть обработки, генерирующие набор прав, отборов и настроек для нового подразделения/вида товаров/вида продукции?

"что-то делают в списках с 5-10 тыс. строк" - это проблема в головах и в UX/UI.
На экране _всегда_ не более 50 строк (извращения с 4К мониторами не рассматриваем).

Если вы уж сподобились делать свои списки, делайте и порционное чтение.

(6) все эти кадавры рождаются от корявой архитектуры.
если юзерам важен процент наполнения\исполнения, то этот набор данных должен жить в РН и оперативно пересчитываться по мере изменения данных, а в списки высирать только посчитанную таблицу остатков.
если всё так плохо, то как то избежать отборов\условий\сортировок по этим полям и сделать их расчётными при получении данных. 30-50 строк за раз оно быстро посчитает.

(0) Так а в чем проблема переделать на динамический список?

(7) а вот не вру)))) ... Эти документы События клепаются от 1000 в день и больше... Многие из них автоматом. В ручную 5%, остальные обработками. Кстати и своей обработкой клепаю эти События. но у меня хоть ручной выбор. Операторы ставят "галочки" на какие Объекты клепать События

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

(23) + Обработка будет использоваться раз в месяц, но Объекты в нее попадают с периодичностью в 5 лет. Т.е. статус завершено в данном случае говорит о том, что этот Объект, ещё 5 лет не трогать

(9) Обрезка идет сразу!!! Оператор выбирает % процент, который считается по каждому Объекту и Дату на который идет расчет процента. Уже получается список 5к длиной.... потом идут игры с датой последнего События по данной операции ... и там остается записей 300-500... Вот с ними да, приходится думать оператору

(22) про миллион доков загнул явно

(26) ради интереса посчитаю общее кол-во .... ответ выдам.

(27) чего считать то ? И так видно, что врешь не краснея.

(28) 5 636 369

(29) Это что ? Количество всего документов в базе, или что ?

(30) да, количество док События в базе... Тут вся база крутится вокруг Объектов (дома) ит Событий. Их пачками все отделы каждый день добавляют! В основном автозаполнением, в ручную 2-5%

(31) +++ и реквизитов в этом Событиии вагон и маленькая тележка

(31) )))))))))))))))))))))))))))))))))

Т.е твоя поделка всегда берёт ВСЕ документы в базе и для них что-то считает ?
Чтоб получить выборку в 0.01% ?

(33) нет конечно! Она берет События определенного ВидаСобытия, Группы и Подгруппы. Но при этом без обрезки по дате, потому как это надо операторам. Потом из этих Событий по ЛицевымСчетам считается процент исправных плательщиков по каждому подъезду дома (Объекта) и только те подъезды, которые подошли под Процент выводятся в ТЧ обработки

Ничего не понял. Но если без дополнительного РС никак и он большой - то да, эффективное решение на ДС в ОФ не получится.

(35) Доп РС как раз не большой. В него идет запись только обработанных оператором строк. И периодичность у него год. Он нужен мне как раз для того, чтобы визуализировать состояние строк, а так же отсекать Завершенные События

(36) Если РС небольшой, то можно фильтровать ДС по вхождениям ссылок в массивы ссылок (через стандартные отборы). А отрисовывать по связанным данным через ПриПолученииДанных. То есть статически будут вычитываться только данные РС.