Привет!
Ребят, в модуле формы документа Перед проведением проверяю остатки, если остатков нет, хочу вызвать режим диалога, с вопросом уверен ли пользователь, что ему нужно провести. Но с серверной процедуру клиентскую вызвать не позволяет. Как быть?

(5) блокировка снимается автоматом при закрытии формы (правдо не совсем сразу, там может пройти пару минут)

(7) Упадет, а не закроется ))

(0) Своя кнопка "провести"

(6) +1

(8) разницы нет, сборщик мусора при отсутствии дискриптора убивает все переменные и блокировки, в самом плохом варианте блокировка будет жить до перезагрузки соответствующего рхоста

(9) а ты покажи реализацию этой своей кнопки :) и получится (2)

(12) Если честно то реализация в (2) так себе
Надо асинхронно делать и в фоновом

Т.е. запускается фоновое задание которое пытается провести, на клиенте через ОбработчикОжидания проверяет результат задания
Если все провелось то прекрасно

Если не провелось то выводим вопрос и в зависимости от ответа или останов или заново запускаем фоновое проведения уже с параметром пофиг на остатки
И ждем ответа

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

(15) ТС не сказал что у него розница, да в рознице есть с этим проблемы.

(2) Большое спасибо! Самый дельный ответ в моей теме) (4) Ребят, вопрос не в методологии, почему я там с остатками хочу дать провести, кому какая разница. Я вообще это для лаконичности написал. Вопрос как реализовать технически вызов диалога вопроса с сервера. И если нет варианта вызвать с сервера, то альтернатива какая?
Если интересно, что именно я проверяю, то я дорабатываю упаковочные листы, и мне надо проверить совпадает ли количество номенклатуры в таб части с таб частью документа основания, потому что пользователь может нечаянно удалить строку, замешкаться и не заметить. Надо ему напомнить, что количество отлично, и хочет ли он провести документ в таком виде. А вы тут начали умничать

(3) Согласен полностью, уже книгу скачал по упр формам, пока нет времени прочесть

(17) Идеология и методология 1С (и всех прочих клиент-серверных технологий кстати) что с сервера не надо вызывать клиента
Можно писать куда то (в хранилище по адресу) а на клиенте проверять периодически что там сервер записал

(14) в большой рознице вообще не нужно остатки проверять....

(13) у мня недавно в Ашан случай был:
понабрал полную тележку, все пропикали, картой оплатил, платеж прошел ....

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

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

(17) "умничать", да? мы тут делимся мнением, причем делаем это безвозмездно, а господин носом воротит? ну ок

(17) Хамишь, парниша

я бы тупо сделал галку на форме "Пофик на остатки всё равно проводи!" и не надо никаких заморочек с асинхронными вызовами фоновых заданий. Плюс такого подхода в том, что еще и останется аудиторский след

(22) полегше на поворотах, полегше.
это Миста, здесь вам не тут

(17) Это не дельный ответ, а говно
Дело в том, что, не поверишь, документ можно провести и не из формы
Поэтому единственно правильным вариантом будет тупо всегда не проводить документ, сообщая о причине
А если ты хочешь опциональное отключение проверки, то добавляешь булевский реквизит документа "НеПроверятьЧтоТоТамЧтоТыТамПроверяешь" и пользователь после того, как у него не получилось провести документ, ставит эту галочку и проводит документ с этой галочкой

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

+(26) Что в (24) и предложили

(27) Такой вариант вообще никем не рассматривается, кроме ТС
Речь о том, насколько корректно делать проверку на клиенте перед проведением

(29) на самом деле это старый старый вопрос из собеседований (был актуальный еще в 7.7), суть в том, что бы не повесить на вопросе открытую транзакцию и тем самым не заблокировать все.

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

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

(30) Я помню про этот "старый старый вопрос из собеседований"
Я не про фоновое проведение говорю, а про программное проведение или проведение из той же формы списка

+(31) За заблокированные в (2) остатки до тех пор, пока какой-то имбецил не нажмет ответ, вернувшись с обеда, программисту обычно выдавали пистолет с одним патроном и оставляли его одного в комнате

(29) это не на клиенте.
Это алгоритм взаимодействия клиента и сервера через одну точку входа и отгбражение запросов на клиенте.

(33) Что не на клиенте?
ПередЗаписьюНаКлиенте не на клиенте?

