|
v7: Оперативный учет, расчет итогов | ☑ | ||
---|---|---|---|---|
0
kloptula
29.12.11
✎
09:17
|
Всех с наступающим. Помогите советом или своим опытом. Есть Торговля 7.7 немного переписанная (сделан серийный учет). Размер базы DBF около 1 ГБ. Есть УРБД с 17 узлами. Пользователи начали жаловаться на долгое открытие периода. Период открывается около 2-х минут. Это пользователи совсем охренели или это нормальное время открытия? Как можно ускорить этот процесс? Деятельность - розница с большим номенклатурным ассортиментом. Спасибо.
|
|||
51
Злопчинский
29.12.11
✎
18:00
|
(48) не, это у мну, блин, чуть ли не основной разрез учета...
|
|||
52
Злопчинский
29.12.11
✎
18:02
|
(50) ээээ.. а как получается тогда быстрое проведение документа текущим временем - он же рассчитывает (штатно) остатки на момент времени предшествующий проводимому документу... - т.е. итог + движения....??? или я в корне все неправильно понимаю..????
|
|||
53
NS
29.12.11
✎
18:03
|
(49) штатными средствами двигается.
|
|||
54
Ёпрст
29.12.11
✎
18:04
|
сделал приход 10.12.2011 100 тапочек, в RA будет +100 тапочки, в RG будет 01.12.2011 100 тапочки (при периодичности хранения останков месяц)
сделал расход 70 тапочек 12.12.2001, в RA будет 2 записи 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки в RG будет 01.12.2011 30 тапочки вот взять итог на 01.12.2011 из таблички итогов - это и еть итог на ТА. |
|||
55
Злопчинский
29.12.11
✎
18:05
|
(53) за счет чего так быстро??? (не верю! ;-)
|
|||
56
Ёпрст
29.12.11
✎
18:06
|
||||
57
Злопчинский
29.12.11
✎
18:07
|
(54) т.е. в RG - для текущего периода хранится просто "накопительный" итоговый остаток? - а для прошлых периодов (при открытии нового периода) - формируется/пересчитывается остаток на начало "прошлого" периода..?
|
|||
58
Ёпрст
29.12.11
✎
18:07
|
(52) он ничего не рассчитывает, просто берется итог из таблички итогов.
всё. |
|||
59
Злопчинский
29.12.11
✎
18:09
|
.. т.е. при открытии периода берется остаток на ТА - переносится в новый откр ываемый период и потом от итогов ТА перерасчитывается по табличке движений "начальный" итог для закрываемого периода...? - типа так?
|
|||
60
NS
29.12.11
✎
18:09
|
(55) За счет того что RG маленький, и многое сделано на оборотных регистрах.
|
|||
61
NS
29.12.11
✎
18:09
|
маленькие.
|
|||
62
Злопчинский
29.12.11
✎
18:10
|
(58) это я понял. я всегда считал что итоги на ТА - это есть готовый итог - как ты написал, но почему-то никогда не задавался вопросом - где он хранится...
|
|||
63
Ёпрст
29.12.11
✎
18:11
|
(57) нет так..
на примере: в RA 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки В RG 01.12.2011 30 тапочки Открываем следующий период, в январь полетят ненулевые итоги из таблички итогов прошлого периода, в RG будет: 01.12.2011 30 тапочки 01.01.2012 30 тапочки делаем в новом году приход 20 тапок, в RA: 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 30 тапочки 01.01.2012 50 тапочки Фирштейн ?? |
|||
64
Злопчинский
29.12.11
✎
18:12
|
(6) вот!! а почему:
а) RG - маленький...??? - типа непосредственно перед открытием/закрытием периода "списали" все в ноль, а сразу после открытия периода - "просторнировали"...? с таким подходом КП всегда будут малюпусенькие...??? |
|||
65
Ёпрст
29.12.11
✎
18:13
|
если ты в прошлом году сделаешь еще расход 50, к примеру, то должен первое, измениться итог на 01.12.2011 и второе, пересчитаться все итоги, что выше, т.е на 01.01.2012..
|
|||
66
Ёпрст
29.12.11
✎
18:15
|
(64) нет, за счет оборотных регистров.
:) |
|||
67
Злопчинский
29.12.11
✎
18:18
|
(63) пока ферштею вроде... при расчете временных итогов в заднем периоде, например в январе считаем документ задним числом на 11.12.2011 - как посчитаем итоги..??
|
|||
68
Злопчинский
29.12.11
✎
18:19
|
(66) а какая хитрость/смысл в использовании оборотных регистров в этом случае?
заменяем регистры остатков регистрами оборотов..?? |
|||
69
Ёпрст
29.12.11
✎
18:20
|
(67) имеешь ввиду, как остаток на 11.12.2011 считать ?
берется предыдущий итог, т.е итог тз таблички итогов на 01.11.2011, далее складываем с движениями из таблички движений с 01.12.2011 по 11.12.2011 (Приход-Расход) |
|||
70
Ёпрст
29.12.11
✎
18:23
|
если ты в заднем числе что-то меняешь в движениях, то должен и итоги подвигать все что позже этой даты с тем же набором измерений.
Отсюда могут возникнуть "нулевые" итоги в прошлых периодах в табличке итогов. Например, такое всегда происходит при свёртке. |
|||
71
Злопчинский
29.12.11
✎
18:24
|
(69) да,
берем итог ЗА ПРЕДЫДУЩИЙ МЕСЯЦ - потому что там в на данный момент хранится итог за предыдущий месяц на КОНЕЦ ПРЕДЫДУЩЕГО МЕСЯЦА - так..?? |
|||
72
Ёпрст
29.12.11
✎
18:24
|
+70 или при удалении (пометки на удаление)\распроведении документа
|
|||
73
Ёпрст
29.12.11
✎
18:25
|
(71) ага..
Только если период хранения останков - месяц ( у меня, к примеру, 5 дней) |
|||
74
Злопчинский
29.12.11
✎
18:25
|
(70) т.е при проведении задним числом пересчитываются все итоги до ТА по совокупности измерений - так..?
|
|||
75
Ёпрст
29.12.11
✎
18:26
|
(74) да.
|
|||
76
Злопчинский
29.12.11
✎
18:28
|
(73) уф!!! спасибо тебе, добрый человек! как-то это мне В ОБЩЕМ всегда понятно было, но вот в частностях - что разжевали теперь - никогда не было необходимости втыкать.. - поэтому/потомучто 1С прямые запросы мало писал.. ;-)
|
|||
77
Злопчинский
29.12.11
✎
18:30
|
(70) т.е. например записали задним числом в регистр с неким набором измерений новое значение ресурса - теперь для каждых последующих итогов "докидываем" разницу между предыдущим и текущим(новым) значением ресурса..??? - что то мне кажется что не так это...
|
|||
78
Ёпрст
29.12.11
✎
18:30
|
на примере тапок:
было в январе в RA: 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 30 тапочки 01.01.2012 50 тапочки делаем расход 50 тапок в декабре: в RA: 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки 11.01.2012 +20 тапочки 15.01.2011 -50 тапочки в RG 01.12.2011 -20 тапочки 01.01.2012 0 тапочки |
|||
79
Ёпрст
29.12.11
✎
18:33
|
+78
ошибся мальца //15.01.2011 -50 тапочки 15.12.2011 -50 тапочки |
|||
80
Злопчинский
29.12.11
✎
18:34
|
(78) подожди!! тут втыкнуть надо!! разобраться раз и навсегда...
|
|||
81
Ёпрст
29.12.11
✎
18:36
|
(80) чебур, ты меня удивляешь :)
|
|||
82
Злопчинский
29.12.11
✎
18:37
|
(78) хитрый какой!! ;-) это понятно, когда мы НОВЫЙ док впихнули задним числом...
а как считается если мы 12.12.2011 вместо 70 продажи поставим 90...? |
|||
83
Злопчинский
29.12.11
✎
18:38
|
(81) ну так блин - я не стеснительный! ;-)
эти ж все тонкости (даже такие простые) платформа штатно скрывает от девелопера - я вот девелопер, а ты - разработчик! - разницу чувствуешь.. ;-) поэтому я у тебя учусь все время, а не ты у меня ;-)) |
|||
84
Ёпрст
29.12.11
✎
18:39
|
(82) А есть особая разница ? :))
в RA: 10.12.2011 +100 тапочки 12.12.2011 -90 тапочки 11.01.2012 +20 тапочки 15.12.2011 -50 тапочки в RG 01.12.2011 -40 тапочки 01.01.2012 -20 тапочки |
|||
85
Ёпрст
29.12.11
✎
18:41
|
алгоритм тупой до безобразия:
делаешь новую запись в RA или апдейтишь существующую, далее перебираешь все итоги от начала периодичности и позже в табличке итогов и делаешь приращение к итогу, если его нет - добавляется строка в табличке итогов.. всё собственно. |
|||
86
Ёпрст
29.12.11
✎
18:42
|
+85 от начала ближайшей даты начала периодичности итогов
|
|||
87
Злопчинский
29.12.11
✎
18:42
|
(84) не.. было же
в RG 01.12.2011 30 тапочки 01.01.2012 50 тапочки . теперь исправляем 70 на 90 (штатный тис) - очищает движения (удаляем расход 70) т.е. идет первый пересчет итогов потом идет второй пересчет итогов (добавляем расход 90) . так??? |
|||
88
Ёпрст
29.12.11
✎
18:43
|
не не не не не.. я не девелопер..
|
|||
89
Злопчинский
29.12.11
✎
18:43
|
(88) ну правильно! это Я - девелопер.. ;-)
|
|||
90
Ёпрст
29.12.11
✎
18:44
|
(87) ты этот пример рассматриваешь ?
в RA: 10.12.2011 +100 тапочки 12.12.2011 -70 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 30 тапочки 01.01.2012 50 тапочки изменяем расход с -70 на -90: в RA: 10.12.2011 +100 тапочки 12.12.2011 -90 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 10 тапочки 01.01.2012 30 тапочки |
|||
91
Злопчинский
29.12.11
✎
18:46
|
(90) да.
это ты хитро написал - у тебя сразу 90 появилось!!! а что будет после того как исчезло 70, но еще не появилось 90..????? |
|||
92
Ёпрст
29.12.11
✎
18:48
|
в RA:
10.12.2011 +100 тапочки 12.12.2011 -70 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 30 тапочки 01.01.2012 50 тапочки убиваем расход с -70 в RA: 10.12.2011 +100 тапочки 11.01.2012 20 тапочки в RG 01.12.2011 100 тапочки 01.01.2012 120 тапочки |
|||
93
Ёпрст
29.12.11
✎
18:48
|
:)
|
|||
94
Злопчинский
29.12.11
✎
18:50
|
(93) ага!!!
то есть реально идет при изменени количества в документе задним числом - ДВА ПЕРЕСЧЕТА (см.87) ??? |
|||
95
Ёпрст
29.12.11
✎
18:52
|
(94) на счет этого не скажу, скорее всего один.
Можно в профайлере посмотреть |
|||
96
Ёпрст
29.12.11
✎
18:53
|
+95 вот если поддержка актуальности итогов включена, то скорее всего 2 (и больше, после каждой записи движения)
|
|||
97
Злопчинский
29.12.11
✎
18:55
|
(95) вот уменя сомнения - как это - один??? один может быть только если рассчитывается дельта между 70 и 90 - и в итоги она докидывается...
??? |
|||
98
Злопчинский
29.12.11
✎
18:57
|
может вот если стоит "автоматическое удаление движений" - то может быть перед записью движения - считывается предыдущее, вычисляется дельта и тогда возможно - один пересчет итогов..???
. а вот если автоудаления движений нет - как например в типовой ТиС - сначала удаляем движеняи регситров по доку (один пересчет?), потом пишем новые значения (второй пересчет). ??? |
|||
99
Злопчинский
29.12.11
✎
18:58
|
..или нет..??
|
|||
100
Ёпрст
29.12.11
✎
18:58
|
(97) ну, 2 раза то проще сделать, чем хранить дельту.
Скорее всего так и реализовано. |
|||
101
Злопчинский
29.12.11
✎
18:59
|
(посмотрел у себя по самому проблемнму регистру - см.(46) - все чисто!! чику п уки!! однако же непонятный дисбаланс...)
|
|||
102
Злопчинский
29.12.11
✎
19:01
|
(100) тогда получается, что при ручном удалении движений - возможно в определенных вариантах имеет смысл дописать вычисление дельты и докидывать ее без удаления движений...? - накладные затраты на такой расчет превысят затарты на лишнюю запись или нет.. будет выигрыш или нет..?
|
|||
103
Ёпрст
29.12.11
✎
19:03
|
(102) даже не задумывался над этим никогда, обычно, запись движений и пересчет итогов не такой уж и долгий процесс, по сравнению с получением, например, останков.
|
|||
104
Ёпрст
29.12.11
✎
19:05
|
по-идее, выигрыш будет, не даром же в снеговике есть запись только измененых движений регистра.
|
|||
105
Злопчинский
29.12.11
✎
19:09
|
(103) получение остаНков - длиннее потому что много чтений надо делать для расчета - итоги извлечь + движения и все это просуммировать..?
|
|||
106
Злопчинский
29.12.11
✎
19:11
|
(101+ возможно такой дисбаланс за счет того, что итоги я не пересчитывал давным давно и куча ненужных записей нулевых в итоге получилась - когда отлаживал алгоритм учета ОстатковГТД???)
|
|||
107
Злопчинский
29.12.11
✎
19:14
|
запустил выгрузку/загрузку - м.б. ужмется лишнее...
|
|||
108
Ёпрст
29.12.11
✎
19:22
|
(106) вполне, сделай выгрузить данные - загрузить данные, или тупо грохни все RG и пересчитай итоги.
|
|||
109
Злопчинский
29.12.11
✎
19:27
|
(108) угумс!!! идет вроде нормально - движени я пока поряд ка 60 МБ, итоги - порядка 8Мб - так до лжно быть !!!
|
|||
110
Злопчинский
29.12.11
✎
19:28
|
(108) ты еще здесь - можно еще вопрос дабы устаканить окончательно неустаканенное годами..
? |
|||
111
Ёпрст
29.12.11
✎
19:34
|
(110) еще тут
|
|||
112
Злопчинский
29.12.11
✎
19:36
|
по (96) - что есть "поддержка актуальности итогов" - завсегда меня это смущало...
|
|||
113
Злопчинский
29.12.11
✎
19:39
|
Параметры:
<ФлагАктуальности> - необязательный параметр. Число: 1 - временный расчет поддерживать в актуальном состоянии; 0 - не поддерживать актуальность временного расчета. Если параметр не задан, то метод просто возвращает текущий флаг актуальности, не меняя его. Замечание: Данный метод можно использовать только в модуле проведения документа. Если флаг установлен, то все последующие движения регистров будут изменять итоги временного расчета, и ,значит, итоги регистров временного расчета будут все время (при проведении документа) находиться в актуальном состояни |
|||
114
Ёпрст
29.12.11
✎
19:39
|
(112) после каждого движения регистра остаток по нему изменяется, т.е актуален..
Грубо, сделал ДвижениеПриходВыполнить, если посмотрел остаток там же, в модуле проведения - он изменится на этот приход. |
|||
115
Злопчинский
29.12.11
✎
19:40
|
..для чего это..? какой смысл..?
типа для щапсиали задним числом в регистр и потом где-то тут же рядом надо прочитать итоги на немножко другой момент времени..? |
|||
116
kloptula
29.12.11
✎
19:40
|
Ёпрст3, можно еще воспользоваться Вашими знаниями в соседней теме по УРБД в режиме "Снежинка"?
|
|||
117
Злопчинский
29.12.11
✎
19:42
|
(116( в очередь!! я первый к Ёпрсту пока!!! МНУ НЕМНОГО ОСТАЛОСЬ...
|
|||
118
Ёпрст
29.12.11
✎
19:43
|
ну , алгоритмы разные бывают..
Поимел остаток и решил узнать например, какой он будет, если спишем N товара.. При актуальность (1) ты просто взял остаток и посмотрел, а так, придётся самому вычислять.. |
|||
119
Ёпрст
29.12.11
✎
19:46
|
(116) я ж тебе там ответил, если будешь разве что удалять записи.
Просто при использовании фоксового провайдера, к примеру, он по другому строит индекс, в отличие от 1с, поентому, опосля инсерта\делете необходимо переиндексировать таблички средствами 1с-ины. |
|||
120
kloptula
29.12.11
✎
19:50
|
Если не делать инсерт, только удалять? Оставлю везде Миграцию "Все для всех". Ну не ставить же для этого sql, не нравится он мне. Работает медленне, чем DBF
|
|||
121
Злопчинский
29.12.11
✎
19:54
|
(118) это понятно, но как это обеспечивается "технически" - вот если актуальность не выставить - после выполнени ядвижени ярегистра - получается пересчета итогов не будет "внутри" процесса записи движения?? - будет только при "закрытии" транзакции..???
|
|||
122
Ёпрст
29.12.11
✎
20:11
|
(121) не знаю, скорее всего, всегда пересчитывается - надо в профайлере смотреть, что там выполняется при этом.
|
|||
123
Злопчинский
29.12.11
✎
20:22
|
(122), то есть что там "унутре" - осталось невыясненым... и наскольо нагружаер систему включение/отключение актуальности - непонятно..
ну раз так - пусть ПОКА так.. ;-) |
|||
124
Злопчинский
29.12.11
✎
20:23
|
Но вот то, что у меня после загрузки итоги считаются уже час целый при маленькой базе (1.6 Гига, с 01.01.10) - это явно блин что-то не то...
|
|||
125
Злопчинский
29.12.11
✎
20:24
|
поэтому интересно, что там у NS с оборотными регистрами намучено..? в чем фишка?
|
|||
126
Злопчинский
29.12.11
✎
21:33
|
Ёпрст, а период для своих 5-идневок как открываешь..?
|
|||
127
Злопчинский
29.12.11
✎
23:02
|
блин, прошерстил все проблемные места - все нормуль.. а период все равно открывается 10 минут... куда копать? на что смотреть? как уменьшить?
|
|||
128
kloptula
30.12.11
✎
15:20
|
Вот еще какая мысль посетила. Можно ли проверить "закрываемость" регистра (при условии, что есть движения и в плюс и в минус), "раскрыв" его по всем измерениям и проверив отрицательные остатки по ресурсам. Если есть минусы, значит все плохо, регистр "не закрыт".
|
|||
129
Mikeware
30.12.11
✎
16:13
|
(128) Можно, но не "минусами..."
1. смотришь количество ненулевых остатков в ресурсах. 2.сворачиваешь по n-1 измерениям, смотришь количество ненулевых остатков в ресурсах. Если сильно упало - значит, по этому измерению со значительной долей вероятности регистр не закрыт... 3. проверяешь по другим измерениям... |
|||
130
Злопчинский
01.01.12
✎
16:36
|
(129) пора уже проверялку для баз написать...
|
|||
131
Mikeware
01.01.12
✎
16:51
|
(130) Да кому это надо?
Хотя работы на пол-часа, не более.. |
|||
132
Злопчинский
01.01.12
✎
17:09
|
(131) время пошло.. ;-)
|
|||
134
Mikeware
01.01.12
✎
17:12
|
(132) Лень. Все лень. Даже курс насфа слушать лень... покатался на лыжах - вроде и не устал, а лень напала...
|
|||
135
Злопчинский
01.01.12
✎
17:18
|
(134) так и запишем - сломался...
|
|||
136
kloptula
03.01.12
✎
21:29
|
Подниму тему. Опять долгое открытие периода на январь 2012.
Взял копию базы и оставил только ввод начальных остатков по 18 местам хранения на 31.12.11. Попробовал сделать открытие периода на январь 2012. Времени заняло столько же (порядка 2 минут). Делаю вывод, что "незакрытость" регистров тут уже не причем. Никаких других документов кроме ввода остатков ТМЦ в базе нет. Ускорить реально или нет? |
|||
137
Mikeware
03.01.12
✎
21:43
|
(136) ПОсмотри профайлером, что оно делает...
|
|||
138
kloptula
03.01.12
✎
21:55
|
Видимо проблема все-таки в количестве остатков. Если оставляю один склад, открытие практически мгновенно, с двумя уже дольше и т.д. SQL даст прирост в скорости?
|
|||
139
Mikeware
03.01.12
✎
22:02
|
(138) значит, проблема в индексах...
а будет ли быстрее сиквел.... вопрос сложный. все зависит от соотношения радиусов™.... |
|||
140
kloptula
03.01.12
✎
22:10
|
Может быть проблема из-за дополнительного измерения в регистре? Измерение - справочник, но у справочника не определен код и наименование (длины нулю равны).
|
|||
141
Mikeware
03.01.12
✎
22:13
|
(140)если по этому измерению все закрывается - то проблем нет.
если по нему не закрывается - надо исправлять соотношение.... |
|||
142
Mikeware
03.01.12
✎
22:14
|
кстати, на работе накидал "проверялку закрыванй". но для сиквела...
|
|||
143
kloptula
03.01.12
✎
22:14
|
(139) А как можно проверить проблему с индексами?
|
|||
144
Mikeware
03.01.12
✎
22:15
|
(143)переиндексироваться...
|
|||
145
kloptula
03.01.12
✎
22:20
|
(144) Я пробовал вообще удалить файлы RG и RA, повторно провел документы ввода остатков, ничего не изменилось. Может это все же нормально, такое время открытия? Если в цифрах, то остатков где-то 10000-12000 строк в номенклатуре по каждому из 18 складов, т.е в целом в базе 180000-216000 записей в регистре.
|
|||
146
kloptula
03.01.12
✎
22:21
|
(145) на период соответственно
|
|||
147
Mikeware
модератор
03.01.12
✎
22:33
|
скопировать 300 тыс записей - недолго
|
|||
148
kloptula
03.01.12
✎
22:36
|
(147) Самое интересное, что сам процесс добавления записей в файл происходит быстро, но перед этим 1С грузит процессор почти все время открытия 1 мин. 50 сек., а секунд 10 именно пишет данные в файл.
|
|||
149
Torquader
04.01.12
✎
00:06
|
(148) Так оно и понятно - сначала в памяти или во временной директории мы записи накапливаем (то есть выполняем запрос), а потом его результат просто и быстро записываем в файл. Как-то, писать неготовые данные - их потом переписывать придётся.
|
|||
150
Злопчинский
04.01.12
✎
14:01
|
да вот хрен его знает... у меня регистры вроде закрыты, база небольшая, товарные остатки примерно 2500 позиций, по несколько партий на позицию - открытие месяца идет ну офигеть как долго...
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |