конфа самописная, SQL
ТА=31.12.13.
Одно из измерений сабжа (партия) - элемент справочника
из вне делаю запросы к RG##  и наблюдаю историю -
сегодня завели партию, двинули регистр - в RG тут же являются записи по всем измерениям от начала месяца (ближайшего периода) вплоть до ТА.
В где руки править?

А как ты хотел?

в ДНК

И вообще - серьёзные люди ТА ставят на 31.12.99

(1) Через какую Ж*** тогда работает НачОст()?

(4) именно через ту. Ибо ты не можешь объяснить, что тебе надо. Так что см (2)

(4) Благодаря этому он и работает быстрее :)

(5) Могу - мне нужно получить начальный остаток на конкретный документ из внешней отчетной системы. Возможно, знаний не хватает, но
- есть понимание про RG и RA
- есть предположение, что такое поведение позволяет двигать регистры задним числом
- и все же - как поступить-то - ведь запрос типа
select sp123,sum(sp124)
from
(select sp123 f1, sp124 f2
 from rg111
 where period=begin
union all
select sp123,sp124*(1-2*debkred)
from ra111
where date_time_iddoc>=@from -- begin+'     0     0   '
    and date_time_iddoc<=@to -- позиция документа
) zz
group by sp123
возвращает лишние записи (из RG)

(7) select sp123,sum(sp124)
читать как
select f1, sum(f2)

Как-то @ по своему отрабатывает

(4) берет предыдущий итог от даты начала периодичности итогов из RG + суммирует записи с RA с начала периодичности итогов  до ДатаЗапроса-1.
Усё.

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

И как бэ, нету у тебя понимания RG и RA, иначе ТА не стояла бы на 31.12.13

(12) А что криминального в этом? (окромя распухания RG, как сейчас выяснилось)

(12) я так думаю, что ТА не (0) поставил туда)

(10) Дата начала периодичности итогов - не совсем понял, что это?

(0) Вы вроде про регистр "остатков" обмолвились!? или это не имеет значения?

(16) в целом,да.

(15) Т.е в этом случае @begin_=dateadd(mm,-1,@begin)

(18) а по RA делаем агрегат начиная с @from по @to из (7)
Так?

(18) не знаю, я SQL в глаза не видел никогда - но что то подсказывает, что ТА Вас обижает - и остатки не правильно берете!
Жди ГУРУ - я в ПУБ подскажу... а Ваш вопрос не по мне...

(18),(19) - бред. Все-же "Дата начала периодичности итогов" - как узнать?

(21) я не знаю что там с SQL - но в файловом режиме (DBF) всегда было и всегда будет, что актуальность остатков по РО - всегда на ТА при быстром отборе... хотя могу ошибаться...

(13)
1. при расчете останков, всегда ты в "заднем числе", т.е при получении останка будут участвовать 2 таблички RG и RA (заместо одной - RG в случае , если документ ТА толкает сам)
что не есть быстро
2. при записи в регистр, надо пересчитывать все итоги в RG позже позиции дока, что тоже не быстро.

(21) открыть наконец предприятие и посмотреть в Операции-Управление оперативными итогами, какая периодичность хранения останков выставлена.
По-умолчанию - месяц.

дата начала периодичности, соотв-но начало месяца, предыдущей - наччало предыдущего месяца и т.д.

(24) ага, значит (18), (19) не бред.
Спасибо, Ёпрст, за развернутые ответы

ознакомься
http://www.script-coding.com/v77tables.html#3.4.2.4.

ЗЫ: хотя для скуля, запрос к останкам мало кто пишет ручонкми, проще ВТ Останки взять из 1cpp,
ну и поля ручонками тоже никто не пишет, есть метапарсер имён

http://www.1cpp.ru/docum/icpp/html/ODBC.html

СПС

(27) Я не пользую 1с++ запросы делаются из внешней отчетной системы

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

(23) Может у него нет временного расчета. ТА можно передвигать раз в месяц на конец следующего и все.

КонецЦикла (просто перетащил)  ну хоть Вы подскажите - вроде везде должно быть одинаково в получении остатков.... при быстром запросе к РО - всегда на ТА

+(33) в (0) ТА=31.12.13! он уверенно говорит об этом!

(33) Время получения АКТУАЛЬНЫХ остатков, конечно, будет в пределах стат. погрешности отличаться

Просто при проведении 1С будет записывать изменения для каждого периода хранения остатков от момента дока до ТА. Вот что мне не понравилось.