Имя: Пароль:
1C
 
v8: Ускорение восстановления последовательности документов в УПП.
,
0 МуМу
 
29.03.11
13:27
Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости.

Предположим серверные настройки оптимальные, сервер очень мощный.  Линейное ускорение  проведения документов, за счет оптимизации запросов,  возможно не более чем на 15%.

Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит?
1 shuhard
 
29.03.11
13:29
(0)[сервер очень мощный.]
дисковая подсистема очень быстрая ?
2 asp
 
29.03.11
13:31
путем апгрейда железа
3 МуМу
 
29.03.11
13:32
(1) Ага,очень быстрая дисковая подсистема и многопроцессорный сервак(предположим 8-16 процессоров). Ну и сервер приложений такой же.
4 МуМу
 
29.03.11
13:33
(2) Не верно. При доп. вложении равной стоимость существующего сервера удастся ускорить только на 15-20 процентов.
5 asp
 
29.03.11
13:33
в данном конкретном случае рулит скорость одного ядра, а не количество процессоров
6 asp
 
29.03.11
13:34
(4) а теперь моя практика: вместо стоечного сервака HP куплен десктоп за 40% цены сервера. последовательность на нем восстанавливается в три раза быстрее.
7 МуМу
 
29.03.11
13:35
Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов.
(5) Это верно.
8 asp
 
29.03.11
13:36
(6) не, даже не 40%. сервер стоил 300 где-то, десктоп 50.
9 МихаилМ
 
29.03.11
13:36
фоновые задания + отложенный расчет итогов.

+ изменение алгоритмов (выборочное перепроведение, запись движений отклонений ...)
10 shuhard
 
29.03.11
13:38
(3)[очень быстрая дисковая подсистема]
RAM диски
11 МуМу
 
29.03.11
13:38
(6) Для каждой конкретной задачи хорошо свое железо. В любом случае для данной задачи будет максимальное ускорение 50 % , либо это будет означать что предыдущий сервак был совсем стареньким. Для современных серваков замена как я уже писал раньше будет 15% и расти потом нелинейно в соответсвии к затратам.
Напомню , я говорю о ускорении в 3-5 раз.
12 shuhard
 
29.03.11
13:39
(7)[Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов. ]
ужо.с
срочно всех на семинары http://softpoint.ru/
13 МуМу
 
29.03.11
13:40
(9) Данную задачу рассматриваем как регламентную которую нужно выполнить в конце месяца. То есть надо перепровести все документы.
14 МихаилМ
 
29.03.11
13:40
не описаны условия задачи,
можно менять алгоритмы проведения.

можно использовать, прямые запросы,

можно ли проводить расчеты в отдельной копии, не в разделенном режиме
и результаты загружать .
15 МуМу
 
29.03.11
13:42
(12) Этого я не говорил и рекламы семинара в этой ветке не будет.  Мне интересно предложит ли кто нибудь более менее точную концепцию реализации. Задача достаточно актуальная. В конце ветки я обязательно отвечу на этот вопрос.
16 shuhard
 
29.03.11
13:44
(15)[В конце ветки я обязательно отвечу на этот вопрос.]
ждём-с
17 МуМу
 
29.03.11
13:44
(14).
Алгоритм проведения менять нельзя. Прямые запросы использовать можно(даст эффект минимальный 10-15%) Расчеты в отдельной копии можно делать.Только что это даст? Важна же хронология документов, один документ влияет на другой.(на себестоимость)
18 Aleksey
 
29.03.11
13:59
(17) Ну почему расчет в файловой версии плюс выгрузка/загрузка в скуль иногда быстрее на порядок, чем просто расчет на скуле
19 Господин ПЖ
 
29.03.11
14:02
(18) базы которые влезают в 1cd я думаю МуМу не интересуют...
20 Aleksey
 
29.03.11
14:08
(19) А зачем пихать всю базу, если мы проводим 1 месяц. Конечно если даже и месяц туда не влазит...
21 shuhard
 
29.03.11
14:17
(20) партии и взаиморасчеты ты умеешь урезать до месяца  ?
22 Aleksey
 
29.03.11
14:18
(21) Да, ввод начальных остатков. Зачем тебе движения за старые месяца, если по сути тебе нужны только итоги?
23 shuhard
 
29.03.11
14:21
(22) блеск, полный отказ от ФИФО в партионном учете
24 Aleksey
 
29.03.11
14:22
МуМу не думаю, что кроме тебя кто-то активно здесь занимался этим вопросом, поэтому рассказывай очень интересно послушать
25 Ёпрст
 
29.03.11
14:23
отключить итоги, весь пересчет итогов делать в своих временных табличках во время перепроведения.
Разве что.
26 Aleksey
 
29.03.11
14:23
(23) Э а каким боком тут ФИФО? По твоему когда программа перепроводит документы за март она берет движения за прошлый год? Или все таки остатки на документ?
27 Ёпрст
 
29.03.11
14:24
+25 т.е сделать аналог с семёрошным толканием ТА вперёд.
28 Aleksey
 
29.03.11
14:27
(25) По сути не перерасчет итогов, а весь расчет движения и писать движения уже самостоятельно. Плюс добавим сюда запись только измененных движений (обычно расчет происходит быстрее чем запись). Т.е. движения не поменялись, значит не переписываем их, а оставляем старые

В теории ускорения должно быть достигнуто за счет отказа перерасчета итогов на каждый измененый документ (итоги в конце считаются) ну и меньше количеств записей документов (чем меньше изменений, тем быстрее перепроводка)
29 iamnub
 
29.03.11
14:28
(0)
Автор - ламо.
30 Aleksey
 
29.03.11
14:28
(27) Там немного по дурацки сделано. По сути как такового ТА нет, а программа смотрит, есть движения после этого документа, значит нужно рассчитывать итоги - нет движения - берем на ТА. Т.е. ТА нельзя двинуть взад, можно только очистить движения впереди, тогда будет расчет на ТА
31 Ёпрст
 
29.03.11
14:29
(28) ну да..
Вот еслиб ешще и период хранения останков был бы короче, 5 дней к примеру, а не месяц - еще быстрее было бы проведение, в разы.
32 Ленинград
 
29.03.11
14:30
зачетный вброс
33 Aleksey
 
29.03.11
14:30
(29) Я бы не стал так говорить на автора, просто ему интересно послушать мнения других, но поверь знаний его в этом вопросе (особенно по 7-ке) поболее чем у многих вместе взятых
34 iamnub
 
29.03.11
14:30
(0)
Пока ты там концепции изобретаешь - у людей уже все давно работает. Ускорение - 12Х.
35 azernot
 
29.03.11
14:31
(26) Возврат с указанным документом партии никогда не проводил? Там-то как раз нужны движения изначального документа...
36 shuhard
 
29.03.11
14:32
(33) компетенция ТС сомнений не вызывает,
формат топик прикольный,
ответ знаю, но не скажу.

в итоге флюд про сферического коня в вакууме
37 iamnub
 
29.03.11
14:32
38 iamnub
 
29.03.11
14:34
(38)
Можно еще быстрее - ХРАНИМКОЙ на СЕРВЕРЕ!!
39 iamnub
 
29.03.11
14:39
(15)
"Мне интересно предложит ли кто нибудь более менее точную концепцию реализации."

Приз-то будет?
40 asp
 
29.03.11
14:40
не хватает условия, что все это нужно делать на типовой конфе.
41 azernot
 
29.03.11
14:40
Как показывает практика 80% необходимости восстановления последовательности связано с изменением сумм (без изменения собсвтенно количества и момента времени документов), соответсвенно в большинстве случаев достаточно пересчитать суммы, без полного перепроведения документов.

Убыстрял восстановление последовательности методом отдельного пересчёта запросами и прямой записи.
По сути метода сводилось к следующему:
1. Проверяем корректность распределения по партиям (упрощённо - в случае ФИФО если есть остаток по более ренней парти с учётом всех допустимых статусов, отборов и т.п. - значит распределение некорректно и документ нуждается в перепроведении). На этом этапе полностью забиваем на себестоимость, нас интересует только корректность списания количества по партиям.
Повторяем п.1 до тех пор пока в интересуемом периоде все партии корректно не распределятся.
2. Восстанавливаем прямой записью суммы партий и связанных движений.

Прирост скорости колоссальный. Во-первых я в п.1 перепровожу только документы с реально некорректными партиями, во-вторых в п.2 я восстанавливаю суммы реально только там, где это необходимо. В идеале бы конечно ещё и в п.1 менять партии без перепровдения, но у меня как-то руки не дошли.
42 wPa
 
29.03.11
15:29
(41) Это не панацея, поскольку не дает гарантии, что будут исправлены оставшиеся 20%, связанные с переносом докумнтов со пересписанием списанных партий, вводом новых партий без их списания по методике. Это лиш метод исправления заранее известной ошибки -  операция над больным - конечное решение, а не полное лечение.
Убыстрение восстановления партий должно быть связано только с восстановлением партий, но к сожалению движения по другим регистрам по методике 1С завязано на партиях. Развязать их,  вытащить из одной транзакции - вот имхо путь к решению проблемы.
43 azernot
 
29.03.11
15:53
(42) Ты не прав, 20% - лечится пунктом 1, когда восстанавливается корректность списания по партиям (в т.ч. и наличие отрицательного остатка после регистратора по партиям - симптом некорректности).
Двжиения других регистров (я их называю связанные движения) я также корректирую в п.2.
Развязать их нельзя, информация в связанных регистрах как раз и берётся из партий. Развязать их - значит организовать некие регламентные процедуры (типа сформировать проводки только в конце месяца)..
44 МуМу
 
29.03.11
16:34
Отходил пообедать. Сейчас буду отвечать.
45 МуМу
 
29.03.11
16:40
(38)В контексте этого подхода не хочу спорить потому как долго разбираться чего там скоряется в 12-ть раз.  Предположим для простоты что запросы по партионке реализованы хранимкой на сервере.  Как в этом случае можно реализовать данную задачу?
46 iamnub
 
29.03.11
16:43
(45)
Я твоего поста вообще не понял.

Ты просил "более менее точную концепцию реализации."

Я показал решение - работает сейчас.

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

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

Лучше я тебе вопрос задам - когда коту делать нечего - он чем занимается?
47 МуМу
 
29.03.11
16:43
(41)Это немного другой подход. Для реализации минимальной задержки актуальной себестоимости применялся подход в котором логировались изменения задним числом. Затем пересчитывались только те документы и только те движения документов на которые они влияли. В данной концепции будем считать что поменялось все и надо все перепровести.
48 Reaper_1c
 
29.03.11
16:45
отказаться от ПУ в пользу РАУЗ.
49 Нуф-Нуф
 
29.03.11
16:46
переходите на рауз
50 МуМу
 
29.03.11
16:46
(46) Ладно , почитаю.  
Условие основное следующее. Изменение кода не допускается, точнее допускается добавить 10 строк кода в существующий код. Это важно с точки зрения того что данное решение не должно привести к изменению логики существующей системы.
51 МуМу
 
29.03.11
16:47
(50)+Под кодом я подразумевал код модуля проведения документов.
52 Mikeware
 
29.03.11
16:47
(49) моим уточненная себестоимость бывает нужна каждый день. а иногда и не по разу...
53 MaxS
 
29.03.11
16:48
(0) Подходит ли вариант с распределенной базой? Полный обмен.  В соседней базе никому не мешая, в монопольном режиме перепроводится всё, что нужно, потом обменом попадает в рабочую базу.

Именно под эту отдельную базу можно подобрать соответствующее железо.
А для  рабочей базы, где работают много пользователей подобрано другое железо под соответствующие задачи...
54 МуМу
 
29.03.11
16:54
(53) Данное решение имеет право на существование но имеет ряд минусов.
В текущей базе нужно закрывать определенный период.  Потому как только с даты предыдущего закрытого периода по дату текущего закрытого периода имеет смысл перепроводить документы.(иначе любое изменение задним числом приводит к возникновению подобной задачи повторно)  Затем необходимо  реализовывать механизмы обмена.  С другой стороны если есть возможность период закрывать, тогда лучше ночью делать пересчет по дату закрытого периода и не парится с обменами.
55 Ёпрст
 
29.03.11
16:57
(54) это, а сколько сейчас по времени занимает примерно проведение одного документа в "заднем" числе ?
ну, строк на 100 в табличной части..
?
Так, для справки.
56 vis_tmp
 
29.03.11
17:02
(55) Смотря насколько оно "заднее"...
57 Нуф-Нуф
 
29.03.11
17:10
(52) хз. да каких целей может понадобится себестоимость текущего дня?
58 iamnub
 
29.03.11
17:12
Дурью маетесь, господа.
59 Ёпрст
 
29.03.11
17:13
(57) профит глядеть..
у нас после проведения накладной смотрят профит в самом документе..
от этого прикидывают скидку/наценку..
Профитная система оплаты, понимашь.
60 Mikeware
 
29.03.11
17:14
(57) Не текущего - вчерашнего, позавчерашнего. Но в течение  дня могут править и "месяц взад", и даже глубже...
"оказалось, что вот это нам привезли дороже, это- дешевле, а вот это как бонус. а насчет этого согласовали с клиентом скидку (наценку за доставку на север)... "
61 shuhard
 
29.03.11
17:15
(59) бывает и прикольней,
у меня каждую ночь в УПП документы перепроводятся за открытый период
62 Mikeware
 
29.03.11
17:16
(59) нет, этого нет. более того, менеджеры не с реализациями работают. И реализации массово появляются начиная с 19 часов..
63 Aleksey
 
29.03.11
17:20
(59) мои профит видят уже в сделки, а руководство вообще периодически хочет видеть предварительный анализ продаж, который работает не по реализациям, а по заявкам, т.е. по резервам :(
64 Ёпрст
 
29.03.11
17:22
ну так, у кого сколько проводится реализация ?

Закинул демку упп в скуль 2008, на серваке 24 ядра, 24 гига оперативы, всё на 10 рейде
Время проведения одного документа в среднем 18 секунд.
Это нормально ?
65 Aleksey
 
29.03.11
17:22
(53) нет не подходит. Я тут давеча за два года перепровел почку бухии, так потом 2 дня ждал когда она в центр загрузиться, так и не дождался. Пришлось убить регистрацию. Такие большие объемы потом хрен куда загрузишь, так что теперь стараюсь больше одного квартала за раз не перепроводить
66 ДенисЧ
 
29.03.11
17:23
(64) типовая - 100 позиций РТиУ, 4 месяца назад, всего четыре месяца в базе - 50 секунд. После моих шаловливых - та же накладная 7-9 секунд...
67 Ёпрст
 
29.03.11
17:24
(66) да уж.. переходите на снеговик - там всё реализовано ?
:))
68 Новиков
 
29.03.11
17:24
(63) это реализовано - ну профит по резервам?
69 Aleksey
 
29.03.11
17:25
Вот если бы типовой интерактивный обмен мог грузить порциями, тогда да. А так ...

p.s. хотя вроде бы фоновый так может, но типовой фоновый только с УТ
70 ДенисЧ
 
29.03.11
17:25
(67) угу. Расчёт себестоимости за месяц (30 000 ОПзС) - 17 часов. После шаловливых - около 8. Тех же часов...
71 ptiz
 
