Hi team,

We had a requirement to use SERVRECTRANS table and we added it for actual transactions on custom workorder app. The user is supposed to add new records and update existing records from ui.

The issue we are facing is the updates I do from UI on first time gets committed to DB, but If I try a second time, it shows success message but the value was getting rolled back. 
I tried explicitly saving the mboset using autoscript on object launchpoint before save, but the saves are getting invoked alternatively only even a raise type error after save is thrown only on alternate saves.

When I try from APIs its working fine. I have just added it in oob workorder app as well, just the table alone in a new tab without any customizations or autoscripts. Still facing the same issue.

Observed this is happening only for SERVRECTRANS and in oob maximo application it was already made it readonly from UI without NEW ROW by the product.

The various transaction tables (MATUSETRANS, SERVRECTRANS, etc.) are not intended to be modified. Even if you make your customization work, you have no idea on the impact to everything else in the system when you do something not intended like this. For example, the new asset rollup process we introduced in 7.6.1.3 that updated these tables to set the rollup flag led to a series of defects including duplicate invoices for pay on receipt services (APAR IJ49711). We had to change how the updates were processed back to SQL to avoid this and a few other issues.

And that's assuming you are not modifying something that impacts cost. That would likely fail to recalculate properly and artificially inflate the costs on the WO which would then inflate the costs of the asset. And that's something we wouldn't fix because it wouldn't be possible to get in this situation out of the box.

If the existing object doesn't work for you, utilize a custom object. That custom object could link back to the receipt if you had some custom fields you were trying to update and then you would avoid any issues modifying the actual SERVRECTRANS record. And if it's out of the box fields, you really shouldn't be modifying them after it has been saved.