Смещаем границы итогов в больших регистрах накопления
База данных - Инструменты администратора БД
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Задача тривиальная - смещение границ итогов. Как известно, есть несколько подвидов этой задачи, и действия, которые выполнит система:
- Если сдвигается только верхняя граница итогов - алгоритму нужно рассчитать и добавить к ранее полученным итогам обороты за каждый месяц, что окажется за пределами рассчитанных.
- Если сдвигается нижняя граница в сторону текущего времени - происходит DELETE записей, выходящих за рамки установленного периода итогов.
- п.1 и п.2 и пересчет итогов.
В случае пункта 3, стандартными путями мы попадаем на две возможные тяжелые операции.
1 - Смещение границ стандартными командами приводит к удалению данных за пределами рассчитанных итогов и пересчету итогов по ранее отсутствующим периодам.
2 - Пересчет итогов, который также удаляет все данные из таблицы итогов через DELETE и затем рассчитывает итоги помесячно
Инфостарт полон статьями по поводу необходимости предварительного TRUNCATE таблиц итогов, дабы нивелировать продолжительность операция DELETE, но в предложенном кейсе это не избавляет от двух процедур расчета итогов.
Обычная последовательность с транкейтом:
1. Truncate таблицы итогов (Для предотвращения долгого делита)
2. Смещение границы итогов (вызывающим пересчет только ранее не расчитанных месяцев, что с учетом п.1 ломает всю информацию по итогам и вообще не нужен, с учетом п.3)
3. Транкейт таблицы итогов (Для предотвращения долгого делита)
4. Пересчет итогов (что бы выправить проблему полученную в п.2)
В идеале, нам нужно просто сместить границу итогов, без запуска процесса расчета итогов, очистить таблицу итогов и запустить полный пересчет итогов по целевой таблице.
Платформенные методы смещения границ итогов в процессе расчета периода, фиксируют данную информацию в таблицу настроек хранения итогов (таблица AccumRgOptNNN), т.е. для исключения лишнего расчета итогов, достаточно внести изменения в таблицу настроек хранения итогов, относящуюся к интересуемому регистру накопления, транкейтнуть таблицу итогов, и запустить расчет.
!!! Обратите внимание, в режиме предприятия в обработке управления итогами, верхняя граница итогов стоит как граница предыдущего месяца (в данном случае 31 марта 2024 года), но в таблице настроек физически будет хранится начало следующего дня (в данном случае 1 апреля 2024 года).
Обозначение полей:
- _Period - Верхняя граница итогов
- _MinCalculatedPeriod - Нижняя граница итогов
Для помощи в автоматизации создания скрипта, была доработана стандартная обработка управления итогами:
- Показывает имена таблиц итогов из структуры хранения для РН
- Замеряет время пересчета по каждой таблице
- Позволяет подготовить SQL скрипт для упрощенной процедуры "Смещение + Пересчет"
Обработка, опираясь на структуру хранения базы, собирает следующий скрипт по отмеченным выше таблицам. Написать скрипт вы можете и самостоятельно опираясь на данную статью.
После выполнения скрипта, необходимо запустить пересчет итогов по целевым таблицам.
Итого для одной таблицы:
- Операция транкейта + операция смещения границ итогов без пересчета онных.
- Одна процедура пересчета итогов
В таблицах настроек хранения итогов регистров накопления, всегда одна запись, поэтому update реализован без какого либо where по записи.
Тестировалось на платформах:
8.3.18.1334 и 8.3.23.1912
ЗЫ: Не претендую на оригинальность, не нашел подобного, когда искал.
Вступайте в нашу телеграмм-группу Инфостарт
