Программно создать колонки в ТЧ документа. Вопросы сохранения этого всего добра. #688422

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

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

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

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

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

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

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

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

Реквизит строка неограниченной длины + При записи: Реквизит=ЗначениеВстрокуВнутр(ТЗ); При открытии: ТЗ=ЗначениеИзСтрокиВнутр(Реквизит).Скопировать

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

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

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

Если колонок создается не много, например, пусть даже 30-40, то добавь сразу столько колонок в твою ТЧ. Потом по мере надобности открывай. Если там сотни колонок, то можно так: Создай новую ТЧ, с колонками. ИД колонки (число) ИД строки (число) Значение (такое какое нужно). При открытии и сохранении гоняешь значения из экранного ТЗ в ТЧ и обратно.

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

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

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

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

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

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

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

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

что в колонках?

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

"Создай новую ТЧ, с колонками. Значение (такое какое нужно). " Вот этого я не понял, можно подробнее плиз?

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

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

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

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

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

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

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

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

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

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

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

насмешил!

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

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

да ))

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

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

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

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

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

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

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

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

+1 Регистры в данном случае не дадут ничего полезного чем ТЧ. >Вот этого я не понял, можно подробнее плиз? В такой ТЧ адрес ячейки и значение. Что именно не понятно?

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

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

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

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

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

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

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

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

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

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

правильный отчет в

смотри .

см

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

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

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

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

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

1986 г.р.

сейчас точно не помню как устроено, но суть в том, что строки по типам цен разворачиваются в колонки ТЧ содержит: Товар1 ТипЦен1 Выводимая таблица Товар1 ТипЦен1 ТипЦен2 ТипЦен3 при сохранении просходит обратное преобразование

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

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

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

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

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

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

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

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