1С 7.7: тест базы вызывает ее "порчу", последствия... Нужны комментарии

Во время командировки на подшефное предприятие (входит в наш холдинг, городок довольно далеко от столицы, место действия - Украина) местные попросили помочь с переносом БД 1С 7.7 на другой сервер.
1С 7.7 оперативный учет + бухгалтерия, БД в DBF, 1.7 гига, инфа с 2004 г., конфигурация нетиповая (!), целиком самописная, писанная местными "светилами" и обслуживаемая ими же.
Конфигурация ведет бухучет и зп (частично, компоненты расчета не было).

Причина переноса - выход из строя старого сервера. Он представлял собой обычный старый ПК, на плате вздулись конденсаторы, перенос был объяснен так: "...в процессе каждодневной переиндексации (!) БД 1С зависает...".

За неделю до нашего приезда силами местного ИТ отдела (не знакомого с 1С вообще) на другом сервере была запущена 1С в портейбл версии и перенесена сама база (путем копирования ее каталога), однако бухов не устраивало то, что в этом варианте не проходит авторизация пользователей (при запуске не требует пароль).

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

Тест затянулся на несколько часов, в процессе теста было выявлено две ошибки усечения текстового реквизита справочника (неопасные, комментарии), изменение времени нескольких ПН документов, а также весьма множественные ошибки отстутствия связей с несколькими типами документов ЗП за довольно старый период. Последнее было на месте объяснено гл. бухом как "... нам тогда-то урезали базу за два года (2004-2005), больше ошибок в ходе тестирования выяслено не было. По результатам на всякий случай весь вывод тестирования был сброшен в текстовый файл для спецов местного франчайзи, писавшего конфу.

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

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

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


Просим прощения за долгое описание проблемы и просим прокомментировать вышесказанное...