УТ 10.3 MsSql. Учет ведется с 2013 года. Граница последовательности партионного учета документов стоит 01.02.2014. Отчеты по партионному учету не используем, но списание по партиям выставлено и происходит. Подскажите, если восстановить последовательность до текущей даты. Быстродействие при проведении документов и формировании отчетов возрастет?

нет

Да. Особенно если навести в остатках порядок, чтобы не было всяких партий. Пусть даже корректировками регистров

(2) За счет чего - да?

Кривая последовательность ведёт к нереальному разрастанию таблицы остатков. А это приводит к замедление формирования виртуальная таблиц. Тем более если барак с такого года

(4) >>Кривая последовательность ведёт к нереальному разрастанию таблицы остатков.

Как последовательность может быть "кривой"? Это просто дата, а на уровне БД таблица, как она может влиять на разрастание остатков?

(5) кривая последовательность = правка задом. Правка задом = незакрытые остатки по партиям. Кривые остатки = неоправданна большая таблица из которой программа получает остатки

Забыл сказать, база 110 Gb

Розничная продуктовая торговая сеть. 16 магазинов

(6) Он же говорит, что списание по партиям происходит, зачем гадать? И где гарантия что посл-ть вообще восстановится?

ТС не привел ни размер таблиц, ни длит-ть запросов, с тем же успехом можно обсудить влияние лунного света на бараньи яйца.

(9) Неактуальная граница последовательности - косвенный признак возможной "кривизны" регистра ПУ.
Желательно посмотреть размеры таблиц регистра ПУ (собственно и остатков и размеры индексов).
Можно запросом посмотреть "незакрытые" партии - насколько они древние. Собственно цель: сократить размер таблицы остатков.
(0) Списание партий оперативное (в момент проведения) или обработкой? Если оперативное - сделайте обработкой (предварительно программно сдвинув границу ПУ).
Не помню точно, но в обработке делается не проведение документа, а вызов процедуры общего модуля партионного учета ДвижениеПартий (кажется).
Можно сделать аналог обработки, не опираясь на границу ПУ, а вызывая ДвижениеПартий для документов, у которых нет движений по регистру ПУ (хотя это и не одно и то же).
Еще: я отказался от записи в регистр сведений СписаниеТоваров. Вместо этого оформил экспортные процедуры в модулях документов, которые формируют таблицу движений по этому регистру (она используется в ДвижениеПартий, как параметр).

> Еще: я отказался от записи в регистр сведений СписаниеТоваров. Вместо этого оформил экспортные процедуры в модулях документов, которые формируют таблицу движений по этому регистру (она используется в ДвижениеПартий, как параметр).

Можешь рассказать поподробнее?
Или поделиться этими процедурами.

Завтра с работы вышлю. Там все нехитро.
Главное: снять флаг оперативного проведения в учетной политике.
Я бы сделал так:
- установил границу поближе к текущей дате;
- снял флаг оперативного списания партий;
- оформил регламентное задание восстановления ПУ.
И посмотрел, что получается.
А потом уже смотреть размеры таблиц и пр.

(10) >>Собственно цель: сократить размер таблицы остатков.

А зачем её сокращать?

(6) и (10), нет?

+(14) это к (13)

(14) Так пока нифига не понятно, в чем проблема. Че тут вообще обсуждать? Методом тыка можно попробовать и РАУЗ прикрутить, вдруг быстрее станет :) Сам факт того актуальная граница или нет, никак не влияет на быстродействие.

(16) Не влияет, но может сигнализировать, что с ПУ ВОЗМОЖНО не все в порядке.
(13) Что партии подбирались быстрее. Для неоперативного списания не критично.

(17) куда подбирались?

(18) Какие партии списываютя.

если версия древняя, то правка одного запроса ускорит проведение документов в 5 раз. граница последовательности хз где не говорит о том, что итоги по партиям не закрыты.

(20)Что за запрос?

А на кой ляд этот партионный учет вообще включен? Кому вообще нужна эта фикция?

(22) Вдруг у них хранятся на складе товары в коробках с бирками-партиями :)

(23) Угу. Прямо так кладовщики и подбирают по партиям. С учетом описанного выше бардака. Сплю и вижу. И задним числом никто ничего не вводит.

(24) Ну еще партионка в программе помогает избежать ситуации более-менее "плавного" повышения рентабельности в отчетах по тем товарам, по которым закупочная цена скачкообразно изменилась.
Сидит такой топ и смотрит - бац! - скачок в отчете (по сравнению с предыдущим месяцем, например).

Ну а чо - хоть какой-то прок от этой фикции, вдруг кому-то именно так и хочется отчет видеть )

(26) Можно еще смотреть отчет стоя на голове, жонглируя при этом тремя степлерами. Вдруг кому-то именно так и хочется отчет видеть.

(27) Кстати есть доработки очетов еще на обычных формах, чтоб надпись "Отчет формируется" крутилась по кругу под всеми углами ))

а сколько запрос по получению партий выполняется?

(25) Тем самым позволяет выявляет ошибки в приходных накладных. Т.е. когда цена было 200 рублей а тут бац и 250, при том что продажная 240. И начинаешь разбираться что за косяк, девочка цифры местами поменяла или по результатам инвентаризации нашли товар и поставили ему завышенную цену.
А вот учет по среднему в этом случае "размазал" бы пики и скрыл ошибки в учете

Вот, хоть кто-то в (30) видит пользу :)

(0) да.
Быстродействие будет в том что объём выборки итогов будет меньше при нормально закрытом регистре то бишь тебе для перелопачивания вернётся 30 тыс записей а не 300 тыс