Запрет редактирования после ввода на основании
Уважаемые Коллеги!
Возникло ТЗ на запрет редактирования табличной части, если при вводе на основании в документе есть позиции из заказа покупателя из резерва. Немного предыстории. Наши доблестные продажники, дабы ускорить процесс удаляют "из резерва" и документ "заказ покупателя" из табличной части после ввода на основании и ставят списание "со склада" в итоге резерв зависает на долгие годы. дабы они не могли редактировать,поступило ТЗ на запрет.
Пока что не понимаю в какой части документа этот запрет ставить: Из формы или из модуля и как это можно реализовать максимально коротким кодом. Обычные формы КА 1.1
Возникло ТЗ на запрет редактирования табличной части, если при вводе на основании в документе есть позиции из заказа покупателя из резерва. Немного предыстории. Наши доблестные продажники, дабы ускорить процесс удаляют "из резерва" и документ "заказ покупателя" из табличной части после ввода на основании и ставят списание "со склада" в итоге резерв зависает на долгие годы. дабы они не могли редактировать,поступило ТЗ на запрет.
Пока что не понимаю в какой части документа этот запрет ставить: Из формы или из модуля и как это можно реализовать максимально коротким кодом. Обычные формы КА 1.1
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(7)перед записью получить текущее состояние документа в бд, запомнить их, а при записи эти данные сравнить с записываемыми и если есть разница по тем данным, которые пользователь не имеет право вносить изменения вызвать исключение и показать пользователю кукишь)
(8)А кто мешает пользователю до записи внести изменения? В БД пусто - сверка прошла, а товары остались в резерве. Программист виноват. Все, конечно, решается правильной мотивацией менеджера если он зарезервировал и продал не из резерва бить по самому больному месту. По кошельку.
(14)а вам при записи нового документа надо с чем-то сравнивать? а зачем? на дубли проверять? Если это новый, то зачем его сравнивать, если он по логике ничего не нарушает или нарушает? Я вашего ТЗ вообще не знаю, для меня вы тут вообще сторонний человек в этом топике и я не уверен завязан ли ваш вопрос с вопросом тс или вы свою линию гнете. Посмотрите как реализовано в УТ 11 проведение документов, там в регистре накопления весит функционал до и после записи с помещением данных во временную таблицу, а потом в менеджере записи документа осуществляется контроль на основании этих данных. Вы можете и дубли проверять, только грамотно настройте и будет вам счастье. Нет, тогда тут было много предложений по поводу подписки на события, права и так далее. Вариантов масса.
А что им помещает тогда просто распровести документ? Раз у них есть право его редактировать и перепроводить, значит есть право и распровести.
Как по мне можно это сделать на форме в событие при создании на сервере, если идти согласно тз, то проверять это условие и вставлять тз значение толькопросмотр в истину.
А если есть вероятность, что они могут тогда в таком случае распровести документ, тогда я бы посмотрел в сторону ролей доступа и прописал бы условие туда, запретив им изменение документа, если отработает условие. Пусть вводят изменения и ловят ошибку при попытки провести документ, злятся, что потратили время зазря, но хотя бы запомнят, что надо думать, когда что-то подобное собираешься делать. В таком случае надо учесть, что пользователи могут не понять почему не так и могут начать звонить, если хочется это пресечь, то тогда дополнить ошибку описанием, допустим, в процедуре передзаписью.
Как по мне можно это сделать на форме в событие при создании на сервере, если идти согласно тз, то проверять это условие и вставлять тз значение толькопросмотр в истину.
А если есть вероятность, что они могут тогда в таком случае распровести документ, тогда я бы посмотрел в сторону ролей доступа и прописал бы условие туда, запретив им изменение документа, если отработает условие. Пусть вводят изменения и ловят ошибку при попытки провести документ, злятся, что потратили время зазря, но хотя бы запомнят, что надо думать, когда что-то подобное собираешься делать. В таком случае надо учесть, что пользователи могут не понять почему не так и могут начать звонить, если хочется это пресечь, то тогда дополнить ошибку описанием, допустим, в процедуре передзаписью.
Если документ новый, то первоначальную таблицу нужно где-то запомнить при вводе на основании и перед записью сверять с табличной частью документа. Если не новый, то можно перед записью сравнить табличную часть объекта и ссылки. Либо действительно блокировать поля по условию при открытии.
я бы сделал подписку на событие записи документа реализация
если строка из реализации совпадает со строкой заказа
и в заказе "резерв"
а в реализации "со склада"
то разрешить только запись
а проведение реализации запрещать
с комментарием (используйте резерв мерзавцы !!!)
если строка из реализации совпадает со строкой заказа
и в заказе "резерв"
а в реализации "со склада"
то разрешить только запись
а проведение реализации запрещать
с комментарием (используйте резерв мерзавцы !!!)
(0) а еще для упрощения
также после записи можно проверить зависшие резервы
и писать в Регистр Сведений
кто создал реализацию и какой резерв остался
сообщение пользователю с требованием исправить
А вечером письмо боссу с жалобой и требование наказать... если резерв не снят
это конечно побольше писать
но результат будет "сочный"
также после записи можно проверить зависшие резервы
и писать в Регистр Сведений
кто создал реализацию и какой резерв остался
сообщение пользователю с требованием исправить
А вечером письмо боссу с жалобой и требование наказать... если резерв не снят
это конечно побольше писать
но результат будет "сочный"
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот