Build 23.212.0024
We have a custom processing screen which makes use of a delegate to perform a union of various records into a single processing list; as described here https://asiablog.acumatica.com/2015/11/union-selects-in-bql.html . This processing screen is used to poll remote API for status updates.
I mention the delegate method of performing a union as we originally thought that might be the reason for our issues, however we now don’t believe that’s the case.
This processing screen works fine when used manually; any success, warning or errors are correctly reported to the UI.
We can using a schedule to automate this processing screen on local development machines and the number of processed rows is correctly reported in the history (greater than 0). Since the automation works locally I presume the configuration of our processing screen is correct. We have read a number of discussions on this matter but none seem to show similar behaviours. We are using the “Process All” action. We also have a NoteID field configured on the DAC which maps to the NoteID of each of the source rows.
In the production environment 0 rows are processed when we can run the same screen manually and process more than 0 rows.
It’s almost like on production, when the screen is being executed by the schedule it is happening under a different tenant that has zero rows to process.
Since the automation works locally, can anyone suggest any way to debug the potential issues in production environment?
Many thanks.
