Статистический вопрос. Сколько считается зарплата?

[3oppo]

У нас в компании порядка 450 чел зарплата обсчитывается ~ 2 час. И мне не понятно либо внедренцы такую кривизну заложили, либо АХАПТА сама по себе такая кривая?! Отпишитесь пожалуйста сколько у вас обсчитывается зарплата и сколько чел в компании.

[samco]

на наших проектах мы оптимизировали Аксапту, а в принципе в базовом варианте действительно расчет идет долго. В основном скорость зависит от количества расчетных механизмов (счетчиков и их сложности), журнала БД и сколько процедур туда включено, большого количества отпусков и больничных....

[mazzy]

Цитата:

Изначально опубликовано 3oppo
У нас в компании порядка 450 чел зарплата обсчитывается ~ 2 час.

Да. Исходная зарплата плохо продумана насчет быстродействия.

Что делать?
1. http://axapta.mazzy.ru/lib/mssqlsetup2/
2. http://axapta.mazzy.ru/lib/querytuning/
3. http://axapta.mazzy.ru/lib/adjustment/
4. настроить кэширование
5. настроить распределение нагрузки между клиентом и АОСом.

Расчет зарплаты в Аксапте можно ускорить.

Обрайтесь к специалистам, если не получается самостоятельно.
К сожалению, только так.

[3oppo]

Спасибо за ссылки.
После некоторой оптимизации SQL (отключение логов, перенос критичных таблиц на скоростные винты, … .. . ) Время уменьшилось до 1 часа. По моему всё равно долго! Отпишите плиз у кого какое время!?

PS. Более 70 просмотров и только один ответ! Неужели это такая большая тайна!? Или просто лень?!

[mazzy]

Цитата:

Изначально опубликовано 3oppo
PS. Более 70 просмотров и только один ответ! Неужели это такая большая тайна!? Или просто лень?!

Ответов было 2.
Модуль Зарплата в Аксапте не является очень распространненным.

[sia]

Если вы не используете функциональность с "Основным номером сотрудника" (EmplTable, поле PayMainEmplId_Ru) , советую удалить все связанное с этим полем из всех запросов при расчете зарплаты. Это особенно актуально при работе с Oracle, расчет ускоряется в разы.

[AnnV]

Думаю, что успокою автора вопроса, сказав, что на нашем предприятии зарплата считается 5-6 часов, стараемся запускать вечерами. Расчетный отдел стонет. Численность работников около 1000 человек. Настройка з/п была очень тяжелая, много счетчиков, много видов заработной платы. По существу оптимизацией расчета мы еще не занимались, работаем в режиме отладки. Так, что спасибо за выложенные ссылки, надеюсь они помогут как-то оптимизировать процесс.

[3oppo]

Цитата:

Изначально опубликовано sia
Если вы не используете функциональность с "Основным номером сотрудника" (EmplTable, поле PayMainEmplId_Ru) , советую удалить все связанное с этим полем из всех запросов при расчете зарплаты. .

К сожалению это поле используется (табельный номер). Вопрос почему оно так сказывается на производительности!? Потому что оно имеет тип string?
Теоретически, если изменить тип поля на int на сколько это увеличит производительность?!

[sia]

Цитата:

Изначально опубликовано 3oppo


К сожалению это поле используется (табельный номер). Вопрос почему оно так сказывается на производительности!? Потому что оно имеет тип string?
Теоретически, если изменить тип поля на int на сколько это увеличит производительность?!

Тут дело не в типе поля, на производительность это не влияет.

Тогда хотя бы сделайте индекс по полю PayMainEmplId_Ru.

[Prof]

Вообще не очень понятно следующее: у вас зарплата считается сразу и вся? Тогда в чем проблема? Поставил на ночь, скажем, со 2го по 3е и готово
Я так подозреваю, что проблема в том, что вы, точнее ваши бухгатера, после каждого изменения запускаете расчет всех процедур заново.
Предложения у меня чисто организационного характера:
1. Рассчитывать одну процедуру только 1 раз в течение расчетного периода. Больше просто не надо. В случае отдельных корректировок перерасчитывайте зарплату индивидуально.
2. Если надо просто изменить статус процедуры с "не рассчитано" на "рассчитано" запустите ее расчет для одного сотрудника (по запросу). Статус все равно поменяется
3. ЕСН также пересчитывается индивидуально по кнопке "расчет" из карточки сотрудника. Пересчитывать ЕСН целиком надо только если у вас изменилась настройка фондов (ну или еще что-нить именно в настройке), но не если у одного сотрудника изменилась база.

Чисто по быстродействию, маленький тюнинг - уберите неиспользуемые вычеты, скидки и льготы для налога на доходы и ЕСН. Они замедляют расчет. Знаю, что часто их оставляют на всякий случай, т.к. они настоены в демо-данных. Так вот уберите.

В заключение могу сказать, что на одном из моих проектов, численность чуть выше чем 450 человек, однако _особых_ проблем в плане быстродействия нет. Да, когда 10 минут рассчитывается ЕСН или создается табель, это раздражает, но это в конце-концов не смертельно.

[3oppo]

Цитата:

Изначально опубликовано Prof
Я так подозреваю, что проблема в том, что вы, точнее ваши бухгатера, после каждого изменения запускаете расчет всех процедур заново.
...
Чисто по быстродействию, маленький тюнинг - уберите неиспользуемые вычеты, скидки и льготы для налога на доходы и ЕСН. Они замедляют расчет. Знаю, что часто их оставляют на всякий случай, т.к. они настоены в демо-данных. Так вот уберите.

Разницу между кнопками «рассчитать текущую» и «рассчитать всё» мы и наши бухгалтера уловили! Маленький тюнинг - уберать неиспользуемые вычеты это понятно. Вопрос чисто статистический!!!

Цитата:

Изначально опубликовано sia

Тогда хотя бы сделайте индекс по полю PayMainEmplId_Ru.

Индексирование поля не дало прироста производительности, привело только к возросшим требования к виртуальной памяти.

Всем спасибо! Будут идеи пишите.