Журнал зарплаты Комплексная 7.7

"Обнаружилось что при применении  

 ЖрнЗарплата.ВыбратьЗаписиПоОбъекту(Сотрудник, ЖрнЗарплата.НачалоПериодаПоДате(ДатаНачала), ЖрнЗарплата.КонецПериодаПоДате(ДатаОкончания));

и дальнейшего перебора записей поменялась последовательность  записей.Сначала идут сторно записи больничного, а потом первичные записи которые сторнированы.
И соответственно в отчете получаеться, что первичные записи при таком порядке перекрывают сторно.

Из за чего мог поменяться порядок при выборке?"

Хочу апнуть тему. потому что какого либо внятного объяснения не нашла перерыв весь инет. Может кто сталкивался?

База в SQL формате или dbf?

SQL

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

база больше 30 гигов боюсь не получиться выгрузить и загрузить данные. Может средствами SQL можно что то сделать?

В таблице "Журнал расчетов" есть поле ROW_ID, похоже на то, что результат выборки упорядочен по нему при выполнении метода ВыбратьЗаписиПоОбъекту. При создании записей в журнале расчетов в таблице они появляются "по мере создания", то есть, хронология соответствует тому порядку как они в жизни создавались и логично предполагать, что сторнирующие записи (или записи перерасчета) не могли быть в таблицу записаны ранее первичных, поэтому проблема возникать не должна. Но поскольку она есть, единственной причиной могу предположить то, что была программная перезапись первичных записей, из за которой они в таблице оказались после сторнирующих. Способов решений в голову приходит три:
1. Выгрузить-Загрузить. Судя по размеру вашей базы, надо делать в выходные. Чтобы быть уверенным, что процесс не завис, порекомендую утилиту ConfMessages, поищите ее в интернете. Глядя в файл выгрузки, можно сказать, что значения ROW_ID туда не выгружаются и если предположить, что выгрузка идет последовательным перебором периодов, то после загрузки мы получим правильное упорядочивание записей. Так ли это - не знаю, надо пробовать.
2. Локализовать проблему, написав какую нибудь обработку, которая из журнала расчетов выберет все подмножества связанных по смыслу записей (Первичные+Перерасчет или сторно), и проверит по отношению к ним корректность логической последовательности перебора методом ВыбратьЗаписиПоОбъекту. Если проблема будет выявлена, то выполнить программное удаление и создание точных копий записей сторно и перерасчета так, чтобы в таблице они появились позднее первичных.
3. Сделать тоже самое что написано в п.2, но напрямую в таблице MS SQL Server. Крайне нежелательный способ, тем более на живой базе.

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

Трогать можно, только надо пытаться спрогнозировать последствия.