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

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp4062 as Фирма,
rr405_vt.sp408 as Номенклатура,
rr405_vt.sp418 as Склад,
rr405_vt.sp3117 as ЦенаПрод,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp4062,
rg405_vt.sp408,
rg405_vt.sp418,
rg405_vt.sp3117,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp418 = '     6   ')         AND (rg405_vt.sp408 IN (

            SELECT DISTINCT СтрокиДокумента.sp1599 [rg405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')
)))
union all
select
ra405_vt.sp4062,
ra405_vt.sp408,
ra405_vt.sp418,
ra405_vt.sp3117,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
inner join _1sjourn as j405_vt (nolock) on j405_vt.iddoc = ra405_vt.iddoc
where j405_vt.date_time_iddoc > '20140401' and j405_vt.date_time_iddoc < '201404255ODW9C 69AFMЯЯЯ'
and j405_vt.rf405 = 0x1
and ((ra405_vt.sp4062 = '     2   ')         AND (ra405_vt.sp418 = '     6   ')         AND (ra405_vt.sp408 IN (

            SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')
)))
) as rr405_vt
group by
rr405_vt.sp4062,
rr405_vt.sp408,
rr405_vt.sp418,
rr405_vt.sp3117
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки
GROUP BY
    ОстаткиТМЦОстатки.Номенклатура

Причем если убрать условие по списку номенклатуры из второго подзапроса, то выполняется за 2 сек, если оставить, то 53 сек. Подскажите что можно глянуть? Фрагментация индекса таблицы DT1611 0.01.

Сам запрос

SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')

формируется быстро

тыб лучше просто запрос привел

как минимум, выкинуть DISTINCT везде, это для начала

и так еще - нафейхоа выбирать во вложенном запросе полей больше, нежели требуется в результате?

во вторых, выкинуть типизацию из подзапроса..

Вообще вложенные вопросы и IN работает медленнее чем временные ьаблицы

(5) сравнивать надо

странно почему до сих пор нет группы sql для таких случаев?

потом, установить галку "быстрая обработка движений" у регистра и из текста запроса выкинуть соединение с
_1sjourn

(5) брехня

(8)Если я установлю галку то 1С не будет джойнить таблицу регистра с журналом когда запрос передает? Или мне самому как-то надо будет указать?

(10) ты этот запрос откуда взял то хоть ?
Исходный текст запроса в студию.

(10) у тебя позиция уже в самом регистре будет, в движениях. поэтому джойнить не нужно будет.

(11)из профайлера у него запрос.
а в исходном - это ВТОстатки.

(11)ТекстЗапроса = "
    //|SET @Номенклатура = ?
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |        AND (Номенклатура IN (
    |            SELECT DISTINCT $СтрокиДокумента.Номенклатура [Номенклатура $Справочник.Номенклатура]
    |            FROM $ДокументСтроки." + "Реализация" + " AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт)
    |)),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
    |";

(13) это понятно, просто он туда еще соединений своих напихал..

Причем так быстрее

(14)
выкини дистиникт и типизацию!

|SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры
    |)),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура

(17)выкинул, не помогло

Я бы условие наружу вытащил, серверу так проще будет.

(20)Не в параметрах ВТ чтоли условие наложить? Просто через Where?

воткнуть галку быстрая обработка движений, в параметрах ВТ воткнуть только измерение (Номенклатура), выкинуть GROUP BY из текста запроса

(21) да
когда оно в параметрах ВТ, то этот запрос будет гарантировано 2 раза выполняться

(22) На тестовой поставлю галку, посмотрим сколько будет обрабатываться регистр

Сделал так, не утешительно тоже.

|SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |Where    ОстаткиТМЦОстатки.Номенклатура IN (        SELECT  $СтрокиДокумента.Номенклатура
    |            FROM $ДокументСтроки.Реализация AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт))";

помимо галки можно еще ускорить

(25)как?

+(26)я так понимаю можно еще поменять порядок измерений в регистре, сильно поможет?

(26) изменить периодичность хранения итогов. Выставить 5 дней.

(26) если речь идет об остатках текущего дня
то вместо
остаки на начало периода + оствтки до документа

надо считать
остатки след период - (остатки от тек документа до конца месяца )



