Как добавить кнопку "Ввести на основании" на форму обработки #596303

Создал обработку. Добавил в нее табличную часть. В табличной части добавил реквизит с типом "ДокументССылка". На форму обработки добавил Табличное поле отображающее эту самую табличную часть. Хочу добавить панель с кнопками выше табличного поля. Не могу понять как добавить кнопку "Ввести на основании" аналогичную одноименной кнопке в форме списка документом. Порылся в типовых... похожего решения не обнаружил.... Прошу помощи, советом или может даже готовым решением.

если не появляется при автозаполнении командной панели, то рисовать свою придётся

Не появится... это же табличная форма на обработке.

конфигуратор придуман как раз для конфигурирования

Намек слишком утончен что бы я мог понять.... :(

передаю открытым текстом: сделай свою кнопку

Это понятно. Каким образом? Писать самому функционал поиска в метаданных документов вводимых на основании текущего?

Кто нибудь делал такую кнопку? Поделитесь алгоритмом.

ты свой журнал документов что ли рисуешь или что ?

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

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

У своего табличного поля ставишь тип значение документ-список (нужный из) Над полем добавляешь панель интсрументов с источником действий - твоим таб полем. Далее или включаешь автозаполнение, или добавляешь кнопку с действием "ввести на основании"

+ на список наклыдваешь отбор. P.S. Все эти действия - для того, что самому не рисовать кнопку.

Если отбор не хочется, то похоже на "Получатся нужно через перебор метаданных создавать свой список и выводить рядом с кнопкой"

Ну, не рядом, а здесь из кнопки красивое подменю

а сделать*

вроде как у документа есть "является основанием для..." -вывести список выбора

Наоборот, "ВводитсяНаОсновании" есть - в метаданных. Ну ТС про это знает)

Ну понятно, я так и думал. Что ж... займусь "изобразительным творчеством".

Да ладно, чего там,  простой цикл :)

мне почему то кажется что и имеет место быть

неа

не оно?

Нет.

а что это? или эти данные нигде не хранятся ?

Хранятся, но во ВводитсяНаОсновании, в тех объектах, которые там перечислены. Это форма для удобства так сделана.

В СП нашел только "ВводитсяНаОсновании" свойство метаданных документа: Использование: Только чтение. Описание: Тип: КоллекцияЗначенийСвойстваОбъектаМетаданных. Коллекция объектов конфигурации, данные которых могут являться основанием для ввода нового объекта базы данных этого типа. Доступность: Сервер, толстый клиент, внешнее соединение.

+ Это логично, зачем связи хранить дважды.

Т.е. перебор всех документов и анализ свойства "ВводитсяНаОсновании" для каждого из них. Ищем там свой документ - и если поиск удался ... добавляем в список?! Прикольно. Вопрос - неужели это ранее никто не реализовывал? И в типовых нигде нет?

"Ищем там свой документ - и если поиск удался ... добавляем в список?!" Да. Сделай таки ради меня не список, а красивое меню) Панель.Кнопки.КнопкаПодменюВвестиНаОсновании.Кнопки.Добавить; :)

Ну это уж полюбому :) Придеццо делать теперь именно так )))

Учитывая что в таблице в которой у меня хранятся документы, будут содержаться документы разного вида, придется этот цикл по заполнению выполнять в событии "ПриАктивизацииСтроки". Отсюда вопрос - не будет ли визуальных эффектов связанных с переформированием данного списка при смене строки?

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

Мне кажется, заметно не будет (визуально), ну кроме как на совсем медленных компьютерах. Никаких обращений к БД тут нет, а перформируемое подменю "невидимо"

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

Ну да, получается некотjрая возьня, зато кнопка будет как родная :-) (особенно если картинку ей установить такую же)

Есть у меня вопрос, не проще ли создать свой журнал документов? Засунуть туда все документы которые тебе надо и все, будете тебе кнопка.

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

+ А если отбор не простой, придется типа ссылка в делать, а это тормоза.

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

Гарантированно не тормозящий вариант - повесить подменю на правый клик (тогда придется меня рисвоать только при нажатии). Но придется учить ее (правую кнопку) нажимать. Многие не умеют ;)

Вот про журнал и отбор, не совсем понимаю. Как это мне поможет. Вернее понимаю как журнал поможет вывести кнопку... но как это будет работать в контексте моей задачи... Объясню - есть серийный номер. Он првязан к какому-то товара. При вводе серийного номера пользователем, обработка выбирает все документы в которых использовался этот товар с этим серийным номером. И выводит их в табличную часть на обработке. Каким боком тут можно использовать журнал?! Я шото недоганяю... приведите пример пожалуйста... может и вправду есть более элегантное решение.

Ну тут тебе еще и критерий отбора надо будет сделать, и все заработает.

Ага, кажись доганяю. С помощью запроса получаю список документов которые нужно вывести в журнал. Потом в журнале добавляю отбор у которого ставлю условие "В списке" и указываю список документов который нужен. И получаю журнал только с нужными ме документами.

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

Ну что же... идея рабочая... только вот как форму журнала разместить на форме моей обработки. Т.к. если пользователь введет часть серийного номера - то в обработки выводится список товаров которые содержат этот фрагмент серийного номера, а потом уже при перемещении по этому списку отображается перечень документом для каждого товара.

ну это ты предложил точно работающий вариант.

Это я ее предложил в . Разве документ-список заменить на журнал )

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

Т.е. я правильно понял, я могу положить на форму обработки табличное поле любого журнала, так?

да, так как ДокументСписок, там можно выбрать ЖурналСписок, или как то так

конечно, тип значения у табличного поля установить нужный из ЖурналДокументовСписок, далее по тексту)

ЖурналДокументовСписок вот, подсмотрел)

Фигасе! Вот жеж... век живи век учись. Все класно, идея очень даже мне нравится. Есть только одно но - для этого придется добавлять объект типа журнал в конфигурацию. Что лишает обработку универсальности. Изначально эта обработка планировалась как "Дополнительная внешняя форма" подключаемая через всем-известный функционал типовых конфигураций.

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

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

Посмотрел существующие журналы, больше всего подходит Журнал "Складские документы". Т.к. в нем есть все документы которые часто используются в бизнес-процессах покупки и продажи товара. Но вот смущает что табличная часть "Серийные номера" существует еще и в других документах (которые не включены в журнал складские документы) таких как например "Авансовый отчет". Т.е. получается если недайбог кто-то что-то купить по авансовому отчету да еще с серийным номером - в журнале я не смогу отбразить этот документ. Вот и получается что, если делать обработку "для людей" что бы могли использовать все кому надо (например скачав с Инфостарта) - журнал не подходит. Получается выход один? Рисовать собственные кнопки?

Хотя Журнал - в 100500 раз более "красивое" решение. Т.к. пользователь сам сможет настроить список нужных ему полей, да и работать будет как с журналом... без каких либо ограничений связанных с тем что я что-то упустил или недодумал в процессе разработки "своих кнопок".

Еще вопрос, если я наложу на журнал отбор, как запретить пользователю его снять, не запревщая при этом добавлять свои отборы в дополнение к уже установленному?

Отбор по ссылку интерактивно не снимается.

по ссылке*

Вообщем пока сделал так: Добавил на форму обработки табличное поле, и командную панель. В командной панели ИсточникДанных = ТабличноеПоле. Автозаполнение = Истина. В методе "ПриАктивизацииСтроки" списка товаров написал:

В качестве источника данных использовал ЖурналДокументов.СкладскиеДокументы