29.03.11
17:26
(0) Не томи! Рассказывай!
72 Aleksey
 
29.03.11
17:26
(68) в заявке да (тупо скопировл из механизма проведения механизм расчета партий, т.е. делаю "виртуально проведение")
73 Mikeware
 
29.03.11
17:28
(65) В снеговике?
74 Aleksey
 
29.03.11
17:29
(73) Угу в типовом непереписанном снеговике, в БП 2.0
75 Новиков
 
29.03.11
17:31
(72) а обычные рту, потом используют списывают те партии из резерва?
76 Aleksey
 
29.03.11
17:31
(73) Там просто все это делается в одной транзакции, плюс в УРИБ обмене если изменились движения, то программа регистрирует эти изменения для ВСЕХ почек.
77 Mikeware
 
29.03.11
17:35
В принципе, обмен можно и переписать слегка....
78 Aleksey
 
29.03.11
17:35
(75) Нет партии не хранятся. Просто показывает результат, который был бы если бы сейчас провели реализацию из этой заявки. Т.е. понятно, что когда появиться реализация партия может быть другой (могут, но не обязаны быть другими), но оценит примерный профит это позволяет.
Впрочем аналогичное может произойти и с проведенной реализацией (изменили время, изменили приход). Так что даже если мы зафиксируем партии, то это не гарантирует нам аналогичный профит в реализации, а раз так, то трудозатраты по фиксации, себя не окупают, и поэтому смысла фиксировать их нет
79 Новиков
 
29.03.11
17:36
(78) а списание автоматическое ГТД в РТУ у вас есть?
80 Aleksey
 
29.03.11
17:37
(79) ГТД в партиях сидит, при проведении, они фиксируються в ТЧ и потом не меняються
81 Новиков
 
29.03.11
17:40
(80) А как же вы счет-фактуру с непроведенного рту печатаете? Проводок же не будет по ГТД?
82 МуМу
 
29.03.11
17:51
Подсказка. Все это сводится к задаче параллельных вычислений.
83 Mikeware
 
29.03.11
17:53
(82) тут разницу между строковыми и числовыми переменными осилить не могут, а ты про "параллельные вычисления" задвигаешь... :-)
84 ptiz
 
29.03.11
18:33
(82) Распараллелить вычисления по разным товарам?
85 Aleksey
 
29.03.11
18:34
(81) Мы счет-фактуру по заявки не печатаем
86 Mikeware
 
29.03.11
18:36
(84) ну в принципе, почему бы и нет. а после - пересчет по взаиморасчетам. Только будет ли быстрее?
87 Aleksey
 
29.03.11
18:36
(82) Была идея засунуть в последовательность измерение товар, и перепроводить конкретно по кривому товару, а не все документы
88 Mikeware
 
29.03.11
18:38
(87) в условии задачи - перепроводить всё.
89 Aleksey
 
29.03.11
18:39
(88) В условиях ускорения, а не полное перепровдение.
90 МуМу
 
29.03.11
18:46
Провести нужно все.
(84) Ну если уж совсем вообщем - да. Нужно заставить работать все процессора сервера.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность.
Вопрос теперь, как концептуально это реализовать?
91 МуМу
 
29.03.11
18:48
(89) Если изменились несколько позиций задним числом то действительно существуют другие более эффективные способы. В данном случае это не тот вариант. Считаем что поменялось все.
92 zaki
 
29.03.11
18:55
Закладка
93 Ёпрст
 
30.03.11
08:19
(91) ты спрашиваешь готовое решение или своё хочешь предложить ?
94 МуМу
 
30.03.11
10:09
(93)Мне интересно, есть ли вообще понимание как подобное может быть возможным.(эта ветка мне интересна для анализа статей, которые я сейчас дописываю) Концепцию я здесь в любом случае расскажу чуть позже.
95 Ёпрст
 
30.03.11
10:19
(94) дык это будет просто концепция, или готовое рабочее решение ?
96 Ёпрст
 
30.03.11
10:20
+95 просто сейчас, упп из "коробки" - это просто мусор.
97 МихаилМ
 
30.03.11
10:26
(94)
окончание статьи я могу угадать

" У автора имеется готовое решение...."
98 МуМу
 
30.03.11
10:27
(95)Это будет описание технологии. Никто не мешает ее реализовать самому. Но как показывает практика(древние статьи на тему производительности 7-ки) от описания до практической реализации очень далеко. Большитнство просто не хотят заморачиваться(как правило если с наскока не получилось то дальше лень) над этим, впрочем в этом есть тоже свои плюсы.
99 Mikeware
 
30.03.11
10:30
(97) сочинение "если б я стал президентом..." ты тоже писал?
100 Ёпрст
 
30.03.11
11:43
(98) ждёмс.
101 shuhard
 
30.03.11
11:46
(90)[.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность.]

примитивный фокус с 10 Организациями в одной базе и
параллельным запуском в 10 1с.exe восстановления по одной организации

мистой зачтен не будет
102 МуМу
 
30.03.11
19:32
(101) Обижаете, подобная задача недостойна обсуждения:)
103 shuhard
 
30.03.11
20:39
(102) и я о том же,
такой примитив мисту не интересует
104 John83
 
30.03.11
21:30
(6) извиняюсь за глупый вопрос, но что такое "стоечный десктоп"?
105 serffer
 
30.03.11
21:37
Очень интересная тема.
106 Ferz
 
30.03.11
23:32
есть идеи но настолько невероятные что их нужно пробовать.

общая концепция примерно такая
n -процессов подготовительные
1 -замыкающий, который и выстраивает последовательность.

Задача подготовительных процессов сохранить откомпилированные запросы и обновить статистику.

Это единственный вариант последовательного!!! (увы с последовательностью ничего не придумаешь) проведения без оптимизации запросов и изменения логики
107 cathode
 
31.03.11
08:50
(106) Если мыслить в рамках одного потока исполнения, действительно кажется, что с последовательностью ничего не поделаешь, так как она кажется набором отметок на временной оси. Но это всегл лишь умственная проекция - удаление одного из измерений. Если у нас, к примеру, есть набор документов, в которых списывается всегда один товар А, а есть набор документов, содержащих только товар Б, то при параллельном проведении этих двух линеек документов важен будет только их порядок друг относительно друга, но не проекция на глобальную временную ось. И в результате такого проведения мы получим то же самое, что и при стандартном подходе "в очередь, сукины деты, в очередь". Таким образом, задача ускорения проведения документов заключается в построении графа зависимостей вхождения номенклатурных позиций в документы от их дат и обработке этого параллельными вычислениями.
Как "наивную", но теоретически верную реализацию, можно предложить следующий подход: на каждую номенклатурную позицию, которая списывалась в данном периоде, создаем один поток исполнения; на всех документах, содержащих более одной строки, на входе ставим джойн всех потоков номенклатур, входящих в этот документ, на выходе - соответственно сплит. На сервере как-то организуем пул исполнителей всех этих потоков с количеством исполнителей, достаточным для загрузки всех процессоров сервера. В результате имеем профит в виде в среднем процессор-кратного ускорения проведения документов и это еще до оптимизации кода проведения.
Я не спец в параллельном программировании, идея мне самому кажется слегка бредовой, просто в этой ветке большинство предлагают стереотипные подходы, а я решил предложить фантастический.
108 Ferz
 
31.03.11
09:23
(107) весь смысл задачи в не неизменности логики ПУ
109 МуМу
 
