[Mkk]

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

[dobraleks]

.. написал в личку..

[MATEVI]

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

А чем ЗаписьЖурналаРегистрации() не устраивает? И монитор?

Замечание:
Системой зарезервирован большой перечень типов событий/события. Незарезервированные имена позволяют пользователю фактически указывать свои собственные типы событий и события. Подробнее см. в документации гл. ''Системные процедуры и функции''.

[Fynjy]

Если база SQL вешаем тригер на изменение таблицы SQL и пишем логи в отдельную дополнительную таблицу ...
[необходимо зарегистрироваться для просмотра ссылки] пример при помощи платной приблуды ToySQL.

[Fynjy]

Уже бы рисовали на 8 самописку ... Все было бы проще ...

[Batchir]

Уже бы рисовали на 8 самописку ... Все было бы проще ...

Это точно, а из УПП выцепить участок версионирования.

[Mkk]

Спасибо алл за отклики.
По сути предлагаемых решений.
1. Вариант с 8-кой. Есть еще на подходе пара конфигураций. Допишу - и подумаю о переходе на 8. Хотя у клиентов древние контуперы. Будут ли они тянуть 8-ку.
2. Вариант с триггером. Поскольку он "внешний" по отношению к конфигурации, да и после общения с Ораклом (pl-sql), у которого триггера на таблицу иногда вообще не срабатывали - пока оставлю в стороне.
3. Запись в журнале регистрации - пока успел окинуть взглядом встроенную помощь - попробовать можно. Только смущает пока то (насколько успел прочитать), что я должен описывать _каждый_ реквизит по факту изменения/записи. А нельзя ли по событию Модифицированность() получить список _измененных_ реквизитов? Было-бы проще...

[Batchir]

Можно попробывать следующее
1. При открытии элемента выгружать в ТЗ список реквизитов и их значения
2. После записи проходиться по всем реквизитам и сравнивать с ранее выгруженной таблицей.

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

З.ы. По поводу получения модифицированных реквизитов не знаю - не приходилось сталкиваться

[Zaval]

1. ДатуЗаписи и Пользователя загнать в периодические реквизиты - и через обработку просматривать.

Таки месье знает... ...где все это добро будет храниться?

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

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

[Vofka]

Присоединяюсь к тому, что сказал MATEVI. В мониторе вроде ж видно кто менял.

[Fynjy]

Присоединяюсь к тому, что сказал MATEVI. В мониторе вроде ж видно кто менял.

Монитор очень тормозной 7.7 очень плохо работает с текстовыми файлами.

[Fynjy]

К тому же не видно какие реквизиты менялись.