не знаю вроде это должно быть заложено в вирт функции но точно сказать не могу.

"Стали долго проводится документы" - а после каких действий стали проводится долго ? Я так понял, что было все хорошо и внезапно стали проводится долго.

*проводиться

(27) С изменением порядка осторожнее. Стандартные функции получения остатков из регистров могут перестать работать.

Вообще запрос у тебя нормальный в (24) стал. Перезагрузи SQL, или очисти процедурный кеш. После этого советую план запроса посмотреть - там ты и увидишь узкие места.

(24) Еще лучше всего фильтр делать в порядке измерений регистра. Тогда попадешь в индекс. Попробуй поменять условия склада и номенклатуры местами. Должно помочь.

(29) в виртуальной таблице это есть....

(32)Порядок в фильтре поменял. План выполнения показывает что 46% уходит на Clustered Index Scan. Чистка кеша на тестовой базе помогла немного. Видимо людей выгонять надо из базы чтобы почистить чтоли. Делаю командой  DBCC FLUSHPROCINDB(@DatabaseID)

(35) Если порядок фильтров по измерениям, то должен быть Index Seek.

Статистика обновлена?

(35) Порядок в фильтре в запросе до лампочки. Важен порядок измерений регистра в конфигураторе.
Но изменение чревато (32).

(34) ну там по моему сравнение идет по 15 число
но в данно м случае лучше переписать как в (29) без вирт функции ,чтобы всегда так считалось

(10) непонятно галку на отбор по движению товаров поставил ?



Как бы ставь галку на движение товаров
и пиши (29) сам руками с учетом что тебе не нужна _1sjourn - и будет тебе счастье.
(но с другой стороны галка немного замедлит перепроведение
документа)  должен решить что важнее тебе решать.

(35) Напиши сюда порядок измерений регистра из конфигуратора.

(37)+ Хотя на какой таблице идет "Clustered Index Scan" ?

(35) В запросе (24) добавь отбор по нужной тебе номенклатуре :)

+(41) Ведь твой документ же двигает только мелкую долю номенклатуры, а не всю БД за 1 сек :DDD

(41) В пероначальном варианте у него и было в параметрах ВТ условие на номенклатура.

(38)Галку поставил на тестовой, но пока регистр обрабатывает, записей там не мало

(39)Фирма, Номенклатура, СКлад, ЦенаПрод
(40)На таблице _1SJourn. Сейчас выполнил запрос на рабоей к регистру партий, показывает ПОиск ключа по таблице _1SJourn 51%. Index Scan по таблице RA405(Регистр Партии) 23%

(44) Галку какую поставил ? Быстрая обработка движений для регистра или Отбор движений на измерении Номенклатура?
Первый вариант должен точно помочь.

(46)Быстрая обработка движений, но регистр еще обрабатывается. Ночью поставлю на рабочей базе, посмотрим сколько будет обрабатывать.

Надо добавить самому индекс по IDDOC+sp1599 для табличной части документа.

(43) >>> Номенклатура IN (
    |            SELECT DISTINCT $СтрокиДокумента.Номенклатура [Номенклатура $Справочник.Номенклатура]
    |            FROM $ДокументСтроки." + "Реализация" + " AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт)

Ты про это?
Это же кто так пишет?
Он же Тупо отбирает все из Документа Реализации, по Табличной части :)
При этом, это скорей всего Тот же самый документ, который и проводится.
А если он Новый и еще не записан? :)

(49) Да, это.
Ему как бы и нужна вся табличная часть в условие. Что быстрее, создать временную таблицу или отобрать по индексу спорный вопрос. Хотя сам склоняюсь к УложитьОбъекты().
Этот код, скорее всего, в модуле документа выполняется при проведении, он никак не может быть НЕ записан к этому моменту.

(50)Уложить объекты немного быстрее работает, использую его. Да, код выполняется при проведении.
ПРоставил галки Быстрая обработка движений у Остатков и Партий на тестовой базе.
Запрос на получение остатков стал выполняться 7 сек, План выполнения говорит что Clustered index scan в таблице регистра 88%. Фрагментация индексов у регистра не указана вобще.

кто в итоге победил?

(51) 7 секунд ? Это непростительно долго.