(17) У тебя возникнут проблемы, если ты хочешь поменять номенклатуру\количество в уже проведенном документе. Например, ты провел документ с кол-вом 5, потом изменил количество на 1 и задаешь пользователю вопрос. В этот момент у тебя на регистре уже есть старые проводки документа, где 5 штук списано. Как вариант делать в транзакции отмену проведения, получение остатков (с учетом блокировок, как в (2)), потом отменять тразакцию и возвращать пользователю результат проверки.

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

(0) Все же просто. Человек же на клиенте щелкает на кнопочку провести и наверное есть типовые процедуры/функции формы связанные с проведением. Вот там с клиента и запускайте свою серверную процедуру/функцию проверки остатков, возвращайте на клиент ответ. Если есть отрицательные остатки, то создаете вопрос, в оповещении продолжаете, либо отменяете проведение.

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

Автору уже писали что никак?

Уходите уже от семёрочной логики если хотите расти) Диалог - на клиенте, действия с базой данных - на сервере. Работа с формой желательно - на клиенте, серверный вызовы - желательно без контекста. Простые правила и будет вам счастье, сразу придёт понимание где что когда и зачем вызывать.

Без формы никакого диалога не будет. Обрабатывай соответствующее событие на форме\формах и задавай диалоги там.

(39) нет у него семерочной логики (Стаж: 28 дней) Просто ТС не понимает как устроено клиент-серверное взаимодействие на платформе.

(37) И ? Если есть отрицательные остатки , для чего выводить Диалог ? Нужно при отриц остатках вывести ПоказатьОповещениеПользователя ссылкой на отчет (с параметрами) - чтоб искал свои косяки в остатках.

(41) Это уже другой вопрос. Вы же не знаете специфику бизнес-процессов компании, мы принимаем за аксиому, что кому-то в их компании это нужно. Тут вопрос был, как с сервера задать вопрос, на что был получен развернутый ответ в (37) (39)

(42) Согласен .Специфично задавать вопросы при отрицательных остатках проводить или нет ))).

(43) еще специфичнее, пытаться сделать это на сервере)

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

(45) Да да . Ларьки . А потом ноуют у нас отрицательные , помогите спасите , обокрали

(46) Нифига, ни разу не ларьки, как наоборот, крупняк. Лучше разобраться потом откуда взялся пересорт, чем показаться перед клиентом ничтожеством и некомпетентом отказав ему в покупке того, что у тебя фактически есть в достойном качестве.

(46) наказывать за недостачи, премировать за излишки :)

Ого, сколько я всего пропустил...
Пообщаться с пользователем не так просто оказалось) ДиалогВопрос работает с ошибкой, Необходимо вызывать "Показать вопрос", а он отнюдь не простой) Но решение найдено, :

    Если ЗначениеЗаполнено(Объект._ДокументОснования) И ПараметрыЗаписи.РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
          
        //Проверим
        ВыполнитьПроверкуТЧПоДокументуОснования(Условие!);

        Если Условие! Тогда    
            Сообщение = Новый СообщениеПользователю();
                            
                //Чтобы отказать в проведении диалогом вопросом, есть такая конструкция: Сначала спрашиваем и отказываем в проведении, а после ответа
                                пользователя, проводим документ еще раз
                Если НЕ ПараметрыЗаписи.Свойство("ОтказатьВПроведении") Тогда
                    Оповещение = Новый ОписаниеОповещения("ПередЗаписьюЗавершение", ЭтотОбъект);
                    ПоказатьВопрос(Оповещение, СтруктураОшибок.ТекстОшибки + "Провести документ?", РежимДиалогаВопрос.ДаНет, 0,
                                                         КодВозвратаДиалога.Да, "Сверка с документом основания");
                    Отказ = Истина; // завершаем работу процедуры в самом ее зачатке
                Иначе
                    Отказ = ПараметрыЗаписи.ОтказатьВПроведении;
                КонецЕсли;
                
            Иначе
                Сообщение.Текст = СтруктураОшибок.ТекстОшибки;
                Сообщение.Сообщить();
                Отказ = СтруктураОшибок.Отказ;
            КонецЕсли;
        КонецЕсли;
        
    КонецЕсли;

А вот вызванная процедура оповещения:

