Можно ли как-то ускорить выгрузку итогов на ТА
Регистр.ВыгрузитьИтоги(ТЗ,1,1)
.
???

(0) 1C++ не предлагать?

(1) опередил)

ВыгрузитьИтоги итак самый быстрый метод при работе с регистрами.

(3) Речь ИМХО о предварительном расчета на определенную дату,а затем уже выгрузить Итоги

А так соглашусь в (3)

Ну и конечно предварительно наложить фильтров по макимуму

(4) у него на ТА, там особого ускорения не поимеешь, быстрее, но не на много

(6) не на много - это сколько?

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

(7) меряй, всё зависит от твоего железа.

скажем так, милисекунды.

проверено , что без фильтра быстрее выгрузитьитоги на ТА

при условии что нет незакрытых

40 000
выгружалось и фильтровалось без 1с++

быстрее чем 10 000 с фильтром

проверено для скл версии при условии , что скл и клиент на разных машинах.
сеть 100 мбит

(11) сейчас попроьуем.. отрубил фильтр по списку товаров, оставил только по фирме...

(12)

выгрузить итоги в отличие от запроса

выгружает разом все записи (запрос - поциями по 50)

(13) да, получается ощутимо быстрее; но все равно вилы - выигрыш нивелируетс необходимостью потом "фильтровать" ненужные записи в итогах...
.

(13) Запрос без сиквела свой результат еще и на диск сбрасывает...
(14) Чтож ты такого задумал в реальном времени то?

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

такс.. ладно, а как в ТЗ, где в одной колонке "Документ" - быстро отрезать часть ТЗ для Документов > КакаяТоПозиция...?

(15) супер мега алгоритм.. как всегда...
.
в принципе-то понятно где можно порыться еще для ускорения, но это уже будет существенная перепись алгоритмов...

а хороший сервер купить  лимона за три никак???

(19) а накуа..? чтобы его юзать пару дней в году...?
.
вот лучше если бы была аренда машинного времени на суперкрее каком-нитьь. залилтуда 1сину (с ВК!!) жмакнул и все... 20-30 мин вместо 3-8 часов...

(19) вот уменя есйчас крутится на сервере - ну и фигли - загрузка памяти небольшая, параллелизьма нет... диск сказевй с базой и все... куда уже быстрее... алгоритмы почти штатные, проводится документ 100-150 строк за секунду примерно... если отрубить фичу которую написал - будет процентов на 10-15 быстрее... все равно все время жрет расчет временных итогов...

Временные итоги - зло.
1С подложила большую свинью неокрепшим одинэсникам, заставив их поверить в реальность машины времени.

(22) А что есть временные итоги и чем их можно заменить? РассчитатьРегистрыНа - оно?

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

(23) оно, чем их заменить

(25) Не понял. И как этот метод заменять? Остаток актуальный минус Обороты?

(26) упрощенный вариант: если документ проведен в заднем числе - значит когда-то все было ок. ну так и считаем что на момент документа все есть ок. теперь проверяем что будет если проведем документ с новыми данными: если на ТА остатки не ушли в минус - значит все ок! (этот метод не гарантирует уход в минуса на участе от документа до ТА)
.
правильный вариант: похож на предыдущий но гарантирует что остатки не уйдут в минуса на всем протяжении от документа до ТА; накладные расходы - незначительные.

по упрощенному варианту вроде как похоже в 8-ке сделано при неоперативном проведении, ибо ничего умнее придумать не смогли.

(28) А разве там при неоператовном что-то контролируется?

(27) а-ля 8.2. Понял, спасиб.

(29) хз.. я ж не 8-ик; у  меня, например, при неоперативном проведении по критичному регистру - контролируется все - если не хватит в любом месте - выругается...

(30)  не.. судя по всему в 8.2 еще проще сделано при неоперативном проведении... но тут надо чтобы 8-ки пояснили...

Ну раньше они ничего не контролировали. Типа задом двигаешь - сам себе злобный буратино

может конечно в УТ11 что-то и поменялось