регистры поди еще и не закрыты.. 7 секунд, это по останкам на складах или по партиям ?
индекс скан по какой табличке ?

(54) судя по всему, ОстаткиТМЦ

(55) там вообще всё мгновенно должно выполняться

самая "легкая" табличка регистра

И это, как и чем делается замер выполнения запроса ?..

(58) замер делается в СКЛ запросом, который выполняется в профайлере. Индекс скан по таблице _1SJourn. Если неделю назад документ проводился  за секунду в базе монопольно, то сейчас стал почти минуту. Остатки ТМЦ около 6-7 секунд, Партии 10-11. Как узнать закрывается регистр или нет? По ргистру остатков быстро данные получает, а вот обороты хромают.

(59) раньше работали в терминале, сейчас - локально...??? или м.б. посмотри как путь к базе в стартере прописан?

(59) Ну и что произошло за эту неделю? Перепроводили, меняли сеть, сервер, терминал-локально, ... ?
Закрываются или нет легко проверить - выгрузи итоги или отчетом универсальным посмотри
Может быть надо переиндексировать, смахнуть пыль

(60)Большая часть работает в терминале
(61)Документы проводятся каждый день массово, сервер не меняли. Реиндексация каждое воскресенье делается, но в этот раз с ошибкой вывалилась. ПОпробую попросить время запустить чтобы.

(61)А по весу табличек регистров не смогу определить закрыт он или нет?
Где то в инете натыкался, но там для ДБФ было вроде.
А как отчетом универсальным посмотреть, подскажи пжл, ато не соображу?

(62) Кстати, для обслуживания индексов и статистик есть такой замечательный скрипт  http://infostart.ru/public/256292/
В рабочее время можно запустить его в режиме сбора статистик.

Что касается незакрываемости регистров, то врядли это твой случай - тогда пухнет табличка RG, а у тебя что-то странное с RA/_1sjourn. Типа, вдруг резко увеличилось количество движений.
Ещё кстати: а что там с "degree of parallellism"? оно иногда весьма неожиданный эффект даёт.

(64)Вобщем выставил галку Быстрая обработка движений у регистров Остатки и Партии.
Переписал условие по списку номенклатуры через MetaDataWork чтобы исключить временные таблицы и джойн с журналом. В итоге запрос по остаткам выполняется 5 сек.
Узкое место все также показывает Индекс скан.
Максимальная степень параллелизма - 1.
Скрипт скачаю, запущу, посмотрим что покажет. Только какие параметры там выставлять надо? Как на примере?

(65) на самом деле я наврал про проблемы с RA - расклад в процентах нормальный, в RA действительно данных больше. Ради интереса посмотрел расклад и время на тестовой базе (около 10тыс. движений в мес.)  - в процентах расклад похожий, время - меньше секунды.
5 сек - это правда что-то запредельное.

(66)Вот уже не знаю куда копать. Скрипт запущу на тестовой, посмотрю что выдаст.

(65) индекс скан по какой табличке ?

(68)по таблице RA и у Остатков и у Партий

Текст запроса сейчас какой хоть ?

(70)Который в профайлере или в 1С?

lf lfdfq b njn b njn

ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
    |";

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp4062 as Фирма,
rr405_vt.sp408 as Номенклатура,
rr405_vt.sp418 as Склад,
rr405_vt.sp3117 as ЦенаПрод,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp4062,
rg405_vt.sp408,
rg405_vt.sp418,
rg405_vt.sp3117,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры)))
union all
select
ra405_vt.sp4062,
ra405_vt.sp408,
ra405_vt.sp418,
ra405_vt.sp3117,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ'
and ((ra405_vt.sp4062 = '     2   ')         
AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))
)
) as rr405_vt
group by
rr405_vt.sp4062,
rr405_vt.sp408,
rr405_vt.sp418,
rr405_vt.sp3117
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки
GROUP BY
    ОстаткиТМЦОстатки.Номенклатура

Выкинь гроупбай из текста запроса и сумму, воткни (Номенклатура) в параметры виртуальной таблицы + условия в ВТ задай в том же порядке, что и измерения в регистре

и.. странно, что примитив с debkred  в ВТ реализован через case, а не просто через умножение.
Это, 1cpp какой хоть версии у тебя ?

