Сменился DOCNO у документа #509242

Люди помогите! Сегодня при сверке бухами обнаружена пропажа документа реализации (1С SQL 7.7 ПУБ, релиз 27) от 4/09/2010. Поиск этого документа по полю DOCNO='J00875' (взял из бэкапа) в таблице _1SJOURN, в базе SQL результата не дал. Поиск его же по полю IDDOC документ нашел, выявилось что у дока теперь другое значение поля DOCNO = '000006' В журнале документов этот док есть но он пустой. В журнале регистрации нашел вот это: Пользователь - ИвановИП Событие - Загрузка изменений данных Комментарий - Новый Объект - Реализация 000006 (12.09.2010) Представление объекта - Реализация J00875 04.09.2010 09:26:44 Дата - 15/09/2010 Пользователь - Моя учетка Событие - Загрузка изменений данных Комментарий - Изменен Объект - Реализация 000006 (12.09.2010) Представление объекта - Реализация 000006 от 12.09.2010 По времени, скорее всего я в это время запускал обмен УРИБ Помогите разобраться, что произошло!

>>>В журнале документов этот док есть но он пустой как это. расшифруйте подробнее

Вроде все по-русски написано...

Кто-то в другой базе поменял номер у документа и сохранил его (при этом, скорей всего, надо было его распровести и провести заново). Потом выгрузили периферийку в центральную - и "О чудо" - документа не стало. P.S. можно ещё файлы обмена посмотреть, чтобы понять, какие бывают грабли.

Доки мы восстановили, но все-таки пытаюсь разобраться, что это было, чтобы больше потом такого не было. В периферийках нигде смену номера не зафиксировал. Еще, одно обстоятельство пробуждает сомнение, что это было чье-то злонамеренное вмешательство. В скулевской базе прогнал запрос: select * from _1SJOURN where DOCNO like "0%" and DATE_TIME_IDDOC like '201009%7579C0%' (сентябрь 2010,12:00), с целью посмотреть сколько документов постигла та же участь что и 000006. Оказалось, в базе их 4884 штуки. Причем: 7 сентября - 4269 документов с одной периферийки (магазин №3), 4 документа центральной базы, 1 документ магазина №1, и 12 сентября - 615 документов магазина №3, 4 документа магазина №4, среди которых и тот, с которого все началось - 000006, 2 документа центральной базы. При этом, с уриб точками у нас нет никаких расхождений по сверкам. Вспоминаю, что такого относящегося к делу было в начале сентября. 3 сентября глюканула дбфная база на 3 периферийке, во время выгрузки УРИБ у них выпадала ошибка не могли провести обмен. Переиндексация, тестирование и исправление результата не дали. 12,13 сентября делал им выгрузку и загрузку в SQL формат. Выгрузка-загрузка делалась из копии 11 сентября, бухи работали в рабочей. После конвертации в SQL 1сина при загрузке ругалась "Нарушена структура индексного файла 1sjourn. Запустите программу в монопольном режиме". При загрузке в монопольном режиме выдавало - "SQL State: 23000 Native: 1505 CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is ' 6OJ '" Пришлось лазить в скуль, искать в таблице _1JOURNAL задублированные записи (их была одна) и удалять те, которые были добавлены последними. Делал согласно То же проделал для таблиц DH19002, DT19002, RA3824, RG3824 (это все был один и тот же документ какой-то там, за 2007 год). После этого - В SQL КОПИЮ 11.09.10 ЗАГРУЗИЛ ДАННЫЕ ЦЕНТРА, И СДЕЛАЛ ВЫГРУЗКУ В ЦЕНТР (срочно нужны были документы) В центре загрузка проходила часа 3... Бухи продолжали работать в глючной дбф версии, через день я перевел им ее в SQL и снова провел обмен. Вот вся имеющаяся у меня информация. Обращаюсь еще раз ко всем, с просьбой помочь разобраться в теме. Могла ли смена номеров произойти из за моих плясок вокруг битой урибки? Каков мог быть в этом случае механизм этого процесса?

2 Zl Докумет есть, но данных в нем нет никаких, табличная область очищена.

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

>>> В периферийках нигде смену номера не зафиксировал Если номер сменили обработкой то это и не будет нигде фиксироваться.

Непонятно магазин №3 магазин №4 работают под dbf или под sql ?

>>>Докумет есть, но данных в нем нет никаких, табличная область очищена Есть ли при этом проводки, движения по этому документу ( именно движения по табличной части ).

Магазин №3 - до 15-16 работал на dbf, после - был переведен на sql Магазин №4 - sql

Движений никаких нет, так как документ не проведен