Microsoft Dynamics GP Scrolling Windows and Line Sequence Numbers

I thought I would write about something meaningless that no one really thinks about. However, I realized that this is a compelling topic since it makes for some interesting discussion around the ability to insert line items withinin most transaction scrolling windows.

Let’s take some time to understand where Line Sequence Numbers come from. A Line Sequence Number is auto generated by Dynamics GP and uses a seed value of 16,384 as a basis for the first line. Each subsequent line in the scrolling window is incremented by this number, so line number 2 would have a Line Sequence Number value of 32,768, line number 3 would have Line Sequence Number Value of 49,152, and so on.

Since most GP transaction entry scrolling windows allow inserting rows in between line items, the newly inserted Line Sequence Number value is calculated as an average between the previous and the next line item sequences, i.e., if you were to insert an item in between row 1 and row 2 in the scrolling window -- keep in mind the values 16,384 and 32,768 respectively -- the Line Sequence Number would then be calculated as:

Line Sequence Number = (16,384 + 32,768)/2 = 24,576.

To visually represent this:

row1.... 16,384
row2.... 24,576 -- newly inserted row
row3.... 32,768

Now, if you were to insert a new row in between 1 and your previously inserted row 2, the new Line Sequence Number is now calculated as follows:

Line Sequence Number = (16,384 + 24,576)/2 = 20,480.

Once again, to visually represent this:

row1.... 16,384
row2.... 20,480 -- newly inserted row
row3.... 24,576 -- previously inserted row 2 is now row 3
row4.... 32,768

At this point, you may be asking, how is this nonsense even relevant? Just imagine for one instance that you attempt to insert line items at the same spot in the scrolling window, say for example at row 2, what would happen? You receive a "You cannot insert a row" error!

What happened? Let’s go back to our visual representation, this time with a real example:

-------- -----------
FOO1 16,384
FO16 16,385
FO15 16,386
FO14 16,388
FO13 16,392
FO12 16,400
FO11 16,416
FO10 16,448
FOO9 16,512
FOO8 16,640
FOO7 16,896
FOO6 17,408
FOO5 18,432
FOO4 20,480
FOO3 24,576
FOO2 32,768

The first time around, you will only be able to insert up to 14 rows in one location before experiencing the error mentioned previously. After the error, you will need to move one to a much more “suitable” location within the scrolling window to insert a new row, for example, row 4 (FO14) where only one item can be inserted due to the Line Sequence Number on FO15 and FO14.

Until next post!

Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC


David Musgrave said…
Inserting and deleting lines will mean that the sequence numbers in a document will not be consecutive multiples of 16384.

This means that if you try to use the divide by 16384 method of providing line numbers on a sales document, you will not get the desired values.

Please see this posting for a VBA method of doing line numbers.
Mariano Gomez said…

It's great to see your posts on my site. That's a very good point that was not mentioned in my post before. Many people tend to use the divide by 16,384 to obtain things like the order of lines in a scrolling window and can end up with undesired results.

Mariano Gomez, MVP, MCP
Maximum Global Business, LLC
Naukri4U said…
Hey, Could you please let me know how GP line item sequence is beneficial?
Actually I am transferring orders form store to GP. During this I am not passing anything for line item sequence. Hence GP is taking it's own sequence. Now the problem is while bringing invoice from GP to eCommerce line item sequence is not matching which is causing problems for me.

Thanks in advance!

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 3

Integration Manager 10 INI settings