Мне нужно, чтобы у меня был отдельный журнал, куда попадали бы документы ЗапазПокупателя с определённым значением реквизита. Так же мне нужно, чтобы создав документ из этого журнала, мы могли в модуле документа определить, что он создан именно из этого журнала? это чтоб при создании запихнуть значение в реквизит нужно но как определить что именно из этого журнала? или мне надо свою панель нарисовать с кнопками?

Платформа какая?

имхо бизнес-логика страдает на обе ноги

(1)8.2 обычная. не управляемые формы.
(2)ваши предположения могут страдать на обе ноги. в данном случае так нужно. это же элементарно. через один журнал создаются документы с одним видом операции. через другой - с другим. так даже в ТИС было

не. ну неужели никто не знает. ФормаРодитель же должна гдето указываться.

(4) у формы есть Владелец, но в твоем случае владельцом будет табличная часть журнала, а не сам журнал. Можно конечно извращаться, но...

В форме списка докментов есть такое понятие как отбор. Можно копать туда. Считывать какой отбор в форме и принимать решение что делать с документом.

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

(6) Если автор из модуля документа сумеет выкрутиться и добраться до значений отбора этого(!) журнала.Сильно сомневаюсь, однако.

"мы могли в модуле документа определить" - глупости это всё(имхо). Но если нельзя, но очень хочется - создай "флаг" по которому будешь ориентироваться на местности. И если делать "это", то не в "модуле документа", а в основной форме объекта при открытии.

ОбработкаЗаполнения(ДанныеЗаполнения)

Где "ДанныеЗаполнение" - документ-основание, если документ вводится на основании или структура отбора, если документ создается из журнала с отбором

(8)а вот как ориентироваться на местности то?

(9)другое дело!

(2) + 1
(3) это 7-шные подходы, они давно отмерли в 8-ке, тут делают по другому, о чем в предыдущих ветках тебе почти каждый говорил

(12)сдаюсь. начал делать отдельный вид документа (( слишком много гемора просто сейчас получу. придется в коде типовой рыться.

У элемента формы типа СписокДокументов есть предопределенный метод "ПередНачаломДобавления". Он отрабатывает, когда ты нажимаешь на кнопку создать новый документ. Юзай его. Делаешь СтандартнуюОбработку = Ложь. Создаешь нужный документ сам, присваиваешь нужный реквизит где надо сам и открываешь форму нового документа.

(14)ооо. вот это как раз то что надо. решение проблемы

(15) это ты щас будешь косиыли 7-ки переводить на 8-ку. в Итоге гемора будет больше, чем если делать по образу и подобию типовых

(16)придется отдельным видом документа делать. чтобы всё по понятиям было. просто хотел избежать гемора при переписании кода.

(17) твой документ ничего не двигает, является только основанием. Где там переписание масштабное? всё норм

(18)не двигает это да. но в нём большое количество функционала - бизнес процессы, рассчет цены. в этом геморик есть. придется в коде менять название ЗаказПокупателя на ЗаказПокупателяСводный

(18)спасибо что убедили делать отдельным документом.

(20) не ради тебя, ради всех 1сников кто потом ЭТО будет сопровождать)

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

А поддерживать потом изменения в обоих документах, это конечно не гемор ) хех

(22) 7-шник?
короче автор - делай сувалку. Делать ли 2-й док. Пусть решит демократия

(23)не знаю как ) а вообще можешь в двух словах пояснить почему восьмерка не приветствует подход из (22) ?

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

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

(24) опираться на данные отбора, подменять формы документов в зависимости от реквизита - ничего этого нет в реальных системах. Я бы даже не документ новый наверно делал, а Вид Операции документа. в зависимости от операции - разный внешний вид документа, что уже везде реализовано. В общем подход - логика работы опирается на данные, а не на то какую форму открыл юзер. Моё сугубое ИМХО

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

(28) это лучше в точки зрения обновления например, если док типовой тот

(27) наглядный пример. Есть счета покупателей, в списке счетов покупателей они идут скопом. Довольно часто клиенты просят видеть все счета одного контрагента у него в справочнике, на новой закладке-счета. Специалистам отдела продаж, обычно, удобней найти в справочнике нужного контрагента и зайдя в него, на закладке счета посмотреть все его счета. И при этом нажав там на добавить новый счет хотят, чтобы по умолчанию в новом счете вставал контрагент из под которого мы нажимали добавить.

Это я к тому, что странно всю эту логику считать семершной и ненужной.

(30) это другая ситуация, вполне стандратная. Это начальное заполнение справочника на основании отбора. В (0) речь совершенно о другом, меняется бизнес логика документа, причем довольно странным способом. В документах тут подход - Вид Операции документа, или новый. Сам я уже больше к виду операций сколняюсь, но тут вопрос об обновлениях последующих и т.д. надо просто выбрать вариант

(30) + это в 8-ке на уровне платформы вобще уже, первоначальное заполнение новых

(3) >>через один журнал создаются документы с одним видом операции. через другой - с другим

ну вот сам и ответил, по виду операции

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

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

(30) Хмм...

Процедура ЖурналДокументовСписокПередНачаломДобавления(Элемент, Отказ, Копирование)
   
   Если Копирование Тогда
       Возврат;
   КонецЕсли;
   
   Отказ = Истина;
   ФормаНовогоДокумента = Документы["ЗапазПокупателя"].ПолучитьФормуНовогоДокумента(, ЭтаФорма);
   ФормаНовогоДокумента.Открыть();
   Возврат;
   
КонецПроцедуры

надо будет забухать с некоторыми людьми этой ветки )

(37) не, подерёмся ещё

(38)врядли ) ты же не сержант1с

(27) Разработчики реальных типовых могут позволить себе любые вольности - новые виды операций и т.п.
А на местах часто требуется снизить стоимость владения ПО, уменьшить затраты на обновление и поддержку.

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

Но если ТС  не требуется часто обновлять эти документы, можно делать как принято в типовых.

(40)Програмно конечно это можно. правда возни немало. если учесть что формы разного размера и там множество привязок. но можно конечно панели использовать