.PNG)
.PNG)
.PNG)
.PNG "4-Ссылки на битые ключи (демо).PNG")
.PNG "2-Обновленные наименования (демо).PNG")
.PNG "3-Ссылки из учета затрат без расшифровки в регистрах аналитик (демо).PNG")
.PNG "5-Битые аналитики для ключей (демо).PNG")
В типовой обработке тестирования и исправления ключей аналитики не устраивало отсутствие возможности взглянуть на проблемные ключи, посмотреть, где и как их использовали, увидеть не только наименования в области сообщений, но и аналитики.
Также она решала только одну из трех обнаруженных в нашей базе проблем, связанных с битыми ссылками или потерянными записями в регистрах. Типовая проверка ссылочной целостности создает отсутствующий ключ, если сохранена его ссылка и аналитики в регистрах АналитикаВидаУчета, АналитикаУчетаЗатрат и т.д. Но что если автоматика бессильна и потерян не ключ, а его аналитики? Пропала из БД статья затрат или номенклатура, а ключ на нее ссылающийся продолжает жить своей жизнью?
Или в регистрах учета затрат по ключу числятся остатки, а записей для этого ключа в регистрах аналитик нет? Механизмы РАУЗ могут не обработать эту ситуацию корректно, а для ее исправления бывает достаточно слегка откорректировать движения документов по этому ключу. Знать бы какие движения и каких документов... Но типовое тестирование даже не сообщает о существовании таких ключей.
Решил немного доработать механизм. Эта обработка реализована на управляемой форме, поэтмоу для использования ее прдется встроить в конфигурацию, либо запускать из под управляемого приложения. Следует учесть, что поиск битых ссылок на аналитики производистя запросом со статичным текстом, рассчитанным на типовую УПП. Поэтому если у вас типы аналитик расширены по сравнению с типовыми, то запрос придется немного откорректировать.
Также нужно учитывать, что при выборе ключа выполняются отборы в списках семи объемных регистров. На больших базах это занимает много времени. Поэтому кликать по строке с ключом следует только тогда, когда действительно необходимо отследить, где он был использован.
.PNG){kind=link}