Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Why are some invoice line numbers in multiple of 16384? What is the logic behind this?
They did that so that you'd have plenty of room to insert additional rows. There's no magic to the 16384, they really could have used anything.
How about this:
SNO Line No Binary
1 16384 100000000000000
2 32768 1000000000000000
3 49152 1100000000000000
4 65536 10000000000000000
5 81920 10100000000000000
I don't get it. I recognize the significance of 16384, but why the binary equivalent? Isn't it true that my data would be just as valid if I decided to number the lines 100, 200, 300, etc.? In fact, you could just number them 1,2,3,etc so long as you don't expect to insert rows. Yes?
Agree with you - it can be any thing - what ever number you want. The question really was why the default is 16384 ? I have always wondered why - and in one of my lean day analysis when I learned that processors read numbers left to right, decided to convert the number from decimal to binary - the pattern provides some explanation - it might be the bits are filled at fixed length field and what we see as decimal actually would be a start for a binary pattern. -- It would be interesting if David Musgrave gives the story behind it.
One more point, there are caveats for it can be any thing... but ....
The 16384 sequence number increment is used so that lines can be inserted multiple times. It is used as it is a power of 2 which means it can be divided by 2 multiple times and remain a whole number. ie. no fractions. 16884, 8192, 4096, 2048, 1024, 512, 256, 128, 64, 32, 16, 8, 4, 2, 1.
Each time you insert a line in a transaction, the new line number is the mid point between the line before (or 0 is this is the first line) and the line after.
More recently on GL transactions the increment was changed to 500. This was purely because on a very large journal will many, many lines incrementing by 16384 could exceed the maximum value for the sequence number and generate errors. To avoid this issue, the increment was changed to 500. This can only be divided a few times before getting a fraction 500, 250, 125, 62.5. But most people don't insert lines on GL transactions much anyway.
I hope this explains the reasoning behind using 16384.
This does not make sense to me. Why not use 1, 2, 3, 4,...n. Send your invoice to an EDI Trading Partner which matches the PO line numbers to your Invoice line numbers. They reject your EDI invoice! That's what happened to us! So we have to use the formula LineNumber = LNITMSEQ/16384.
If you have consecutive numbers, there are no "gaps" to be able to insert lines.
Please note that using LineNumber = LNITMSEQ/16384 will fail if a line has been inserted or deleted.
8192 = 0.5 line inserted
16384 = 1
32768 = 2
65536 = 4
Depending on how you are generating you EDI invoice, there are ways to get consecutive integer line numbers.
You could use the following code to 'translate' the LNITMSEQ to sequential numbers:
select SOPNUMBE, SOPTYPE,
row_number() over (partition by SOPNUMBE, SOPTYPE
order by LNITMSEQ) LineNumber,
(from the GP Reports Viewer newsletter archive: archive.constantcontact.com/.../1113227358859.html)
Thank you David ,Leslie, Victoria -
This still makes no sense! Why use a formula? Why not let the system serialize line numbers with natural flow of decimal numbers from 1 through n? Why not open up the entry screen to include line numbers so we can control line numbering to match EDI PO's line numbering???
What big company inserts 16383 lines in between??
Yes we could use a sequence of 1,2,3,4. But as Leslie points out, how do we insert between these values since there isn't room for it?
Well, we could still make that work.
So if we wanted to insert between 2 & 3 above, all we'd have to do is resequence 3 & 4 to 4 & 5 and then insert into our new "3" record.
But a couple problems with that:
Dexterity scrolling windows rely on the key data under them not changing. We just did that and it would not work so well.
Now of course at one point (20 years ago) we could have addressed that too but obviously we can't go back in time for that and it isn't going to happen today (development effort).
But another good reason to NOT do this is what about all the data (that is attached to the line) - not to mention any 3rd party data? The code would have to go thru all of the known data and fix all of that too to be the new sequence number for the pushed lines.
It would be a lot easier today if we took the POP approach and add a new "Line Number" column that isn't part of a window key - that way only one table needs to be updated on an insert/delete and we don't have to worry about the 2 above issues.
For your original question of why 16384 and not another value, the goal was to provide 15 inserts between rows. 2^15 is 16384.
Now if you say, why not 20 inserts? 25? Well you do have the max sequence issue David mentions but i would suppose the real reason is that this sounded like a reasonable amount of inserts between rows and so that was the value used.
Why is GP designed for line inserts? Those like us who enter orders from EDI Purchase orders of trading partners that require matching line numbers on invoices? In case there is a backorder in one of the line items and we have to re-enter another order for a backorder the line number is, you guess it, 16384! That my friend does not match the PO line number. GP should have given organizations a choice of organization-controlled line numbering as part of the setup.
Can you give me a company that really does a lot of line inserts?
We insert line items all the time on SOP documents and we have customers that I know use that functionality regularly. In fact, I know one of our customers has run into the issue with the max number of lines being inserted between 2 lines in the past, so they are definitely doing a lot of inserts.
While I have seen a number of questions about these in the past, this is the first time that I have actually heard of anyone having a problem with the line item sequence numbers.
I would second that comment. We have several clients whose clients will not pay an invoice if line items are out sequence from the original quote. Having the ability to insert a line is essential. Perhaps in this case you need to 'freeze' the order prior to sending it to your vendor via EDI. That way line numbers will not change. You can choose whatever method you want to have a sequential line number. As a matter of fact, you could change the SOP10200.LNITMSEQ to 1,2,3, etc provided you will never insert lines between any other lines. If you commit your sales orders to POs you will need make adjustments there as well.
I talk about this in great detail in my article Microsoft Dynamics GP Scrolling Windows and Line Sequence Numbers. You can also check out my article Is there a maximum number of lines that can be inserted in any given scrolling window? for more information.
Business Applications communities