Ситуация: Пользователь проводит Расходную Накладную,при этом он забыл выбрать склад из выпад.списка.

В Модуле Документа я проверяю

//************************************//
Процедура ОбработкаПроведения()
                                     
   Если Склад.Выбран()=0 Тогда
       Предупреждение("Выберите склад,с которого  
                       |будете отгружать товар!");
       СтатусВозврата(0);
       Возврат;
   КонецЕсли;

 //*********
 //*********

При обработке документа пользователь нажимает на ОК,
1С спрашивает "Хотите сохранить?" - Угу,
"Хотите провести?" - Угу,
и только после этого выясняется-"Выберите склад,с которого  
                       |будете отгружать товар!"

Вопрос:Как проверять -выбран ли склад - (при нажатии на Ок),но ДО 1С-овских вопросов Сохранить/Провести ?

ПриЗаписи()
(ПередЗаписью)

На кнопку ОК() повесь функцию, которая будет проверять, а потом записывать.

to ДенисЧ
но ведь на Ок уже висит функция "#Записать?Провести?Закрыть"
как быть?

(3) Процедура ПриЗаписи()
    Если Склад.Выбран()=0 Тогда
      Предупреждение("Выберите склад,с которого  
                      |будете отгружать товар!");
      СтатусВозврата(0);
      Возврат;
  КонецПроцедуры

Убрать логику "#Записать?Провести?Закрыть" в свою функцию.
т.е. где так.
процедура МояЗапись()
 Если ПРоверкаРеквизитов() = 0 тогда
   сообщить("Не заполнены реквизиты");
   возврат;
 конецЕслИ;

 записать();
 ПриЗаписи();
 провести();
 форма.Закрыть();
конецПроцедуры

(3) Повесишь свою процедуру, а в ней запишешь, проведёшь и т.д.
Но лучше смотри (1)

ДенисЧ - тебе объяснить, в чем твоя ошибка?

(7) попробуй, поучи дурака.

(7) А зачем спрашивать? (двусмысленно...)

(5) Фигню написал.

Спасибо.

(10) обоснуй.

(8) При обновлениях не видно, какие изменения были сделаны на форме. Таким образом внесенные тобой изменения не отслеживаются.
Изменения, сделанные в модуле формы, отслеживаются легко, поэтому именно они и рекомендуются.

Закладка “Дополнительные” содержит:

Формула    Поле ввода команд, исполняемых при нажатии кнопки. Строка команд может содержать один оператор встроенного языка (обычно используется для вызова процедуры, описанной в программном модуле), далее после символа" # " могут следовать имена предопределенных команд для кнопки, разделенных пробелами. Предопределенных команды для кнопки существует три:
Закрыть    закрыть окно;
Записать    выполнить операцию записи информации;
Провести    выполнить операцию проводки (имеет смысл только для Документа).

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

1С:Предприятие, версия 7.7. (c) 1996-1999, Фирма "1С"

(12) Это ты обоснуй
записать();
ПриЗаписи();

Цытата из (0) "Вопрос:Как проверять -выбран ли склад - (при нажатии на Ок),но ДО 1С-овских вопросов Сохранить/Провести ?"

А теперь подумайте и попробуйте. Когда будет вызвана ПриЗаписи()? До вопроса или после?

А по поводу объединения - правильно сравнивать конфигурации надо.

(15) Процедура (предопределенная) ПриЗаписи() вызывается при _интерактивной_ записи документа. При программном вызове функции Записать() она (п/п) не вызовется.

Посмотри (14), убери с кнопки знаки ? и оставь свою проверку

(18) Подходов разных может много. Я привёл один. Ты другой. Ты мне не доказал, что я не прав.

Жить надо проще

(20) я так и поступил. Одна функция, в делай что хочешь.

А где делать

ПриЗаписи()
(ПередЗаписью)


в МодулеДиалога или в Модуле документа?

(18) не-ет, хотелось бы 1с-проверку оставить!, пользователю она нужна, а вот мою проверку желат.делать ДО.

Во накинулись на человека!
Ну накривил он несколько, но по сути ДенисЧ - прав.
Если уж автор встаёт на путь доработки типовой конфигурации - то уже пофигу мороз, по какой методике у него пойдут изменения - малой кровью при обновлении он всё равно не отделается (аппетит приходит во время еды).

А вообще, тот, кто не может выйти за религиозные рамки встроенных в кнопки команд - извечно будет стенать в плену идиотских вопросов 1С: записать? - да, записать; провести? - да, провести. После пары сотен таких диалогов сам по себе напрашивается вопрос: а нафига спрашивать пользователя, проводить ли документ, если пользователь уже НАЖАЛ КНОПКУ ОК???!!! То есть пользователю есть только один путь провести - нажать ОК и сказать два раза "да". И для тех пользователей, кто дружит со здравым смыслом, подобные подтверждения по куче раз кажутся неуместными, ибо человек знает, что он делает, а не идиот, который нажал куда-то и смотрит - что из этого получится.

P.S. Это всего лишь моё мнение - ничего личного.

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

(26) Зачем кучу функций? Достаточно двух процедур всего.

И вот в том-то и дело, что преследуя цель "обновление за один день" - ты вынужден ходить в строгих рамках определённых методов. Функционал от этого страдает. В то же время конфы, которые не нужно обновлять - избавлены от таких проблем. Либо, когда простота обновления - не самоцель - тоже сам себе хозяин - можно выбирать наиболее оптимальные пути и алгоритмы.

Эх, обновленцы..

(27) Тогда сравни пост 4 и пост 5.
зы А цели такой нет. Выбирается оптимальный путь. В данном случае - именно 4. А если не нужны знаки вопросов, то можно их и в форме убрать.

(28) На самом деле тут достаточно (0) и (5) - только без вызова ПРоверкаРеквизитов()

(29) Достаточно (0) и (4).

(30) Глупо. Один вопрос два раза.

(31) Т.е. ты лично воспользуешься способом (5)?

(32) Лично я сделаю (0), кнопку "Провести", в ней формулу Проведение() и
Процедура Проведение()
 Если Форма.КнопкаПроведения.Доступность()=0 Тогда
   Возврат;
 КонецЕсли;
 Если Модифицированность()=1 Тогда
   ПриЗаписи();
   Если СтатусВозврата()=1 Тогда
     Записать();
   КонецЕсли;
 КонецЕсли;
 Если СтатусВозврата()=1 Тогда
   Провести(0);
 КонецЕсли;
КонецПроцедуры

(33) Тогда совет. Не формулу Проведение(), а формулу ПриВыбореЗначения("кнПровести").
И так для всех кнопок. Чтобы унифицировано было.

(34) Учту как вариант. :)

(35) Ты из Раруса?

(36) Неужели я так плохо выгляжу? ;))

Как вариант - ба-а-а-льшие красные надписи, которые пропадают по мере заполнения... %)

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

(37) Плохо, плохо.
Смотри. Берем правильно оформленный непроведенный документ. Заходим. Очищаем Склад. И закрываем. При этом компьютер спрашивает нас - "Сохранить изменения?". Мы говорим - да. И результат - документ без выбранного склада. Такой ситуации в варианте 4 просто не возникнет.

(40) Долго же ты думал. А сказал мимо.
В (0) вопрос про "...Пользователь проводит...". Про то, что нельзя сохранять документ при каких-то условиях, речи вообще не шло. Как не шло её и о том, что процедура ПриЗаписи() - не нужна. Если ты внимательно посмотришь в (33), то увидишь, что там эта процедура как раз вызывается, и если она будет содержать какие-то условия типа (4) и вернёт нулевой статус возврата - проведение даже не начнётся.

(41) При варианте, который предлагаю я, эта процедура не вызывается. А отрабатывает процедура ПриЗаписи.
зы А ты попробуй вспомни, почему да отчего выработались какие-либо правила. Просто вляпался когда-то в случай, что - "мы только посмотрели, не знаю, почему он перепровелся". А сегодня упорный тип попался. Два(!) часа закрывал документ крестиком и пытался сохранить в закрытом периоде. Это упорство да в мирных целях. (Насмотрелся у других. До сих пор понять не могу, почему одна кнопка с пятой-шестой попытки пропускает не выбранное значение. В отладчике ни одного сбоя. А у этих...)

(24)
"Если уж автор встаёт на путь доработки типовой конфигурации - то уже пофигу мороз, по какой методике у него пойдут изменения - малой кровью при обновлении он всё равно не отделается "

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



(40) Садись... Оценка 2....
Пользователь в момент записи документа его просто сохраняет... Ибо он может просто не знать того же склада... Или просто хочет сохранить недозаполненный док, чтобы пойти в сортир...

Критические реквизиты, их заполнение и непротиворечивость надо проверять в модуле дока... Жертвуя временем проведения...

P.S. кстати, свинью с отсутствием проверки можно пронаблюдать в ТиС 9.2.... Разработчики постарались...

(43) Во первых - Время проведения дока должно быть минимальным. Во вторых - человек должен в обязательном порядке вначале заполнить шапку документа и лишь потом - табличную часть.
И с какого перепуга пользователь не будет знать склада? Если пользователь не заполняет все поля - значит есть избыточность. Значит программист что-то неправильно сделал. Не доработал.
Садись, оценку, так и быть, ставить не буду.

А проверку можно делать при перепроведении доков. А по кнопке - передача параметра в ОбработкуПроведения. Это лучше.

Ну во первых, эта проверка мизерна по времени...

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

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

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

Поехали. По поводу склада - у каждого юзвера по умолчанию стоит определенный склад. Он не должен его очищать. Далее - если комплектование с нескольких складов - тогда он решает, с какого склада будут отгружать и делает перемещения на тот склад. Записывает. Перемещения проводят кладовщики тех складов. Это один из вариантов. РН поводят по факту выдачи клиенту.
ps  А кто сказал, что записанный документ не могут изменить? А простите, пустой склад у вас на ЕНВД? Как это определяется?

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

Армянский комсомол.... Сами создаем трудности, сами их преодолеваем...
Не надо строить юзера там, где этого не требуется

P.S. просто ты работаешь так, как удобней тебе...

Кончайте спорить. ZZZZZ прав, все проверки лучше производить ПриЗаписи()- проверено и не раз. У нас, например, юзеры заполняют не только склад, а и кучу других реквизитов шапки. Только ПриЗаписи() и спасает от тупых.

ПриЗаписи это хорошо... и не вредно...
Но ведь доки создаются не только интерактивно...

(50) Создаёшь программно - там и проверишь...

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

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

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

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