Типовые конфигурации 1С, такие как "Управление торговлей" или "Управление производственным предприятием" контролируют остатки определенных регистров (например товарных регистров) только при оперативном проведении документов (текущим моментом времени). При неоперативном  же проведении (как правило "задним" числом, т.е. в прошлом) этот контроль считается бессмысленным с точки зрения 1С (с) http://forum.infostart.ru/forum24/topic35110/

Ну и местные v8: Контроль остатков при неоперативном проведении

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

(35) в этом есть определенный смысл, но только в частных случаях. приемлемого решения для общего варианта - 1С предложить не смогла. Хотя в части количественного контроля - реализуется не так уж и сложно и нересурснозатратно.

(37) стоимость списания - это некая нематериальная сущность.. и опыт поазывает что все траблы начинаются там где пытаются количественно выражать нематериальные сущности.. ;-)

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

(40) Ну да. Даже в методологии 8.2 заложено, сначала делаем движения, потом смотрим, а если минуса. Т.е. предполагается, что товара всегда хватает, и поэтому можно смело проводить, и не блокировать базу расчетом и проверкой остатка. А когда уже провели, можно и спокойно посмотреть, а что получилось. В крайнем случае удалим движение, если нехватает

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

(0) Некоторый прирост может дать установка флага "Отбор итогов" для измерений по которым накладываются фильтры. Но это необходимо пробовать, т.к. эффект достигается не всегда. И расплата будет в виде увеличения размера ИБ за счет добавления индексов и увеличения времени формирования записей в регистр (то бишь времени проведения).

(22) Речь ведь о времени выгрузки на ТА, а не временном расчете.

Кстати, orefkov несколько лет назад озвучивал решение позволяющее отказаться от временного расчета регистров.

(43) решение, насколько я помню, было по (27) по упрощенному варианту; если найдешь ссылку на рецепт orefkov - кидай! освежим в памяти

(0)
Автор, используйте 1С++, выигрыш по производительности превышает 100 раз, сам делал снижая время формирования отчета с 1 часа до 30 сек.
Естественно имеет смысл только для большого количества данных.

(44) Выгрузка итогов на ТА, расчет временных итогов и контроль остатков при проведении задним числом не одно и то же, хотя и связаны.

Ссылка есть, но кидать не буду. Пользуйтесь поиском, знания надо добывать :)

(46) спасибо за пинок, у меня работает из (27) правильный вариант, а у Орефкова было по типу упрощенного.

(47), в смысле пинок? я пытаюсь вам помочь в решении вопроса производительности, вам более конкретно расписать или ссылок на литературу дать?

Если не устраивают конструкции 1С++, можно компоненту использовать только как оболочку для прямых запросов к БД.

(48) пинок это было ироничное в сторону (46)

(48) я в курсе про 1С++ и что она может ;-) использовал.. но в прямых запросах я слабоват,
так что про "более конкретно расписать" - тут поможет только конкретный код прямых запросов на замену РассчитатьРегистрыНА()... ;-)

http://www.script-coding.com/Direct_queries.html
тут очень емкая статья, описано все, но очень кратко.
Для вашего случая можно сначала посмотреть "главу 7", если не получится придется перечитать все с начала. Если не получится что-то конкретное можно задать конкретный вопрос.

Для сильно неравномерно распределения документов в месяце, можно переписать виртуальную таблицу Остатки, но для этого нужен некоторый опыт запросов к SQL

(51) знаю эту ссылку, есть там кое-где вроде нерассказанные тонкости, в т.ч. и по периодичности регистров... ладно, спсб, как вопросы будут - задам; обычно помогают, нормально... ;-)

(47)
Ты упустил одну важную деталь в моем способе, делающую его не настолько упрощенным, как описано в (27) :)
Это фирма 1С не смогла придумать ничего более лучшего, как положиться на авось при списании задним числом, а моя метода безо всяких временнЫх расчетов и проверки всех движений гарантировала правильный порядок списания партий и неулетания в минуса на всем временнОм отрезке от дока до ТА.

(54) а где почитать?

(55)
Да где-то здесь же...
http://www.google.ru/search?ie=UTF-8&q=orefkov+списание+партий+site%3Amista.ru
тут к примеру
А что если отказаться от рассчета регистров при получении партий ?
v7: Кстати, а разгадали секрет метода У ЛЮ - 2?
да много там веток всяких.

