Item Groups are a perpetual source of pain when customizing transaction sublists. They break the conventions of how items are added to sublists by using a poorly documented process called "exploding".
This rhythmatic explosion is what your frame of mind has chosen - Nas
A Series of Unfortunate Events
NetSuite will trigger several events as an Item Group is added and exploded. The most useful one is sublistChanged().
It's important to know that Item Groups can have their start/end lines disabled. This means you won't see those extra lines on your transaction, and the explosion process will be slightly different.
First...
sublistChanged fires as the IG item is committed. At this point, the sourcing is done, and you can read the itemtype sublist field to identify it as a 'Group' type item. You can't assume that every commit of an IG is the start of an explosion though! It could be an edit. We can read a couple of seemingly undocumented sublist fields to help tell them apart: groupsetup and includegroupwrapper.
groupsetup tells us if the IG is already setup (exploded). 'T' if exploded, 'F' if not. It's only populated on the start line of an IG though. As mentioned earlier, this line can be disabled, meaning it might not be present. We can read the next field to know what to expect.
includegroupwrapper tells us if the IG has start/end lines. 'T' if the lines are enabled, 'F' if not.
And maybe...
sublistChanged will fire again to remove the IG item if includegroupwrapper is 'F'. This happens prior to the members being added, and will temporarily yield an empty sublist if no other items have been added.
Then...
sublistChanged fires one last time once the members have been added. The line index will be set to the last line of the sublist. Confusingly, the values on the current line will match the line after the end of the item group. You can actually duplicate this line just by committing the current line. This seems to be an oversight, and is only noticeable when inserting an IG. When adding an IG to the end of a sublist, the line after the IG and the last line of the sublist will be the same blank line.
Finally...
postSourcing fires on various tax-related fields, and signifies the end of the explosion process.
Getting to the Bottom of It
Another difficulty is determining the last line of an IG. As previously mentioned, the explosion leaves us on the last line of the sublist, and not the last line of the IG.
We can get the first line # of the IG during the first sublistChanged event. If we know the IG has an end line, we can search for it beneath the start line. This means testing each line for an itemtype of 'EndGroup'. If we encounter the start of another IG, or the end of the sublist before we find the end, then something has gone wrong.
We need a different approach for IGs that don't have start/end lines enabled though. We can store the sublist's length on the first sublistChanged, and subtract it from the length on the second sublistChanged. This will give us the length of the IG. Adding this to the first line # gives us the last line #.
Putting it Together
1. We detect the start of an explosion by waiting for a sublistChange that meets the following criteria:
- context.sublistId is 'item'
- context.operation is 'commit'
- the current sublist value for itemtype is 'Group'
- groupsetup is not 'T' or includegroupwrapper is not 'T'
Now that we've found the first line, we can store its number along with the current length of the sublist.
2. We wait for the next sublistChange that's a commit. It should be for the last line of the sublist.
We determine the last line of the IG by either searching for the End Of Group item, or subtracting the original line count from the current line count and adding the start line #.
3. We wait for postSourcing to fire for 'nexus' or other tax fields. Now we know the Item Group has exploded, where it is, and that it's safe to manipulate.
Don't you never, ever, pull my lever because I explode and my nine is easy to load - LL Cool J
No comments:
Post a Comment