На случай, если в конфигурации есть какой-либо уникальный механизм. Все действо происходит в: Управление торговлей, редакция 11 (11.4.9.98)

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

Цель: какой-либо вариант контроля этих ключевых реквизитов, или иное решение проблемы.

Варианты, которые я вижу:
1. Возложить целиком и полностью справочник "СоглашенияСКлиентами" на плечи бухгалтерии и отобрать у оператора права на справочник.
Минусы: Время бухгалтера ценнее времени оператора. В справочнике помимо ключевых реквизитов еще много информации, и нагружать этим бухгалтерию - плохо.

2. Самопал под единичный случай:
- новый регистр сведений: для лога ключевых изменений, с жестко заданными измерениями и реквизитами.
 - новая подписка: на событие "при записи" справочника "СоглашенияСКлиентами"
 - проверка изменились ли ключевые реквизиты
 - в случае изменения ключевых реквизитов писать информацию в регистр
Минусы:
 - слишком костыльно и не универсально.
 - Если бухгалтерия увидит что подобное возможно, то в будущем будут добавлены аналогичные подписки, регистры сведений для контроля (например) ключевых реквизитов справочника "ДоговорыКонтрагентов", потом для номенклатуры и тд. В итоге будет создано по паре "регистр сведений + подписка" для каждого справочника (а мб и документа) с контролем изменений.

3. Решение "Фиксация данных" из флакона (https://infostart.ru/public/976048/).
Плюсы: что-то с замахом на универсальность
Минусы:
 - назначение решения - контроль за регистрами, а не за справочниками. (или возможно я просто не понял как правильно воспользоваться решением),
 - не полная универсальность,
 - требуется адаптация,

4. Написать свой механизм, который чем то будет похож на "Фиксацию данных" из флакона, но заточен под документы и справочники (мб и под регистры, но задач по контролю за регистрами в ближайшее время не предвидится)
Минусы:
 - время
 - очень большой шанс что нужное мне решение уже написано и выложено, но я его не могу найти

Вопросы:
1. Есть на инфостарте что-либо решающее мою проблему (готовая разработка, или просто описание механизма)?
2. Есть другие варианты, которые я не вижу?
3. Мб "Фиксация данных" из флакона решает мою проблему, а я не смог в ней разобраться?
---
Запихать в расширение доступность поля при открытии формы от какогонить права. Есть право доступно, нет права не доступно. типичный ковногод, но если сделать по уму то это жопа.
И вообще проблема больше административная. что значит иногда оператор меняет ключевые реквизиты
---
В итоге сделано почти так. Задачу "отслеживать изменения" в итоге свели к "запретить редактирование некоторых реквизитов...."
Сделано по образу и подобию БСП, используются её типовые возможности.

//При создании на сервере, после записи на сервере добавлен вызов
ЗапретРедактированияРеквизитовОбъектов.ЗаблокироватьРеквизиты(ЭтаФорма);

добавлены процедуры:
Процедура Подключаемый_РазрешитьРедактированиеРеквизитовОбъекта(Команда)
Процедура Подключаемый_РазрешитьРедактированиеРеквизитовОбъектаЗаверше­ние(Результат, ДополнительныеПараметры) Экспорт

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

 тогда версионирование , если оно предусмотрено....
---
Цель версионирования: просмотр изменения.
Моя текущая цель: видеть что изменения были и где они были (причем не все изменения нужны, а только определенных реквизитов). Т.е. то что есть версия в регистре версионирования, не означает что это интересующая нас ситуация (а данные по изменениям там хранятся в хранилище значений, и вытаскивать их оттуда как то пакетно - неправильно)
---
так вы хотите, чтобы вам приходило сообщение об изменении конкретного реквизита ?
---
не совсем. я хочу что бы был лог с измененными объектами за месяц. Вывести его потом - не проблема. Никаких сообщений никуда отправлять не надо
---
(7)какие то у вас взаимоисключающие параметры, то им можно менять в уже созданных, то нельзя.
версонификация полностью покажет вам что надо, что там в этих соглашениях кроме дней отсрочек поменяться еще может.
---
из шапки темы (т.е. меннять должен, но только после согласования):
"Оператор" не должен менять некоторые ключевые реквизиты (например отсрочка платежа) без согласования с бухгалтерией.

из 7 ответа: Хотелось бы не ограничивать доступность поля в уже существующих элементах справочника
из 11 ответа: Моя текущая цель: видеть что изменения были и где они были

Я нигде не говорил что нельзя изменять. Можно, и нужно! но только по согласованию. А что бы мы потом могли проверить что и где наменяли - нужен лог изменений ключевых реквизитов
---
В итоге сделано почти так. Задачу "отслеживать изменения" в итоге свели к "запретить редактирование некоторых реквизитов...."
Сделано по образу и подобию БСП, используются её типовые возможности.

//При создании на сервере, после записи на сервере добавлен вызов
ЗапретРедактированияРеквизитовОбъектов.ЗаблокироватьРеквизиты(ЭтаФорма);

добавлены процедуры:
Процедура Подключаемый_РазрешитьРедактированиеРеквизитовОбъекта(Команда)
Процедура Подключаемый_РазрешитьРедактированиеРеквизитовОбъектаЗаверше­ние(Результат, ДополнительныеПараметры) Экспорт

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

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

настройки хранении изменений
Соглашения об условиях закупок (например)
сохранять при записи

я что-то не очень уже понимаю :)
---
Там хранится каждый факт записи объекта.
Представим утрированную ситуацию:
1. Нас миллион элементов справочника "СоглашенияСКлиентами"
2. Каждый элемент справочника изменяется минимум раз в месяц
3. Изменений ключевых реквизитов справочника - всего 100 раз в месяц (нас не интересует изменение реквизитов типа "наименование")

Как итог: в регистре версионирования ДВА МИЛЛИОНА (каждый был записан дважды) за 1 месяц. А нас интересуют только 100 из этих записей.
---
тогда добавляйте событие в форме
 конкретного справочника (реквизита)

а действия , на какие уже фантазии хватит...
---
Это решение, но только под одну ситуацию.

2. Самопал под единичный случай:
- новый регистр сведений: для лога ключевых изменений, с жестко заданными измерениями и реквизитами.
- новая подписка: на событие "при записи" справочника "СоглашенияСКлиентами"
- проверка изменились ли ключевые реквизиты
- в случае изменения ключевых реквизитов писать информацию в регистр
Минусы:
- слишком костыльно и не универсально.
- Если бухгалтерия увидит что подобное возможно, то в будущем будут добавлены аналогичные подписки, регистры сведений для контроля (например) ключевых реквизитов справочника "ДоговорыКонтрагентов", потом для номенклатуры и тд. В итоге будет создано по паре "регистр сведений + подписка" для каждого справочника (а мб и документа) с контролем изменений

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

Если речь идет о уже записанном документе ,
 то открывать форму только для просмотра.
На форму добавить кнопку "Ввести комментарий"
 - она будет доступна.
При нажатии кнопки открывать диалог для ввода строки.
После окончания ввода передавать строку в комментарий и программно ЗАПИСЫВАТЬ документ - Записать(РежимЗаписиДокумента.Запись)

это к документу относится, но можете применить и к справочнику
я так понял с кодом у вас нет проблем , а у меня есть :)
---
Это вообще никаким образом не решает проблему. Либо вы не поняли что я хочу сделать, либо я не понял вас.
---
так вы хотите контролировать , изменялся ли реквизит
и если изменялся, эти данные записывать в определенную переменную
или сохранять в каком то файле ?

