перерасчет зарплатного журнала

[Greggy_imported]

Здравствуйте! Очень критичный вопрос! У нас такая ситуация при перерасчете журнала зарплаты если там например человек 30 ... времени занимает оооочень много ... плюс к этому на сервере бешенно растет лог транзакций ... не знаете в чем причина ... мб мы что то не так делаем? например 10 челоек из 30 может расчитываться больше 2 часов!!!

[andrevk]

Это значит что у вас большое количество sumindexfields в таблице Payroll Journal Line.
Еще скорее всего у вас модель восстановления SQL Servera - Full.
Можно на время расчета зарплаты перейти на модель Simple.
Также сделайте Оптимизацию таблицы Payroll Journal Line.

[Greggy_imported]

Цитата:

Сообщение от Andreblack

Это значит что у вас большое количество sumindexfields в таблице Payroll Journal Line.
Еще скорее всего у вас модель восстановления SQL Servera - Full.
Можно на время расчета зарплаты перейти на модель Simple.
Также сделайте Оптимизацию таблицы Payroll Journal Line.

по sumindexfields может быть ... я ничего там не трогал ... значит коряво спроектирована таблица ... модель Full ... делал Simple никак не повлияло на скрость работы ... оптимизацию делал

[andrevk]

Посмотрите сколько всего индексов в таблице Payroll Journal Line. Каждый индекс сильно тормозит работу. Попытайтесь найти и отключить ненужные. Либо отключите обслуживание индексов на Sql Servera
Еще мне помогало Rebuild индексов средствами Sql Servera

[konrad_imported]

С суммовых индексов поснимать галку - обязательно. Для журналов суммовые индексы на SQL-таблицах не только не помогают, а даже вредят. Модель восстановления - пусть Full будет. Когда-нибудь пригодится.
Желательно также отключить создание SQL-ключей, используемых только в отчетах. При пустом состоянии журнала запустите оптимизацию таблицы 14820 средствами Навижн - пускай ее причешет слегка.
Также рекомендую пробежаться по видам расчета в настройках и поснимать галки в неиспользуемых в вашей организации элементах, а из расчетных групп удалить неиспользуемые види расчетов.
И еще. Ставите галку "Пересортировать журнал после расчета" ? Тоже тормозит сильно.
В прилагаемом файле - ключи с моей боевой базы. 800 человек рассчитывается за 15 минут. Правда, тут еще и железо, несомненно, влияет. Также у Вас могут быть отчеты, использующие отключенные у меня ключи.

[Greggy_imported]

Цитата:

Сообщение от konrad

С суммовых индексов поснимать галку - обязательно. Для журналов суммовые индексы на SQL-таблицах не только не помогают, а даже вредят. Модель восстановления - пусть Full будет. Когда-нибудь пригодится.
Желательно также отключить создание SQL-ключей, используемых только в отчетах. При пустом состоянии журнала запустите оптимизацию таблицы 14820 средствами Навижн - пускай ее причешет слегка.
Также рекомендую пробежаться по видам расчета в настройках и поснимать галки в неиспользуемых в вашей организации элементах, а из расчетных групп удалить неиспользуемые види расчетов.
И еще. Ставите галку "Пересортировать журнал после расчета" ? Тоже тормозит сильно.
В прилагаемом файле - ключи с моей боевой базы. 800 человек рассчитывается за 15 минут. Правда, тут еще и железо, несомненно, влияет. Также у Вас могут быть отчеты, использующие отключенные у меня ключи.

это именно про перерасчет? причем приходится менять руками цифры а потом запускать перерасчет ... а расчет с нуля у нас тоже быстро работает ...

[konrad_imported]

А перерасчет прозводится, как я понимаю, по отфильтрованной по какому-то признаку группе сотрудников, и раз вручную меняются цифры - то без предварительной очистки строк? Тогда беда. И ничего хорошего я там придумать не смог. Уж больно хитро 14800 кодеюнит работает по вставке записей. Тут проще поштучно сотрудников перерасчитывать. Ручную коррекцию сделал - пересчитал. И к следующему сотруднику. Наши только так и делают. И присланные мной индексы именно для группового расчета не оптимальны.

[Greggy_imported]

путем различных манипуляций с таблицей Payroll Journal Line и SQL сервером ... удалось добиться скорости перерасчета 2 минуты на человека ... но все равно это много

[Corleone]

Цитата:

Сообщение от Greggy

путем различных манипуляций с таблицей Payroll Journal Line и SQL сервером ... удалось добиться скорости перерасчета 2 минуты на человека ... но все равно это много

Была похожая проблема, обрати внимание на CU 14800 функцию MoveLines.
Я переделал так:


WITH PayrollJnlLine DO BEGIN
RESET;
SETRANGE(Template,Template);
SETRANGE("Batch Name","Batch Name");

JournalDimension.RESET;
JournalDimension.SETRANGE("Table ID",14820);
JournalDimension.SETRANGE("Journal Template Name",Template);
JournalDimension.SETRANGE("Journal Batch Name","Batch Name");

IF IncludCurLine THEN
SETFILTER("Line No.",'>=%1',"Line No.")
ELSE
SETFILTER("Line No.",'>%1',"Line No.");
IF FIND('+') THEN
BEGIN
REPEAT
PayrollJnlLine2 := PayrollJnlLine;
PayrollJnlLine2."Line No." := "Line No." + 10000;
PayrollJnlLine2.INSERT;

JournalDimension.SETRANGE("Journal Line No.","Line No.");
IF JournalDimension.FIND('+') THEN
REPEAT
JournalDimension2 := JournalDimension;
JournalDimension2."Journal Line No." := PayrollJnlLine2."Line No.";
// JournalDimension.DELETE;
JournalDimension2.INSERT;
//
UNTIL JournalDimension.NEXT(-1) = 0;
// UNTIL JournalDimension.FIND('+');

DELETE(TRUE);
// UNTIL NEXT(-1) = 0;
UNTIL FIND('+');
END;
END;

[Corleone]

Цитата:

Сообщение от konrad

И ничего хорошего я там придумать не смог. Уж больно хитро 14800 кодеюнит работает по вставке записей.

MoveLines двигает весь журнал на 10000, двигая при этом измерения. Но реализовано это как-то криво. Попробуй вставить мой код из предыдущего поста.

[Greggy_imported]

в конце приведенного вами кода

DELETE(TRUE);
// UNTIL NEXT(-1) = 0;
UNTIL FIND('+');
END;
END;

не совсем понятна строчка UNTIL FIND('+'); - как мне кажется при таком раскладе корректно работать не будет ....

неправильно немного ответил - этот ответ относится к последнему сообщения Gmc

[Corleone]

Цитата:

Сообщение от Greggy

в конце приведенного вами кода

DELETE(TRUE);
// UNTIL NEXT(-1) = 0;
UNTIL FIND('+');
END;
END;

не совсем понятна строчка UNTIL FIND('+'); - как мне кажется при таком раскладе корректно работать не будет ....

неправильно немного ответил - этот ответ относится к последнему сообщения Gmc

DELETE(TRUE);
UNTIL FIND('+');

Так там же удаление идет, цикл просто пока все не удалится...

[konrad_imported]

У меня тут такая идея появилась.
А если поправить код так, чтобы использовать DeleteAll по завершении цикла вместо поштучного удаления внутри?
Не пробовали? Вроде побыстрее должно выйти.

[Corleone]

Цитата:

Сообщение от konrad

У меня тут такая идея появилась.
А если поправить код так, чтобы использовать DeleteAll по завершении цикла вместо поштучного удаления внутри?
Не пробовали? Вроде побыстрее должно выйти.

Основные тормоза не из-за делета, а из-за кривого пермещения измерений.

[konrad_imported]

Поменял функцию. Поставил код с DeleteAll. И так как у меня измерения на сотрудниках не используются (и не будут) - выкинул из кода манипуляции с измерениями.
Пересчет 860 сотрудников без очистки - 4 минуты на тестовом сервере. Вообще фантастика. На боевом летать теперь будет.
GMС, спасибо за наводку на идею!

[Greggy_imported]

Цитата:

Сообщение от konrad

Поменял функцию. Поставил код с DeleteAll. И так как у меня измерения на сотрудниках не используются (и не будут) - выкинул из кода манипуляции с измерениями.
Пересчет 860 сотрудников без очистки - 4 минуты на тестовом сервере. Вообще фантастика. На боевом летать теперь будет.
GMС, спасибо за наводку на идею!

Хотелось бы знать конфигурацию вашего тестового сервера ... и еще уточнить что вы подразумеваете под перерасчетом ... перерасчет у нас это когда при расчитаном журнале меняем какие - либо суммы (в нашем случае мы меняем сумму К ВЫПЛАТЕ) и заново запускаем расчет. Как мы не бились ничего путнего не смогли сделать ....

[konrad_imported]

Тестовый сервер - обычная рабочая станция, 4 гига мозгов, двухядерный процессор 3000 Мгц, два идишных диска по 100Гб
У меня механизм такой.
Из внешних источников в журнал расчета ЗП закачиваются "внешние" проводки ряда начислений-удержаний. От 4 до 16 проводок (строк) по сотруднику. Далее эапускается расчет без очистки журнала. При расчете создается еще порядка 5-15 строк (расчетных элементов) на сотрудника, в ряде расчетных элементов которых используются закачанные ранее внешние проводки.
Далее при выверке могут правиться ( и правятся) суммы на каких-либо расчетных элементах (кроме закачанных из внешних источников). Далее в штатном режиме происходит перерасчет исправленного сотрудника без очистки. Но в данном тесте штатный "поштучный" перерасчет я не использовал. На паре десятков пиплов поменял суммы и запустил групповой перерасчет по всему журналу без очистки. (правда, и без пересортировки).

[Corleone]

Цитата:

Сообщение от Greggy

Как мы не бились ничего путнего не смогли сделать ....

Значит не судьба.

[Галина]

Цитата:

Сообщение от Gmc

DELETE(TRUE);
// UNTIL NEXT(-1) = 0;
UNTIL FIND('+');
END;
END;

Не пойму. Посмотрела код. У меня в стандарте такой же код, как вы приводите. Кроме одной строки:
в стандарте эта строка:
// UNTIL NEXT(-1) = 0;
вы предлагаете поменять на
UNTIL FIND('+');
Вы для какой версии приводите код?

[Галина]

Возник вопрос правда не совсем тему.
Объем зарплатной базы с января этого года составлял 6 гб. Прочитав тему - убрала с Зарпл.ЖурналСтроки галки с MainSiftIndex. Решила убрать эти же галки и с Зарпл.КнигиОперации. Объем базы составил 1.4 гб.
Я в шоке. 4 гб - составляли ключи?
И теперь собственно вопрос. Чем мне это грозит? В принципе flow-field поля в Зарплате не используются-как в основном Навижине. Поэтому мне кажется ничем не грозит.