В ОСВ по 10му счету краснота, база клиент-серверная. Пересчет итогов в глючной базе (также выгрузка/загрузка в нее же) не помогает. Пересчет делал и в конфигураторе (все галочки) и в пользовательском режиме. Если загрузить в чистую базу выгрузку с этой глючной, то остатки стают нормальные.
Что за беда и как бороться?

так-то новую базу создали и запустили, но осадок остался.

(0) а как загружаете в чистую? если через dt, то можно же выгрузить dt и потом обратно его же и загрузить...

предварительно сделать бекап средствами sql.

(2) через dt. Я его обратно и загружал, но в рабочей это не помогает.

что отличает новую базу от существующей?! По сути только кэш... но хз, дождемся советов более опытных коллег)

какие-то регламентные задания наверно, обновление статистики и т.д.

(0) Прибить итоги, пересчитать, наслаждаться.

Еще вылезла проблема: в документах списание с расчетного счета , проводки сидят нормально (визуально), пример:
Дт 60.01 Контрагент, Договор, все сидит.
Но запросом вместо договора NULL показывает:
ВЫБРАТЬ
    ХозрасчетныйОбороты.Регистратор КАК Регистратор,
    ХозрасчетныйОбороты.Счет КАК Счет,
    ХозрасчетныйОбороты.Субконто1 КАК Контрагент,
    ХозрасчетныйОбороты.Субконто2 КАК Договор,
    ХозрасчетныйОбороты.СуммаОборот КАК СуммаОборот
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Обороты(&НачДата, &КонДата, Регистратор, Счет = &Счет_60_02, , Субконто1 = &Контрагент, , ) КАК ХозрасчетныйОбороты

При этом если делать отбор по конкретному договору в запросе, то нормально.

(7) ааа...смотреть виртуальные таблички, заместо того, что есть в самой базе..это пять

(8) из dt база загружена, при загрузке это все не обновляется ?

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

Зачем только это делать - загадка.

Прибей ты уже таблички итогов через truncate table, ну или штатненько, кодом. Да пересчитай итоги

(11) Прибил таблицы (все итоги)
TRUNCATE TABLE _AccRgAT0493
TRUNCATE TABLE _AccRgAT1512
TRUNCATE TABLE _AccRgAT2513
TRUNCATE TABLE _AccRgAT3514
TRUNCATE TABLE _AccRgCT515

Пересчитал итоги, та же самое, и остатки тоже кривые по счетам (куча минусов).
У проблемных доков, которые запросом 2е субконто NULL показывают если зайти и перезаписать проводки (с ручной корректировкой) то ничего не меняется. Если перевыбрать договор, то потом запросом уже нормально вытаскивается.

(12)А если распровести и заново провести такие документы?

(12) кеш так и не чистили ?

(13) это нереально, этих документов много

(12) из dt в новую гружу и такая же проблема, кэш не причем наверно

(0) Пробовали провести обслуживание базы средствами SQL (проверка целостности, пересчет индексов, обновление статистики)?

(12) в самом регистре то чего хоть? Выбери хотя бы обычным запросом записи регистра бухгалтерии с фильтром по регистратору.

Зы: до "красноты", чего с базой делали?

В (0) написано, что при загрузке в чистую базу все ОК, а в (15), что ничего не меняется. Чему верить ? Может краснота не от неверных итогов?
Постройте карточку счета по какому нибудь материалу. Точно краснота глючная или она и должна быть, потому что кто-то что-то ...

(17) большое спасибо за наводку в нужном направлении. В проводках документа показывает что все норм, когда зашел в регистр (журнал проводок бух и нал учета), то там в нужных субконто пусто. Возможно вид субконто слетел. Помогает перезапись проводки с каким-либо изменением (например, можно в содержание пробел добавить/убавить или переключить активность проводки туда-сюда).
Как-так получилось: перевод на КОРП, с программным заполнением подразделений (делал много раз уже, всегда было все нормально), но тут пока делал вышибало несколько раз (сервер видит что активности нет и вышибает видимо, хотя обработка в это время работала)