Один из вариантов решения этой проблемы - на картинке анонса, это проведение ТиИ с проверкой логической целостности. По крайней мере, я надеюсь, что это так, но проверить это предположение у меня возможности не было - база очень большая, и логическая целостность выполняется весьма продолжительное время, остановить работу на пару суток не представляется возможным.
Причиной является расхождение данных в основной таблице документа _DocumentXXX и данных в таблице журнала _DocumentJournalXXX. Определить это возможно с помощью прямого сравнения этих таблиц, даже стандартными запросами 1с (с незначительным ограничением, если графа журналов неограниченной длины).
Проверить свою базу на наличие таких вот скрытых "мин" вы можете, воспользовавшись отчетом "ПроверкаЛогическойЦелостностиЖурналов" из данной публикации, который в удобном виде выдаст результат сравнения. Или ничего не выдаст - тогда можете радоваться - значит данные в таблицах документов и таблицах журнаолв согласованы. Ну, по крайней мере без учета реквизитов неограниченной длины, которые не сравнить в запросе в общем виде.
Отчет работает на любых видах баз - клиент-серверных и файловых. Скорость выполнения отчета естественно, зависит размера и структуры базы, однако на нормальном сервере MS SQL для 500гб базы он формируется несколько минут. На других СУБД, естественно, не проверял.
Из-за того, что отчет использует запросы 1с, при использовании общих реквизитов в режиме разделения данных "независимо" - отчет строится только для данных в пределах текущего разделителя (так как из запроса не обратиться к такому реквизиту).
В обновленной версии псевдонимы длятаблиц запросов поменяны на менее вероятные (было - "Журнал" и "Документы", стало "ТабПроверяемыйЖурнал" и "ТабПроверяемыеДокументы", спасибо kapustinag за указание на ошибку)
Что делать, если отчет показал не пустой результат? Прямых средств воздействия на значения в таблице журналов у нас нет. Изменение "кривых" документов не помогает - в таблице журналов все равно остаются неправильные данные (Ну, по крайней мере у меня не прокатило). Можно сделать Тестирование и Исправление, однако это требует монопольного доступа, а также занимает очень много времени, зачастую, на которое остановить работу невозможно.
Обработка "ИсправлениеЛогическойЦелостностиЖурналов" - это "генератор запросов" для исправления неправильных данных в таблице журналов документов. Обработка работает, цепляясь через ADO к серверу СУБД и напрямую изменяя там данные. Обработка используя методы 1с, такие как ПолучитьСтруктуруХраненияБазыДанных() определяет таблицы, в которых находятся неправильные данные, а также предлагает "для ознакомления" (из-за лицензионных ограничений 1с) тексты запросов для СУБД, которые бы могли бы исправить ситуацию. Сначала генерируется запрос для удаления строк, которые не совпадают с данными в основных таблицах документов, или вообще не должны быть в журнале (например, докумены другого вида, или удаленные из основной таблицы), потом для создания строк, которых не хватает в журнале (т.е. строк с правильными данными взамен удаленных на первом шаге, а также те, которые в принципе отсутствовали в журнале)
Из-за того, что используется ADO, работает только на windows (win-сервере или в неуправляемых формах), протестирована на MS SQL, однако учитывая то, что используются элементарные запросы вида "DELETE FR OM table WH ERE field = value" и "INS ERT INTO table (field) VALUES (val ue)" работать должна на любой СУБД. Данные для удаления и вставки получаются целиком срествами 1с, аналогично получению данных в отчете.
Так как политика 1с запрещает прямое изменение данных (но при этом предоставляет некоторую информацию о физическом размещении), обработка не делает никаких прямых запросов, а только показывает тексты запросов, которые бы сделали нужные действия.
ВНИМАНИЕ! Если вы (вдруг) решите использовать сгенерированные запросы, сначала протестируйте их на копии - ведь никто не застрахован от ошибок, вдруг я не учел какой-то случай, особенно если в базе активно используются разделители.