31.03.11
09:40
(107) Вообще то подход не фантастический а уже реально используемый. Для некоторых задач подходы проще для некоторых сложнее. Описанный вариант с разделением па потоки в разрезе одной номенклатуры тоже можно применять. Проблема в том что тогда нужно было бы реализовывать бизнеслогику.Пришлось бы реализовывать отдельную обработку которая расчитывала партионку по одной номенклатуре в разрезе N документов. А затем можно было бы запускать эти обработки из нужного количества потоков(сессий) 1С полностью параллельно.  Данный подход имеет более высокие накладные расходы, однако в специфических случаях его можно и нужно применять.(например отдельно для номенклатуры которая с высокой вероятностью встречается в каждом документе и тем самым существенно снижает уровень параллельности)
Итак, идея концептуально правильная. Формируется пул потоков(сессий 1С), этому пулу потоков необходимо параллельно и правильно распределять документы. С одной стороны должна соблюдаться хронология а с другой все документы должны насколько это возможно проводится параллельно.
Вопрос теперь каким образом это реализовать?
110 Nikulin
 
31.03.11
09:41
Свои 5 копеек.
а почему бы не поделить номенклатурный справочник скажем на 10 групп. далее каждая сессия 1с обрабатывает движения партий по своей номенклотурной групе.
вуаля.
111 МуМу
 
31.03.11
09:41
(108) В общем верно, в (107) действительно пришлось бы реализовывать отдельно бизнес логику, поэтому его не рассматриваем.Хотя вообщем идея правильная.
112 МуМу
 
31.03.11
09:43
(110) Вопрос в статистике. Если у вас в компании товар четко разделен в разрезе менеджеров и это легко доказать. То тогда да. Вы можете разделить этот товар в разрезе этих групп, зная что они полностью независимые. В этом случае можно добиться некоторого паралеллизма.(группы скорее всего не одинаковые по объему инф. потоков) Но такое на практике бывает редко.
113 МуМу
 
31.03.11
09:45
Если же просто разбить справочник номенклатуры на Н частей и попытаться на основании этих групп разбить документы на независимые группы. Выяснится что этого не получится, кроме тех исключительных случаев когда в табличной части документа находится одна-две номенклатурынх позиции.
114 Nikulin
 
31.03.11
09:46
(112) можно предварительно провести обработку и сбалансировать группы например по количеству операций над данным товаром. Чтобы в каждую группу попало одинаковое количество операций. т.е. в одной группе может быть 2 товара а в другой 100.
115 МуМу
 
31.03.11
09:48
(114) При среднем количестве строк в документе более 10-и данная задача становится практически нереальной. Не верите? Проведите эксперимент у себя на БД.
116 Reaper_1c
 
31.03.11
09:48
Не надо на документах циклиться - надо восстанавливать последовательности по минимальному кванту. Т.е. по связке серии и характеристики и перезаписывать движения документов извне. Вариантов может быть много - составление уравнений, сопоставление всего прихода со всем расходом на периоде и даже банальный алгоритм подокументного расчета но с обязательно с очисткой движений позже ГП по связке, чтобы запросы обращались к записи с актуальным итогом. Собиаем все связки, пилим их на количество камней и раздаем разным процессам для обработки
117 Mikeware
 
31.03.11
09:49
(113) Не перепроводить-то нам надо не документы, а партии. Поэтому достаточно первого параллельного прохода по партиям, а затем - по результатам продаж/по документам (в зависимости от того, на что влияет себестоимость партий.)
118 МуМу
 
31.03.11
09:49
+(114)То есть выяснится что в большинстве документов находятся одновременно несколько номенклатурных позиций относящихся к нескольким группам что не позволит обрабатывать их паралллено.
119 Vladal
 
31.03.11
09:50
А за какой период провести? У нас внедрюки с прошлого февраля последовательность гонят-гонят, никак не выгонят.
120 Mikeware
 
31.03.11
09:51
(118) обрабатывать нужно не документ, а движение документа по номенклатуре
121 Mikeware
 
31.03.11
09:52
(118) так у тебя таки есть решение, или ты тут чисто идеи собираешь? :-)
122 Nikulin
 
31.03.11
09:53
(117) я об этом и говорю. Например.
1. организуем стэк занятых документов.
2. разбиваем товар на квантовые составляющие (например товар + серия).
3. запускаем процессы, присваеваем им группы.
4. при изменении движения помещаем документ в стэк (чтобы никакой другой процесс не менял его.
5. меняем движения по париям в рамках кванта+документа.
6. удаляем документ из стэка.
.... ну можно не стэк использовать а блокировки и ожидания.
помоему взлетит. и минуем необходимость организовывать управляющий процесс.
123 МуМу
 
31.03.11
09:53
(116) Пока что рассматриваем варианты с неизменной бизнеслогикой.(т.е. мы ее не выносим в отдельные обработки). В (107),(109) описан вполне работающий вариант, только у него есть несколько недостатков.
124 Mikeware
 
31.03.11
09:56
(122) а зачем стэк занятых? у тебя расщепление по номенклатуре, этого достаточно...
125 Nikulin
 
31.03.11
09:59
(124) на случай если пересечется момент изменения квант+документ в разных потоках.
126 Nikulin
 
31.03.11
09:59
т.е. пересечется документ =)
127 Mikeware
 
31.03.11
10:00
(125) измерения у тебя не пересекутся, а на документы пофиг.
128 МуМу
 
31.03.11
10:01
(121) У меня есть решение:) Концептуальное описание я потом здесь выложу.
(122) Не понятен пункт 3. Предлагаю пример.
Есть последовательность документов. На сколько можно разбить параллельных потоков провдение этих документов?
Приходная накладная 1 (Товар1,Товар2,Товар3)
Расходная накладная 1 (Товар11,Товар12,Товар13)
Расходная накладная 2 (Товар1,Товар22,Товар23)
Расходная накладная 3 (Товар21,Товар22,Товар23)
Расходная накладная 4 (Товар31,Товар32,Товар33)
Расходная накладная 5 (Товар41,Товар32,Товар43)
Расходная накладная 6 (Товар51,Товар52,Товар53)
129 Nikulin
 
31.03.11
10:01
(127) ну вобщем да. если обработка наткнется на блокировку дстаточно предусмотреть ожидание освобождения...
130 Nikulin
 
31.03.11
10:05
(128) ну мне лень считать кол-во товаров там
общая формула:
товар1 1 измененй
товар2 5
товар3 3
хтим разбить на 2 потока
получаем что всего 8 зменений . раскидываем пропорционально получаем
в 1 потое товар 1 и 3
во втором потоке товар 5
Примерно так.
Идеального распределения тут не достич, но на большом массиве данных будет примерно равное распределение
131 МуМу
 
31.03.11
10:05
Еще один пример. На сколько потоков можно разбить данную последовательность?
Приходная накладная 1 (Пакет,Товар2,Товар3)
Расходная накладная 1 (Пакет,Товар12,Товар13)
Расходная накладная 2 (Пакет,Товар22,Товар23)
Расходная накладная 3 (Пакет,Товар22,Товар23)
Расходная накладная 4 (Пакет,Товар32,Товар33)
Расходная накладная 5 (Пакет,Товар32,Товар43)
Расходная накладная 6 (Пакет,Товар52,Товар53)

Я это к тому что уровень параллелизма и соответсвенно ускорения для каждой системы свой. Хотя для приведенного примера есть свои пути обхода.
132 Nikulin
 
31.03.11
10:08
(131) вобщем конечно да, можно стремиться к идеалу и преодолевать опеделенные трудности. а можно ограничиться определенной достаточностью
133 МуМу
 
