Проверка актуальности итогов регистров накоплений

Публикация № 961323

Администрирование - Администрирование данных 1С - Тестирование и исправление

5
Иногда возникают ситуации, когда с остатками происходит что-то непонятное. Остаток на начало + Оборот != Остаток на конец. После пересчета итогов проблема уходит. Но как узнать вовремя, что что-то не так?

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

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

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

Как работает? Сверяет обороты по с периодичностью "запись" с оборотами без периодичности. Проверяет последний год от текущей даты. Проверяет все регистры накоплений.

Механизм проверки выглядит так:

	Для Каждого Рег Из Метаданные.РегистрыНакопления Цикл 
		
		ТекстЗапроса = 
		"ВЫБРАТЬ
		|	РегОбороты.Измерение,
		|	СУММА(РегОбороты.Ресурс) КАК РесурсПериод,
		|	0 КАК Ресурс
		|ПОМЕСТИТЬ ТаблицаДанных
		|ИЗ
		|	РегистрНакопления.ИмяРегистра.Обороты(&D1, &D2, Запись, ) КАК РегОбороты
		|
		|СГРУППИРОВАТЬ ПО
		|	РегОбороты.Измерение
		|
		|ОБЪЕДИНИТЬ ВСЕ
		|
		|ВЫБРАТЬ
		|	РегОбороты.Измерение,
		|	0,
		|	СУММА(РегОбороты.Ресурс)
		|ИЗ
		|	РегистрНакопления.ИмяРегистра.Обороты(&D1, &D2, , ) КАК РегОбороты
		|
		|СГРУППИРОВАТЬ ПО
		|	РегОбороты.Измерение
		|;
		|
		|////////////////////////////////////////////////////////////////////////////////
		|ВЫБРАТЬ
		|	ТаблицаДанных.Измерение,
		|	СУММА(ТаблицаДанных.РесурсПериод) КАК РесурсПериод,
		|	СУММА(ТаблицаДанных.Ресурс) КАК Ресурс
		|ПОМЕСТИТЬ ТаблицаДанныхГрупп
		|ИЗ
		|	ТаблицаДанных КАК ТаблицаДанных
		|
		|СГРУППИРОВАТЬ ПО
		|	ТаблицаДанных.Измерение
		|;
		|
		|////////////////////////////////////////////////////////////////////////////////
		|ВЫБРАТЬ
		|	ТаблицаДанныхГрупп.Измерение,
		|	ТаблицаДанныхГрупп.РесурсПериод,
		|	ТаблицаДанныхГрупп.Ресурс
		|ИЗ
		|	ТаблицаДанныхГрупп КАК ТаблицаДанныхГрупп
		|ГДЕ
		|	ТаблицаДанныхГрупп.Ресурс <> ТаблицаДанныхГрупп.РесурсПериод
		|";
		
		ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "Измерение", Рег.Измерения[0].Имя);
		ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "Ресурс", "" + Рег.Ресурсы[0].Имя + "Оборот");
		ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "ИмяРегистра", Рег.Имя);

Если есть проблема по какому-то регистру, пересчитываем этот регистр:

РегистрыНакопления[ИмяРег].ПересчитатьИтоги()

P.S. Обработка протестирована на релизе 1С:Предприятие 8.2 (8.2.19.130). Должна работать на любых релизах 8.2-8.3.

5

Скачать файлы

Наименование Файл Версия Размер
Проверка актуальности итогов регистров накоплений:
.epf 5,03Kb
11.12.18
8
.epf 5,03Kb 8 Скачать

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 45 12.12.18 20:20 Сейчас в теме
Задумался сегодня на эту тему, попробовал реализовать свой вариант "на коленке" и вот что немного смутило в процессе.

Рег.Ресурсы[0].Имя


Тут мы берем первый попавшийся ресурс регистра накопления. С одной стороны это быстро и голову ломать не нужно. А с другой стороны, это может быть ресурс, который просто напросто не используется прикладным решением исходя из настроек какой-нибудь функциональной опции и всегда имеет значение 0. В то время как ошибка может засесть в других ресурсах того же самого регистра.
3. dmt 48 13.12.18 04:42 Сейчас в теме
(1) Гм. С новыми конфигурациями слабо знаком. Там такое действительно есть? Можно пример? Или это теория?
5. PerlAmutor 45 13.12.18 05:54 Сейчас в теме
(3) Теория. Но если брать на вскидку такой ресурс как СтоимостьНУ. То у нас в базе, например, налоговый учет не ведется и этот ресурс всегда 0.
7. dmt 48 13.12.18 06:24 Сейчас в теме
(5)
) Теория. Но если брать на вскидку такой ресурс как СтоимостьНУ. То у нас в базе, например, налоговый учет не ведется и этот ресурс всегда 0.


Понятно. Если еще кто-нибудь из коллег присоединится к мнению, что такая проблема существенна, перепишу обработку.
2. CheBurator 3395 12.12.18 23:54 Сейчас в теме
Костыль.
Понятно, что с костылем кловылять всяко лучше чем без костыля, но хотелось бы не допускать травматизма.
То бишь - причины такого разбегания в чем? как устранить эти причины?
4. dmt 48 13.12.18 04:45 Сейчас в теме
(2) Самому интересно. Ходят слухи, что это связанно с демоническим обновлением, но я не верю.
6. PerlAmutor 45 13.12.18 06:00 Сейчас в теме
(2) Причины практически те же, что и в случаях, когда в базе появляются объекты с одинаковым GUIDом из-за обмена или переноса данных. Когда проведенный документ не имеет движений там где они быть должны. Когда непроведенный документ имеет движения. Когда помеченный на удаление документ имеет движения. Когда в подчиненных справочниках появляются элементы без владельца.

