gifts2017

Стандартные доработки. Запрет изменения документов “ЗаказовПокупателей”, по которым есть движения.

Опубликовал Олег Молочников (milkers) в раздел Программирование - Практика программирования

Стандартные доработки.  Запрет изменения документов “ЗаказовПокупателей”, по которым есть движения.

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

Молочников Олег Spb. 2011.

Стандартные доработки.  Запрет изменения документов “ЗаказовПокупателей”, по которым есть движения.

 

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

 

1.       В Общий модуль ”Полные права” добавьте следующую функцию:


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

   
Запрос = Новый Запрос();
   
Запрос.УстановитьПараметр("ЗаказПокупателя", ЗаказПокупателя);

   
ТипЗначения = ТипЗнч(Документы.ЗаказПокупателя.ПустаяСсылка());
   
Счетчик=0;
    Для Каждого
РегистрНакопления Из Метаданные.РегистрыНакопления Цикл
        Для Каждого
РеквизитРегистра Из РегистрНакопления.Измерения Цикл
            Если
РеквизитРегистра.Тип.СодержитТип(ТипЗначения) Тогда
                Если
Счетчик>0 Тогда
               
Запрос.Текст = Запрос.Текст + "
                |ОБЪЕДИНИТЬ ВСЕ
                |"
               
КонецЕсли;
               
Запрос.Текст = Запрос.Текст + "
                |ВЫБРАТЬ
                |   ИСТИНА
                |ИЗ
                |   РегистрНакопления."
+ РегистрНакопления.Имя + " КАК " + РегистрНакопления.Имя + "
                |ГДЕ
                |   "
+ РегистрНакопления.Имя + "." + РеквизитРегистра.Имя + " = &ЗаказПокупателя
                | И "
+ РегистрНакопления.Имя + ".Регистратор <> &ЗаказПокупателя
                |"
;
               
Счетчик=Счетчик+1;
            КонецЕсли;
        КонецЦикла;
    КонецЦикла;
    Возврат НЕ
Запрос.Выполнить().Пустой();

КонецФункции

2.      В  модуль  формы документа в текст функции ”ПриОткрытии()” добавьте следующие строки:

  Если ПолныеПрава.ЗаказыПокупателя_СуществуютСсылки(Ссылка) Тогда
       
ЭтаФорма.ТолькоПросмотр=Истина;
    КонецЕсли;

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Олег Молочников (milkers) 07.04.11 13:16
Стандартные доработки. Запрет изменения документов “ЗаказовПокупателей”, по которым есть движения.

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


Перейти к публикации

1. Eugeneer (Eugeneer) 07.04.11 13:16
А зачем так много????? Документ.Проведен уже перестало работать?
Если док проведен по нему уже есть движения. Зачем делать выборки?
2. Eugeneer (Eugeneer) 07.04.11 13:20
Тремя строчками все делается....


В модуле ПриОткрытии есть участок

Если ЭтоНовый() Тогда
лялялял
Иначе
КонецЕсли;

После иначе это значит открыт существующий док! Туда ставится условие по проверке проведенности документа и всё!.
Три строчки. Зачем делать выборки движений ?
3. Eugeneer (Eugeneer) 07.04.11 13:22
А задним числом всегда регулируется датой запрета редактирования. Чтобы юзеры не лазили и не правили доки задним числом http://infostart.ru/public/58415/
4. Eugeneer (Eugeneer) 07.04.11 13:27
"Это позволяет предотвратить часть ошибок, возникающих из-за действий пользователя задним числом." и где решение проблемы? При исправлении задним числом ошибки лезут не из за доступа, а из за того что человек не отследил до конца цепочку. Ая заявки часто - зыбыли коммент дописать, не на того контрагента, не та цена, еще что то не то. Очень часто мелочам.

Ошибки задним числом не из за редактирования происходят. Если нужно исправить по факту - то нужно! И для этого есть дата запрета и ГБ которая разрешает что то исправить по наличии служебки.

