Подскажите как лучше сделать.
Допустим в документе есть табличная часть, в которой очень много колонок(реквизитов табличной части).
Я хочу добавить ещё одну колонку, которая будет заполняться из регистра, скажем во время нажатия на какую ни будь кнопку.
Так же во внимание нужно учесть, что документ может быть ещё не записан в системе, поэтому нам нужно работать с элементами формы.

Как это лучше реализовать?

Мы можем выгрузить всю табличную часть, описать её поля в запросе, левым соединением присоединить нужные мне данные, а после просто выгрузить в эту табличную часть.
Но! а если полей запроса очень много? Это всё нужно будет ведь описывать, ну покрайне мерие название давать, что уже плохо.
Мы можем конечно написать ВЫБРАТЬ * ИЗ &ТабЧасти, но нам потом соединять и выгружать, мне кажется не прокатит. Хорошо... может и прокатит(я что то не попробовал) но запрос нужно будет писать без конструктора.

>> но запрос нужно будет писать без конструктора.

Порвало.

Автор двоечник? Столько ошибок в тексте, что невозможно читать.

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

(0) Если сложности в "без конструктора" - внимательно посмотрите на конструктор. Он многое умеет :-)
Но непонятна задача - что за колонка, что с ней будет происходить, почему нельзя добавить её в табличную часть и не мучиться...

Сломал глаз пока читал.

Вопрос: какие данные будут в новой колонке и от чего отталкиваться ?

Можно добавить новую колонку на форме, потом в событии таблицы ПриВыводеСтроки заполнять ячейку через ОформлениеСтроки УстановитьТекст.


Можно так же по нажатию на новую кнопку, нажимают кнопку, по циклу Для каждого, обходим ОформлениеСтрок и заполняем ячейки.

Извините, старался писать внятно и понятно, видимо переборщил.

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

Колонка будет в табличной части Но её заполнять должна процедура по нажатию на кнопку. Данные будут браться из регистра для каждой номенклатуры, т.е. связь с номенклатурой.
Проблема в том, что документ может быть НЕ ЗАПИСАН во время нажатия на кнопку. Поэтому мы не можем обратиться к записи в БД.

(5) Если колонка будет в табличной части и должна _заполняться по нажатию на кнопку_ - тогда данные в этой колонке должны быть реквизитом табличной части. ТабличноеПоле _не_ хранит данные.

(5) берешь данные из формы, помещаешь в ТЗ, ТЗ передаешь в запрос и делай дальше что хочешь

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

(0) Если собираешься выводить чисто какую-то справочную информацию "по кнопке", то лучше для этого колонку в ТЧ формы не использовать. Могут быть головняки с модифицированностью формы при просмотре проведенного документа. Особенно в закрытом периоде.

(8) придётся описывать много полей, Ватсон

(8) "документ может быть ещё не записан в системе, поэтому нам нужно работать с _элементами формы_" - это бред.

(10) Поэтому я и создал ветку, так как не уверен, что это правильный выход из ситуации.
(11) Почему бред? Допустим у нас есть документ, пользователь его открыл, понадобавлял строк в эту табличную часть, нажимает на эту кнопку. Если мы будем брать данные из базы, то мы не увидим новые строки, так как их нет ещё в базе, мы его не сохраняли. Поэтому нам нужно брать данные не из базы, а из формы.

(12) это правильный выход из ситуации. таки в нашей работе приходится немножко работать руками

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

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

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

(12) Не из "базы", а из табличной части (ещё не записанного) объекта. Ощутите разницу.

(16) Вопрос другой - а пользователю эти дополнительные поля нужны?

(16) Построй таблицу значений новой колонки в зависимости от исключительно ключевых значений строки. Перебери строки и установи значение.

(16) Ну или финальный самый ленивый вариант - запрос в цикле.

(15) (17) Не понял, к чему вы клоните. К тому что мысль не правильно выразил или я что то упускаю?
(18) всмысле нужны?
(19) (20) если бы задача горела, то сделал бы запрос в цикле, но так как не горит особо, то решил узнать как будет более правильнее

(21) Если у тебя РЕАЛЬНО много колонок и ты ленив, сделай так:
1. Сгенерируй запрос который выберет тебе в виртуальную таблицу(ВТ) табличную часть.
2. Запрос который выберет из ВТ ключевые поля на основе которых строится значение новой колонки и вычисли значение колонки для них. Получишь некую таблицу ТЗ
3. Запросом соедини ВТ  левым соединением с ТЗ.
4. Загрузи обратно.

(22) ну это да, спасибо, тоже об этом подумал

(21)
- "Я хочу добавить ещё одну колонку" - в табличную часть?
- "Мы можем выгрузить всю табличную часть, описать её поля в запросе, левым соединением присоединить нужные мне данные, а после просто выгрузить в эту табличную часть" - и это будет правильным решением.
- "а если полей запроса очень много?" - кто такие поля запроса?
- "ну покрайне мерие название давать, что уже плохо" - а как Вы намерены обращаться к данным, если не по имени?
- "Мы можем конечно написать ВЫБРАТЬ * ИЗ &ТабЧасти, но нам потом соединять и выгружать, мне кажется не прокатит" - поместите табличную часть во временную таблицу, а затем хоть засоединяйтесь с ней.

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

(25) документ "прощаем всё". в ТЧ - контрагент, сумма долга. почему бы по кнопке не прописывать в изменённую ТЧ получение актуальных сумм долга?

(26) Зачем ? Напиши обработку которая как результат сделает тебе документ или кнопку заполнить которая выведет форму красиво там все покажет , галочки там всякие и как результат заполнит табличную часть. Документ как объект необходим лишь для фиксации некоего действия в системе , не надо на него нагружать функции анализа и т.д.

(27) и для изменений существующего документа открывать обработку? не хочу

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

(29) такое вот изощрённое пользовательское желание. вчера записал, сегодня пора проводить, а данные уже другие

(30)Согласен бывает :-), но поверь мне , это порочный путь , надо пользователей воспитывать.

(31) В документе 1594 строки с десятком реквизитов. После твоего предложения забить все руками за раз, он на тебя пойдет за битой.

+(32) с битой

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