В 1С гарантий нет ни от чего. С кривыми итогами встречаюсь периодически в своей базе. Раньше раз в неделю делал реструктуризацию базы вручную, бонусом и итоги пересчитывались и фрагментация таблиц снижалась. Теперь такая возможность пропала. Позавчера включал пересчет итогов, так как отчеты стали врать. Помогло. В БСП не обнаружил регламентных заданий по пересчету итогов.
8. CheBurator 3395 14.12.18 02:53 Сейчас в теме
(6) "когда в базе появляются объекты с одинаковым GUIDом из-за обмена или переноса данных."
- ну это еще, допустим, чисто технологическая заморочка, совпадение гуидов еще может быть вроде как, 100% гарантии здесь нет

"Когда проведенный документ не имеет движений там где они быть должны. Когда непроведенный документ имеет движения. Когда помеченный на удаление документ имеет движения. Когда в подчиненных справочниках появляются элементы без владельца."
- это следствие чего-то? кривого кода? сбоя в механизмах платформы? насколько мне известно - технологически в 8-ке совсем не запрещено иметь движения у непроведенных документов.. и у помеченных на удаление... Так в результате чего такие "нестыковки"..?
9. PerlAmutor 45 14.12.18 06:06 Сейчас в теме
(8)
Так в результате чего такие "нестыковки"..?


ОбменДанными.Загрузка = Истина;
10. dmt 48 14.12.18 06:21 Сейчас в теме
(6), (8), (9) Что-то вы намешали, коллеги.
Проблемы с итогами, это ИМХО, проблемы платформы.
Проблемы с кодом "ОбменДанными.Загрузка = Истина" это уже проблемы конфигурации и/или программиста.

На самом деле, не все так плохо с 8-кой. На нормально обслуживаемой базе, с нормальным железом, проблемы типа (0) происходят довольно редко. Я даже и не помню когда была предыдущая подобная ситуация, год или два назад.
Самое-то неприятное, что проблему обычно выявляют пользователи, через какой-то промежуток времени после возникновения ситуации. И тогда:
1. Непонятно когда вообще наступил час Х.
2. Если это было несколько дней назад, трудно вспомнить, что же именно могло привести к беде.
11. aegoncharov 14.12.18 11:47 Сейчас в теме
Я что-то не понял... Виртуальная таблица "Обороты" для регистров типа "Остатки" вроде как читает только таблицу реальных записей, то есть никакие таблицы итогов не читаются в принципе, и результат от сбитых итогов не может зависеть. Эта обработка что ли только для оборотных регистров?

Цитата из книги:
Алгоритм, применяемый системой для получения оборотов регистра накопления остатков.
Для построения виртуальной таблицы оборотов регистра накопления остатков всегда используются данные таблицы движений регистра (из базы данных).
12. dmt 48 14.12.18 12:07 Сейчас в теме
(11) Хм. Похоже на то.

Словил проблему на РП "Продажи". Написал (0) для проверки результата. Поймал проблему еще на одном (самописном) оборотном регистре...

Косяк. Ввел коллег в заблуждение.
13. aegoncharov 14.12.18 12:18 Сейчас в теме
Вообще, конечно, идея хорошая, сам недавно нарвался на базе заказчика на сбитые итоги. Сначала по регистру бухгалтерии, причем у них около пяти месяцев была эта проблема и они в оборотках видели нереальные остатки, и закрывали счета исходя из неверных остатков. Пересчет итогов привел к тому, что в оборотках изменились остатки по закрытым периодам (то есть отразились реальные остатки), счета 26, 20, 40 раскрылись, в общем ужас-ужас. Потом, там же, нарвался на слетевшие итоги в регистре УчетЗатратРегл. Полный пересчет итогов, конечно, помог, но надежный инструмент диагностики для быстрого выявления проблем хотелось бы иметь.
14. aegoncharov 14.12.18 12:22 Сейчас в теме
Причем по регистру бухгалтерии сбитые итоги выглядели так: видимо был какой-то документ с проводками, эти проводки были учтены в таблицах итогов, потом сам документ с проводками пропал, а в таблицах итогах все осталось как с этими проводками.
При этом вроде бы запись записей в регистр и апдейт таблиц итогов должен же быть в одной транзакции, как сбой происходит, ума не приложу. MS SQL.
15. dmt 48 14.12.18 12:27 Сейчас в теме
(14) О, я правильно понял? Если грохнуть документ на SQL, не трогая движения, и потом прогнать (0), если покажет различия, то механизм годный?
16. aegoncharov 14.12.18 12:32 Сейчас в теме
(15) Если движения и таблицу итогов не трогать, то итоги продолжат соответствовать движениям, то есть с итогами как таковыми все нормально будет.
Чтобы создать проблему, нужно в MSSQL зайти в таблицу итогов и поправить там циферки, вот тогда будет проблема и можно тестировать обработку.
17. dmt 48 14.12.18 12:44 Сейчас в теме
(16) Тогда этого немного долго проверять.
Оставьте свое сообщение