You can set how many invoices are in a cycle through a customer-amendable system property.
The payment run cap is a system property called INV_PER_PAYMENT_CYCLE. With the right worker role permission, you can change this in the front end, and Mosaic fully audits the change and who made it. For more details, see Changes to system properties
This cap sets how many invoices are in the cycle, so when the cycle completes, it determines how many invoices it has to process.
⚠️ Important: Be careful with the completion side of the pay cycle process. If the invoice cycle size is too large, the system might not finish in time and could revert to an incomplete cycle.
The Mosaic front end usually gives the Java and SQL back ends about 10 minutes to finish the job. If it takes longer, it errors out and rolls everything back. During completion, the operation creates all the Remittance Advice PDFs and, depending on your interface, the AP file data too.
If the 10-minute timeout is breached and causes errors you can’t fix, you’ll need to raise a service request with us to split the cycle into smaller ones. Our SQL team will handle this as a chargeable change, but it might not be completed as quickly as you need, which could cause cash flow issues and supplier complaints.
The best approach is to time and benchmark how long the system takes to complete a cycle over several cycles at different times to get an average before making a change like this. You can’t realistically replicate this on a test instance because it doesn’t have the same resource and usage demands as production. If it takes about eight minutes on average to complete and you double the invoice size, it probably won’t finish within 10 minutes.
Systems can slow down at certain times of day when more users are on, reports are running, log shipping is using resources for live reporting, or threads get stuck. You won’t always know what’s causing the slowdown, but it won’t help what you’re trying to do. In these cases, letting the system refresh overnight and trying again first thing can sometimes help, but you don’t want to routinely end up in a bad spot because of the system property size.
If you have a bespoke interface and you’ve checked your original spec to confirm the data generates at the point of completion, you may want to submit a change request before implementing anything. This would move the interface out of the completion phase which has a Mosaic timeout as described above and into the export job phase, which doesn’t have those constraints. Without this change, Mosaic waits less for the backend during completion before confirming it within the allocated timeout.
If you need further assistance, please raise a new case online and reference the title of this article.