Hi All, i have a scenario in which a userevent does some aftersubmit processing that is exceeding the 1000 units limit on large invoices. My workaround was to switch the code over to a scheduled script and fire this from the user event script so I have increased limits of 10.000 and the option to call the scheduled script from itself to continue work whenever I still reach the limit. This solves my problem but raises a new one when I have multiple invoices created in a short timespan (such as a billing operation). this launches more scheduled scripts than there are deployments and thus the userevent script errors out with INPROGRESS / NO DEPLOYMENTS AVAILABLE. I could solve this partially by increasing the number of deployments but this seems unreasonabe as we have 1000+ invoices which can be generated within 30minutes. potentially making me have to create 500+ deployments depending on runtime. Using map/reduce makes sense for the processing after all the invoices are created but this means that users would have to wait for this to be ran before they can send out invoices (the processing adds info which is printed on the invoice) which is very counter intuitive if the invoice is already created in the UI. Any suggestions for a good fix for this scenario is appreciated!

what are you doing to the invoice items?

We have some info 4 records deep that we would like to be displayed on the invoice. This is 40 units per invoice line and this adds up quickly on large invoices

that sounds like you are doing a search per line

We do not do a search but we load the records with the internal ids per line

you may want to do the logic in a map/reduce script anyways

Are map/reduce script also bound to 1 execution per deployment?

yes, but it makes more sense to make a custom record queue with it instead

How would you go about that?

make your map/reduce script process those instead

And what happens when the script is in summarised fase and a new invoice is saved?

you wait for the next invoice

Ok. Thanks for the info! I will try this out.

it also means you get the best practice of Logic to Handle Map/Reduce Restarts

Alternatively instead of firing directly the SC just have the UE create a custom record instance (like a queue) then all you need is one deployment to pick those records and apply logic

while I've done so on numerous occasions I cringe at using NS as a queue - it's not really optimized for such.

Now I noticed that battk already suggested that, sorry for the spam here

For people interested. I solved this today with a differrent solution. I moved the userevent logic to retrieve this infomation from the invoice to the subscription line (this is record level 2) and set a custom field value. This script has enough units to retrieve the info from the record level 3 and 4 because I get 1000 units for each subscription line (invoice line) instead of 1000 units for all. Then I changed the custom field on the invoice to source its value from the custom field on the subscription line. This sourcing action does not use any units because it is not in a suitescript. The net result is the same but no more issues with governance limits and slow user experiences 🎉