(56) "Достаточно постулировать, что в каждой партии может быть только один приход, и в дальнейшем партия только списывается."

А как же возвраты? рожать для них новые партии?

(57)
Внимательнее читайте :)
Вопрос обсасывался. Для этого и добавляется в регистр измерение "МоментПоступления". Приход ставиться в ту же партию, но с другим МоментомПоступления, равным моменту прихода возврата.

(58) перемещение, как я понимаю, в этой схеме не учитывается никак ?

ё

(58) ну, вообщем, у меня аналогично сделано.

единственное я не дотумкал как это прикрутить чтобы по суммам правильно было...

собственно тяма в монотонности функции остатков (56) - к этому я пришел не из упоминавшихся, а в результате большой переписики с SELENAT.
.
Едиснтвеннное, что осталось нерешенным - это суммовой учет... если при изменении задним числом поменять сумму прихода/расхода - как обеспечить правильность ранее спи санных сумм - непонятно.....

(63) а чего там с ним ?
восстановишь гп и привет.
Этот метод токма гарантирует тебе "защиту от красноты" в останках, и что всё потом перепроведется без проблем и привет.

> Основной гимор при ЗЧ - уменьшение прихода. Может не дать провести документ с уменьшенным приходом, тк часть или весь товар с этого поступления уже списался, хотя в-принципе, мог бы успешно списаться и из других приходов.
- у меня в принципе это решено. списывать остатки следует по ЛИФО, тогда при уменьшении прихода требуемое колво всегда можно добрать из более ранних приходов. Единственное здесь чутю-чуть усложняется расчет итогов при заднем числе - приходится учитывать минусовые остатки по некоторым "партиям", списывая их с более ранних приходов. По крайней мере у меня такая конструкция успешно работает. Единственное что было отмечено ранее - восстановление ГП все равно остается, но превращается в чисто технологическую процедуру при этом 100% проходящую без затыков.

(64) ну.. это не интересно... ;-) хотелось чтобы без восстановления ГП правильно было... ;-) - но пока не придумал.. не выходит каменный цветок.

кстати, если есть ТЗ, в которой в одном столбце есть "позиция" и ТЗ отсортирована по позиции в хронологии - как быстро обрубить строки которые позже некой выбПозиция..? Индексированной таблицей это можно сделать..? - сделать ключ по позиции... ?

а получить сразу нужную тз не судьба ? Это лучше, чем потом фильтровать её.

(68) а как ты получишь нужную ТЗ - либо Рег.ВыгрузитьИтоги(ТЗ) на ТА + отсечение  по ТЗ, либо запрос на ТА с отсечением сразу в запрсое - но будет ли это быстрее..?

(63)
Ну, если проследить тут хронологию, то это он мою методу пытался развить до чего-то большего.
(69)
Если без всяких ВК, то я бы на достаточно больших ТЗ находил граничную строку бинарным поиском. А так конечно, лучше сразу получить запросом с уже откинутыми остатками.

(70) да, наверное - тогда была большая ветка по этому вопросу.

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

(70)На (59) так и есть ?

(72) :)
на проклабе полно алгоритмов для удаления строк из тз.
Не так и много времени займёт.
Естественно, никаких УдалитьСтроку там нет (это один из самых медленных способов при работе с тз)

(67) ТЗ.Заполнить() не прокатит?

(74) я в курске! "удаление" идет првильно, надо просто быстро найти граничную позицию - в демо я тупо перебором делал, потому что объемы маленькие.
.
если запросом получать итоги на ТА с обрезкой уже в запросе - это намного быстрее будет если резать таблицу быстрым поиском граничной позиции..?
.
(70)  orefkov - у тебя как - поиском по ТЗ или запросом режется?

(76) запросом быстрее

(77) спсб!

у меня просто объемы базы/данных не такие большие чтобы серъезно вставал вопрос об оптимизации всего и вся (прямые запросы и прочее) - потому и не использую особо...

(78) ты там, с перемещением что делать будешь ?

