Есть документ. Программно добавляю колонки в таблицу значений. Количество не фиксированное, соответственно в документе сохранить не смогу. Методами Сохранить/ВосстановитьЗначение - тоже не могу, необходимо работать нескольким пользователям с документом. Регистр - жОсткое извращение, но всё же сработает, не хочется таким путем идти. Ребят, какие мысли?

иди выпей коньяку, проспись и переформулируй вопрос.

(1) Попробую растолковать. Есть документ. ТЗ - реквизит формы, в кот. добавляется произвольное количество колонок. Вопрос: каким макаром сохранять?

+ 2 коньяку бы -- это да, если бы результат был)

(2) Что сохранять? Куда сохранять?

как только выяснишь, куда сохранять, сигнализируй

В хранилище значений можно.

(0) К чему такие извращения? Со временим возникнет желание анализировать эту информацию. Каким образом это будешь делать?

(0)Реквизит строка неограниченной длины +

При записи:
Реквизит=ЗначениеВстрокуВнутр(ТЗ);

При открытии:

ТЗ=ЗначениеИзСтрокиВнутр(Реквизит).Скопировать()

(8) спасибо, проанализирую данный случай

(8) А потом кто-нибудь меняет в конфигураторе тип, сохраненный в этой таблице, и привет

(10)а завтра ядерная война и мы все умрем:-)

Если колонок создается не много, например, пусть даже 30-40, то добавь сразу столько колонок в твою ТЧ. Потом по мере надобности открывай.

Если там сотни колонок, то можно так:

Создай новую ТЧ, с колонками.
ИД колонки (число)
ИД строки (число)
Значение (такое какое нужно).

При открытии и сохранении гоняешь значения из экранного ТЗ в ТЧ и обратно.

про видимость и роли автору уже говорили или тут только извращения предлагать?

(13) Дружище, странный вопрос, ты на мисте! Только извращения разумеется.

(0) Колонка в ТЧ: "ИмяКолонки". Хранить либо в одной "развернутой" ТЧ, либо в двух (как в типовом документе "установка цен")

(0) Хотелось бы услышать цель данного документа?
Какое событие он фиксирует?

(15) там реквизиты есть в ТЧ, не оно

(16) формирует заказы покупателей и как следствие создает маршрут по ним

(13) причем здесь "видимость" и "роли", аргументируй

(12) была такая идея, колонок немного, что-то около 20-30, если др. варианты не прокнут, то так и придется

(18) что в колонках?

(18) Может не в табличной части хранить данные а в регистре сведений?
А на форме документа отображать этот регистр так, как понадобится?
Там же можно навертеть как угодно. И колонки добавлять сколько вздумается. :)

(12) "Создай новую ТЧ, с колонками.
ИД колонки (число)
ИД строки (число)
Значение (такое какое нужно). "

Вот этого я не понял, можно подробнее плиз?

22+ Ну т.е. как в операции сделать.
Только с отображением колонок придется помучится. А так все должно получиться.

(21) в колонках числа, но разница...

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

(26) ИМХО - это самое оптимальное.
Остальные варианты либо ссылочную целостность не дают, либо избыточную информацию придется хранить.

(26) хранилище значений.
Но, имхо, переменное количекство колонок есть зло. Лучше уж регистр

Регистр - это не крайний, а самый разумный и оптимальный вариант.

(26) посмотри документ Уставновка цен номенклатуры - там тоже количество колонок по ценам в псевдо ТЧ произвольное.

Добавь в документ реквизит с типом Таблица значений и в него сохрани.

(25) рассказываю разницу. всё становится сильно проще, если колонки сделать строками

(30) да нет там того, чего я хочу, там фиксированное количество реквизитов...

(31) хм...да нету там такого типа, уже искал

(31) насмешил!

(25) "в колонках числа"

Ну значит одна сводная ТЧ для хранения данных:
ИмяКолонки (строка)
Значение (число)

(34) тогда см (26).Чего бояться регистров, если они твои и с поставщиком конфигурации не связаны. Если объснишь по какой причине разные колонки, то возможно и решение будет связаны с этими причинами.

(35) да ))

(26) "в топике про регистр я упомянул"
Зачем регистр, если тоже самое можно в ТЧ самого документа хранить? ;)

установа уен номенклатуры как вариант

(0) Ну делаешь просто - создаешь реквизит у документа с типом ХранилищеЗначения, в него запихиваешь табличное поле с формы. Профит.

Несруктурированный документ - это какая-то...

(41) Рейв выше предложил, сейчас обкатываю

