The ability to execute uBAQs over REST is indeed great, but I have concerns about some of the limitations of this.
Currently a complete row must be written by the calling app, which sort of defeats the purpose of updatable columns
If the intent is to expose a uBAQ as an endpoint for multiple applications, we are reliant on the developer of those apps to perform both a clean GET and PATCH on that record. For this reason, I cannot use it as I intended.
You can always customize the UBAQ.Update method. That way you can only update the fields you want.
Interesting…that’s a really good idea
Does the Update method get re-written by Epicor though? I assume you’re talking about the pre-processing but I think the base remains
I am talking about updating the base processing of the UBAQ. I am only suggesting this on UBAQ. This might not work for what you want it to do. This will allow you to update individual fields at least. I am sure there are other techniques to use.
I would like that expanded to not just REST, but also in the client application. It does the same thing in a regular dashboard. If you update with a record that isn’t refreshed and there has been a change (like QOH for example) it will write a non-updateable column.
That is the feature of the UBAQ. 
Which is why we had to change the base processing behavior for most of our Updatable Dashboards.
this is something a customer should not have to do. ESPECIALLY, when just about every class on BPM’s they tell you to not mess with the Base unless you really know what you are doing.
As I wrote in your original post, you don’t need to set all fields, you only need to set fields included in mapping on Update tab in the BAQ designer, go there and remove the fields you don’t want to send. As I remember only key fields are mandatory, all other can be removed