(80) а точно также по идее. с поправками на то, в каком регистре что надо отрациь по перемещениям. основной смысл - любой приход на склад - это всегда новая "сущность", в решении Орефкова эта сущность чтотоучетное+моментвремени.
.
в демо-конфиге своей я пишу не момент времени, а позицию
а вот в рабочей конфиге ступил немного - пишу "партиеобразующий" документ... соответсвенно в запросе надо как-то будет отрезать документы которые выше ВыбДокумент - как это сделать в запросе - пока слабо представляю (если не адресоваться к позиции документа)

(81) Это как ?
Ты делаешь приход  - расход при перемещении, с каким измерением ?

(82) давай определимся по какому регистру хотим учитывать перемещение?
.
стучи в мыло [email protected] свою аську - фигли тут секреты выдавать? ;-)

не, точно - доделаю нафиг демо-конфигу по работе без временных итогов и буду продавать ;-) (апологетам вопроса - раздача бесплатно!)

(83) Чебур, ты меня удивляешь..
Тут половина ветки про Партии, про что же еще ?!
:))

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

(86) в каком месте ?!
Я задавал еще вопрос Орефкову - ответа так и нет..
Из его постулата - 1 раз приход, пишем момент времени прихода и привет, потом его расходуем.

Теперь, что делать с перемещением ? Приход с каким моментом времени ? Расход с каким ?

(87) любой расход - штатно, любой приход - новая "партия" с новым моментом времени.
в иотоге вместо осциллирующей функции остатков получаешь совокупность монотонно убывающих функций. если монотонно убывающая функция на ТА в минусе - все пипец, нарушение учета

(84) Лучше сделай без работы задним числом :)
По сабжу - все просто - в QA выполняешь запросы, попадаешь в индексы, смотришь планы и выбираешь лучший
Думаю, что можно незначительно оптимизировать ВыгрузитьИтоги(ТЗ)
Гораздо важнее то, как дальше используется эта ТЗ

(89) > без работы задним числом...
- ну так при реализации "орефковщины" - хоть в заднем числе, хоть в переднем - по барабану; это и имелось в виду.
.
а без работы задним числои - ну никак. самый простой пример: банковская выписка, которая сегодня (ибо получена сегодня) вводится за вчера.. или ваще за пятницу...
.
можно и в этом случае обойтись без ЗЧ - но тогда надо переписывать тотально все конфиги - что на 8-ке, что на 7.7 типовые - ибо в них нет разницы между датой регистрации хозоперации и датой к которой относится хозоперация, что конечно - полняа бредятина.. особенно когда начинается скрещивание "бух" и "оу/уу"

А поможет кто составить прямой запрос? он очень простой (для специалиста наверное ;-)
.
Регистр.ОстаткиГТД
измерения(в порядке следования в пофигураторе):
.
Фирма, спр.Фирмы
Номенклатура, спр.Номенклатура
ВидДеятельности, Перечисление.ВидДеятельности
ГТД, спр.ГТД
Документ, тип = Документ (неопределенного вида!)
Ресурс: Количество, число
.
Надо для текущего документа (выбДокумент) и фирмы (выбфирма или списокзначений/таблицазначений(как удобнее) фирм) и списка номенклатуры (тз или списокзначений - как удобнее)
.
получить итоги по регистру на ТА при условии что
Документ(измерение) < ВыбДокумент (в смысле хронологической позиции).
.
база ДБФ, SQLite или VFP - в наличии
.
возможно даже за денежку.
.
спсб если кто откликнеться.

:)
за такое даже деньги стыдно брати..

(92) я не возражаю!!!!!! ;-)

Ну на..тут тупо итоги на ТА, отсортированные по позиции измерения Документ.
Условие сам воткнешь, надеюсь
:)

Остальное - в личной карточке.


ТекстЗапроса="
|Select
|   Итоги.Номенклатура [Номенклатура :Справочник.Номенклатура]
|  ,Итоги.Фирма [Фирма :Справочник.Фирмы]
|  ,Итоги.Документ [Док :Документ]    
|  ,SUM(Итоги.Количество) [КонОст $Число]
|From
|    [РегистрИтоги.ОстаткиГТД] as Итоги
|inner join [Журнал] Жур on Жур.iddoc = substr(Итоги.Документ,5,9)
|where
|     Итоги.period = :ПредПериод
|Group by Итоги.Фирма,Итоги.Номенклатура,idx_date_time_iddoc
|Order by Жур.idx_date_time_iddoc
|";
Попытка
   база = СоздатьОбъект("SQLiteBase");