(42) всё в жизни может быть

(19) Тем что лучше готовая ТЧ с полным списком фиксированных колонок, а какие колонки показывать - решать при открытии(создании на сервере) в зависимости от роли пользователя.
У тебя в шапке топика ТЧ, а внутри уже ТЗ.

(39) если делать ТЧ, то например, 30 колонок по 30 строк - подумай, сколько по времени будет документ с такой ТЧ сохраняться/проводиться. Тем более в ТЧ количество строк ограничено.

(39) +1 Регистры в данном случае не дадут ничего полезного чем ТЧ.

(23) >Вот этого я не понял, можно подробнее плиз?

В такой ТЧ адрес ячейки и значение. Что именно не понятно?

(45) верно подметил, спс, если есть модеры - измените в названии ТЧ на ТЗ

А почему бы не сделать как в документе "Установка цен" в типовых конфигах?

(46) В типовом табеле в ЗУП, если не ошибаюсь 4*31*2 + 2 = 250 колонок и ничего платформа пережевала не подавилась...

(49) коллеги, ну вот где вы там видите, тыкните строчку, нет там такого!

(46) сохроняться вообще без проблем будет, а проведение от этого вообще не зависит. Кстати как раз в проведении будет проблемнее работать с регистром сведений, чем с ТЧ.
И ещё как будет делаться привязка к регистру сведений у не записанного документа?

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

(50) (52) насколько я понял из (0) речь идёт о произвольном количестве колонок.

(54) ты привел пример 30 колонок по 30 строк, тебе привели пример в 250 колонок в типовой, который нормально работает. В чём проблема?

(54) Понятно. Вот только обычно в какое-то ограничение вписывается.

Значение в строку.  Решения с 40 колонками в ТЧ, стукнитесь обо что нибудь кто предложил :)

(55) правильный отчет в (36)

(55) смотри (36).

(58)(59) см (49)

(60) ничего не нашел по теме. смотрел в бух 2.0

(61) Это в части торговле наверное

(61) а в бух-ии есть несколько типов цен (никогда там не возникала необходимости вести в БП различные цены)?
в типовых УТ, УПП, КА точно механизм есть

попробовал запихать в строку, все колонки сохраняет, а те, которые добавлялись программно - нет, ЧЯДНТ?

(64) Если хочешь головной боли продолжай сохранять в строку...

1986 г.р.

(49) сейчас точно не помню как устроено, но суть в том, что строки по типам цен разворачиваются в колонки

ТЧ содержит:
Товар1 ТипЦен1
Товар1 ТипЦен2
Товар1 ТипЦен3

Выводимая таблица
Товар1 ТипЦен1 ТипЦен2 ТипЦен3

при сохранении просходит обратное преобразование

(67) спасибо, я помню как, хотел найти другой способ, так как в данном случае это аналогично созданию регистра, в котором нужно будет сохранять. Вообще-то "Тицен" и "индекс" содержит вторая ТЧ, по ним же генерируется, связь через соответствие.

(66) на личности переходить не буду, как-то непрофессионально получится, спасибо и тебе тоже

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

(70) Регистр не лучше ТЧ, а только хуже.

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

(71) Чем он принципиально хуже? (без сарказма, действительно интересно.)

(72) Не сказать, что прям в 10 раз хуже, но так несколько хуже.
Данные оторваны от объекта, отсюда:

-При открытии документа лишний запрос к бд.
-В запросах к документу лишнее соединение.
-Усложняется обмен с другими базами.
-В момент записи документа нужно проследить, что бы данные в регистре обновились только в том и только в том случае, если документ записан. Если произошел отказ записи документа (по какой-либо причине), то и регистр не должен быть записан. И наоборот. Если ошибка при записи регистра, то и документ не должен быть записан. Этого лучше всего добиться передав данные для записи в модуль объекта и записывать в одной транзакции.

Это все можно обойти, но зачем усложнять себе жизнь...

Думаю, выигрыша в объеме хранимых данных в регистре не будет (думаю примерно одинаково, что так, что так).

(73) В ТЧ же нужно-то всего два маленьких цикла, перед записью документа и при открытии, для трансформации данных в другой вид...

(73) Возможно я ошибаюсь, но насколько я знаю, в БД шапка и табличная часть хранятся в разных "таблицах" (извините за путаницу), поэтому 1 и 2 пункты неактуальны. Усложнение обмена - вопрос для обсуждения.
Соглашусь разве только с 4 пунктом. Но на мой взгляд, оба варианта по функциональности примерно одинаковые и сугубо дело вкуса.