И уж если контролировать что то - то табличную часть! Вот у меня пример:

/Мания1С
Если РольДоступна("дкМенеджерПродаж") ИЛИ НЕ РольДоступна("дкКладовщик") Тогда
//ЭлементыФормы.Контрагент.Доступность = Ложь;
Если СостояниеСборки = Перечисления.СостоянияСборкиЗаявок.ОтданНаСборку
ИЛИ СостояниеСборки = Перечисления.СостоянияСборкиЗаявок.СборкаЗавершена Тогда
ЭлементыФормы.Товары.ТолькоПросмотр = Истина;
КонецЕсли;
КОнецЕсли;
5. Сергей Ожерельев (Поручик) 07.04.11 13:33
Про программное изменение заказа (какой-нибудь обработкой, например) забыли оба. Надо добавить соответствующий код или в модуль объекта или в подписку на событие.
kuza_87; Androsovych; +2 Ответить 2
6. Eugeneer (Eugeneer) 07.04.11 13:50
(5) программное изменения заказа - это конечно супер. но такие вещи делает обычно программист-специалист. Если в руках у юзера есть обработки изменения - то это жесть.
А по поводу того что автор модифицирует программу, когда все регулируется датой запрета редактирования - это конечно ужас.
Еще хуже то какой он выбрал метод проверки проведенности документа и вдобавок - запрет заказов в текущем дне...В текущем то дне зачем обрезать? заявки в течении одного дня могут неоднократно корректироваться. Для этого есть оперативный режим проведения. И работает он замечательно.
Это называется высосали проблему с пустого места (там где её нет).
7. Олег Молочников (milkers) 07.04.11 13:58
(1)(2) Отслеживается не проведение этого документа а наличие ссылок на этот документ в проводках других документов.
(3) Дата запрета редактирования не отменяет необходимость запрета редактирования сегодняшнего заказа, если на основании этого заказа сделаны другие документы, например реализация.
Пусть сначала распроводят реализацию, потом правят заказ.
(4) Есть и другие важные реквизиты, которые м.б. нельзя менять (Например договор). Их состав строго индивидуален. В примере, для простоты, блокируется все.
(5) Наличие программных изменений для меня уже форсмажер. С таким я разбираюсь индивидуально.
8. Eugeneer (Eugeneer) 07.04.11 14:04
(7) ну вот это уже совершенно иначе смотрится чем основное описание.
9. Олег Молочников (milkers) 08.04.11 13:06
(8) Ну, несмотря на объяснения, плюс ты все равно зажал. :D
10. Eugeneer (Eugeneer) 08.04.11 13:09
11. Ярослав Юнка (y22-k) 08.04.11 16:20
Подпиской не судьба сделать?, а по поводу доступности кнопок, Ест дата запрета
влеплю минус.
Корежить типовую там где можно без этого обойтись.
12. Олег Молочников (milkers) 08.04.11 16:41
(11) По поводу подписки. При групповой обработке заказов покупателей это очень сильно замедлит работу системы. Данный дополнительный контроль актуален именно при ручной попытки изменить документ. Так, что забирай минус обратно :D .
По поводу даты запрета: Дата запрета редактирования не отменяет необходимость запрета редактирования сегодняшнего заказа, если на основании этого заказа сделаны другие документы, например реализация. Пусть сначала распроводят реализацию, потом правят заказ.
13. Ярослав Юнка (y22-k) 08.04.11 17:33
(12) Очень Сильно Это сколько?
Можно просто настроить автоматическую синхронизацию ЗАКАЗ - РТУ или в обратную сторону. или использовать Схему ЗАКАЗ - Корректировка -РТУ
14. Олег Молочников (milkers) 08.04.11 17:47
(13) Зависит о количества строк в документе и количества документов сделанных на основании этого заказа или документов имеющих резерв по этому заказу. Но в большой базе даже простейшее групповое изменение всех заказов может занять несколько суток, так как для каждого заказа он будет динамически строить запрос по всем регистрам накопления и время выполнения каждого запроса может достигать нескольких секунд. В совсем огромных базах мой алгоритм (без изменений), возможно, будет излишне замедлять даже открытие одного заказа.
15. Олег Молочников (milkers) 08.04.11 17:49
(13) А на счет автоматической синхронизации, никак не могу понять, что Вы имеете в виду.
16. Александр Синцов (Sintson) 13.04.11 09:46
Решали подобную проблему, Ваш вариант очень замедлит работу системы, особенно в части групповой обработки данных, а также, как показывает опыт на больших базах часто возникают коллизии при таком подходе.
Подобным уже откомментировали, оказывается, так что не пинайте.
17. simuljakr (simuljakr) 14.04.11 09:26
(16) А как Вы решили подобную проблему, если не секрет ?
18. Олег Молочников (milkers) 14.04.11 10:23
(16) Так как вы не указали кому конкретно вы отвечаете, повторюсь что моя реализация ни как не повлияет на групповую обработку, так как реализована в момент интерактивного открытия пользователем формы. Рискну предположить, что и коллизий мой метод вызывать не должен.
19. Александр Синцов (Sintson) 14.04.11 17:36
(18) Прошу прощения, я не разобрался в какой момент времени вызывается тотальная проверка на движения документа.