Процедура ПередЗаписьюЗавершение(РезультатВопроса, ДополнительныеПараметры) Экспорт
    
    //Оповещение = Новый ОписаниеОповещения("ПослеЗакрытияВопроса", ЭтотОбъект);
    //ПоказатьВопрос(Оповещение, СтруктураОшибок.ТекстОшибки, РежимДиалогаВопрос.ДаНет, 0, КодВозвратаДиалога.Да, "Сверка с документом основания");
      ПараметрыЗаписи = Новый Структура;
    Отказ = ?(РезультатВопроса = КодВозвратаДиалога.Нет, Истина, Ложь);
        ПараметрыЗаписи.Вставить("ОтказатьВПроведении", Отказ);
        Записать(ПараметрыЗаписи);
    
КонецПроцедуры

Таки образом, сначала мы заранее отказываем в проведении (в процедуре ПередЗаписью - на клиенте), а потом вызываем вопрос. В зависимости от ответа, заполняем значение параметра записи. И Вызываем новую Запись документа с установленным параметром. При повторной записи, снова оппадаем в процедуру ПередЗаписью - там проверяем параметр записи, и решаем отказать или продолжить

(49) Многовато я вставил, вот суть:

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

                Иначе
                    Отказ = ПараметрыЗаписи.ОтказатьВПроведении;
                КонецЕсли;

(52)
Процедура ПередЗаписьюЗавершение(РезультатВопроса, ДополнительныеПараметры) Экспорт
    
    //Оповещение = Новый ОписаниеОповещения("ПослеЗакрытияВопроса", ЭтотОбъект);

    //ПоказатьВопрос(Оповещение, СтруктураОшибок.ТекстОшибки, РежимДиалогаВопрос.ДаНет, 0, КодВозвратаДиалога.Да, "Сверка с документом основания");

      ПараметрыЗаписи = Новый Структура;
    Отказ = ?(РезультатВопроса = КодВозвратаДиалога.Нет, Истина, Ложь);
        ПараметрыЗаписи.Вставить("ОтказатьВПроведении", Отказ);
        Записать(ПараметрыЗаписи);
    
КонецПроцедуры

(49) Зачем так сложно?
Можно же было проще:

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

Процедура ПослеЗакрытияВопроса(РезультатВопроса, ДополнительныеПараметры) Экспорт
    
    Если РезультатВопроса = КодВозвратаДиалога.Да Тогда
        ПродолжитьПроведение();
    КонецЕсли;
    
КонецПроцедуры

Мне вот интересно, нахрена некоторые что-то спрашивают на Мисте, если потом из всех ответов выбирают самое дебильное и делают самое трешовое

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

Чтобы было понятно,можно объяснить человеческим языком.
Представим,мы сидим за столом в кафе и делаем заказ официанту.
Мы что-то выбрали - официант это все записал на бумажку и отбыл на кухню (серверный вызов).
Там он пересказывает заказ поварам,и последние начинают его готовить.
Если чего-то нет,то официант возвращается за столик,чтобы мы внесли коррективы.

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

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

(57) Спецолимпиада между соседним столиком и скаканием официанта туда-сюда может продолжаться бесконечно. Тогда уж нужно ставить поваров на управляемую блокировку

(56) Да все проще на самом деле
Кто-то выбирает путь говнокодера, кто-то профессионала
И этот вектор определяет все остальное
Именно поэтому некоторые новички не выбирают говенные решения, потому что они может и не понимают клиент-серверной архитектуры и не способны написать правильный код, но они способны прислушаться и прислушиваются к советам более опытных коллег
А другим хоть на пальцах объясни, что это лютое дерьмище и почему, они один хрен будут лапками своими тараканьими махать "Сойдёёёт" и генерить лютое позорище

+(59) Радует, что такие говноеды редко прыгают выше сотки
Не радует, что говноедов таких как говна за баней, профессионалов хрен найдешь, даже за деньги

(59) Мне всегда казалось, что перфекционизм постепенно уходит с профессионализмом. Это не из личного опыта, я сам пока "расту" и стараюсь развиваться. Но по тем же друзьям из большого ИТ и что они рассказывают - часто кривое легаси не трогают, часто прикостыливают какую нибудь хрень лишь бы не поломать работающее, часто решают задачи за счёт производительности, но задача выполнена. Тут конечно море частных случаев и не везде так конечно...

Опять же наверняка слышал поговорку "лучшее - враг хорошего"?)

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