(75) не тот видимо копировал запрос, вот текущий
ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

(76)Версия DLL 2.5.0.8

(76) debkred через case в любой версии 1cpp

(78) странно, а чего так ?

(79) есть существенная разница?

еще, чтобы вместо условий
period={d '2014-03-01'}
date_time_iddoc > '20140401' and date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ'

было что то типа:
period={d '2014-04-01'}
date_time_iddoc > '201404298FCZV4 6AIESЯЯЯ' and date_time_iddoc < '20140501'

в модуле проведения допускается использовать
ОбратныйРасчетОтТА(1)

(80) ага, религиозные убеждения :)

я бы на месте автора воткнул быструю обработку движений по измерению Номенклатура и вернул фильтр по $ДокументСтроки

(83) слушай, лень профайлер открывать, при указании конкретного измерения в параметрах ВТ, вт же не разворачивается в запрос, как в (74) , т.е по всем измерениям ?..

(84) ага. Там и профайлера не надо, достаточно select *

(84) нет, не разворачивается
(74) не соответствует (77)

(86) я так и знал :)

что одна из черепашек врёт.

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

сдаётся, что это не время выполнения запроса, а время еще чего - например, показа тз через выбратьстроку, еще чего.. хз в общем

(90) типизация 100500 строк номенклатуры?

(91) ну не знаю, всё равно не 5 секунд :)

(90)
пЗапрос = СоздатьОбъект("ODBCRecordSet");
    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

пЗапрос.УстановитьТекстовыйПараметр("КонДата", СформироватьПозициюДокумента(Конт.ТекущийДокумент(), -1));
    пЗапрос.УстановитьТекстовыйПараметр("Фирма", Фирма);
    пЗапрос.УстановитьТекстовыйПараметр("Склад", Склад);
    
    СписокНоменклатуры = СоздатьОбъект("СписокЗначений");
    Конт.ВыгрузитьТабличнуюЧасть(СписокНоменклатуры, "Номенклатура");
    пЗапрос.УложитьСписокОбъектов(СписокНоменклатуры, "#СписокНоменклатуры", "Номенклатура");
    
    пЗапрос.Отладка(1);
    Сообщить(ТекущееВремя());
    пТЗ = пЗапрос.ВыполнитьИнструкцию(ТекстЗапроса);
    Сообщить(ТекущееВремя());

Выдает

11:44:54

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp408 as Номенклатура,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp408,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))         AND (rg405_vt.sp418 = '     6   '))
union all
select
ra405_vt.sp408,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404255IQX5S 69A9KЯЯЯ'
and ((ra405_vt.sp4062 = '     2   ')         AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))         AND (ra405_vt.sp418 = '     6   '))
) as rr405_vt
group by
rr405_vt.sp408
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки

11:45:01

_GetPerformanceCounter() точнее
Тут все может быть по-разному, т.к. кешируется
А вообще посмотри план выполнения
Но думаю лучше навести порядок как я писал ранее

(89)индекс-скан по индексу DATETIME на периоде в месяц при большом количестве движений может и 5 и более секунд делаться

(95)4 раза выполнил запрос с _GetPerformanceCounter, выполняется все дольше и дольше: 8141, 8818, 12616 и 14724

(96) а чего скан ?

(97) порядок измерений в регистре какой хоть ?

(99) Фирма, Номенклатура, Склад, ЦенаПрод

(97)чой-то у тебя неправильно. по идее, закэшироваться должно, и в ближайшее время выполняться моментально....

Так, сколько ?

    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    | where Номенклатура IN (Select Val FROM #СписокНоменклатуры)
    |";

+102 ну и совет с ОбратныйРасчетОтТА(1) сделал ?

ну и это, воткни turbomd наконец (чтоб на лету модули править) и  обнови 1cpp до последней.

(102)Выполнил 4 раза также: 15072, 11102, 11421, 10420
(103)Если у меня ТА на 30 число, а док на 25 это не помешает?
(104)Щас база восстановится тестовая, буду там пробовать.

>>> у меня ТА на 30 число

Нахрена ты её туда задвинул ?!

(105) задвинь ТА на конец года. а лучше - лет на 100....

(106)Иначе доки не проводятся, много документов на 23:59:59

(106)не существенно, мы же рассматриваем проведение не актульного документа.

(109) ? та ну ? у него щас все доки в заднем числе :) ну и шерстить ra как то не очень.. тем более, записи целого месяца.

