When trying to create the BAQ I get the below error. I am trying to give the sales dept more info so they can adjust the sell price based on what it will cost us to make.
Severity: Exception, Table: PriceLstParts, Field: , RowID: 6beb42d6-a02a-4907-ae92-1fe5aee956fd, Text: Update not allowed.
Query returned 1 row(s).
My edited my UBAQ to only the comment field and the basePrice and it still does not work. I have been able to get it to work once but with a long delay or even having to kill Epicor and come back in and it is updated. But if I try again it does not work.
There isn’t a lot of information to go on other than the uBAQ, which isn’t working, so we need to tackle the project from a different angle to understand how to proceed.
Maybe walking through how the process is done today so that we can identify a path to success. How do users do this today?
I am creating a new process for the purchasing dept. to input the cost of a part in the pricelstparts table so the sales dept. can set the sell price. So the 1st step was to create a field which I done. Then do a UBAQ which I am trying to do but with no luck. I have changed the UBAQ to the default comments field but still no luck.
PS I have since been able to get it to work but it takes hours for it to update just one field that I changed. I believe it is some bad logic in Epicor that it is running against the whole data results not just the updated field. Will test this by setting BAQ to just one part when ever it gets done updating a field.
I would like to know if you would have the same results if you created a UBAQ for pricelstParts and tried to update a comment.
I am unable to get the ubaq to work. I am getting an error cannot create new record. Sorry.
I have found that Epicor does update more than it should on UBAQ at times. The grid of data that you are trying to update. Is it only one record? or everything? You may want to make sure the grid you are updating is as small of a data set as possible. We have also moved to custom BPM on uBAQs because of this, as our data sets were larger and couldn’t be reduced.
another word of caution. if you have multiple people using the uBAQ at the same time, whomever saves last wins. We had folks overwrite other folks work, we had to implement a pre processing BPM to check the sysrevid of the records before things were saved. If something was changed in the database since the time of the data pull, users were not allowed to save.
When you get there I can share some of that, though that is posted on this site somewhere as well.