а потом или отправлять эти данные на почту :) сразу
или уведомлять периодически
или просто , чтобы она была.... ?
---
Вариант сохранения (если им будет удобно пользоваться) может быть любой: в файл/ в регистр и тд. Я пока придерживаюсь варианта сохранения в регистр, т.к. файл, письмо и тд может быть удален пользователем.
А вот регистр пользователь не сможет удалить, я ему прав не дам)
---
Надо определить сначала идеологию процесса, тут есть варианты
1) оператор может менять эти реквизиты, но только после согласования --- программная реализация этого не на одну неделю работы о)
2) оператору запрещено менять эти реквизиты --- в форме прописываем доступность и все дела
3) оператор может делать что хочет, но бухгалтерия должна получить отчет о сделанном достаточно быстро --- ну тут тоже можно придумать много чего
4) ее что-то?
потом уже реализовывать.
---
3) оператор может делать что хочет, но бухгалтерия должна получить отчет о сделанном достаточно быстро --- ну тут тоже можно придумать много чего
Я склоняюсь к этому варианту, и думаю как его реализовать / ищу готовое решение.
---
я б, пожалуй, завел бы регистр, при записи пишем туда измененные реквизиты. А бухгалтеру пишем отчет и открываем его при входе в программу например. Ну или по обработке ожидания. Не очень сложно, надо только обдумать, как отмечать уже просмотренные записи, чтобы отчет не рос бесконечно, а исключить из него то, что уже не актуально.
---
я б, пожалуй, завел бы регистр, при записи пишем туда измененные реквизиты. А бухгалтеру пишем отчет и открываем его при входе в программу например. Ну или по обработке ожидания. Не очень сложно, надо только обдумать, как отмечать уже просмотренные записи, чтобы отчет не рос бесконечно, а исключить из него то, что уже не актуально.

Это замечательное решение, если оно будет универсальным а не для одного конкретного случая. Что будет если потом надо будет аналогичный контроль приделать к допустим справочнику "ДоговорыКонтрагентов"? А будет либо усложнение структуры регистра для хранения изменений, либо создание второго регистра. Повторим N раз, и у нас засрана конфигурация)

Как сделать универсально, что бы все (или большинство) настроек производились в режиме предприятия, я пока не пойму. Курю решение "фиксация данных". У меня ощущение что оно либо может делать то что мне надо (просто я еще не разобрался как), либо очень близко к этому и его можно доработать/создать похожий механизм.
Там очень хорошо решен вопрос фиксации данных, но плохо с их обработкой/выводом. фактически ты просто открываешь регистр и смотришь в него.
---
а в чем проблема сделать универсальным? Сделать типы произвольными, процедура определения изменений универсальной делается легко, она и так будет универсальной, не вручную же перебирать реквизиты. Ну еще нужен будет список важных реквизитов, хранить его отдельно, в нем будут две колонки "Вид справочника" и "Имя реквизита".
Если заказчик все это готов оплачивать, то почему и нет, хорошая задача, несложная и небыстрая о)
---
Один регистр, одна подписка, и два определяемых типа.
---
Комментарий (38) так же и к вашему ответу
---
а в чем проблема сделать универсальным? Сделать типы произвольными

Падает скорость работы, база раздувается

процедура определения изменений универсальной делается легко
Да, делается. Про легко - не уверен.

Ну еще нужен будет список важных реквизитов, хранить его отдельно, в нем будут две колонки "Вид справочника" и "Имя реквизита".
Это будет ТЗ, жестко вшитое в конфигурацию? или это будет справочник?

я обдумываю подобное решение, но нюансов больше чем кажется.
1. Для текущей задачи мы контролируем только один реквизит
2. Для другой аналогичной ситуации нам требуется контролировать 5 реквизитов

