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

[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 кодеюнит работает по вставке записей. Тут проще поштучно сотрудников перерасчитывать. Ручную коррекцию сделал - пересчитал. И к следующему сотруднику. Наши только так и делают. И присланные мной индексы именно для группового расчета не оптимальны.

[Corleone]

Цитата:

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

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

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

[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;

[Галина]

Цитата:

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

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

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

[Greggy_imported]

Цитата:

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

Была похожая проблема, обрати внимание на 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;

я чего то недопонимаю может быть ... но объясните мне как может работать код

IF FIND('+') THEN
BEGIN
REPEAT
...
...
UNTIL FIND('+');
END
в приведенном примере будет всего одна итерация насколько я понимаю!

[Corleone]

Цитата:

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

я чего то недопонимаю может быть ... но объясните мне как может работать код

IF FIND('+') THEN
BEGIN
REPEAT
...
...
UNTIL FIND('+');
END
в приведенном примере будет всего одна итерация насколько я понимаю!

Не буду комментировать каждую строку, но там не одна итерация, из-за того, что FIND('+')=TRUE всегда когда есть записи, а там ещё DELETE.

Цитата:

// UNTIL NEXT(-1) = 0;
вы предлагаете поменять на
UNTIL FIND('+');
Вы для какой версии приводите код?

3.7
Да, хотя я уже сомневаюсь что только это, щас ещё перепроверю.

[Greggy_imported]

Цитата:

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

Не буду комментировать каждую строку, но там не одна итерация, из-за того, что FIND('+')=TRUE всегда когда есть записи, а там ещё DELETE.

Приношу свои извенения ... сначала сам недотумкал ...

[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С, спасибо за наводку на идею!

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