If you follow me, you know I’m working on item groups and discovering they are quirky! The same code run from the client-side will not work from the server-side. I recently posted notes about working with Item Groups from the client. As I continued to write client-side SuiteScript, I realized it was not as performant as I would have liked. 

Here are the differences when handling Item Groups between client-side & server-side:

1. Client-side, to delete an item group you delete the “Item Group”, all sub-items, and the “End of Item Group” item. They are treated just like other item types.
2. Client-side, to add an item group you add all lines back exactly as they were removed. Add the group, all sub-items and also the trailing end of group. In my previous post, I noted that in order to accomplish this you needed to look up the Item Group definition to get the list of sub-items.
3. Server-side, you cannot delete the “End of Item Group” item. It throws an error. You delete the “Item Group” and all sub-items and “End of Item Group” go too!
4. Server-side, when you add an “Item Group” all sub-items and the “End of Item Group” item are added for you. There is no need to look up sub-items. So adding one item, can actually add many lines. However, if you’ve modified anything in the item group, there is no mechanism to remember your changes when you add the group back. It comes back as though it is being added for the first time (which it is).

One more caveat, Item groups are editable. So let’s look at the scenario where you are rearranging a transaction. Keep in mind, some financial transactions are locked and cannot be rearranged. However, a transaction like an estimate which has not become a sales order can be rearranged as follows (meaning reordering line items).

This is my algorithm for doing this from server-side code.

1. Remove all sublist items from bottom to top.
2. When you encounter an “End of Item Group” (identified by checking internalId == ‘0’), stop deleting until you reach the “Item Group”. When you delete it, all subsequent lines in the group will be deleted along with it.
   
3. When adding items back, do this from top down.
4. When add lines and you encounter an “Item Group”, stop and remove all items in the group, with the exception of the “End of Item Group”. That cannot be deleted. After the delete completes, the last line is the “End of Item Group” and the line above it is the “Item Group”. The group is empty!
5. Then INSERT all sub-items back into the group. In essence, you are re-filling the group with its’ sub-items. Why? In my scenario, it is possible that items in the group have been modified/added/removed since the group was originally added to the transaction.
   

So that’s it in a nutshell.

My project required an algorithm to reorder items in an estimate. I originally performed this operation client-side. However, it was not performant on lengthy transactions. To fix this, I’m now calling a RESTlet (server-side) to handle all the removal and adding back of line items.

In my sandbox, I was able to take a transaction with 50+ lines that ran over 1 minute and it completed in ~10 seconds. For a transaction with 1-5 items, you could probably get away with running your code client-side.

Hope this saves you some time. I know it took a lot of experimentation for me to get over this speed-bump!