Создаем новый документ, надо проверить - что это не дубль в рамках месяца по критериям
В каком событии кошернее?
При создании на сервере
Обработка заполнения
или еще где?

(0) перед запись

Ю

(1) это совсем уж крайний вариант
а то получится: пользователь создал, заполнил, потратил время, а ему - хрен тебе!

с другой стороны - пока реквизиты не заполнит, проверить нечего

(3) а при создании на сервере как себе это представляете?) Тогда при изменении показателей на форме, чтобы загоралась красная кнопка.

Перед записью, если  режим записи - проведение

+3 да и пофик с потерянным временем )) сам дурак значит

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

(8) тоже вариант

(4) Проверяй дергая с клиента сервер при изменении данных в полях контроля: Номер, Дата и что там еще.

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

(10)+ Затык только с номером документа, он при записи присваивается платформой

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

Дело, конечно, ваше. Но ни одна типовая так не работает

При начале редактирования ТЧ и перед нажатием кнопки "Подбор"

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

(13) >> ни одна типовая так не работает.

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

А по сути ответили уже в (10) и (8).
События формы и элементов:
1. ПриИзменении у всех тех элементов, отображающих ключевые реквизиты, по которым определяется уникальность.
2. (опционально, если надо) ПриЧтенииНаСервере формы, когда открывается форма уже созданного ранее документа.
3. ПередЗаписьюНаСервере формы. Нужно, если документ заполняется обработкой заполнения и события элементов ПриИзменении не отрабатывали.
События самого документа.
1. ПередЗаписью. На случай программного создания и заполнения документа.

Перед открытием формы предлагать заполнить в отдельной форме ключевые показатели. Дальше или переносить или материть

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

(18) Можно нагибать только когда юзер ввел достаточно данных и сделал паузу

(19): т.е. "ПередЗаписью", ммм?

(20) Не обязательно, просто когда сделал паузу во вводе данных.

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

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

(21)+ Точнее с цветами можно поиграться делать желтым когда юзер еще ничего не ввел или вводит, красное если проверка не прошла зеленое если прошла.
И момент что если не прошла и красное то как только юзер начал менять делаем желтым типа понятно что еще не проверялось.

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

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

(24) У вас заблуждение в том что юзер ничего не хочет "проверить" он хочет вбить данные и записать.
И у него будет легкий раздраж когда вместо записать получить "хер тебе" - иди вот туда далеко назад и там исправь что наколбасил не того.

Когда полей мало это ладно, но если данных было на много экранов и на разных вкладках то опс, юзер на разраба UI все маты сложит.

Потому что кнопка "Записать" никак не связана логически с действием "Проверить".

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

Хотя как выкинуть "Провести" я пока хз но думаю придумают.

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

(0) я в таком случае делаю отдельную форму с ключевыми реквизитами (3...5шт) после заполнения - проверка и сразу запись и открытие уже формы на дальнейшее редактирование

(13) Немного удивляют иногда такие моменты. Я для теста в КА2.4 накидал ордер на пересортицу, и немало так удивился, что фин. документ по пересортице делается вообще без какого-то контроля, я по ошибке сразу сделал два. Документы между собой никак не связаны.

Вставлю свои пять.

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

(25): ну.. ваше зацикливание самовыражения на "самдурак" вкупе с совершенно неверными представлениями о психологических нюансах и закономерностях лишний раз подтверждают, что 1) я, увы, прав; 2) вы, увы, с излишней самоуверенностью выдвигаете утверждения, касающиеся областей, в которых вы менее компетентны, нежели ваш собеседник; 3) доводы собеседника вы осмыслять даже не беретесь.
вышесказанное делает дальнейший разговор бессмысленным и скучным.
за сим - удач вам и здоровья.

Что будет если проверка стоит перед записью, и параллельно записываются два объекта? Ведь перед записью ни один из них еще не существует.

(31) Вот валит, гад

Вопрос - насколько критично наличие дубля?
Если нужно пернуть сообщением и интенсивность ввода мальникая - то перед записью проверка более чем достаточно.
А если прям алярм всебизнеспроцессы выстроены на уникальности и это ключ к учетной системе - то ручками ставим упр блокировки, возможно даже придется помоечный объект метаданных для этого сделать.

(31) (32) Реально завалил да.

Но проверка ПриЗаписи с блокировкой это дичайшие тормоза на больших объемах.
Но вероятно придется туда ее засовывать еще.

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

(0) 100%-й защиты от дурака не существует.

(33) у меня документ не проводится, по каким полям тогда блокировать?

(37) в при записи тогда пиши в это регистр свед

(37) Помоечный РС с накладыванием на него блокировки, можно физически даже не писать.

(39) Аможно и писать как господин в (38) предлагает

Где нить ПередЗаписью воткнуть блокировку на регистр, тогда конкурирующая транзакция встанет в ожидание.

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

(41) блокировка не нужна, ибо отлуп нужен сразу.
блокировка - это очередь

(43) Все остальные случаи не дают гарантии, вот в чем беда

(44) Без блокировки даст записать два одинаковых набора измерений?

(45) не даст, но это не значит что блокировки не будет

не, так усложнять не хочется

(46) Просто платформа ее сделает за тебя + куча промежуточных действий

возник побочный вопрос - удобно проверять заполнение реквизитов через ПроверитьЗаполнение()
а вот как избежать вывода сообщений этого метода? в описании ОбработкаПроверкиЗаполнения  чего то не нашел подходящего ничего

(47) делать надо сразу нормально

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

вместо блокировки данных лучше юзать
ЗаблокироватьДанныеДляРедактирования

но регистр для блокировки все равно нужен будет

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