Я согласен что это возможно) Сама тема создана для того что бы оценить варианты, выслушать мнение других людей
---
1. Произвольные типы бывают только на форме, в БД их не бывает. А скорость падает не от определяемых типов, а: а) от типов ЛюбаяСсылка и их составляющих СсылкаСправочник,СсылкаДокумент... б) неумения использовать в запросах ВЫРАЗИТЬ (КАК) для составных и определяемых типов.
2. Зачем тебе зашивать в ТЗ список реквизитов? Прелесть как раз в том, чтобы править регистр сведений с этими контролями из Предприятия.
3. И в чем проблема зашить в этот РС 5 реквизитов для одного объекта?
---
2. Зачем тебе зашивать в ТЗ список реквизитов? Прелесть как раз в том, чтобы править регистр сведений с этими контролями из Предприятия.

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

3. И в чем проблема зашить в этот РС 5 реквизитов для одного объекта?
А в следующем будет 6?)
Имхо, не хорошо закладывать фиксированное количество реквизитов. Это должно настраиваться
---
Кто сказал, что оно ФИКСИРОВАННОЕ? Ты разве в Предприятии не можешь в любой момент открыть форму списка регистра сведений и добавить в него ЛЮБОЙ количество реквизитов ЛЮБЫХ объектов, которые надо контролировать? Ну или наоборот - удалить, необходимость в контроле которых отпала.
---
Падает скорость работы, база раздувается
ну сколько таких записей будет, что мы уже начинаем оптимизировать скорость? За какой период мы их будем хранить? Там прям миллионы записей?

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

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

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

Может просто бухгалтера поменять?
1. А причем тут бухгалтер? Нарушает инструкции "оператор".
2. Уволить кого-либо не в моей компетенции)
---
Ну ведь задача стоит узнать, какие изменения были внесены БЕЗ СОГЛАСОВАНИЯ. Значит, в каком-то виде процесс согласования все-таки присутствует, пусть и не в 1С.
И вот когда-то, когда обнаружили косяк - начинаем читать лог изменений за последний квартал и вспоминать - что и в каком виде было согласовано, а что не было. Так?
Это же бред.
---
Ну ведь задача стоит узнать, какие изменения были внесены БЕЗ СОГЛАСОВАНИЯ. Значит, в каком-то виде процесс согласования все-таки присутствует, пусть и не в 1С.
Да, всё так.

Но для оптимизации затрат времени на все эти согласования схема следующая:
1. Запрещаем изменять без устного согласования (инструкцией по работе)
2. В 1с оставляем полные права на изменение объекта
3. Логгируем изменения ключевых реквизитов
4. Выводим список объектов с измененными ключевыми реквизитами бухгалтерии (скорее всего раз в неделю/месяц)
5. Бухгалтерия сама проверяет список и ищет те изменения которые были без согласования

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

что она там найти хочет, какие не соответствия
Например, график оплат.
---
Если оператор меняет графики оплат как ему вздумается что бы произвести отгрузку это АДМИНИСТРАТИВНО должно решаться, а не потом уже махать кулаками бухгалтера, что это вы отгрузили месяц назад фактуру когда был долг.
как и сказал если ничего кроме графика оплат как ключевой реквизит не меняется (а больше там и нечего менять) то версонифицирования более чем достаточно. Но всегда найдутся кто хочет изобрести велосипед
---
Как только я вижу "устное согласование", я понимаю, что кое-кто хочет позаниматься профанацией.
---
Сколько людей столько и мнений)

1. Не для каждого чиха требуется бумажка
2. Когда я говорил про "устное" согласование, то немного слукавил. т.е. его можно получить по почте/внутреннему мессенджеру/иным привычным путем - это остается за рамками рассматриваемой проблемы. Главное - отсутствие согласования именно в 1С.
---
Сообщение было скрыто модератором.
---
У оператора должны оставаться права на видимость и изменение этих реквизитов. Но, допустим в конце месяца, бухгалтер хочет видеть какие объекты меняла оператор, с целью выявить изменения без предварительного согласования.
Вариант - отдельный механизм для "согласования прямо в 1с", и потом разрешение на редактирование только после согласования. Но это лишняя механическая работа, развод бюрократии. Этот вариант имеет место на жизнь, но не в моем случае.