31.03.11
10:12
(130) Попытка разделить заранее товары на группы а затем на основании этого разделить на потоки заранее обречена на провал. Дело в статистике. Убедиться проще всего написав несложную обработку.Практически гуппы такие возможны но они будут не сбалансированны. Задача их балансировки практически на вашей системе может вообще не иметь решения. Потому как товары из нескольких групп будут присутсвовать в табличной части большинсва документов одновременно.
134 Nikulin
 
31.03.11
10:18
(133) Да я и говорю что не идеально но при оценке затрат на разработку для многих случаев достаточное решение.
135 trad
 
31.03.11
10:42
(133) а если каждый поток при проведении документа будет рассчитывать только товары своей группы
136 trad
 
31.03.11
10:44
а товары распределить по потокам след. образом:

|select Номенклатура
|from СтрокиДокументов
|group by Номенклатура
|order by count(*)

- эту выборку посеять в несколько корзин-потоков
137 cathode
 
31.03.11
11:14
(109) Не совсем так. В решении предлагается не многопоточный расчет себестоимости, гранулой которого является позиция номенклатуры, а синхронизация потоков на входе в документ. Наши потоки бегут сначала свободно. Как только они натыкаются на очередной "свой" документ, т.е. содержащий данную номенклатуру, они останавливаются и ждут все остальные потоки, номенклатура которых входит в этот же документ. При синхронизации документ проводится и выпускает потоки своей номенклатуры в свободное выполнение. Как-то так.
138 Alsh
 
01.04.11
08:09
Заглохла ветка... А было интересно...
139 MM
 
02.04.11
17:18
МуМу, где методика, пока ветка совсем не потонула?
140 МуМу
 
02.04.11
18:13
Дел много было. Выложу в понедельник.
141 azernot
 
03.04.11
12:20
Любое разделение на группы номенклатуры и попытка их параллельной обработки по сути всё равно приведёт к методике описанной в мной в (41). Т.е. не стандартное проведение, а пересчёт прямой записью нужных регистров (всех, с условием на неправильность, с условием по группе и т.п.). Поскольку та методика была отвергнута как "немного не та", имхается многоуважаемый МуМу хочет предложить нашему вниманию что-то совсем революционное. Ждём-с!
142 ДенисЧ
 
03.04.11
12:23
отправил большой заказ на попкорн. жду.
143 Mikeware
 
03.04.11
12:37
(142) ты столько не съешь :-)
Кстати, предложенная в (137) мысль о синхронизации потоков имеет некий смычл. Но в условиях большой связности потоков ожидание будет занимать значительное время, что сведет на нет параллельность. Вчера попробовал рассчитать потоки для параллельного проведения (автокорелляцией товаров) - на первый взгляд, получилась изрядная чушь.
144 skeptik_m
 
03.04.11
13:00
А производственные операции в базе есть? Если цена партии одного ТМЦ может влиять на цену партии другого ТМЦ, то все попытки считать по отдельным ТМЦ (группам) в отдельных потоках заведомо не годны. Нужно строить полный граф зависимостей (желательно еще в момент проведения документа дописывать информацию в этот граф, который хранить в в виде таблицы БД), но тут уже минимальными изменениями конфигурации (10 строк) не обойдешься.
145 Mikeware
 
03.04.11
13:02
(144) теоретичски этот граф (полный) известен до перепроведения - мы ведь сейчас (по условиям задачи) оперируем не партиями, а документами...
146 skeptik_m
 
03.04.11
13:48
(145) В том-то и дело что в стандартной конфигурации граф неизвестен до проведения. Нам же для организации работы паралельных потоков проведения нужно понять, какие документы можно проводить независимо друг от друга, а какие должны "подождать", пока не будут проведены определенные предыдущие поскольку они от них зависят. Если заранее построенный граф есть - все просто: есть поток-диспечер, которая обходит граф и "раздает" задания на перепроведение конкретных документов потокам-исполнителям, которые их собственно их перепроводят.
Степень достигаемой параллельности зависит от того "как фишка легла" при построении графа. Теретически возможна и такая ситуация, когда обрабатывать прийдется все строго последовательно, она в общем случае маловероятна (но на каком-нибудь специфическом производстве все может быть).
147 skeptik_m
 
03.04.11
14:09
Впрочем, если заранее известнол у нас чистое купи-продай, без преобразований одних ТМЦ в другие, в качестве графа зависмостей вполне можно использовать саму последовательность. Имеем список "заблокированных товаров" (ведется процессом-диспечером), когда отдаем документ в "пул паралельного проведения", помещаем туда товары из этого документа. Когда документ будет обработан одним из паралельных процессов-обработчиков - убираем товары из этого списка. В пул на обработку документ можно добавлять только в том случае если ни один товар из него "не заблокирован". В противном случае нужно с эти документом ждать, а пока обрабатывать следующие в последовательности.
148 МуМу
 
03.04.11
14:37
(147) Ну концептуально так.
Создается отдельный пул соединений 1С.  Координатор задач выбирает из общей последовательности очередной документ. Далее координатор блокировок накладывает блокировки и  проверяет нет ли пересечений по блокировкам с проводящимися или стоящими в очереди документами.(в данном примере по табличной части товара)Если блокировки не пересекаются  то документ выдается свободной сессии на проведение. Если блокировки пересекаются то тогда документ ставиться в очередь  за связанным с ним документом. Если документ зависит от нескольких документов – ставится в очередь за последним по времени.
149 МуМу
 
03.04.11
14:40
То есть заранее разделить документы на группы, на графы ни к чему хорошему не приведет.
В данном механизме эмулируется своего рода работа пользователей. Ведь они же могут и проводили(если правильно настроены блокировочные механизмы) эти документы параллельно. И от того что они проводили параллельно последовательность не нарушилась(опять таки если блокировки правильно настроены). Изменилась последовательность из за изменений задним числом.
150 МуМу
 
03.04.11
14:42
Фактически координатор задач(и блокировок) для каждого нового документа который берет из общей последовательности проверяет есть зависимость или нет. Если нет то в свободную сессию на проведение , иначе в определенную сессию в очередь. При завершении проведения документа срабатывает событие по которому можно все очереди перестроить или же не перестраивать а брать из последовательности новый документ и выполнять описанную ранее процедуру.
151 МуМу
 
03.04.11
14:43
Для данной технологии нельзя применять ни координатор блокировок от 1С 8. Ни координатор блокировок от MSSQL.
Это происходит по тому, что необходимо проверять все множество товаров на вхождение хотя бы одного элемента не просто для последнего в очереди. Необходимо смотреть пересечение по всему множеству товара документов стоящих в очереди.
Приведу на примере блокировок MSSQL.

Есть следующие документы:
Расходная накладная №1 (Товар1,Товар2,Товар3,Товар4)
Расходная накладная №2 (Товар4,Товар5,Товар6,Товар7)
Расходная накладная №3 (Товар7)
Блокировки пускай накладываются слева на право.
В этом примере Расходная накладная №2 станет в очередь за Расходной накладной №1 по пересечению на Товар4.  При этом она не наложит ни одной блокировки потому как сразу повиснет на позиции Товар4. При этом  Расходная накладная №3 может успеть провестись ранее  Расходная накладная №2 что конечно будет не верно, ведь у них есть пересечение по Товар7.  А  провестись она может ранее потому как по размеру меньше и потому как блокировка на Товар7 не была наложена.
Координатор от 1С тоже не подходит потому, как в момент ожидания на блокировке не накладываются блокировки намерением от ожидающей сессии ну и потому что очередь работает по LIFO.
152 МуМу
 
03.04.11
14:45
Но еще раз повторюсь, логику документов переписывать не нужно.(разве что пару строк кода).
Блокировки известно откуда брать - по товару из  табличной части документа. Их можно брать независимо координатором блокировок.
153 МуМу
 
