Помогите разобраться, как сохранять ТЗ в документе ( справочнике) , а потом получить эту информацию виз другого документа или отчёта?

в реквизитах шапки/табл.части документа нельзя указывать поля с типом ТаблицаЗначений или подобное. А именно только в реквизитах хранится введённая информация в документе. Потом можно к ним обращаться из дркгих док-тов/отчётов. Чтобы съимитировать ТЗ в документе, необходимо создать эти реквизиты документа - колонки ТЗ. И причём получится как бы ограничение на кол-во строк.
Например, если ты хочешь хранишь ТЗ в документе о реквизитах доп.документов, Номер|Дата|Контрагент, то ты должен создать реквизиты шапки:
Номер1 Дата1 Контр1 (1-я строка)
Номер2 Дата2 Контр2 (2-я строка)
Номер3 Дата3 Контр3 (3-я строка)
При проведении док-та, ты считываешь строки таблицы и записываешь в эти реквизиты значения ТЗ.
В данном примере, число строк ТЗ в док-те не более 3-х.
При открытии док-та пришешь процедуру, считывающую эти реквизиты и заполняющую ТЗ.
По другому вроде никак.

Нужно завест в объекте (документе, справочнике) ревизит типа Строка неграниченой длины (РеквизитТЗ).
В модуле объекта

ТЗ = СоздатьОбъект("ТаблицаЗначений");
ТЗ.ДобавитьКолонку(...);
ТЗ.НоваяСрока();
...

При сохранении объекта (после заполнения ТЗ) вызывать метод
РеквизитТЗ = ЗначениеВСтроку(ТЗ);

Во всех местах, где нужна ТЗ нужно вызывать метод
ТЗ = "";
ЗначениеИзСтроки(Объект.РеквизитТЗ).Выгрузить(ТЗ);

Естесвенно в запросе работать с такой ТЗ не получится.. Контроль ссылочной целостности не выполняется и т.п.

По такой эе методике можно работать и со списом значений.

Огромное спасибо за ответы и помощь!!!

Vladko—Спасибо навел на одну идею надо будет попробовать. Я попробую создать несколько справочников и сделать ссылку на них из «Документа», а там как предложено. В общем поэкспериментирую, тем более, что аналоги ребята уже писали.

azernot- Спасибо за ответ!!
Я читал здесь на форуме ответ на похожий вопрос, там был ответ Корума
1. "неправильно" (из-за ссылочной целостности): создать реквизит шапки (строка неогр длины), ПриЗаписи() дополнить ТвойРеквизит = значениевСтрокуВнутр(ТвояТЗ);
ПриОткрытии() дополнить
Попытка
ТвояТЗ= значениеИзСтрокиВнутр(ТвойРеквизит);

2. "правильно": создать подчинённый документ, при открытии его таб часть заливать в свою тз. При закрытии - сливать обратно в документ.
Кода в этом случае чуть больше ;о)

Как быть с его мнением?!! Или я чего-то не правильно понял?

Подчинённый докуменn - конечно лучше! Но он подходит только в случае если ТЗ фиксированная по колонкам. Или придётся в подчинённом докумене создать 1000 и > колонок с неопределённым типом/видом..

Вобщем всё зависит от задачи.

sergiowood Написал:
-------------------------------------------------------
> azernot- Спасибо за ответ!!
> Я читал здесь на форуме ответ на похожий вопрос,
> там был ответ Корума
> 1. "неправильно" (из-за ссылочной целостности):
> 2. "правильно": создать подчинённый документ, при
>
> Как быть с его мнением?!! Или я чего-то не правильно понял?

ИМХО ты неправильно понял критерий правильность/неправильность.

azernot, в своем сообщении написал "Естесвенно в запросе работать с такой ТЗ не получится.. Контроль ссылочной целостности не выполняется и т.п."
Это есть ограничения такого способа. Если тебя эти ограничения не останавливают, то ты можешь этот способ использовать.

Корум, в своем сообщении подразумевал, что ограничение по контролю ссылочной целостности является принципиальным и необсуждаемым. Отсюда вердикт - "неправльно".

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

В качестве альтернативы предложу следующий вариант:
Справочник с реквизитами:
Документ;
Номер (наименование) табличной части (если нужно несколько ТЗ в одном документе);
Номер колонки;
Наименование колонки;
Номер строки;
Значение.

В этом случае, кода будет еще больше. Однако снимается ограничение на фиксированное количество колонок.

Я всегда почти использую в 7.7 метод с "ЗначениеВСтроку()". Всегда можно проверить вручную ссылочную целостность там, где это нужно через "НайтиЭлемент()". К сожалению, в 8.0 таким образом таблицу у меня сохранить и восстановить не получилось.

Огромное спасибо за ответы, помощь и разъяснения !!!
Идея в общем достаточно тривиальная, хранение информации в элементах справочника ВалДоз/Расх ( 1С: Бух. для Украины)с целью последующего просмотра и корректировки при составлении Налоговой и Бух отчётности, а то иногда не понятно, что попало в ту или иную строку (ячейку) налоговой декларации (баланса), а так можно будет проверить, сделать пару другую фильтровок. Так же планирую на каждый элемент справочника повесить ссылки на строку (ячейку) налоговой декларации (баланса). Т.о. хранить планирую Документы (ссылка на док.), а для фильтрации и анализа сумму, дату и счёт по которому пошла проводка.
Постараюсь сделать симбиоз идей Vladko, azernot и poppy, а там куда Бог даст.
Может кто-то подскажет как енто можно лучше релизовать?

