|
v7: Ускорить выгрузку итогов на ТА | ☑ | ||
---|---|---|---|---|
0
Злопчинский
06.12.11
✎
00:08
|
Можно ли как-то ускорить выгрузку итогов на ТА
Регистр.ВыгрузитьИтоги(ТЗ,1,1) . ??? |
|||
1
rs_trade
06.12.11
✎
00:12
|
(0) 1C++ не предлагать?
|
|||
2
Азат
06.12.11
✎
00:12
|
(1) опередил)
|
|||
3
Ёпрст
06.12.11
✎
00:15
|
ВыгрузитьИтоги итак самый быстрый метод при работе с регистрами.
|
|||
4
Aleksey
06.12.11
✎
00:17
|
(3) Речь ИМХО о предварительном расчета на определенную дату,а затем уже выгрузить Итоги
А так соглашусь в (3) |
|||
5
Aleksey
06.12.11
✎
00:18
|
Ну и конечно предварительно наложить фильтров по макимуму
|
|||
6
Ёпрст
06.12.11
✎
00:19
|
(4) у него на ТА, там особого ускорения не поимеешь, быстрее, но не на много
|
|||
7
Злопчинский
06.12.11
✎
00:33
|
(6) не на много - это сколько?
|
|||
8
Aleksey
06.12.11
✎
00:44
|
ну при условии что она сама за секунду отрабатывает (если конечно не выгружаешь 10 000 записей), то ...
|
|||
9
Ёпрст
06.12.11
✎
00:44
|
(7) меряй, всё зависит от твоего железа.
|
|||
10
Ёпрст
06.12.11
✎
00:45
|
скажем так, милисекунды.
|
|||
11
МихаилМ
06.12.11
✎
00:54
|
проверено , что без фильтра быстрее выгрузитьитоги на ТА
при условии что нет незакрытых 40 000 выгружалось и фильтровалось без 1с++ быстрее чем 10 000 с фильтром проверено для скл версии при условии , что скл и клиент на разных машинах. сеть 100 мбит |
|||
12
Злопчинский
06.12.11
✎
01:05
|
(11) сейчас попроьуем.. отрубил фильтр по списку товаров, оставил только по фирме...
|
|||
13
МихаилМ
06.12.11
✎
01:08
|
(12)
выгрузить итоги в отличие от запроса выгружает разом все записи (запрос - поциями по 50) |
|||
14
Злопчинский
06.12.11
✎
01:13
|
(13) да, получается ощутимо быстрее; но все равно вилы - выигрыш нивелируетс необходимостью потом "фильтровать" ненужные записи в итогах...
. |
|||
15
Reaper_1c
06.12.11
✎
01:16
|
(13) Запрос без сиквела свой результат еще и на диск сбрасывает...
(14) Чтож ты такого задумал в реальном времени то? |
|||
16
Злопчинский
06.12.11
✎
01:19
|
(13) вернул фильтр взад.. в итоге по всему алгоритму с фильтром - быстрее получается...
|
|||
17
Злопчинский
06.12.11
✎
01:20
|
такс.. ладно, а как в ТЗ, где в одной колонке "Документ" - быстро отрезать часть ТЗ для Документов > КакаяТоПозиция...?
|
|||
18
Злопчинский
06.12.11
✎
01:22
|
(15) супер мега алгоритм.. как всегда...
. в принципе-то понятно где можно порыться еще для ускорения, но это уже будет существенная перепись алгоритмов... |
|||
19
zavsom
06.12.11
✎
01:24
|
а хороший сервер купить лимона за три никак???
|
|||
20
Злопчинский
06.12.11
✎
01:27
|
(19) а накуа..? чтобы его юзать пару дней в году...?
. вот лучше если бы была аренда машинного времени на суперкрее каком-нитьь. залилтуда 1сину (с ВК!!) жмакнул и все... 20-30 мин вместо 3-8 часов... |
|||
21
Злопчинский
06.12.11
✎
01:31
|
(19) вот уменя есйчас крутится на сервере - ну и фигли - загрузка памяти небольшая, параллелизьма нет... диск сказевй с базой и все... куда уже быстрее... алгоритмы почти штатные, проводится документ 100-150 строк за секунду примерно... если отрубить фичу которую написал - будет процентов на 10-15 быстрее... все равно все время жрет расчет временных итогов...
|
|||
22
orefkov
06.12.11
✎
01:40
|
Временные итоги - зло.
1С подложила большую свинью неокрепшим одинэсникам, заставив их поверить в реальность машины времени. |
|||
23
mdocs
06.12.11
✎
01:44
|
(22) А что есть временные итоги и чем их можно заменить? РассчитатьРегистрыНа - оно?
|
|||
24
Злопчинский
06.12.11
✎
01:46
|
(22) угумс... у меня, например вообще можно обойтись без Врем.итогов - количественный учет без врем.итогов я знаю как сделать, суммовые учет меня интересует только в части оборота, т.е. на всякие партионные стоимости не замешан... поэтому конечно переделать все без врем.итогов.. ну.. дня два-три плотно посидеть придется... чтобы по всем алгоритмам переделать...
. а так ак база у мен янебольшая - может ее всю с темпами запихнуть на рам-диск..? - именно на моменты массового проведения - будет ускорение..? |
|||
25
Злопчинский
06.12.11
✎
01:47
|
(23) оно, чем их заменить
|
|||
26
mdocs
06.12.11
✎
01:51
|
(25) Не понял. И как этот метод заменять? Остаток актуальный минус Обороты?
|
|||
27
Злопчинский
06.12.11
✎
01:58
|
(26) упрощенный вариант: если документ проведен в заднем числе - значит когда-то все было ок. ну так и считаем что на момент документа все есть ок. теперь проверяем что будет если проведем документ с новыми данными: если на ТА остатки не ушли в минус - значит все ок! (этот метод не гарантирует уход в минуса на участе от документа до ТА)
. правильный вариант: похож на предыдущий но гарантирует что остатки не уйдут в минуса на всем протяжении от документа до ТА; накладные расходы - незначительные. |
|||
28
Злопчинский
06.12.11
✎
02:01
|
по упрощенному варианту вроде как похоже в 8-ке сделано при неоперативном проведении, ибо ничего умнее придумать не смогли.
|
|||
29
Aleksey
06.12.11
✎
02:03
|
(28) А разве там при неоператовном что-то контролируется?
|
|||
30
mdocs
06.12.11
✎
02:04
|
(27) а-ля 8.2. Понял, спасиб.
|
|||
31
Злопчинский
06.12.11
✎
02:06
|
(29) хз.. я ж не 8-ик; у меня, например, при неоперативном проведении по критичному регистру - контролируется все - если не хватит в любом месте - выругается...
|
|||
32
Злопчинский
06.12.11
✎
02:06
|
(30) не.. судя по всему в 8.2 еще проще сделано при неоперативном проведении... но тут надо чтобы 8-ки пояснили...
|
|||
33
Aleksey
06.12.11
✎
02:10
|
Ну раньше они ничего не контролировали. Типа задом двигаешь - сам себе злобный буратино
|
|||
34
Aleksey
06.12.11
✎
02:10
|
может конечно в УТ11 что-то и поменялось
|
|||
35
Aleksey
06.12.11
✎
02:12
|
Типовые конфигурации 1С, такие как "Управление торговлей" или "Управление производственным предприятием" контролируют остатки определенных регистров (например товарных регистров) только при оперативном проведении документов (текущим моментом времени). При неоперативном же проведении (как правило "задним" числом, т.е. в прошлом) этот контроль считается бессмысленным с точки зрения 1С (с) http://forum.infostart.ru/forum24/topic35110/
|
|||
36
Aleksey
06.12.11
✎
02:15
|
Ну и местные v8: Контроль остатков при неоперативном проведении
|
|||
37
mdocs
06.12.11
✎
02:16
|
(32) Простой запрос без параметра даты среза даст как раз актуальный остаток количества после проведения. Но вся эта простота допустима там где не нужна стоимость списания.
|
|||
38
Злопчинский
06.12.11
✎
02:16
|
(35) в этом есть определенный смысл, но только в частных случаях. приемлемого решения для общего варианта - 1С предложить не смогла. Хотя в части количественного контроля - реализуется не так уж и сложно и нересурснозатратно.
|
|||
39
Злопчинский
06.12.11
✎
02:17
|
(37) стоимость списания - это некая нематериальная сущность.. и опыт поазывает что все траблы начинаются там где пытаются количественно выражать нематериальные сущности.. ;-)
|
|||
40
Злопчинский
06.12.11
✎
02:19
|
видимо, самы максимально быстрый вариант проведения - это расчет и запись толь ко тех данных которые важны для оперативной работы. все остальное - получать по мере необходимости только тогда, когда это надо - похоже, что именно по этуму пути и пошли в 1С со всеми ихними неоперативными проведениями, раузами и прочими приблудами...
|
|||
41
Aleksey
06.12.11
✎
02:27
|
(40) Ну да. Даже в методологии 8.2 заложено, сначала делаем движения, потом смотрим, а если минуса. Т.е. предполагается, что товара всегда хватает, и поэтому можно смело проводить, и не блокировать базу расчетом и проверкой остатка. А когда уже провели, можно и спокойно посмотреть, а что получилось. В крайнем случае удалим движение, если нехватает
|
|||
42
Злопчинский
06.12.11
✎
02:32
|
(41) это наерное хорошо будет работать на складах с большим товарным запасом (вот как у меня например), те же, кто работает "с колес", с активными заявками-заказами поставщикам - хз.. сомнительно мне это...
|
|||
43
Simod
06.12.11
✎
06:08
|
(0) Некоторый прирост может дать установка флага "Отбор итогов" для измерений по которым накладываются фильтры. Но это необходимо пробовать, т.к. эффект достигается не всегда. И расплата будет в виде увеличения размера ИБ за счет добавления индексов и увеличения времени формирования записей в регистр (то бишь времени проведения).
(22) Речь ведь о времени выгрузки на ТА, а не временном расчете. Кстати, orefkov несколько лет назад озвучивал решение позволяющее отказаться от временного расчета регистров. |
|||
44
Злопчинский
06.12.11
✎
06:13
|
(43) решение, насколько я помню, было по (27) по упрощенному варианту; если найдешь ссылку на рецепт orefkov - кидай! освежим в памяти
|
|||
45
Darlok
06.12.11
✎
06:17
|
(0)
Автор, используйте 1С++, выигрыш по производительности превышает 100 раз, сам делал снижая время формирования отчета с 1 часа до 30 сек. Естественно имеет смысл только для большого количества данных. |
|||
46
Simod
06.12.11
✎
06:18
|
(44) Выгрузка итогов на ТА, расчет временных итогов и контроль остатков при проведении задним числом не одно и то же, хотя и связаны.
Ссылка есть, но кидать не буду. Пользуйтесь поиском, знания надо добывать :) |
|||
47
Злопчинский
06.12.11
✎
06:21
|
(46) спасибо за пинок, у меня работает из (27) правильный вариант, а у Орефкова было по типу упрощенного.
|
|||
48
Darlok
06.12.11
✎
06:36
|
(47), в смысле пинок? я пытаюсь вам помочь в решении вопроса производительности, вам более конкретно расписать или ссылок на литературу дать?
Если не устраивают конструкции 1С++, можно компоненту использовать только как оболочку для прямых запросов к БД. |
|||
49
Злопчинский
06.12.11
✎
06:40
|
(48) пинок это было ироничное в сторону (46)
|
|||
50
Злопчинский
06.12.11
✎
06:43
|
(48) я в курсе про 1С++ и что она может ;-) использовал.. но в прямых запросах я слабоват,
так что про "более конкретно расписать" - тут поможет только конкретный код прямых запросов на замену РассчитатьРегистрыНА()... ;-) |
|||
51
Darlok
06.12.11
✎
06:48
|
http://www.script-coding.com/Direct_queries.html
тут очень емкая статья, описано все, но очень кратко. Для вашего случая можно сначала посмотреть "главу 7", если не получится придется перечитать все с начала. Если не получится что-то конкретное можно задать конкретный вопрос. |
|||
52
Darlok
06.12.11
✎
06:51
|
Для сильно неравномерно распределения документов в месяце, можно переписать виртуальную таблицу Остатки, но для этого нужен некоторый опыт запросов к SQL
|
|||
53
Злопчинский
06.12.11
✎
06:52
|
(51) знаю эту ссылку, есть там кое-где вроде нерассказанные тонкости, в т.ч. и по периодичности регистров... ладно, спсб, как вопросы будут - задам; обычно помогают, нормально... ;-)
|
|||
54
orefkov
06.12.11
✎
07:10
|
(47)
Ты упустил одну важную деталь в моем способе, делающую его не настолько упрощенным, как описано в (27) :) Это фирма 1С не смогла придумать ничего более лучшего, как положиться на авось при списании задним числом, а моя метода безо всяких временнЫх расчетов и проверки всех движений гарантировала правильный порядок списания партий и неулетания в минуса на всем временнОм отрезке от дока до ТА. |
|||
55
1Сергей
06.12.11
✎
09:23
|
(54) а где почитать?
|
|||
56
orefkov
06.12.11
✎
09:53
|
(55)
Да где-то здесь же... http://www.google.ru/search?ie=UTF-8&q=orefkov+списание+партий+site%3Amista.ru тут к примеру А что если отказаться от рассчета регистров при получении партий ? v7: Кстати, а разгадали секрет метода У ЛЮ - 2? да много там веток всяких. |
|||
57
Aleksey
06.12.11
✎
11:30
|
(56) "Достаточно постулировать, что в каждой партии может быть только один приход, и в дальнейшем партия только списывается."
А как же возвраты? рожать для них новые партии? |
|||
58
orefkov
06.12.11
✎
12:15
|
(57)
Внимательнее читайте :) Вопрос обсасывался. Для этого и добавляется в регистр измерение "МоментПоступления". Приход ставиться в ту же партию, но с другим МоментомПоступления, равным моменту прихода возврата. |
|||
59
Ёпрст
06.12.11
✎
12:28
|
(58) перемещение, как я понимаю, в этой схеме не учитывается никак ?
|
|||
60
Ёпрст
06.12.11
✎
12:29
|
ё
|
|||
61
Злопчинский
06.12.11
✎
14:09
|
(58) ну, вообщем, у меня аналогично сделано.
|
|||
62
Злопчинский
06.12.11
✎
14:10
|
единственное я не дотумкал как это прикрутить чтобы по суммам правильно было...
|
|||
63
Злопчинский
06.12.11
✎
14:16
|
собственно тяма в монотонности функции остатков (56) - к этому я пришел не из упоминавшихся, а в результате большой переписики с SELENAT.
. Едиснтвеннное, что осталось нерешенным - это суммовой учет... если при изменении задним числом поменять сумму прихода/расхода - как обеспечить правильность ранее спи санных сумм - непонятно..... |
|||
64
Ёпрст
06.12.11
✎
14:20
|
(63) а чего там с ним ?
восстановишь гп и привет. Этот метод токма гарантирует тебе "защиту от красноты" в останках, и что всё потом перепроведется без проблем и привет. |
|||
65
Злопчинский
06.12.11
✎
14:21
|
> Основной гимор при ЗЧ - уменьшение прихода. Может не дать провести документ с уменьшенным приходом, тк часть или весь товар с этого поступления уже списался, хотя в-принципе, мог бы успешно списаться и из других приходов.
- у меня в принципе это решено. списывать остатки следует по ЛИФО, тогда при уменьшении прихода требуемое колво всегда можно добрать из более ранних приходов. Единственное здесь чутю-чуть усложняется расчет итогов при заднем числе - приходится учитывать минусовые остатки по некоторым "партиям", списывая их с более ранних приходов. По крайней мере у меня такая конструкция успешно работает. Единственное что было отмечено ранее - восстановление ГП все равно остается, но превращается в чисто технологическую процедуру при этом 100% проходящую без затыков. |
|||
66
Злопчинский
06.12.11
✎
14:23
|
(64) ну.. это не интересно... ;-) хотелось чтобы без восстановления ГП правильно было... ;-) - но пока не придумал.. не выходит каменный цветок.
|
|||
67
Злопчинский
06.12.11
✎
14:25
|
кстати, если есть ТЗ, в которой в одном столбце есть "позиция" и ТЗ отсортирована по позиции в хронологии - как быстро обрубить строки которые позже некой выбПозиция..? Индексированной таблицей это можно сделать..? - сделать ключ по позиции... ?
|
|||
68
Ёпрст
06.12.11
✎
14:30
|
а получить сразу нужную тз не судьба ? Это лучше, чем потом фильтровать её.
|
|||
69
Злопчинский
06.12.11
✎
14:42
|
(68) а как ты получишь нужную ТЗ - либо Рег.ВыгрузитьИтоги(ТЗ) на ТА + отсечение по ТЗ, либо запрос на ТА с отсечением сразу в запрсое - но будет ли это быстрее..?
|
|||
70
orefkov
06.12.11
✎
14:48
|
(63)
Ну, если проследить тут хронологию, то это он мою методу пытался развить до чего-то большего. (69) Если без всяких ВК, то я бы на достаточно больших ТЗ находил граничную строку бинарным поиском. А так конечно, лучше сразу получить запросом с уже откинутыми остатками. |
|||
71
Злопчинский
06.12.11
✎
14:53
|
(70) да, наверное - тогда была большая ветка по этому вопросу.
|
|||
72
Злопчинский
06.12.11
✎
15:00
|
(70) угумс, я производил замеры на большой тестовой базе - основное время как раз сжирало отсечение таблицы; наваял даже демо конфу с реализованным алгоритмом обсуждаемым здесь, но не допилил до "коммерческого" варианта...
|
|||
73
Ёпрст
06.12.11
✎
15:04
|
(70)На (59) так и есть ?
|
|||
74
Ёпрст
06.12.11
✎
15:06
|
(72) :)
на проклабе полно алгоритмов для удаления строк из тз. Не так и много времени займёт. Естественно, никаких УдалитьСтроку там нет (это один из самых медленных способов при работе с тз) |
|||
75
Эльниньо
06.12.11
✎
15:08
|
(67) ТЗ.Заполнить() не прокатит?
|
|||
76
Злопчинский
06.12.11
✎
15:21
|
(74) я в курске! "удаление" идет првильно, надо просто быстро найти граничную позицию - в демо я тупо перебором делал, потому что объемы маленькие.
. если запросом получать итоги на ТА с обрезкой уже в запросе - это намного быстрее будет если резать таблицу быстрым поиском граничной позиции..? . (70) orefkov - у тебя как - поиском по ТЗ или запросом режется? |
|||
77
Ёпрст
06.12.11
✎
15:35
|
(76) запросом быстрее
|
|||
78
Злопчинский
06.12.11
✎
15:36
|
(77) спсб!
|
|||
79
Злопчинский
06.12.11
✎
15:37
|
у меня просто объемы базы/данных не такие большие чтобы серъезно вставал вопрос об оптимизации всего и вся (прямые запросы и прочее) - потому и не использую особо...
|
|||
80
Ёпрст
06.12.11
✎
15:37
|
(78) ты там, с перемещением что делать будешь ?
|
|||
81
Злопчинский
06.12.11
✎
18:42
|
(80) а точно также по идее. с поправками на то, в каком регистре что надо отрациь по перемещениям. основной смысл - любой приход на склад - это всегда новая "сущность", в решении Орефкова эта сущность чтотоучетное+моментвремени.
. в демо-конфиге своей я пишу не момент времени, а позицию а вот в рабочей конфиге ступил немного - пишу "партиеобразующий" документ... соответсвенно в запросе надо как-то будет отрезать документы которые выше ВыбДокумент - как это сделать в запросе - пока слабо представляю (если не адресоваться к позиции документа) |
|||
82
Ёпрст
06.12.11
✎
18:48
|
(81) Это как ?
Ты делаешь приход - расход при перемещении, с каким измерением ? |
|||
83
Злопчинский
06.12.11
✎
19:19
|
(82) давай определимся по какому регистру хотим учитывать перемещение?
. стучи в мыло [email protected] свою аську - фигли тут секреты выдавать? ;-) |
|||
84
Злопчинский
06.12.11
✎
19:20
|
не, точно - доделаю нафиг демо-конфигу по работе без временных итогов и буду продавать ;-) (апологетам вопроса - раздача бесплатно!)
|
|||
85
Ёпрст
06.12.11
✎
19:26
|
(83) Чебур, ты меня удивляешь..
Тут половина ветки про Партии, про что же еще ?! :)) |
|||
86
Злопчинский
06.12.11
✎
19:34
|
(85) ты меня удивляешь два раза.. все уже выше написано.
если ч то - маякай в почту асю или скайп |
|||
87
Ёпрст
06.12.11
✎
20:04
|
(86) в каком месте ?!
Я задавал еще вопрос Орефкову - ответа так и нет.. Из его постулата - 1 раз приход, пишем момент времени прихода и привет, потом его расходуем. Теперь, что делать с перемещением ? Приход с каким моментом времени ? Расход с каким ? |
|||
88
Злопчинский
06.12.11
✎
20:10
|
(87) любой расход - штатно, любой приход - новая "партия" с новым моментом времени.
в иотоге вместо осциллирующей функции остатков получаешь совокупность монотонно убывающих функций. если монотонно убывающая функция на ТА в минусе - все пипец, нарушение учета |
|||
89
КонецЦикла
06.12.11
✎
20:11
|
(84) Лучше сделай без работы задним числом :)
По сабжу - все просто - в QA выполняешь запросы, попадаешь в индексы, смотришь планы и выбираешь лучший Думаю, что можно незначительно оптимизировать ВыгрузитьИтоги(ТЗ) Гораздо важнее то, как дальше используется эта ТЗ |
|||
90
Злопчинский
06.12.11
✎
20:16
|
(89) > без работы задним числом...
- ну так при реализации "орефковщины" - хоть в заднем числе, хоть в переднем - по барабану; это и имелось в виду. . а без работы задним числои - ну никак. самый простой пример: банковская выписка, которая сегодня (ибо получена сегодня) вводится за вчера.. или ваще за пятницу... . можно и в этом случае обойтись без ЗЧ - но тогда надо переписывать тотально все конфиги - что на 8-ке, что на 7.7 типовые - ибо в них нет разницы между датой регистрации хозоперации и датой к которой относится хозоперация, что конечно - полняа бредятина.. особенно когда начинается скрещивание "бух" и "оу/уу" |
|||
91
Злопчинский
06.12.11
✎
20:30
|
А поможет кто составить прямой запрос? он очень простой (для специалиста наверное ;-)
. Регистр.ОстаткиГТД измерения(в порядке следования в пофигураторе): . Фирма, спр.Фирмы Номенклатура, спр.Номенклатура ВидДеятельности, Перечисление.ВидДеятельности ГТД, спр.ГТД Документ, тип = Документ (неопределенного вида!) Ресурс: Количество, число . Надо для текущего документа (выбДокумент) и фирмы (выбфирма или списокзначений/таблицазначений(как удобнее) фирм) и списка номенклатуры (тз или списокзначений - как удобнее) . получить итоги по регистру на ТА при условии что Документ(измерение) < ВыбДокумент (в смысле хронологической позиции). . база ДБФ, SQLite или VFP - в наличии . возможно даже за денежку. . спсб если кто откликнеться. |
|||
92
Ёпрст
06.12.11
✎
20:33
|
:)
за такое даже деньги стыдно брати.. |
|||
93
Злопчинский
06.12.11
✎
20:54
|
(92) я не возражаю!!!!!! ;-)
|
|||
94
Ёпрст
06.12.11
✎
21:05
|
Ну на..тут тупо итоги на ТА, отсортированные по позиции измерения Документ.
Условие сам воткнешь, надеюсь :) Остальное - в личной карточке. ТекстЗапроса=" |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"); ПредПериод = мд.ПолучитьНачПериода(ПолучитьДатуТА());//начало периода Запрос.Подставлять("ПредПериод",ПредПериод); запрос.ВыполнитьЗапрос(ТекстЗапроса).ВыбратьСтроку(); |
|||
95
Злопчинский
06.12.11
✎
21:13
|
(94) вот ты ленивый! нет чтобы и условие воткнуть...
|
|||
96
Злопчинский
06.12.11
✎
21:14
|
не ну блин реально ленивый: а условие на список номенклатуры? а услвоие на список фирм?
не, ну как так можно... ;-) |
|||
97
Ёпрст
06.12.11
✎
21:49
|
дарю:
база.УложитьОбъекты(Список,"ВыбНоменклатура",0,"Номенклатура"); ТекстЗапроса=ТекстЗапроса+" | Where Итоги.Номенклатура in (select val from ВыбНоменклатура)"; При условии на <ВыбДок юзай модификатор ~~~ при передачи параметра и сравнивай позицию ..фирщтейн ? |
|||
98
FN
06.12.11
✎
22:03
|
(97) + лучше без Уложитьсписок (тормоз + гадит темпдб)
примерно так: IN (select distinct $СтрДок.Номенклатура from $ДокументСтроки.НужныйВидДока СтрДок (nolock) where СтрДок.iddoc = :Док) где :Док = ТекущийДокумент() При большом списке номенклатуры быстрее. При маленьком списке быстрее в строку уложить через MetaDataWork |
|||
99
Ёпрст
06.12.11
✎
22:19
|
(98) :)
это в sqlite - то ? |
|||
100
FN
06.12.11
✎
22:27
|
сто!
|
|||
101
FN
06.12.11
✎
22:27
|
(99)упс. прочитал тему по диагонали
|
|||
102
Злопчинский
06.12.11
✎
22:33
|
ух понапиали-то.. буду н а выходных пробовать...
|
|||
103
orefkov
07.12.11
✎
00:31
|
(87)
Ну, в классике перемещение в партиях вообще не отражается :) Но в том конкретном случае, который я делал (это было давно, и сейчас я там не работаю) был единый регистр "Товары", с партиями и складами. Перемещение делалось так: расход из партии с моментом поступления из итогов регистра. приход в эту же партию с моментом поступления = доку перемещения. Т.е было Товар1 Партия1 Склад1 01.02.2010 20 штук стало Товар1 Партия1 Склад1 01.02.2011 15 штук Товар1 Партия1 Склад2 07.12.2011 20 штук |
|||
104
orefkov
07.12.11
✎
00:32
|
Опечатка.
Было Товар1 Партия1 Склад1 01.02.2011 20 штук |
|||
105
orefkov
07.12.11
✎
00:33
|
Блин, спать хочу.
Было: Товар1 Партия1 Склад1 01.02.2011 20 штук стало Товар1 Партия1 Склад1 01.02.2011 15 штук Товар1 Партия1 Склад2 07.12.2011 5 штук Вот. |
|||
106
КонецЦикла
07.12.11
✎
01:23
|
(90) Зачем переписывать "тотально все конфиги" если речь идет о написании своей?
По работе задним числом я подразумевал ввод документов в хронологической последовательности (как это происходит в реальной жизни) Про выписку понятно, но такое проведение документа не должно означать восстановление последовательности по взаиморасчетам (и в принципе не противоречит изложенному в пред. предложении) |
|||
107
Злопчинский
07.12.11
✎
02:24
|
(103) угумс, так...
|
|||
108
Злопчинский
07.12.11
✎
02:29
|
(106) > По работе задним числом я подразумевал ввод документов в хронологической последовательности (как это происходит в реальной жизни)
- ну так это сразу приведет к тому, что например по той же выписке: ты вводишь выписку 7 декабря (когда получил из банка), а учитывается она в 6 декабря - когда прошли движеняи по банку - и хоть убейся для ПРАВИЛЬНОГО отражения придется иметь дату хозоперации и дату "бухоперации", в противном случае например если выписку ввели в 10 утра 7 декабря, а реализация в 9.30 - в одной раскладке получитс янеобходимость отражать авансы с выписок СЧФ, а в другой - нет.. один из этих вариантов - нарушение... . или что-то другое имел в виду..? . я под (первым этапом!) работой "в заднем числе" имею в виду ввод документов в "точки/моментывремени" бухопераций - и при таком вводе не должно быть противоречий в учете при рассмотрении хронолгической последовательности бухопераций. |
|||
109
Ёпрст
07.12.11
✎
08:44
|
(105) ну ясно в общем, приход всегда с новым моментом времени..
Где-то у меня конфа валяется с таким решением. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |