0

I'm writing simple User Event script (using beforeSave entry in my case) for the Sales Order which reads every item line in it and changes some values in the item line according to the given circumstances.

The problem I've encountered:

If some field of the item line in the Sales Order was changed by the Administrator (role) just now or some time ago, this field should not be changed by my script. Via N/runtime module I can get current user role and verify that he changed something just now, but that doesn't help if the change has been done before the current edit "session".

How can I know, if any administrator changed something? Can I get some history/log/system info for each item line in the sales order?

Thanks in advance

Ivan
  • 35
  • 2
  • 7
  • NetSuite support answered. It's impossible to get some log via suitescript. The only possible solution right now is to create some custom checkbox on a form (Sales order in my case) and set some server script to check it every time, when some administrator make some changes (downside - new custom field, new script and this works for new orders only) – Ivan Feb 27 '18 at 09:11

2 Answers2

1

If you need to prevent your code from changing values on a Sublist (in your case the Item list on a Sales Order) only when an Admin was the one who initially set the value, then I would recommend using a custom record where you could store a list of fields or data per transaction that were changed by an admin. For example, on create of a Sales Order, your beforeSubmit user event would create this data tracking custom record and set some field to tie it one-to-one to your sales order (meaning you have 1 custom record for each sales order, but never more than 1, you could even store the internal ID of that custom record on the sales order in a hidden field so you dont have to look it up in future edits). In your custom record you could use a long text field (has a limit of 1 million characters I believe) to store JSON data representing fields or values that were set/changed by an Admin. On each edit, your user event code should check the role of the user interacting with the sales order and read/update the custom record accordingly. This would work on create, edit, copy, whatever (inline edits are not possible against an item list on a sales order so no need to account for those). This would require a decent amount of code in order to do the lookup and checking each time, but custom records are super fast and use very little governance so your users shouldn't see any notable performance loss. I recognize this is far from an ideal solution, but its a lot more feasible than the 'always helpful' NetSuite 'support' solution. Good luck, and hope this helped!

Todd Grimm
  • 509
  • 1
  • 3
  • 14
  • Thank you for the answer. I will definitely consider that. – Ivan Feb 28 '18 at 13:01
  • @Todd: That is still an overkill. Why create a custom record if you can create a custom field containing the JSON data of all the column fields that is being updated by the Admin? I reckon it will be much better than looking up a custom record which will need another field(which could have been the field that holds the JSON) for a lookup. A client script with a field change function will push the field id that is being edited then your other script will reference this on load of the SO and you don't need to load the custom record to check the column fields. – vVinceth Mar 05 '18 at 06:12
  • @vVinceth I prefer to stay away from Client scripts whenever they can be avoided. Handling this all via user event scripts would run quickly and outside of the original setup time being more work, the tool would be easy to build on and expand functionality. Having to deal with field changed events client side and account for all the possible user interactions in real time can be frustrating, and can cause performance issues for the user. Both approaches satisfy the request, perhaps your solution works best in 9/10 situations, this is just how I would have done it. – Todd Grimm Mar 06 '18 at 14:55
1

Todd's solution will work, but a bit of overkill to get all the field ids and store it in a custom record since you just wanted to know if there is a change on certain field.

Having a client script that is ticking a check box running on Field Changed would be much simpler solution. The client script will detect if it is the column or field(if needed) that you are tracking. If it is the field, then simply set the checkbox to 'T'. Then on your scheduled script you simply check this checkbox before updating the record.

vVinceth
  • 905
  • 5
  • 7