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

да обычно хватает подробного разбора одного примера

- Есть документ (Счет), порождающий движения, и есть документ (Отгрузка) обнуляющий оные.
выбирай итоги по регистрам, если их нет - всё ОК, если есть - смотри наличие отгрузки..

+2 или выбрать все Отгрузки, проанализировать остатки по регистру для первичного (Счета)

+3 для начала сделай хоть что-нибудь, и покажи заказчику. Заказчик понимает, что просит- только, когда увидит результаты.. © :)

(2) и в какой момент времени ему смотреть итоги? ну был счет на 1000р была отгрузка на 50руб. (потом еще на 250р) и так в течении месяца\двух\трех, когда должен закрыться регистр? правильно - когда будет произведена вся отгрузка - отсюда вышестоящий вопрос - в какой момент времени проверять закрытие регистра?

(0) На твой вопрос - ответ - не существует... Все очень индивидуально а то, что в (1) (2) просто частные случае.

понятно что можно все руками сделать. просто вопрос именно по автоматизации таковой проверки.
(6) теоретически можно задать входные параметры. например, то что не закрылось за год можно считать багом.

(7) Попробуй так протестировать например регистр "Платежный календарь" в котором платежи могут растянутся на год и более...

(8)это частный случай. речь идет о том чтобы задать критерии оценки, прогнать анализ по базе и разобрать все подозрительные случаи вручную. таким образом процесс можно было бы частично автоматизировать

+8 ну или возьми регистр "Заказы покупателей,поставщикам" - они могут быть не закрыты, но это не значит, что где-то есть ошибка - просто необходимо раз в месяц\квартал\год их закрывать (закрытие заказов покупателей\поставщикам)

(9) Любое закрытие регистров - является частным случаем чего-то... поэтому с каждым случаем надо разбираться отдельно.

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

(12) у нас давно написан отчет "Анализ Счетов", там проверяется всё: регистры, оплата, перемещение, отгрузка, документы и т.д.
http://gyazo.com/11f74844bea965b5c2a80152556f96f6

Этому моему отчету лет 10-12.. не помню уж..
Используют все менеджеры, а их у нас 15 человек

(0) сколько?

(13) при чем здесь ваш отчет.))
нужна обработка которая основываясь на метаданных обошла бы все регистры, выполнила анализ и сообщила результаты.

(16) золотая мечта всех бухгалтеров и манагеров... 1С с одной большой кнопкой. Чтоб нажал и все. квсе отчеты вывелись вся отчетность сдана и можно идти курить, пить кофе, трындеть с коллегами

(15) я и сам могу написать просто велосипед не хочу изобретать.

(16) Возможно, и ни при чем.
Но бухгалтер, менеджер, и пр. будут в ужасе кричать"Ах, ах, у меня в регистре остатков остались остатки!!"
И дальше - логичное продолжение - начинается поиск документов, прощелкивание по журналам, сверка итогов по счетам, отгрузкам и пр. др.

Отчет по регистрам нужен исключительно программисту. А бухгалтерам и продавцам - вот тот самый "нипричемошный" отчетик, понятный каждому..
И не нужно бушкам рыться в документах, их дома ждёт семья с сумкой и покупками..

Вот еще один отчет по Регистрам Остатков:
http://gyazo.com/73622fa42274cc7f98dbcf3cee46d481
это уже типа анализа работы сотра за период..
И тоже - только регистры..

(19) а можно вас спросить вы вообще в курсе о невыведении регистров в ноль?))

(20) Можно. Сейчас приведу еще один пример - уже отчет, важный программисту, чтоб было видно, что там закрыто или не закрыто.. минутку..

(21) и знаете почему это плохо?)

(22) Я знаю одно: чтобы увидеть мне, правильно-ли работают проведения документов, и "выводятся ли в ноль" регистры при завершении сделки предприятия с покупателем, я вынужден вывести состояние регистров.. Вернее - 2 состояния:
1 - Итоги
2 - Движения

Вот в этом случае у меня итоги ненулевые,
http://gyazo.com/e2ead0bbcff0e9800781283555d45e13

Возможно, частичная отгрузка из-за отсутствия товаров, возможно, ошибка в модуле документа (проведения).

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

Будут бушки или инженеры заниматься анализом, почему не обнулился регистр?
Думаю, что их мало интересует, что там напридумывало 1С.. регситры какие-то.. субконто..
Им нужны документы.

А "выведение в нуль" - дело программиста.

Желаю успеха!

(23) при чем тут ваши документы и остатки в отчетах - все дело в технической реализации таблицы итогов. когда размер базы превышает 60 гиг и начинает вываливаться по необъяснимым причинам, а убытки составляют более миллиона в день, очень даже интересует почему это база не работает. поверьте мне на слово.

(24) 60 гиг на 8ке ни о чем. Не может вываливаться. Кстати, как то Гилев писал что желательно раз в недельку полный пересчет итогов делать, особенно после перепроведений. Так как если движение задним числом в ноль выходит, то в таблице остатков присутствуют записи с нулевым значением итогов

(25) к сожалению полный пересчет пока не получается завершить по причине вот этого Тестирование и Исправление-Прервать выполнение проверки через ...

(26) а если замерить выгрузку загрузку базы? При выгрузке загрузке происходит тот же пересчет. И как показала практика иногда быстрее работает чем ТиИ с тем же, а то и лучшим результатом. Кстати, помеченные на удаление объекты поудаляли? Еще посмотрите за сервером 1с в момент вываливания кто выжирает память. Может есть какой отчет неоптимальный/запрос для расчета который сжирает на сервере всю оперативку и ложит базу.

можно попробовать выгрузить загрузить на тестовой базе. как-то я делал выгузку год назад на это часов 6 чтоли ушло тогда...
удалить помеченные нереально - при проверке целостности база усыпает наглухо. думаю о переходе в новую базу.

А если тупо на скуле сделать задачу по убийству пустых итогов?

(28) для начала выгрузка загрузка попробуйте. Решает как перезагрузка виндовс до 80% проблем )))

(30) опять же это простой базы
(29) это уже нештатная работа с базой

1. Посмотреть физический размер таблиц.
2. Выделив в п.1 самые большие, делать выводы.

Универсального механизма проверки корректности логики регистров не существует. Ибо железка неспособна понять логику человека - автора регистра. К тому же диапазон довольно широк - начиная с классических ошибок не закрывающихся по измерениям ресурсов и заканчивая какой-нибудь экзотикой с парой десятков измерений в одном регистре с использованием измерений простого типа (число, строка, булево).

Поэтому всё равно придётся смотреть глазками и разбирать причины разбухания таблиц. А учитывая высказывания (25) "60 гиг на 8ке ни о чем", скоторым я полностью согласен,  можно вообще предположить, что проблема вовсе не в самих регистрах.

(25)(32) а вдруг у автора 60 гиг не в скуле, а в файл-сервере? это уже изысканный номер))))

Если бы это было ни о чем, тогда и выгрузка / загрузка, да и ТиИ осуществлялась бы в разумных временных пределах. Сейчас же ее даже обслужить регламентно практически невозможно.
Еще такой момент база на дб2 9.7, а это я думаю тоже значит много это или нет. Субд сервер серверу рознь.