Если пересчет итогов не занимает много времени, то можно просто время от времени пересчитывать итоги.
А вот если пересчет итогов по одному регистру занимает несколько часов, то уже возникает вопрос, как же быть уверенным, что с итогами все нормально.
Для себя закрыл вопрос написав обработку и включив ее в регламент. Теперь каждую ночь обработка проверяет регистры накопления и шлет письмо, если что-то не так.
Как работает? Сверяет обороты по с периодичностью "запись" с оборотами без периодичности. Проверяет последний год от текущей даты. Проверяет все регистры накоплений.
Механизм проверки выглядит так:
Для Каждого Рег Из Метаданные.РегистрыНакопления Цикл
ТекстЗапроса =
"ВЫБРАТЬ
| РегОбороты.Измерение,
| СУММА(РегОбороты.Ресурс) КАК РесурсПериод,
| 0 КАК Ресурс
|ПОМЕСТИТЬ ТаблицаДанных
|ИЗ
| РегистрНакопления.ИмяРегистра.Обороты(&D1, &D2, Запись, ) КАК РегОбороты
|
|СГРУППИРОВАТЬ ПО
| РегОбороты.Измерение
|
|ОБЪЕДИНИТЬ ВСЕ
|
|ВЫБРАТЬ
| РегОбороты.Измерение,
| 0,
| СУММА(РегОбороты.Ресурс)
|ИЗ
| РегистрНакопления.ИмяРегистра.Обороты(&D1, &D2, , ) КАК РегОбороты
|
|СГРУППИРОВАТЬ ПО
| РегОбороты.Измерение
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТаблицаДанных.Измерение,
| СУММА(ТаблицаДанных.РесурсПериод) КАК РесурсПериод,
| СУММА(ТаблицаДанных.Ресурс) КАК Ресурс
|ПОМЕСТИТЬ ТаблицаДанныхГрупп
|ИЗ
| ТаблицаДанных КАК ТаблицаДанных
|
|СГРУППИРОВАТЬ ПО
| ТаблицаДанных.Измерение
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТаблицаДанныхГрупп.Измерение,
| ТаблицаДанныхГрупп.РесурсПериод,
| ТаблицаДанныхГрупп.Ресурс
|ИЗ
| ТаблицаДанныхГрупп КАК ТаблицаДанныхГрупп
|ГДЕ
| ТаблицаДанныхГрупп.Ресурс <> ТаблицаДанныхГрупп.РесурсПериод
|";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "Измерение", Рег.Измерения[0].Имя);
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "Ресурс", "" + Рег.Ресурсы[0].Имя + "Оборот");
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "ИмяРегистра", Рег.Имя);
Если есть проблема по какому-то регистру, пересчитываем этот регистр:
РегистрыНакопления[ИмяРег].ПересчитатьИтоги()
P.S. Обработка протестирована на релизе 1С:Предприятие 8.2 (8.2.19.130). Должна работать на любых релизах 8.2-8.3.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Задумался сегодня на эту тему, попробовал реализовать свой вариант «на коленке» и вот что немного смутило в процессе.
Тут мы берем первый попавшийся ресурс регистра накопления. С одной стороны это быстро и голову ломать не нужно. А с другой стороны, это может быть ресурс, который просто напросто не используется прикладным решением исходя из настроек какой-нибудь функциональной опции и всегда имеет значение 0. В то время как ошибка может засесть в других ресурсах того же самого регистра.
Костыль.
Понятно, что с костылем кловылять всяко лучше чем без костыля, но хотелось бы не допускать травматизма.
То бишь — причины такого разбегания в чем? как устранить эти причины?
(1) Гм. С новыми конфигурациями слабо знаком. Там такое действительно есть? Можно пример? Или это теория?
(2) Самому интересно. Ходят слухи, что это связанно с демоническим обновлением, но я не верю.
(3) Теория. Но если брать на вскидку такой ресурс как СтоимостьНУ. То у нас в базе, например, налоговый учет не ведется и этот ресурс всегда 0.
(2) Причины практически те же, что и в случаях, когда в базе появляются объекты с одинаковым GUIDом из-за обмена или переноса данных. Когда проведенный документ не имеет движений там где они быть должны. Когда непроведенный документ имеет движения. Когда помеченный на удаление документ имеет движения. Когда в подчиненных справочниках появляются элементы без владельца.
В 1С гарантий нет ни от чего. С кривыми итогами встречаюсь периодически в своей базе. Раньше раз в неделю делал реструктуризацию базы вручную, бонусом и итоги пересчитывались и фрагментация таблиц снижалась. Теперь такая возможность пропала. Позавчера включал пересчет итогов, так как отчеты стали врать. Помогло. В БСП не обнаружил регламентных заданий по пересчету итогов.
(5)
Понятно. Если еще кто-нибудь из коллег присоединится к мнению, что такая проблема существенна, перепишу обработку.
(6) «когда в базе появляются объекты с одинаковым GUIDом из-за обмена или переноса данных.»
— ну это еще, допустим, чисто технологическая заморочка, совпадение гуидов еще может быть вроде как, 100% гарантии здесь нет
«Когда проведенный документ не имеет движений там где они быть должны. Когда непроведенный документ имеет движения. Когда помеченный на удаление документ имеет движения. Когда в подчиненных справочниках появляются элементы без владельца.»
— это следствие чего-то? кривого кода? сбоя в механизмах платформы? насколько мне известно — технологически в 8-ке совсем не запрещено иметь движения у непроведенных документов.. и у помеченных на удаление… Так в результате чего такие «нестыковки»..?
(8)
(6), (8), (9) Что-то вы намешали, коллеги.
Проблемы с итогами, это ИМХО, проблемы платформы.
Проблемы с кодом «ОбменДанными.Загрузка = Истина» это уже проблемы конфигурации и/или программиста.
На самом деле, не все так плохо с 8-кой. На нормально обслуживаемой базе, с нормальным железом, проблемы типа (0) происходят довольно редко. Я даже и не помню когда была предыдущая подобная ситуация, год или два назад.
Самое-то неприятное, что проблему обычно выявляют пользователи, через какой-то промежуток времени после возникновения ситуации. И тогда:
1. Непонятно когда вообще наступил час Х.
2. Если это было несколько дней назад, трудно вспомнить, что же именно могло привести к беде.
Я что-то не понял… Виртуальная таблица «Обороты» для регистров типа «Остатки» вроде как читает только таблицу реальных записей, то есть никакие таблицы итогов не читаются в принципе, и результат от сбитых итогов не может зависеть. Эта обработка что ли только для оборотных регистров?
Цитата из книги:
Для построения виртуальной таблицы оборотов регистра накопления остатков всегда используются данные таблицы движений регистра (из базы данных).
(11) Хм. Похоже на то.
Словил проблему на РП «Продажи». Написал (0) для проверки результата. Поймал проблему еще на одном (самописном) оборотном регистре…
Косяк. Ввел коллег в заблуждение.
Вообще, конечно, идея хорошая, сам недавно нарвался на базе заказчика на сбитые итоги. Сначала по регистру бухгалтерии, причем у них около пяти месяцев была эта проблема и они в оборотках видели нереальные остатки, и закрывали счета исходя из неверных остатков. Пересчет итогов привел к тому, что в оборотках изменились остатки по закрытым периодам (то есть отразились реальные остатки), счета 26, 20, 40 раскрылись, в общем ужас-ужас. Потом, там же, нарвался на слетевшие итоги в регистре УчетЗатратРегл. Полный пересчет итогов, конечно, помог, но надежный инструмент диагностики для быстрого выявления проблем хотелось бы иметь.
Причем по регистру бухгалтерии сбитые итоги выглядели так: видимо был какой-то документ с проводками, эти проводки были учтены в таблицах итогов, потом сам документ с проводками пропал, а в таблицах итогах все осталось как с этими проводками.
При этом вроде бы запись записей в регистр и апдейт таблиц итогов должен же быть в одной транзакции, как сбой происходит, ума не приложу. MS SQL.
(14) О, я правильно понял? Если грохнуть документ на SQL, не трогая движения, и потом прогнать (0), если покажет различия, то механизм годный?
(15) Если движения и таблицу итогов не трогать, то итоги продолжат соответствовать движениям, то есть с итогами как таковыми все нормально будет.
Чтобы создать проблему, нужно в MSSQL зайти в таблицу итогов и поправить там циферки, вот тогда будет проблема и можно тестировать обработку.
(16) Тогда этого немного долго проверять.