Вопрос к теоретикам - "перед записью" или "проведением" #722931

Вопрос такой- где правильнее делать проверку незаполненности реквизитов формы в "перед записью" или "обработка проведения". вот небольшой код (проверка табличной части на заполнение одного реквизита строки):

ПередЗаписью Отказ от проведения связан с гораздо бОльшими накладными расходами.

Чем раньше заметишь ошибку, тем лучше. Так что перед записью.

ПередЗаписью. Транзакция еще не активна

Глупые вопрос от теоретика, конечно все надо проверять перед записью

перед записью

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

В частности цена. На момент записи я пока не знаю какая цена, от записал пока и всё. Как узнаю (ответственный за цену приедет с обеда), проставлю и проведу документа А вы что предлагаете?? проставлять левые значения, чтобы было?

это не "на сервере" передпроведением, а "перед монитором" передпроведением

(6,7) Садись, два. Параметр РежимЗаписи.

Синтаксис: ПередЗаписью(<Отказ>, <РежимЗаписи>, <РежимПроведения>) Параметры: ... <РежимЗаписи> Тип: РежимЗаписиДокумента. В параметр передается текущий режим записи документа. Позволяет определить в теле процедуры режим записи. Изменение значения параметра позволяет изменить режим записи.

А что, ОбработкаПроверкиЗаполнения уже не кошерно использовать?

ОбработкаПроверкиЗаполнения конечно же

(11, 12) А как в ней отличить простую запись от проведения?

Правильнее проверять перед записью, НО с проверкой: проводится ли при этом документ. Потому как если проверять/запрещать перед записью (и документ не проводится, а просто записывается), то у пользователя НЕ будет возможности начать делать документ, записать промежуточный (не до конца заполненный) результат  в базу, пойти пообедать, продолжить по возвращении ;)

если разрешено записывать с пустыми полями - то ПриПроведении если не разрешено - то ОбработкаПроверкиЗаполнения если требуется интерактивные действия - то предЗаписью в модуле ФОРМЫ

Почитать СП и понять что отличать ничего не требуется. Так как процедура вызывается при записи для документов, которым запрещено проведение и при проведении, если проведение разрешено.

а типовые в обработке проведения проверяют

Не надо брать пример со старых типовых. А новые уже проверяют в ОбработкаПроверкиЗаполнения. Правда с них тоже пример лучше не брать.

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

Проведение. Голосилку давай

Проверку незаполненности реквизитов формы нужно делать в событиях формы, желательно в проверке заполнения. Событие проведения у форм отсутствует.

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

Сама формулировка задачи "Проверка незаполненности реквизитов формы" подразумевает наличие формы, а значит, интерактивный ввод данных. ОбработкаПроверкиЗаполнения тоже, если что, сама по себе не работает, если записываешь объект программно.

хоть 1 пример приведи

вот от тебя-то и неожидал что ты не можешь пользовать в процедуре ПередЗаписью проверку на редим проведения

ОбработкаПроверкиЗаполнения не всегда применима. Например, при аккуратной доработке типовой или партнерской  конфигурации. Т.к. у реквизитов документа может не стоять признак ПроверятьЗаполнение. И в подписку на событие реквизит не попадет. Ставить признак самим - увеличивать геморрой при обновлении. А подписка ПередЗаписью отработает без проблем.

Тебе кто мешает самому в подписке добавить реквизит в массив ПроверяемыеРеквизиты?

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

Единственное, что нужно учитывать: при программной записи/проведения документа этот обработчик не вызывается (вызов нужно сделать самостоятельно методом  ПроверитьЗаполнение).

Я за "ОбработкаПроверкиЗаполнения"

Ага видел я это поведения в новых типовых. Теперь из-за этого бухи косячат по чёрному Раньше при проведении документа проверялся корректность договора, типа а принадлежит ли договор правильной фирме и контрагенту Сечас при групповом проведении программе пофиг, и спокойно проводит документы по "чужому" договору

Я за ОбработкаПроверкиЗаполнения. Проверять реквизиты при проведении - это быдлокод.

это во всяких 3.0 всё в форму перенесли?

ХЗ куда перенесли, но по в последних релиз при групповом изменении реквизитов отключены всякие контроли

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

Еще один неведающий о параметре РежимЗаписи. Также, как и про ОбменДанными.Загрузка, очевидно.

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

+1.. Почему бы не использовать??

считать себя умней других - сильно плохая привычка а по сути могу сказать что в 90% случаях про эти параметры забывают

>> а по сути могу сказать что в 90% случаях про эти параметры забывают Расшифруй. Это азбука из 8.0, на курсах на это обращали внимание еще 9 лет назад я еще не встречал спеца, который об этом не знает.

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

>>считать себя умней других - сильно плохая привычка В таком случае не поступай так, дружище. >>а по сути могу сказать что в 90% случаях про эти параметры забывают С каких это пор недостаток квалификации отдельных кадров влияет на правильность методики? >> да и зачем собственно их вставлять, если тот же код можно поместить в ОбработкаПроведения без всяких проверок К моменту проведения, уже завершился факт записи документа, факт его регистрации в последовательности, факт его регистрации в таблицах обмена, наложились соответствующие блокировки. При отказе потом это всё обратно восстанавливается. Зачем, собственно,всё это делать, если тот же код с проверками на режим записи можно поместить в "ПередЗаписью" и снизить нагрузку на систему, уменьшить время получения сообщения об ошибке на время бесполезного ожидания предоставления блокировки и повысить параллельность работы?

Проверки, выполняемые в и вне транзакции записи объекта 2.1. Проверки в обработчике ОбработкаПроверкиЗаполнения выполняются вне транзакции записи объекта. Поскольку в случае некорректного заполнения объекта выполнение операции будет прервано еще до записи объекта в базу данных, то размещение проверок в этом обработчике является наиболее эффективным. При выполнении внетранзакционных проверок в обработчике ОбработкаПроверкиЗаполнения необходимо учитывать тот факт, что новое состояние объекта еще не записано. Если требуется выполнить запрос к тем или иным данным системы, например, прочитать признак ВидНоменклатуры для товаров, выбранных в табличной части документа, "отталкиваясь" от данных документа, то такую поверку можно выполнить, применяя сохранение необходимых для запроса данных во временные таблицы. 2.2. В то же время, в обработчике ОбработкаПроверкиЗаполнения не следует размещать проверки, которые должны гарантировать целостное состояние объекта или зависящих от него данных (например, движений) на которые рассчитывает система. Поэтому для реквизитов, некорректные значения которых могут привести к рассогласованности данных в информационной базе, проверку корректности следует выполнять в обработчиках событий, возникающих в транзакции записи - ПередЗаписью, ПриЗаписи, ОбработкаПроведения (для документов). Для транзакционных проверок, в свою очередь, выделяются два случая: Проверка состояния движений, формируемых документами оперативного учета. Такие проверки довольно часто встречаются в приложениях с оперативным учетом. Проверка состояния других объектов информационной базы, ссылки на которых содержатся в текущем объекте. Такие проверки следует применять очень редко. Не следует злоупотреблять количеством проверок в транзакции записи объекта. Следует помнить, что внутри транзакции записи имеет смысл выполнять только проверки таких ресурсов или таких правил соответствия объектов друг другу, которые не изменяются без проверок всеми участниками процесса. В первом случае, проверку остатков некоторого ресурса имеет смысл выполнять в транзакции записи только в том случае, если все документы выполняют такую же проверку в транзакции записи. Если хоть один из документов, изменяющих ресурс, делает это без проверок, выполнение проверок другими участниками процесса бессмысленно и такие проверки необходимо выполнять вне транзакции. Исключением может быть только случай, когда документ, который выполняет изменение контролируемого ресурса без проверок, вводится крайне редко. Например, не смотря на то, что документ "Инвентаризация товаров" изменяет остатки товаров без проверок, эта ситуация допустима в виду того, что он вводится крайне редко. Каждое такое исключение из правила должно быть оправданным. Во втором случае, если при записи Подразделения в транзакции записи выполняется проверка, что сотрудник, выбранный в качестве руководителя подразделения, имеет должность "Руководитель", то при записи Сотрудника также должна выполняться и "встречная" проверка этого же правила: нельзя записать Сотрудника с должностью отличной от "Руководитель", если он указан руководителем того или иного подразделения. Поскольку правило, что "Сотрудник", выбранный руководителем подразделения, должен иметь должность "Руководитель", может быть нарушено как при записи подразделения, так и при записи сотрудника, то и проверка должна выполняться или в транзакции записи обоих объектов, или вне транзакции записи обоих объектов (а может и не выполняться вообще).

Нигде. В свойствах реквизита проверку установи.