— Всё настолько глупо и непрофессионально, что работать практически совершенно невозможно. Невозможно понять логику непрофессионала.
— А может, он хитрый профессионал?
— Хитрый профессионал не поехал бы в приют. (пауза) Хитрый профессионал не поехал бы в приют, чёрт побери!!!

(61) Перфекционизм в своей крайности — это плохо
Ужасно, если программист 10 лет будет оттачивать свою первую и единственную обработку группового перепроведения документов
Но проблема в том, что говнокод — это другая крайность
Когда зачастую созданное "программистом" настолько непрофессионально, медленно, неэффективно, ненадежно, криво, убого, неправильно, что либо в лучшем случае дает мизерную эффективность, либо в худшем случае прямо сейчас требует или через непродолжительное время потребует выполнения задачи заново, чаще всего с нуля
Лебедев неплохо про это сказал https://blog.tema.ru/C0QpwyWd_32

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

(64) когда я учился в ПТУ, там был, блин, мастер. Он и стукал колотушкой по голове, чтобы все далали правильно

(65) Во некоторых франчах сейчас так же практикуют))) Да, PR?

(64) Я и не жду этого
Я жду, что между кучей говна и более менее приличным кодом котенок выберет второе

(66) Не знаю, в нашем все удаленно работают

(67) не выберет. У него нет интуиции. А интуиция - производная опыта

(69) Стремление к говнокоду или профессионализму — это врожденное
А что говнокод, а что хорошее решение, рассказали в ветке

Тут предлагают галочку на форме - тоже тот ещё костыль. Юзеру начхать на причину вопроса, он будет всегда эту галочку ставить и не будет разбираться в сути проблемы. У юзера не должно быть выбора, т к. любой выбор он всегда сделает в сторону "продать как-нибудь и наплевать на 1с", и будет по-своему прав. Нужно нормально бизнес-процесс выстроить, без вопросов в стиле: "А вы точно хотите продать или получить проблемы с покупателем?".

(71) не будет юзер всегда галочку ставить. Ему лень будет её ставить, если документ и без неё провелся

(71) Согласен
Просто не проводить документ
Хочешь провести без контроля — к админу или главбуху

(72) Особенно, если за эту галочку потом будут иметь в мозг или в кошелек

(71) Меня ещё с первой работы на семёрке "забавляли" диалоги с пользователями) Там директор на них настаивал. Буквально менеджер продаёт товар и ему вопросов и предупреждений 5: не забудьте распечатать чек! Поставить автоматические скидки? Предложить сопутствующие товары? и всё в таком духе))) Представляю как манагеры страдали)
А я ещё эту хрень автоматизировал на семёрке для "быстрых продаж". Везде как дурак программно код ответа подставлял по условию)

(54) Ну вот, тыж не подсказал вовремя! )) Спасибо. Записал себе

(55) А что вы посоветовали, товарищ? Где конкретный код? Или только языком лабать?

(25) Интересно, что ты удалил мое сообщение, но посмотри сколько говна из людей льется, ты это оставил. 90% этих выебо*щиков пыжатся и показывают свою крутизну друг другу. Особенно этот: (60) PR. А по делу ответили лишь единицы.

(77) Я предложил в (26), но по ходу ты даже поиском пользоваться не умеешь, так что не в коня корм

(76) Как раз вовремя и подсказал в (37). В (54) я на примере это показал

(80) За (54) в приличном обществе могут и морду набить и с волчьим билетом уволить
Я за похожее видел увольнение в 30 секунд

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

У себя в конторе и на своих проектах я бы такое реализовывать не стал, все должно быть автоматизировано без 100500 вопросов. Если товара нет, то нужно его отправить на обеспечение, отдел закупки уже работает по этому списку и т.д. Если это розница, то кассир в любом случае должен пробить товар, без 100500 вопросов.
Что там у ТС я хз, заранее написал как лучше сделать и описал как работает ПоказатьВопрос.

(81) Обосновывать свою позицию, конечно же, не обязательно)

Я, например, вообще яростный противник диалогов, если если это не вопрос жизни и смерти. Потому что пользователи один хрен их не читают, а сталкиваясь пару раз нажимают на автомате даже не задумываясь.
Но если в рамках ТЗ в рамках бизнес-процесса в конторе ТС это нормально - то почему бы и нет?.. Сомневаюсь, что ТС может и должен решать что не надо так делать.

