Как при вводе на основании перед вводом проверить документ основания на изменения или принудительно записывать перед этим ?

Основание = ссылка, не объект. Так что imho лучше записывать, разумеется.

Вынос мозга какой-то. А запятые никак не расставить?

(2) хм.. а не нужны. слова переставить надо бы, да

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

(3) парочку я бы поставил.

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

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

Вот как раз и надо поставить защиту от дураков )

Fish правильно говорит, ну заставишь ты го записать, создаст он, а потом он возьмет и опять поменяет. Он же "дурак" (с).
Будешь добавлять проверку, а не создан ли на основании, и не давать менять цену? :)

Это уже отмазки )))

Задача все равно осталась не решенной )

Можно так попробовать исхитриться - по ссылке получить форму. Это будет открытая форма документа основания (можно для очистки совести проверить на Открыта()).
После этого проверяешь модифицированность и делаешь что хочешь. Или грозно ругаешься или принудительно записываешь.

(7) Опыт показывает, что на любую защиту найдётся дурак, который эту защиту обойдёт, либо не заметит :)). А загромождать конфу лишними проверками - только тормозить работу базы.

Я не против каких-то примитивных проверок, но, имхо, не зря в типовых такая проверка не реализована. Человек, работающий с документами должен понимать что он делает. И нести ответственность за неправильный ввод данных.

А твой вопрос - это попытка решить административные вопросы техническими методами.

(11) + Я недавно подобным макаром одну хотелку реализовывал - чтобы после проведения дока на основании автоматом закрывалась форма документа-основания :)

Форма = Основание.ПолучитьФорму("ФормаДокумента");
Форма.Модифицированность() //говорит правду

проверять в ПередОткрытием формы

а если несколько открыто форм )))

(9) Это не отмазки, это реальный опыт. Видел я конфы, в которых были попытки внедрить подобные "защиты от дурака". Документы там открывались и записывались по 5 минут. И всё равно находились идиоты, которые умудрялись сделать что-то, не предусмотренное этими защитами. Так что правильнее просто написать инструкции по вводу на основании и всем пользователям раздать её под подпись.

(6) Зато у документа вводимого на основании есть событие "ОбработкаЗаполнения", а в типовых конфигурациях есть пример как организовать процедуру проверки модифицированности: при печати из формы проверяет и записывает.
(14) Можешь получить другую форму. Ответ "нет".

(14) Лучше еще Открыта() проверяй на всякий случай.
(16) Несколько форм одного дока можно открыть только спецом задавая ключ уникальности.

а несколько форм не может быть открыто, в общем:


Процедура ОбработкаЗаполнения(Основание)


       
       Форма = Основание.ПолучитьФорму("ФормаДокумента");
       Форма.Модифицированность();
   

КонецПроцедуры // ОбработкаЗаполнения()

будем считать что работает )
всем спасиба

(18) "Можешь получить другую форму. Ответ "нет"."
Подумал, СП почитал, прежде чем отвечать?

согласен с (19)

(21) и подумал и почитал

(20) Что будешь делать, чтобы запретить менять цену уже после ввода на основании? Допустим я записал док, ввел на основании другой, и в первом поменял цену. Что тогда?

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

(25) Так ты не понял. Я меняю основание СРАЗУ ПОСЛЕ создания подчинённого дока. И в чём смысл твоей проверки тогда? Она никак косяк не исключает.

(24) А в чем сложность? Элементарно же делается.

(25) Отмазки. Естьт возможность создать документы с разной ценой? Есть. Задача осталась не решенной ;)

(27) Напиши как?

(29) Проблема, как я понял - залочить данные еще открытого документа-основания после проведения документа на основании? Мы об этом говорим?

(30) Не совсем. Проблема немного глубже. Как исключить возможность различных данных в документе-основании и подчинённом. поверь мне, она конечно, решаема, но требует кучи проверок как при открытии, так и при вводе на основании и записи. Мы как-то такое реализовывали. И всё равно находились умники, которые умудрялись накосячить.
простой пример: Есть док основание. Я его записываю, нажимаю кнопку "ввести на основании". НЕ записывая подчинённый документ, меняю док-основание и после этого записываю подчинённый. Есть и другие варианты обхода. Как ты их все разрулишь и предусмотришь?

(30) А если поменяет До проведения ? -) Ну нажал, открылась вторая форма - переключился назад, поменял. Опа.
Лочить сразу при вводе на основании? А если он окажется от ввода (закроет окно)? При закрытии разлочивать, если без проведения? А если создаст на основании, закроет пред окно, снова откроет? Открыто будет доступны (введннного на основании еще нет(не записан)) И тд, и тп

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

(31) Количество вариантов которые нужно "зарезать" вполне себе конечно. Ничего военного на самом деле. Назови "незарезываемый".

(34) Никто не говорит, что оно бесконечно. Но если у тебя на основании одного дока может быть введено 10 подчинённых, тогда все эти проверки "на дурака" начинают серьёзно тормозить процедуры проведения. Особенно когда работает 150 человек и одновременно проводит кучу документов.

(31) (33) +100500. Когда работал с 1с еше как пользователь, сломал нечаянно хитромудрую защиту на доступ к папке, потому что не знал, что там есть защита)))

(33) Это совершенно отдельная тема. Ессно любая система должна быть разумно сбалансирована в плане защиты от дурака. Далеко не всегда имеет большой смысл резать все ошибочные варианты, если результат ошибки несложно и своевременно выкупается. Но относительно частые промашки пользователей всегда имеет смысл нейтрализовать программно.

(37) к (35)

(37) Вот поэтому ТС и надо подумать, а стоит ли делать эту проверку в принципе :)))

З.Ы. Как резюме: чем проще система, и чем меньше в ней подобного рода "проверок", тем более безглючно и надёжно она работает. Гораздо эффективнее учить пользователей правильно пользоваться программой.

Это уже его проблемы. Мне было интересно чисто технические моменты обсудить :)
А защита от дурака часто слишком завязана на конкретную специфику, чтобы можно было общие рекомендации плотно задвигать...

(40) щетаю, защита от дурака должна присутствовать.

(41) Это были общие рекомендации применительно к конкретному случаю. Задача в (0) решаема, конечно, но очень долгим, громоздким и затратным с точки зрения производительности способом. А все те способы, которые здесь предлагались, проблему в (0) не решают.

(43) "защита от дурака" всегда громоздка, затратна и объемна как по времени так и по коду.

А вся то байда - запретить одновременно открывать более одной формы документа основания, и при создании подчиненного документа запретить изменение основания. Блокировать объект при СозданииНаСервере. Перед этим проверять мож кто другой его заблокировал. В обработкезаполнения подчиненных теже проверки. (ИМХО)

(45) Почитай внимательно (32). Подумай ещё :))

(46) Подумал. Ввожу на основании, при заполнении подчиненного беру объект который принадлежит вызвавшей форме (она, как помним, одна в этот момент времени), проверяю модифицированность, записываю (провожу) основание, взвожу флаг запрещающий менять объект основание. Все, вопросы "Вы хотите записать/провести основание" добавить по вкусу.

+(47) вернулся он в форму основания, а ему "фиг поменяешь".

Задача вполне решаемая, причем малой кровью.

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

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