Сохраняешь просто:

Реквизит=ЗначениеВСтроку(МояТаблица);

А при восстановлении используешь вот что:

Код
МояТаблица=ВосстановитьТаблицуИзСтроки(Реквизит); Если МояТаблица=0 Тогда    МояТаблица=СоздатьОбъект("ТаблицаЗначений");    МояТаблица.НоваяКолонка(...);    ... КонецЕсли; Показать полностью

где определяешь:

Код

Функция ВосстановитьТаблицуИзСтроки(Стр)    Т=ЗначениеИзСтроки(Стр);    Если ТипЗначенияСтр(Т)<>"ТаблицаЗначений" Тогда       Возврат 0;    КонецЕсли;    Справочник=СоздатьОбъект("Справочник.Контрагенты");    // Для проверки целостности    К=1;    Пока К<=Т.КоличествоСтрок() Цикл       Если Справочник.НайтиЗначение(Т.ПолучитьЗначение(К,"Контрагент"))=0 Тогда          Т.УдалитьСтроку(К);       Иначе          К=К+1;       КонецЕсли;    КонецЦикла;    Возврат Т; КонецФункции Показать полностью

O-Planet пасибо за кусок кода с примером!!

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

Спасибо за помощь GENDALF, но "ввод на основании" это совсем другая история .
Весь смысл в программном заполнении и хранении информации в ТЗ, а потом её машинная или «ручная» обработка.

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

Сhe Burashka- огромное спасибо, вся красота в простате.

На сто рядов проверенный способ:
Документ.ХранительДанных
Бухучет = НЕТ
Оперучет = НЕТ
НомерДок [число 5]
———————шапка——————————
Владелец [Неопределенный ]
———————табличная часть—————
Р1 [Неопределенный]
. . . . . . . . . . .
Р15 [Неопределенный]
———————описание——————
Вспомогательный документ для хранения
дополнительной табличной части объектов
метаданных, например:
вторая табличная часть какого-либо документа

Угу. Перегружать бух итоги - это "красота и простота" :)

Слушай вариант на 200%!

1. Создаешь справочник "ХранилищеДанных" с одним реквизитом: "Документ". и подчиненный ему "ДанныеПоДокументам"
2. При записи дока ищешь (создаешь) запись в "Хранилище", куда записываешь ссылку на записываемый документ, а в подчиненных этой записи элементах в справочнике "ДанныеПоДокументам" хранишь и потом используешь все, что заблагорассудится.
3. При пометке на удаление (снятии) помечаешь (снимаешь с пометки) и записи в этих справочниках по текущему документу.

Чем лучше, чем с бухитогами? -
1) Не бухитоги
2) Не ограничен по кол-ву субконто
3) Со справочником работать проще
4) Не изменил план счетов и при обновлении не будет больших проблем

2Сhe Burashka: ты, видать, плохо себе представляешь, что такое разбухшая таблица проводок и сколько времени уходить на банальный персчет итогов при добавлении одного вшивенького счета
O-Planet: а если надо сохранить 2,3 и более ТЧ одного документа?
Столько же починенных справочников делать? А если я вообще еще не знаю сколько в будущем мне понадобится ТЧ в каком-нибудь документе?

Так что см. вариант Abadonna, тем более это ссылка на давно и успешно работающую конфигурацию

См. вариант O-Planet! :)
В подчиненном я могу все что угодно вписать, вплоть до номера ТЧ.

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

И железо наимощнейшее, и организация правильная, и скорость работы, а вот при изменении плана счетов - полная ж...

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

Добрый день!
Во множестве мнений рождается истинна.
Abadonna- огромное спасибо, что обратил внимание на последствия при изменении плана счетов и на время при обработке (пересчёте) итогов.
Что касается варианта «Документ.ХранительДанных», вариант классный, но для данной задачи, если использовать в чистом виде,то получиться жесткий (ограниченный) по гибкости использования. Его действительно классно применять при создании дополнительной таблице в документе. Хочу переделать планировщик оплаты и сделать планирование бюджета для оплаты полученных поставок, вот там и попробую использовать.
А вот использовать идею poppy с идеей O-Planet и с идеей Abadonna будет то, что надо. Я создам имеющемуся спр. ВалДох/Расх подчинённый справочник (идея O-Planet) с необходимыми для работы реквизитами (аналог идеи poppy), а колонки ТЗ на элементе справочника будут формироваться и соответствовать типу реквизитам из подчинённого справочника (идея Abadonna ).
Думаю, что так должно получиться. Как считаете?!

Можно добавить и справочник хранилище, в который будут добавляться необходимые реквизиты для хранения и обработки, а на его основании и по его реквизитам формировать подчиненный элемент справочника, в котором в шапке будет один реквизит «Документ» и добавить ТЗ шапка которой заполниться от «справочник хранилище» по элементам и его типам. Правда тогда все усложниться, но гибкость получиться…..

Идея Сhe Burashka проста в исполнении и отчёты по счетам стандартные можно использовать, но как подумаю про пересчёт….

P.S.Наверно правду говорят, что иногда самая прямая и короткая дорога в обход.

Согласен тоже, перегружать бухсчета для хранилища информации не лучшая идея.