Исключение
   ЗагрузитьВнешнююКомпоненту("1sqlite.dll");
   база = СоздатьОбъект("SQLiteBase");
КонецПопытки;

база.Открыть(":memory:");
запрос = база.НовыйЗапрос();

мд = СоздатьОбъект("MetaDataWork");
ПредПериод = мд.ПолучитьНачПериода(ПолучитьДатуТА());//начало периода
Запрос.Подставлять("ПредПериод",ПредПериод);
   
запрос.ВыполнитьЗапрос(ТекстЗапроса).ВыбратьСтроку();

(94) вот ты ленивый! нет чтобы и условие воткнуть...

не ну блин реально ленивый: а условие на список номенклатуры? а услвоие на список фирм?
не, ну как так можно...
;-)

дарю:

база.УложитьОбъекты(Список,"ВыбНоменклатура",0,"Номенклатура");
ТекстЗапроса=ТекстЗапроса+"
| Where Итоги.Номенклатура in (select val from ВыбНоменклатура)";

При условии на <ВыбДок юзай модификатор  ~~~ при передачи параметра и сравнивай позицию ..фирщтейн ?

(97) + лучше без Уложитьсписок (тормоз + гадит темпдб)

примерно так:
IN (select distinct $СтрДок.Номенклатура
from $ДокументСтроки.НужныйВидДока СтрДок (nolock)
where СтрДок.iddoc = :Док)
где :Док = ТекущийДокумент()
При большом списке номенклатуры быстрее.
При маленьком списке быстрее в строку уложить через MetaDataWork

(98) :)
это в sqlite - то ?

сто!

(99)упс. прочитал тему по диагонали

ух понапиали-то.. буду н а выходных пробовать...

(87)
Ну, в классике перемещение в партиях вообще не отражается :)
Но в том конкретном случае, который я делал (это было давно, и сейчас я там не работаю) был единый регистр "Товары", с партиями и складами.
Перемещение делалось так:
расход из партии с моментом поступления из итогов регистра.
приход в эту же партию с моментом поступления = доку перемещения.
Т.е было
Товар1 Партия1 Склад1 01.02.2010 20 штук
стало
Товар1 Партия1 Склад1 01.02.2011 15 штук
Товар1 Партия1 Склад2 07.12.2011 20 штук

Опечатка.
Было
Товар1 Партия1 Склад1 01.02.2011 20 штук

Блин, спать хочу.
Было:
Товар1 Партия1 Склад1 01.02.2011 20 штук
стало
Товар1 Партия1 Склад1 01.02.2011 15 штук
Товар1 Партия1 Склад2 07.12.2011  5 штук

Вот.

(90) Зачем переписывать "тотально все конфиги" если речь идет о написании своей?
По работе задним числом я подразумевал ввод документов в хронологической последовательности (как это происходит в реальной жизни)
Про выписку понятно, но такое проведение документа не должно означать восстановление последовательности по взаиморасчетам (и в принципе не противоречит изложенному в пред. предложении)

(103) угумс, так...

(106) > По работе задним числом я подразумевал ввод документов в хронологической последовательности (как это происходит в реальной жизни)
- ну так это сразу приведет к тому, что например по той же выписке: ты вводишь выписку 7 декабря (когда получил из банка), а учитывается она в 6 декабря - когда прошли движеняи по банку - и хоть убейся  для ПРАВИЛЬНОГО отражения придется иметь дату хозоперации и дату "бухоперации", в противном случае например если выписку ввели в 10 утра 7 декабря, а реализация в 9.30 - в одной раскладке получитс янеобходимость отражать авансы с выписок СЧФ, а в другой - нет.. один из этих вариантов - нарушение...
.
или что-то другое имел в виду..?
.
я под (первым этапом!) работой "в заднем числе" имею в виду ввод документов в "точки/моментывремени" бухопераций - и при таком вводе не должно быть противоречий в учете при рассмотрении хронолгической последовательности бухопераций.

(105) ну ясно в общем, приход всегда с новым моментом времени..
Где-то у меня конфа валяется с таким решением.