(17) Запретили изменять проведенный документ пользователям без полных прав.
20. Олег Молочников (milkers) 14.04.11 17:54
(18) Этот вариант хуже, так как на этого пользователя сваливается дополнительная нагрузка.
21. Михаил Иванов (wwizard) 29.02.12 23:26
22. zaebunga (1c-intelligence) 30.08.12 10:32
Способ хорош простотой своей реализации, но есть ряд вопросов/предложений:

1. ЭтаФорма.ТолькоПросмотр = Истина оставляет доступными некоторые кнопки на командных панелях. Например, кнопки заполнения ТЧ. При этом документ удастся записать, т.к. при закрытии форма спросит "Записать?";
2. Если типовое решение используется нормально, то используются также документы "КорректировкаЗаказаПокупателя", "ИзменениеЗаказаПокупателя". С их помощью удастся внести изменения.
3. Часто есть потребность менять какие-то реквизиты документа или его ТЧ, не меняя при этом содержательной части (комментарий, ответственный, напомнить о событии, подразделение, дата оплаты и т.д.). Ваш метод такие изменения тоже запретит.

Я делал подобное для заказов поставщику, там было так:
1. Подписка ПриЗаписи для регистра накопления ЗаказыПоставщикам (ПриЗаписи, потому что записываемый набор уже в БД и читается запросом);
2. В обработчике подписки просто проверяются остатки регистра по этому заказу.
3. Если остатки отрицательные, ставится Отказ.

В чем смысл:
1. Работает от любого документа (сам заказ, корректировка, ПТиУ, и т.д.);
2. Контролирует как обычное превышение, так и расхождение аналитики (как правило - цена или ставка НДС). В заказе цена стоит 100 р., в ПТиУ указали 101 - все, система фиксирует отрицательный остаток, т.к. контроль идет по всем измерениям;
3. Можно менять любые реквизиты документа, запретов нет - но при проведении выполняется контроль. Т.е. пользователь наколбасил что-то, пытается провести, а ему сообщение выходит, типа вот по такому набору полей у тебя превышение.
4. Пользователь может увеличивать объемы в заказе, т.к. превышения при этом не возникает. Но это считается нормальным, т.е. нет смысла это запрещать.

Такое же решение работает для заказа на производство и внутреннего заказа. По заказу покупателя не делал, т.к. потребности не было.
Polzavatel; katavyjob; kuza_87; sergos3331; +4 Ответить
23. Gosha Ivanov (Polzavatel) 25.03.14 08:46
Подскажите, как запретить в "Реализации товар и услуг" изменение Менеджерами (роль) документа, если в статусе документа кладовщик (роль) установил статус "Отгружен".
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа