Итак управляемая форма, на ней таблица. Необходимо запретить ввод некорректных данных в некую колонку. В методе ПередОкончаниемРедактирования(Элемент, НоваяСтрока, ОтменаРедактирования, Отказ) если пользователь не отказался от ввода делаем проверку и устанавливаем Отказ=Истина и выдаем предупреждение пользователю. Естественно возвращаемся в режим редактирования. После этого нажимаем Esc и вуаля - некорректные данные успешно внесены в таблицу. Что бы избежать данной возможности нужно всегда проверять на корректность данные, независимо от того отказался пользователь в от изменений или нет.

Как-то не логично это

а что за данные?

Не логично задра4ивать пользователя тупыми сообщениями.

Провел эксперимент. Всё работает нормально. Код покажи.

Проблема в коде (кодере)

Хот не вру. Если есть предупреждение, то есть косяк.

(0) "устанавливаем Отказ=Истина и выдаем предупреждение пользователю"
очищай значение при этом

А вообще, не надо пользователю ничего предупреждать пока он вводит в ТЧ что-то. Это раздражает.

Можно написать разные варианты обработки. Вот первый, который вроде бы должен быть по логике вещей:

Процедура ВыборкаПередОкончаниемРедактирования(Элемент, НоваяСтрока, ОтменаРедактирования, Отказ)
  Если Не ОтменаРедактирования Тогда
   Если Элемент.ТекущиеДанные.КОтгрузке>Элемент.ТекущиеДанные.ВРезерве Тогда
       Отказ=Истина;
       Предупреждение("Нельзя отгрузить количество, больше зарезервированного!");
   Иначе
       .... чего-то делаем или нет
   КонецЕсли;
 КонецЕсли;
КонецПроцедуры

Немного пояснений. Параметр ОтменаРедактирования=Истина - если пользователь отказался от редактирования. Логично ничего не делать в этом случае и система должна остаться в том виде, как и до редактирования. Как раз в таком варианте и происходит обман, о котором я и писал.

Если процедуру скорректировать на

Процедура ВыборкаПередОкончаниемРедактирования(Элемент, НоваяСтрока, ОтменаРедактирования, Отказ)
   Если Элемент.ТекущиеДанные.КОтгрузке>Элемент.ТекущиеДанные.ВРезерве Тогда
       Отказ=Истина;
       Предупреждение("Нельзя отгрузить количество, больше зарезервированного!");
   ИначеЕсли Не ОтменаРедактирования Тогда

       .... чего-то делаем или нет
   КонецЕсли;
КонецПроцедуры

То тогда не обойдешь.

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

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

(0) При вводе некорректных данных не делать отказ и не возвращать старое значение. И даже разрешить запись. Хочет 200 пусть будет 200.
Но если это неверное значение, то подсветить его красным. И запретить проведение. В проведение и выдать сообщение о проблеме.

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

(11) Много надумано. Юзеры тоже люди.
Ужасно бесят модальные сообщения по каждому чиху и запрещения на ровном месте.
Получив запрет при проведении, пользователи быстро поймут значение красной ячейки. Причем если много строк, то можно вывести под таблицей строку в которой будет написано, что есть ошибки.

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

(11) проще перед записью все ТЗ пробежаться по ТЗ и выдать одно сообщение типа "в строкеNN неверные данные"

(13) *всеЙ ТЗ

Люди дело говорят
особенно если учесть что ТС пытается контролировать
Если Элемент.ТекущиеДанные.КОтгрузке>Элемент.ТекущиеДанные.ВРезерве Тогда

т.е. если пользователь просто хочет ввести КОтгружке больше чем с текущих данных есть ВРезерве, то пользователя уже посылают
А рано. Может о просто готовит документ
И как раз к моменту проведения условие выпониться
И главное, что при проведении все равно проверять это же условие и все равно выдавать отказ в случае чего...

не нужно так делать, ТС

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

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

А устанавливать максимальное допустимое значение в ячейке ещё опасней.

+(18) Но в некоторых случаях так лучше.

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

1. В обработчике ПередНачаломИзменения запомнить значение реквизита.
2. В ПередОкончаниемРедактирования, при ОтменаРедактирования = Истина возвращать значение реквизита.

(21) - это уже как сделать через Ж, то что должно работать по-нормальному. Ведь начало поведения объекта - по уму. Если начать редактирование и вместо Enter жмем Esc - все работает так, как положено: ничего не вызывается, значение назад восстанавливается. И поэтому совсем непонятно почему при событии ПередОкончаниемРедактирования - не сохранить то же поведение. Ведь валидность ввода еще не прошла, и одно событие и другое равнозначно. Подозреваю по Esc работатет штатная процедура библиотеки ADO, а вот ПередОкончаниемРедактирования - это уже продукт и логика чисто 1С.

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

(22) Пиши в 1С

(10) Да не, иногда действительно важно проверить прямо при вводе данных. Помню, работала на мясокомбинате, там заказы операторы вводили не с листа торгового агента, а по телефону непосредственно от клиента. Клиент сказал - "Докторскую 10 батонов" и пошел дальше диктовать, а потом сразу повесил трубку, и не факт что у него есть телефон, чтобы ему перезвонить и сказать, что "Докторской есть только 5 батонов, может возьмете Молочной"?