03.04.11
14:46
Там много еще всяких ньюансов, но это я подробнее выложу в понедельник в статье.
154 МуМу
 
03.04.11
14:48
Уровень параллелизма зависящий от данных разумеется влияет на максимальное ускорение.  Рассчитать его без реализации координатора задача достаточно непростая. Потому как это зависит как от пересечения множеств товаров, так и от времени проведения документов.
155 skeptik_m
 
03.04.11
14:48
Надо помнить, что это будет работать в таком виде только в случае, если нет взаимозвисимости между разными товарами, т.е. производство полностью отсутствует.
156 МуМу
 
03.04.11
14:49
При правильной реализации координатор должен отнимать не более 3 процентов ресурсов.
157 skeptik_m
 
03.04.11
14:51
Думается мне, что более-менее правильная реализация координатора (то есть не идеальная, но удовлетворительная) особо большой проблемы не представляет.
158 МуМу
 
03.04.11
14:52
Ну самый распространенный пример если у вас в каждом втором документе будет "пакет полиэтиленовый" то уровень параллелизма будет очень маленьким. С другой стороны этот товар можно исключить из расчета и блокировок в силу нескольких причин. Товар с большой вероятностью присутствует на складе. Колебания по абсолютному значению маржинальности крайне малы и ими можно принебречь.
159 МуМу
 
03.04.11
14:55
(158)+Хотя если финансовый упрется для данного примера есть обходные пути.  Только тогда придется отдельно логику реализовывать. Рассчитывать отдельно без пакета по поисанному алгоритму а для пакета делать отдельный пересчет на уровне записей движения только по пакету.
160 bazvan
 
03.04.11
14:56
(148) Поготь а разве не так же работают интеловские процесоры (выполняют инструкции) которые Коре2Дуба (Конрой или как прально ядро называется)? Или я чето путаю
161 МуМу
 
03.04.11
14:59
(160) Они то рады работать-только кто им даст:) Если мы все действие выполняем в одной сессии то для процессора это четкое указание - выполнять на одном процессоре(ну или менять их но задействован будет только один).  Ведь сервер не догадывается о внутренних процессах и особенностях. Он не знает что можно параллелить а чего нельзя. Это и есть особенность параллельных вычислений. Мы должны его написать так что бы сервер мог его параллелить на уровне процессоров.
162 МуМу
 
03.04.11
15:00
В понедельник с утра будет выложена статья в которой все это более подробно будет освещено. А затем до 12-го числа будет опубликован большой набор статей посвященный параллельным вычислениям и технологии "гибких блокировок"(по сути это просто бренд).
163 bazvan
 
03.04.11
15:02
(161) Я имел ввиду что как она микропрограмма самого чипа так и выполняет инструкции. не относительно приложений а именно внутри чипа.
Чето такое как раз читал в Апгрейде в 2005 что ли году или когда там появился этот Конрой
164 bazvan
 
03.04.11
15:06
+(163) могу ошибатся. Сори если фигню спорол
165 skeptik_m
 
03.04.11
15:07
(158) Ну если лезть в частности, то есть случаи когда можно паралельно проводить документы по одному и тому-же товару. Это ели расчет ведется по орагнизациям и/или складам отдельно.
"Разделителем проведения" может быть не только товар.
166 МуМу
 
03.04.11
15:13
(165) Разумеется зависит от специфики и от данных. Для партионки если в регистре партионного учета склад не предусмотрен добавлять нельзя. В этом случае блокировки будут по ЮРЛИЦО+ТОВАР. Если есть склад то тогда ЮРЛИЦО+СКЛАД+ТОВАР.Во втором случае конечно уровень параллелизма выше.
167 finik
 
03.04.11
15:53
закладка
168 ptiz
 
04.04.11
11:57
Где статья?
169 МуМу
 
04.04.11
12:12
Статья еще редактируется, поэтому прошу на формат и синтаксис внимания большого не обращать.
http://softpoint.ru/article_id375.htm
170 МуМу
 
04.04.11
15:00
Завтра выложу другую, посвященную параллельным вычислениям.
171 Kraft
 
04.04.11
15:06
кайфовая ветка... Очень нестандартная для нынешней OFF-ной мисты.
172 DailyLookingOn Sunset
 
05.04.11
07:26
Просмотрел концептуальный пресс-релиз.
бууээээ
173 smaharbA
 
05.04.11
07:46
а что вы будете делать с измененными техкартами, торгаши
174 disk-2008
 
05.04.11
07:50
Да, в УПП не только торговля.
175 shuhard
 
05.04.11
08:06
(169) как и ожидалось,
статья оказалась голимой рекламой Гибких блокировок СофтПоинта
176 Mikeware
 
05.04.11
08:43
(175) не без этого. Хотя тема навела на некоторые размышления
177 МуМу
 
05.04.11
08:44
(173). Принцип абсолютно тот же для производства. Было бы наивно расчитывать на то что будет выложено готовое решение. К тому же как вы уже заметили это всего лишь технология(извините что мы ее называем "гибкие блокировки"). Данная технология требует адаптации для конкретной специфики.
178 МуМу
 
05.04.11
08:47
(175) Не нужно принимать все так близко к сердцу;) Чего же вы ожидали? Что я буду пиарить лично себя(как делают многие)? - мне это не нужно. Обещание я свое выполнил. Решение уверяю вас абсолютно рабочее. Любой одинэсник может при желании его реализовать, только на это нужно время и упосртво. Конечно же есть подводные камни, ну а где без них не бывает.
179 МуМу
 
05.04.11
08:49
Еще раз повторю, что торговля выбранна лишь как тематика которая проще всего для понимания. Все таки с производством знакома гораздо меньшая аудитория. Для производства принципы абсолютно те же.
180 МуМу
 
05.04.11
08:53
Вот еще одна статья , вообще на тему параллельных вычислений.
http://www.softpoint.ru/article_id376.htm  
Написан большой пул статей, будет выкладываться в среднем две в неделю. Да, там будет скрытый пиар но будет и много чего полезного. В частности технологии которые можно применять независимо и реализовать самостоятельно.
181 МуМу
 
05.04.11
08:55
Следующая статья будет посвящена ускорения обмена в 1С путем применения тех же параллельных вычислений.
182 shuhard
 
05.04.11
09:01
(180)[Да, там будет скрытый пиар ]
что, РАУЗ в УПП, выход КА и УТ 11 прихлопнули сегмент ?
183 МуМу
 
05.04.11
09:04
(182) Нет, работы хватит на всех:) Просто давно статьи не выкладывали.
184 Mikeware
 
05.04.11
09:05
(182) РАУЗ - не панацея.
185 smaharbA
 
05.04.11
09:07
всегда хочется на халяву (не меняя кода) и что бы считало правильно
186 Jolly Roger
 
05.04.11
09:51
да уж... гора родила мышь...
187 Scooter
 
05.04.11
10:03
дочитал до виртуальной биржи, дальше не стал
188 AlexNV
 
05.04.11
10:20
Как вариант распаралеливания:
1. Поднимаем еще один сервер и пихаем его в кластер
2. На основном отрубаем регл задания
3. Делаем кол-во процессов нового сервера = кол-во ядер - 1
4. Делаем фоновые задания, кол-во = кол-ву процессов
5. Ими проводим по партиям
6. и не забываем про упр болкировки
189 МуМу
 
05.04.11
10:47
(186) Я лишь обещал то что обещал. Возможно вы ожидали или поняли задачу как то по другому. Задача реализуема, концепция объяснена.
(187) Тем кто понимает этого достаточно. (пример приведен для большего понимания)
(188) Так не взлетит. Последовательность будет нарушена, потому как процессы будут брать документы по очереди а вот проводится они будут не в хронологической последовательности. Либо если выбирать такой вариант необходимо изменять время документов(в некоторых случаях это не верно).
190 МуМу
 
