|
Скорость закрытия месяца В ЕРП
| ☑ |
0
Buster007
22.06.18
✎
17:53
|
Коллеги, скорее всего те, у кого установлено ЕРП уже сталкивался с проблемой медленного распределения затрат и расчета с/с.
Как решали проблему? Нашли ли какие-нибудь методы по ускорению этого процесса? Может вы применяете какой-то другой алгоритм по распределению затрат? В общем поделитесь - не скупитесь) И всех с пятницей
|
|
1
KSN
22.06.18
✎
17:55
|
Да вроде норм все.
Админы говорят что все крутится на 32 ядра, 96 гиг и полка с 32 ссд.
|
|
2
Buster007
22.06.18
✎
18:02
|
(1) есть протокол расчета?
|
|
3
shuhard
22.06.18
✎
18:06
|
(0)[ Может вы применяете какой-то другой алгоритм по распределению затрат]
нет, у нас большая часть уходит на партионный учет,
а разгоняли серверной группировкой и подбором сходимости
протокол не дам, на текущем проекте его ещё нет
ну и конечно 2-3 дня для производства = норма
|
|
4
KSN
22.06.18
✎
18:28
|
Производство у нас несложное. Закрывает методолог организации. Протокола нет.
|
|
5
РБ
25.06.18
✎
06:15
|
само закрытие идет часа 4.
в целом месяц закрываем (от предварительного до окончательного)дня 3-4
|
|
6
Buster007
25.06.18
✎
09:21
|
(3) "и подбором сходимости" можешь пояснить?
|
|
7
shuhard
25.06.18
✎
09:24
|
(6) число итераций, точность закрытия, количество параллельных, объём пачек
там дофига что есть подвигать =)
|
|
8
Buster007
25.06.18
✎
09:57
|
(7) а, это понятно ) я подумал может что-то в сходимости узлов при заполнение партий в движениях в партионном учете
|
|
9
cons74
25.06.18
✎
10:40
|
- вынесли выполнение на отдельную машину (офисная но с i7) - требования назначения функциональности
- а еще (коллеги делали, не в курсе подробностей) есть некий регистр взаиморасчетов, в который система пишет так, что при добавлении одной записи вносит изменения в сотни последующих (которые относятся к будущему периоду). Так запись изменили так, что в течении месяца запись делается в отдельный новый регистр, а потом из него - обратно.
|
|