а так, в потоке бы проводил и привет

(110) "у него щас все доки в заднем числе :)"
кто сказал?.. не факт

(108) зачем ты их туда задвинул ?

(112) ну как это не факт ? ТА то он вперёд толканул, в 30 число, а проводит 25-е

+ расчет не от ТА стоял, целый месяц напрягать ра приходится запросу.

(111) проводил бы в потоке - не дергалась бы ra вообще - не возникло бы проблемы, не пришлось бы исследовать

ну , точнее 25 дней :)

(116) я за то и говорю, нахрена он та задвинул вперёд ?
:))

(114) ааа я тебя не правильно понял
"у него щас все доки в заднем числе :" - я подумал, ты про то, что все доки 30

А так, период 5 дней.. и можно вообще забыть, где там ТА..

(113)Если у текущего непроведенного документа дату поменять на 5 дней вперед, то время меняется же? Либо при записи ставить время документа?

у мну тоже доки разрешено проводить будущей датой.
и текущее проведение всегда неактуальное
живу спокойно, все проводится моментально
(периодичность итогов - месяц)

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

(123) для начала, (81) и (103) сделай...

(124)Попробовал в обработке: 302, 298, 297, 317. Конт указал просто ссылку на документ.
Только какие могут быть последствия?

+(125)Я только не пойму, если у меня нет итогов еще на 1 мая, как результат то корректный получается?

(126) че ?..

(125) "Только какие могут быть последствия?"
никаких, кроме ускорения
Но замечу, что ОбратныйРасчетОтТА можно применять только в модуле проведения, либо в иной транзакции с блокировкой проведения документов

(126) итоги на начало 1 мая = итогам на конец 30 апреля. Логично же.
А итоги на конец апреля как раз таки записаны тут period={d '2014-04-01'}

(128)Т.е. в глобальнике при проведении можно смело использовать?
(129)Не пойму, тогда зачем движения еще с 25 по 30 апреля?

art_id, sql сервер какой версии?

(131)2005

(130) глобальник не причем. при проведении - да

Движения 25-30 _вычитаются_ из итогов на конец 30апр
Иначе, движения 1-25 прибавляются к итогам на начало 1апр
Посмотри внимательно в отладочные запросы. Обрати внимание на даты и знаки

+ на знаки в этом выражении case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end

(133)Увидел, спс

(129) только одно непонятно - почему для итогов на конец месяца выбрано первое число....

(130)
2. останки не на ТА вычисляются как предыдущий остаток + (приход - расход до нужной даты), либо останки на ТА - движения до документа..

(134) а почему все-таки кейс, а не умножение?

(136) наверно потому что первое во всех месяцах первое, а последнее - разное

(138) выше сказано - религия наверно

(137)НЕ обратил внимание что в первом случае складываются, а во втором вычитаются.
Попробую сегодня скрипт запустить из (64), странно что ни с того ни с сего вдруг стал долго выполняться запрос.

надо бы как-нить померить скорость с кейсом и без..

(139) Ну, фактически же это остатки на начало следующего? я бы взял первое число следующего....
хотя твоя логика тоже

(138) это реально вопрос религии: я проверял на несколькоих миллионах записей - разница в рамках статистической погрешности.

(141) нехрен ТА вперёд загонять.
Раньше документы в "потоке" проводились и запрос просто обращался к одной табличке - к RG.. а сейчас молотит еще и тяжелую RA

(140) другая (моя) версия, автор ВТ подсмотрел это у самих одинесовцев

(143)ага, а что брать для периодичности 5 дней, к примеру ? :)

(144) ок, спасибо. я не проверял на больших объемах.
Хотя кейс - он читабельнее для человека, поэтому раз не быстрее - значит, правильнее.

(147) убил.

(145)всегда ТА была на 7 дней макс вперед установлена

(142) ничего не выявишь.даже померить проблематично.
как бы case более правильней с точки зрения неявного преобразования типов. ну если так нравиться умножение то пиши
в нем явное преобразование типов.