05.04.11
10:49
(188) Там пример в статье приводится почему координатор блокировок 1С и MSSQL не подходит.
191 AlexNV
 
05.04.11
10:49
(189) смотря как определять какую номенклатуру проводить
Вариант: есть таблица, в ней позиции для проведения, процессы выбирают что они будут проводить. Если все процессы завершились корректно, то двигаем ГП.
192 МуМу
 
05.04.11
10:53
191. Корректность проведения(откаты транзакций по логике или на физическом уровне) это вообще отдельная тема.(это один из подводных камней которые нужно решать) В статье про это не расписано. В данном случае дело не в этом. Вот расскажите каким образом процессы будут выбирать документы из очереди документов? т.е. есть 8-м сессий 1С , каким образом они будут получать порцию сових документов(этом может быть и один документ)? Как вы в этом случае обеспечите ровно такую же хронологию как была изначально?(учитывая что время документов может существенно отличаться а также то что некоторые документы могут висеть на управляемых блокировках)
193 MM
 
12.04.11
16:44
Жаль затихла тема.
На чём стоит писать координатор блокировок для распараллеливания? На 1С его получится его написать или нужен настоящий язык программирования?
194 МуМу
 
12.04.11
18:07
Зависит от объема информацинных потоков. Мы реализовывали на C++.  На 1С реализовать можно но накладные расходы будут больше.
195 iamnub
 
14.04.11
00:20
(194)
O_O На С++

Называется - горе от ума. Задача решается намного проще - без картинок и умных слов.

Работает у меня, работает у MIKEWIRE.

А вы, муму, постарайтесь отойти от "надо перепровести все документы!", ей богу - как за программиста - так просто стыдно.
196 МуМу
 
14.04.11
21:00
(195) В частном случае решается гораздо проще. А в общем почетайте на тему параллельных вычислений - что это такое и зачем нужно. Может так не будет за меня стыдно.
197 МуМу
 
14.04.11
21:02
(196) извиняюсь за опечатки-за них действительно стыдно;)
198 Fragster
 
гуру
14.04.11
21:02
купить мать, в которую можно воткнуть 64 гига оперативы, и сделать рамдрайв на 60 с базой. перепроводить в файловом режиме
199 Fragster
 
гуру
14.04.11
21:03
(198)+ ну это правда если база меньше 60 гб
200 _Demos_
 
14.04.11
21:27
(15) конец ветки.  выкладывай что там у тебя
201 shuhard
 
14.04.11
21:33
(198) сие очевидное решение, предложено ещё в (10)

цена на порядок ниже варианта софтпоинта,
ускоряет всё, а не только восстановление последовательности
202 МуМу
 
15.04.11
01:43
(201) Читаем отзывы на http://softpoint.ru/feedback.php
Внимательно думаем...   Предложи им свое решение которое "ускоряет все"(цитата из (201)) и думаю наступит счастье и может быть даже и комунизм.
203 Злопчинский
 
15.04.11
04:45
> Для данного примера все будет зависеть от того насколько пересекаются между собой номенклатурные составы документов. Если пересечения небольшие, то уровень высокий и ускорение потенциально высокое.
.
это значит что оптимальным будет не документ из 100 строк, а сто маленьких отдельненьких документов по 1 строке, которые можно получить "разложив" исходную базу - перепровести - собрать исходную базу..
204 Mikeware
 
15.04.11
08:11
(195) это разные решения.
теоретически - у Владимира получаются меньшие вмешательства в конфигурацию. И один проход.
(203) теоретически - да.
205 guevara74
 
15.04.11
08:29
Согласен со всеми, кто сказал слово РАУЗ
206 iamnub
 
15.04.11
11:52
(202)
А ты часто "внимательно думаешь"?
207 iamnub
 
15.04.11
11:53
(204)
Я имел ввиду - у нас с тобой одинаковые решения.
Ускорение до x10 без гибких блокировок и C++-сной зайуми.
208 iamnub
 
15.04.11
11:54
Вообще у меня мечта - вынести вообще восстановление партий в .NET логику. Это первая итерация.

Вторая - заюзать CUDA. ))))))
209 Scooter
 
15.04.11
11:59
(195)а где ваше решение почитать

ЗЫЖ если в этой ветке было ткните плиз в номер сообщения
210 iamnub
 
15.04.11
12:06
(37)
211 Злопчинский
 
15.04.11
15:18
стопудово ясно, что на перепроведение доков навешано куча всего сопустствующего. если просто выбдрать расчет провести его "в стороне" и вложить обратно в данные - все должно получиться просто офигенно быстро...  ?
212 МуМу
 
15.04.11
15:40
(207) Решения разные принципиально. У нас например есть отдельно решение "интеллектуальное востановление последовательности"(выборочное востановление), есть решение с кешированием расчета остатков для однопоточного расчета(ускорение линейного расчета- на него больше похоже).  
Каждое решение лучше подходит для своего случая. Описанное решение в ветке подходит для большинства случаев. Это подтверждается практикой. В конце концов все решает рынок. Если ты уверен в решении (37) - предлагай его. Получай заслуженную выгоду.
(211) Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является.
213 iamnub
 
15.04.11
15:49
(212)
"Решения разные принципиально"
Я не пойму. Ты - Mikeware?

"Описанное решение в ветке подходит для большинства случаев."
Мое решение - простая внешняя обработка, которая будет работать без каких-либо допиливаний. Плюс (по желанию) - можно отключить механизм расчета себестоимости при самом проведении документа - это себя изжило.

Так что проще - внешняя обработка или "гибкие нейросети на С++"?
214 iamnub
 
15.04.11
15:52
И знаешь, Муму, к твоим "нейросетям" претензий-то как бы и нет.

Просто ты создал тему (как оказалось для пиара) - бросил замануху, народ повелся, начал что-то предлагать - а ты тут с видом "все в г_овне - один я в белом" - вывалил свой ИИ в картинках. Как-то по жлобски.
215 МуМу
 
15.04.11
16:21
(214) Здесь не пиар, пиар на сньюсах, рбк и т.п.:)   Вопрос - если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?
Хочешь пиар? Если оно такое простое и универсальное-реализуй его для УПП. Выложим его бесплатно на мисте и на сайте софтпоинта. Если будет хотя бы 10-ть благодарностей(с примерами использования) - я выплачу тебе 1500 у.е. за потраченное время. Всем будет только хорошо.
216 МуМу
 
15.04.11
16:23
(214)Уверяю тебя и всех остальных - я не хочу чего либо заработать на посетителях этого сайта. Это принципиально другая аудитория. Мне здесь нужно только лишь обратная связь. За это я готов заплатить сам(как информацией так и деньгами):)
217 Ёпрст
 
15.04.11
16:28
(213) т.е во время проведения вообще не толкать партии, а потом фоном твоей обработкой ?
218 iamnub
 
15.04.11
16:45
(217)
Да. Во время проведения движения по регистру партий делаются, но с пустой партией и ценой последнего прихода.
219 iamnub
 
15.04.11
16:51
(215)
А ты в софтпоинте главный?
220 iamnub
 
15.04.11
16:56
(215)
У меня и взаиморасчеты также считаются - моргнуть не успеешь - еще быстрее.

Я разделяю первичные данные и данные рассчитанные на основании первичных данных (расчетные). И я понимаю, что незачем пихать расчет косвенных данных в обработку проведения, а лучше рассчитать их скопом и в фоне.

Пока разработчики УПП этого не поймут - в УПП много чего не будет.

P.S. Насколько я знаю - что-то подобное в УПП есть (фоновое проведение (???),РАУЗ). Мы замутили свою приладу раньше. )))
221 luns
 
