Ошибка при вызове метода контекста (Записать) #487444

Пробую изменить данные в закрытом периоде с помощью своей обработки, под учеткой главбуха, под моей естественно работает, но под его выдает ошибку "Ошибка при вызове метода контекста (Записать): Операция не выполнена! Редактирование данных этого периода запрещено. Изменения не могут быть записаны...", вот код:

вопрос то в чем?!

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

Дай права, сделай, забери права.

То есть никакие режимы записи не помогут если нету прав?

сам то подумай, как пользователь сделает то что ему запрещено?

если период закрыт, то и нефиг там кому-то копаться и дрова ломать...

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

Другого способа нету?

Сделать обработку, в которой проверять кто запускает и игнорировать запрет на редактирование.

это не поможет... там подписка на событие...

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

попробую, отпишу как будет результат

Не согласен :( Любые программные ограничения(!) можно отменять/изменять программно же :)

Менять дату запрета изменения данных

для этого тоже нужны права...

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

Я тоже так думаю, но вот как это сделать? =)

ты можешь программно отключить подписку на событие?

+1 хочется код, если мона конечно =)

открыть период и менять

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

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

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

или она за себя не ручается? :)

Вот код который блокирует запись в закрытом периоде, если передать перед записью в парметре отказ Истина то запись все равно не происходит: Если принудительно поставить Если Истина Тогда то все нормально записывается, как передать туда Истина перед записью?

проверяй в начале процедуры после проверки на Отказ, Источник и ПравоДоступа и, соответственно, решай - делать Возврат или продолжать дальше...

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

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

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

(для затравки :)

упс :) "Игнорировать" --> "Исключение"

Благодарю, работает, но обратно границы не ставит, оставляет на том же месте.

ну дык верни взад...

взад не идет пишет ошибку: "Ошибка при установке значения атрибута контекста (ГраницыЗапретаИзмененияДанных): Несоответствие типов

ПараметрыСеанса.ГраницыЗапретаИзмененияДанных = Новый ХранилищеЗначения(СоответствиеГраницЗапрета, Новый СжатиеДанных);

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

минус мне, все работает

Как вариант:   ПараметрыСеанса.ГраницыЗапретаИзмененияДанных = Новый ХранилищеЗначения(Неопределено, Новый СжатиеДанных);

Сорри, с утра невнимателен - делаю ошибки.

нечего бывает, чего-то у меня снова не работает =)

Со второго раза работает =) сейчас разберусь что к чему тут.

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

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

Ок.

Подытожу сделанное. Работает только со второго нажатия, не удалось разобраться что в системе БП 1.6 такого удивительного происходит, что со второй попытки работает, мне думается дело в кэше. Вот код:

ЗАЧЕМ??? в прошлых платежах проставлять поступления?

зачем утруждаться читать весь топик???

смотри

как всегда, через задницу, делаете.

как всегда... а ты знаешь как сделать не через нее?

знает, даже не сомневайся. Вам, по всей видимости, нужен контроль - что поступило от контрагента после проплаты. Для этого видимо бух и хочет туда это вписать. Но это не очень удобно. Удобнее как-нибудь сообразить отчет (он даже может уже присутствовать в системе, например, отчет по взаиморасчетам), а не ковырять каждый раз прошлый период. И нагляднее  - можно сразу за период все посмотреть, да и гемора, при правильном подходе, меньше.

про этот отчет я вкурсе, он раньше использовался, но по нему не возможно узнать связь между поступлением ТиУ и платежкой, для этого в закрытом периоде нужно править платежки

че по дате не видно что ли?

+53 в конфу лезть лениво - неужели там нельзя получить связь по Контрагент - Договор между платежкой и поступлением, ну и далее по дате?

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

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

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