Hi Artur,

We can’t say anything without investigating the issue functionally as well as technically. It’s better if you can raise a case for IFS Global Support team to investigate this issue. Then they will investigate and provide a fix.

Kind Regards,

Kalpa.

hello

the question was if there is any time limitation for performing this job? is this automatically killed when reach some time?

@Artur Bednarek ,

The default statement execution timeout is set to 30 minutes. You can increase this but please note that it might affect the overall performance of the application.Please refer the below thread for more information.

Why do we get "Request aborted" when executing a long running function from Enterprise Explorer ? | IFS Community

Also, if there are lots of vouchers to be updated, you can schedule it as a background job to avoid this time-out issue.

Hope this explanation helps you.

Best Regards,

Sachin

Hi @Artur Bednarek 

I agree with Sachin’s explanation.

Also, please note that when updating a Voucher to General Ledger which has a high number of voucher rows (> 100,000), there might be a performance degradation.

Here’s a solution I have found in one of the posts.

In these scenarios, as Sachin also has mentioned the recommended option is to update the vouchers to GL via a background job. To setup this, the below steps needs to be followed:

1. Go to Databases Process window and check whether GL Update Batch Queue is enabled
2. If it’s disabled, go to Batch Queue Configuration window and RMB on the GL Update Batch Queue and click on ‘Init Batch Queue’

3. Afterwards, go to System Parameters for Accounting Rules and set the value of GL_UPDATE_BATCH_QUEUE to TRUE

This will ensure that all vouchers which are being updated to the GL will be done in the background via a seperate queue (rather that the default queue) and none will be done online irrespective of where the GL Update process was initiated.

Furthermore, for performance gain, the oracle parameter OPTIMIZER_DYNAMIC_SAMPLING should be set to 0. Usually, this is set to 2. In order to do this, please execute the below in the database:

ALTER SYSTEM SET OPTIMIZER_DYNAMIC_SAMPLING = 0;

This can be a temporary measure if executing in the background is not always required. If so, changing the System Parameter GL_UPDATE_BATCH_QUEUE to FALSE will ensure that online processing will resume for the subsequent vouchers which are to be updated.

Hope the above solution would assist.

Thanks and Best Regards

Madusha

finally go through, but afterhours, maybe when the system was less loaded.

however thanks a lot for your solution and we will have it in the tool box next time.

Have a good weekend - you did a great job :)

Hi @Artur Bednarek 

Can agree with the above recommendations to optimize the Update GL voucher process. Additionally, you can split these vouchers into some reasonable set of vouchers when updating GL without updating the whole lot at once. This method can be used to update the GL voucher in both as a background job or as a online job.

Additionally, you can use Voucher Summary window to specify, by voucher type, whether or not voucher rows with the same information in a voucher are to be totaled.  For voucher rows to be summarized Currency Code, Currency Rate, Identity, Reference Series, Reference Number, Transaction Code, Text and Correction must be the same in each voucher row. Debit and credit amounts will also be summarized separately, i.e. no netting will take place. The summary parameters specified will be used when the General Ledger update is performed using the Update GL Vouchers window. From this, you can gain additional performance improvement.

Thanks & regards,

Amalith

Even if you schedule the “GL Update” to run as a batch job in the background, it will have the same error in the background job. Background job will not be any faster than the online job, and will be aborted by Oracle at the mark of 30 minutes.

Your options are, either to improve the performance to run this job in less than 30 minutes or increase the “Execution time out limit” to sometime more than 30 mins via Reconfiguring the Extended Server as shown in the above link/post…

If you increase the time out to be more than 30 minutes, it makes sense to schedule the job to run in background, otherwise you will be stuck for that many minutes ( Ex: 60 mins ), without being able to use your PC or IFS Applications...