📌Note: It is possible to amend the Pay Cycle Invoice limit through a system property called INV_PER_PAYMENT_CYCLE that determines the maximum number of invoices in a scheduled payment cycle. If the number of invoices generated exceeds this limit, Mosaic will split and distribute them across multiple new cycles as required.
🤓Tip: You can make changes to system properties if your version of Mosaic is 22.1 or above in the System Properties area of the Configuration Tools. See: Changes to system properties.
⚠️Warning: It is important to test this out. The worst-case scenario is that you have thousands/millions of pounds of locked-up payments because a payment cycle won't complete.
After all, the transaction time for this process causes a timeout to roll back the completion, due to the number of invoices being larger than your hardware can cope with, especially with other users on the system.
This will be especially the case if you have a bespoke interface and the method by which the data for your file is written is done at the point of cycle completion rather than the point of export of the file. This is because the front end that you have clicked complete is waiting for the bespoke interface in the database to crunch the data, and if it waits too long, the front end will just kill the process entirely.
Performance Impact: Larger payment cycles will process more invoices in a single transaction, which could:
Increase memory usage during invoice generation.
Extend processing time for payment cycle completion.
Potentially cause timeouts during large batch operations.
Database Transaction Size: The invoice generation process runs within database transactions.
Larger cycles mean:
Longer transaction duration.
Increased risk of deadlocks.
Greater rollback overhead if errors occur.
If you need to reject invoices, or more invoices to reject, potentially causing timeouts and requiring rejections to be done in smaller batches at a time.
So, while technically possible to increase the limit, we would recommend:
Testing thoroughly in a non-production environment with realistic data volumes.
Monitor performance during the first few large cycles after the change.
Consider incremental increases (e.g., 500 first, then 1000) to assess impact.
⚠️Important: If you are on a version of Mosaic below 22.1, then please raise a case with the support team, as this will need to be done on your behalf if hosted, or a script provided if self-hosted.