Напомнило как я показал на одном собеседовании свою обработку, которая с одного ресурса бесплатно тащит порции по 100 запросов в день нужных данных как образец кода. На что мне заявили что это говнокод, потому что кто делает такую муда**ую архитектуру - ограничивать по 100 запросов, что за бред. Сцуко, это задача такая. Ну надо конторе получать эти данные и не хочет она платить. Оценивай реализацию задачи, а не постановку её) В этом плане я целиком на стороне Kassern :)

На мой взгляд в этом и есть коренное отличие одинэсника от фигня-кодера, что однинэсник может и должен влиять не только на реализацию, но и на постановку

(85) А так же иметь в голове несколько вариантов реализации задачи и предложить самый подходящий.

(82) Еще раз, есть две непреложные истины, независящие от бизнес-процессов компании

В транзакции любые вопросы пользователю неприемлемы

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

(84) Обоснование уже было раньше, в (87) еще раз, для тех, кому сложно прочитать ветку с самого начала

Круто, мой ник подсвечен золотым теперь!
(83) Все верно написал, мой вопрос был не методологическим, а технический

(79) Пишешь, что поиском пользоваться не умею, но я прочел твое решение, оно не подходит, потому что в теме - я описал про остатки лаконично. На самом деле я сверял количество по ТМЦ в документе Упаковочный лист, с количеством документа основания. Причем "ПоказатьВопрос" вызывается, только в том случае, если в Упаковочном листе Количества меньше, чем в документе Основания.

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

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

(85) Несомненно

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

(89) Не соглашусь
Потому что еще раз, провести документ можно не только из формы документа
Я бы так делать никогда не стал по куче причин

(85) 1сник - это что-то типа человек-айтишник? И комп собрать и винду поставить и домен поднять и скриптик написать и сайд забацать и самописку с функционалом ERP запилить?) Да не, можно, только зачем я всё это буду делать за 100-200, когда могу пойти в Java и делать только что то одно за 300? И, я хоть всё равно стараюсь развиваться, потому что не хочу быть линейным кодером всю жизнь, но требовать таких вещей от начинающих программистов, которые на форуме спрашивают технические вопросы - неправильно.

(91) Так я и говорю, что в данном случае на мой взгляд не та ситуация
И если уж это и проверять, то точно не в транзакции

(93) Он имел в виду разработчик и эникейщик
Что ты придираешься, как-будто не понял?

(94) Вот тут есть красивая табличка с началом транзакции https://infostart.ru/1c/articles/1175475/
Можно прикрутить это дело до начала транзакции со стороны формы, если ответ не положительный на вопрос, то даже и не начинать транзакцию

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

(96) Конечно можно, поэтому и странно, что ты этого не предложил сразу, а предложил говнорешение

(98) Так я и не уточнял, до в или перед транзакцией это запускать, еще раз подчеркну, я лишь написал, как технически реализуется ПоказатьВопрос

И явно указал, что это тема для формы и никак не связано с событиями МО при проведении

(95) Да я то как раз понял что вы оба в абстрактном 1снике видите эдакого архитектора, главбуха и сеньора в одном лице. И это меня удивляет, учитывая что PR связан с франчем, а FirstLineSupport как бы ник намекает что он работает в не в ларьке, и что там есть линии поддержки, то есть опять же разделение труда. Зачем тогда нужны консультанты, архитекторы, ведущие программисты, если каждый линейный кодер и стажер обязаны знать все механизмы, все стандарты разработок, всю методологию и бизнес-процессы?

Посмотри на тон, в котором ты пишешь в (81). Да я понимаю, что с юмором, но со стороны похоже на хамство) Да и вообще Татьяныч-стайл "то говно, это говно". Ну так ругай компанию 1с тогда, что останавливаться - это ведь они в принципе добавили возможность вести диалог с пользователем)))

(98) А вот ТС реализовал, как раз так как вы пишите, сначала отменяет транзакцию, задает вопрос, а потом заново записывает документ, что имхо криво.

Вот это расшевелила моя тема форумчан - 100 ответов. И лишь два по делу (54) (2), не считая моей реализации (52)!  
Ладно, все тут поняли кто есть кто. Давайте закончим, решение есть)

Согласен

(101) Просто не перевариваю, когда говнокод подается с уверением, что это прекрасное решение

(102) Где, блеать, я так пишу?