Сбой при Z-отчете. Как лечить? : УКМ-2

Касса Siemens с фискалкой.
Начала вываливаться с руганью на ошибки в файлах данных.
Смену не закрыли, принесли мне. Гружу - касса "бодро" заявляет, типа надо бы смену закрыть. Сдуру соглашаюсь, печатает контрольку, соглашаюсь на зетку, касса тупит и заявляет "Ошибка в таблицах данных". При загрузке теперь ругается на неверной номер последнего чека. Полагаю смена закрылась в УКМ, но не закрылась в ФП (или наоборот). Чего делать?

Снять фискальный отчет, а затем править cf_ini.db в соответствии с этими данными. Возможнл еще и cashsail придется править и currests. Кропотливая ручная работа в общем.

В ЦТО, одним словом

Мы сами этим занимаемся. Исторически так сложилось)). Быстрее и качественнее.

scandisk, а потом cashmain /i прогонял?

cashmain /i не поможет, если рассогласование номеров смен уже произошло.
Скорее так: забэкапить каталог с УКМ, запустить scandisk, разобраться с номерами смен, а потом уже сделать переиндексацию.
Надо смотреть номера смен по фискалке и по УКМ. Если в фискалке смена закрылась, а в УКМ - нет, то возможно придется править cf_ini+currests.db или делать (zreprt).exe /forcez.

Thalt, я что-то пропустил?
не нашел, где речь шла о рассогласовании смен...

Если глюк появился после попытки закрытия смены, то, imho, имеет место быть именно косячок с номерами смен, а не чеков.
Кстати. На неверный номер последнего чека оно, вроде, ругалось и тогда, когда не могло свести сумму в кассе и сумму по продажам. Тогда приходилось вручную считать сумму по cashsail за текущую смену и вписывать в cf_ini.

может быть и так, но я встречался с ситуацией, когда запись о скидке по чеку в одной таблице была, а в таблице продаж этого чека не было
Исправлял: scandisk, cashmain /i
Пару раз исправлял таблицы с помощью Dtutil32

Все достаточно просто. При таких сбоях на диске с появляется файлик (qtest).rpt И в нем находяться записи в виде
FM=??????? DB=?????? IC=??????? LC=?????? NC=????? и т.д.
Если кому-то это интересно могу рассказать методику лечения данных сбоев...