может, Табличным Полем?

NvW писал(а) 26. Октября 2008 :: 10:48:


Возьми из репозитория КОП для подмены многострочной части документа. Там реализован механизм создания ТП на основе многострочной части или метаданных. Он конечно не 100% работоспособен, и не совсем стабилен. Но как пример для тебя очень подойдет.

Пы.сы. как то думал я на предмет нескольких табличных частей в одном документе. Варианты реализации у меня были, но от того что я не выбрал "единственно-верный" для себя способ, то соответственно ничего готового на данный момент нет.
1 вариант: в "реальную" многострочную часть добавляют реквизиты для обоих табличных полей с префиксами либо в идентификаторе либо в комментарии. Префикс = ИДТабличногоПоля+"_"...
Например надо чтобы была мн.часть "Товары" и мн.часть "Тара" тогда создаем соответствующие кнопки (контейнеры) с идентификаторами (например) ТП_Товары и ТП_Тара. После чего добавляем реквизиты: ТП_Товары_Номенклатура, ТП_Товары_ЕдИзм... , ТП_Тара_Номенклатура... и т.д. Соответственно в одной табличной части (реальной мн.части) будут хранится все данные, а в ТП отображаться только те которые относятся к текущему табличному полю. Создать КОП для управления и обработки. Чтобы везде можно было отдельно получить значения соответствующих колонок.
Из минусов такого решения могу назвать то что при больших объемах данных обработка может длиться "какое-то" время. Хотя если перевести на прямой запрос можно получить и выигрышь. Но все равно работа по записи обратно может занять время. В общем надо пробовать
2 вариант: добавляем 1 документ с 1-й мн.частью, добавляем 2-й документ со 2-й мн.частью. В обоих прописываем реквизит "ДокументВладелец", "ДокументНаследник" чтобы можно было быстро достучаться до другого документа. Работа будет во многом похожа на 1-й вариант, т.е. тоже КОП для управления и пр. Но есть возможность обращаться к документам отдельно, модули проведения писать отдельно. А значит КОП будет освобожден как минимум от сервисных методов вроде ПолучитьМногострочнуюЧасть("ТП_Товары") или еще каких. Но опять таки есть минусы. Надо хорошо понимать что такая структура неуниверсальна и при отмене одного документа, надо бы и второй отменять... да и посмотреть движения "одного" документа не получиться, т.к. в реале их два.

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