15.04.11
17:00
(215) как пример ответа на вопрос "если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?".

отчет "Финансовый расчет" в УПП, часто выдает ошибку 256 таблиц
вот ссылка: http://1c-pro.ru/index.php?showtopic=5416
ошибка датирована 2007 годом
в 2008 я написал свой отчет, так как 1с не отвечала на вопрос когда пофиксят.
вот мой: http://luns-it.ru/2010/02/отчет-финансовый-расчет-для-упп-подс/

сейчас 2011 и ошибка в типовом так и осталась.
222 iamnub
 
15.04.11
17:19
(221)
Ну, сейчас тебе зашлют "1500 у.е. за потраченное время"!!
223 МуМу
 
15.04.11
20:49
(222) Меня многие здесь знают. Обманывать не буду. Напиши, выложи методику+обработку. Выложим бесплатно. Будет больше 10-и положительных отзывов - отправлю(им) тебе 1500 у.е. (любыми вариантами по желанию)
224 Snovy
 
15.04.11
20:56
В свое время в институте (я заканчивал по специальности оборудование сварочного производства) меня учили, что самое лучшее сварное соединение - это отсутствие сварного соединения. Так и здесь - самое лучшее решение по восстановлению последовательности - это отсутствие необходимости восстанавливать последовательность. А все остальное - ересь...
225 МуМу
 
15.04.11
22:50
А еще ересь - бюрократия,взятки и т.п. Реальная жизнь - штука многогранная.
226 Snovy
 
15.04.11
22:59
(225) Еще раз - нормальная учетная система не подразумевает шаманства с восстановлением последовательностей чего бы там ни было - либо все это автоматизировано другими способами, либо регламентировано (жестоко, жестко, мягко) и т.д. Т.е. на поверхности лежит другая архитектура учетной системы, только обычно глаз замылен чем то, называемым "типовым". Мы живем в трехмерном мире, а проблемы учета рещаем в стиле 2D - вместо того, что бы перепрыгнуть проблему, мы ее обходим...

ПС. Термины навеяны недавним окном ИТРП и их нравоучениями (с коими я не совсем согласен), но лично я давно партионный учет (НКС, МПЗ, расчеты с контрагентами, ЦБ) решил полным отказом от каких-либо последовательностей, а перепроведение документов - это вообще грех, за который во времена инквизиции сжигали на кострах :)
227 МуМу
 
15.04.11
23:02
Мы живем не в идеальном мире. У многих эта проблема актуальна. Перевоспитать всех слищком сложная задача.
228 Snovy
 
15.04.11
23:15
(227) Вообще решение лежит на поверхности, причем с объединением (использую термины 1С) ордерного склада, партионки в классическом стиле и партионки в стиле 1С, финансового учета и оперативного учета - это использование учетных цен и счетов 15 и 16. 1С дернулась в этом направлении и заглохла на 1/10 пути. А ведь данная методология (даже не побоюсь этого слова - технология) абсолютно легальна с точки зрения всех видов регламентированного учета (РСБУ, НК, МСФО) и поддерживает любые прихоти управленческого учета. Применение методики учета в БУ счетов 15 и 16 разводит реальный складской учет и финансовый учет на две составляющие (приход/использование и расчеты с поставщиком/оценка себестоимости).
229 МегаБум
 
15.04.11
23:16
(0) зачем тебе последовательность?
А где пит?
230 Snovy
 
15.04.11
23:19
(229) Так вот пита и нет... а то бы сейчас!!! Кстати, кто-нибудь что-нибудь о нем знает (о Пите)?
231 azernot
 
16.04.11
00:06
Как только вы захотите анализировать реальную валовую прибыль по сделкам, вам понадобится последовательность (партии, средняя и т.п.). Все разговоры про "волшебный" РАУЗ или про учётные цены только в первом приближении кажутся легким решением, на самом деле не отвечающее требованиям оперативности и точности. Решение не редактировать документы задним числом тоже имеет кучу минусов. В итоге по-любому встанет проблема востановления последовательности и, соответсвенно, её оптимизации. Самым лучшим решением будет в любом случае восстановление только реально нарушенной последовательности (а не всей подряд как это делает типовое решение). В случае если у вас есть механизм восстановления последовательности точечно (по конкретной номенклатуре/организации/складу и т.п.), распараллеливание процессов уже не становится некой сверхзадачей (хотя бузусловно ускорит процесс).
Если же последовательность нарушается глобально, по всем измерениям и всегда, как это требует автор, то тут уже стоит задуматься об организации бизнесс-процессов как таковых, а возможно и отказа от партий в принципе.
232 azernot
 
16.04.11
00:19
+(231) Мудрёно получилось... Основная мысль в том, что всё-таки не стоит ставить задачу параллельной обработки данных во главу угла, в первую очередь стоит научиться универсально обрабатывать последовательность точечно, только там где это реально требуется. А там уже и параллельность организовать по предлагаемой автором методике гораздо проще (т.к. минимальная единица уже не документ, а конкретный набор записей). Ну и необходимость последовательности для меня очевидный факт, поскольку никакие другие методики не отвечают моим требованиям к оперативному и точному учёту.
233 D_o_t_e_r
 
16.04.11
00:27
(232) - собственно что в этом то сложного? У меня на работе холдинг в 9 конторок упрощенки, упп, месяц проводится монопольно за 20 часов. При исправлении данных месяцом ранее (стабильно бывает и не раз в месяц) - последствия понятны... Так вот, всего то пару часов допиливал групповую обработку справочников и документов, и там сделал то по сабжу всего ничего - отбор по вохождению "Организация" и "номенклатура из списка в документе" + проведение с паузами - чтобы если край как надо днем восстановить - работе не мешать. Как бы вот и вс1/ зачем огород городить в этом случае?
234 D_o_t_e_r
 
16.04.11
00:29
А сабж тоже бред собственно. Если такое "надо" каждый день - так это что то в "датском королевстве" не аллё.
235 МегаБум
 
16.04.11
01:23
средневзвешенную уже предлагали?
236 Злопчинский
 
16.04.11
05:18
> Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является.
.
- непонятно! сторонней обработкой решаем логически законченный блок/алгоритм востановления/расчета псоледовательности... при чем здесь транзакции? или речь идет о фоновом восстановлении последовательности при работающих юзверях..?
.
вообщем особо непонятно зачем восстанавливать последовательность... получается что последовательность восстанавливать нужно только для правильного исчисления себестоимости/партионки... - ну и нахрена? была кривая партионка, по ней принимались решения, выполнялись.. теперь хреняк! выясняется, что "партионка" кривая - надо бы подкорректировать... - ну и фигли - корректируем в текущем моменте! нахрена ее сзади корректировать...??? отсается вопрос - как узнать, как именно корректировать в ТА...? какие данные - ПРАВИЛЬНЫЕ..???
.
вопрос идет о чем? о том как быстро восстановить последовательность...? может все-таки более продуктивно - не давать ее нарушать..? по крайней мере нарушение количественной последовательности - отлвливается практически мгновенно (спасибо питу, селенат и иже)... нарушение суммовых последовательностей последовательностей - см. выше - нака их восстанавливать..? кидаем добавку (на сумму исправления) в ТА - и все...????
237 МуМу
 
16.04.11
15:15
Я смотрю на этом форуме сплошные идеалисты. У нас есть отдельное направление которое занимается консалтингом. Что такое сторнирование и т.п. я прекрасно представляю. Я понимаю что важно для управленческого учета не допускать коррекции задним числом. Но жизнь такова что все не идеально. Есть статистика в виде обращений клиентов. Одна из проблем - вышеозвученна.