Thanks. We’re using the M/R to create payment records for incoming files from the bank. In some cases, a single payment can be applied to thousands of invoices so we’re breaking this up into groups of 1000 due to governance limits in a single invocation of the

reduce

function. When a subsequent group of 1000 is processed, we look for the previous Payment record and continue applying it to more invoices. Due to volume increase, it can now take >12 hours for this process to complete. If we up the concurrency limit on the deployment record, it’s possible that two groups of 1000 for the same incoming payment could be processed at the same time. This would give us two payment records rather than a single payment record for a single payment. The customer wants only one payment record per incoming payment.

what are you doing that is costing so many points

The bank file is imported into a custom record where we can set customer id and invoice id based on the information provided from the bank. One custom record per check/invoice. So 1 check for 2000 invoices gets us 2000 of these custom records. The M/R script uses these records as it’s source. The bulk of the governance comes from updating these custom records to indicate they have been processed and the Payment record that processed it. This is how we detect if a Payment record is already pending for the customer with the next batch of invoices to apply.

you might want to actually use parent/child sublists to do this

Thank-you. I will take a look at that.