Announcements
Why are some invoice line numbers in multiple of 16384? What is the logic behind this?
*This post is locked for comments
Hi CRC,
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.
Kind regards,
Leslie
How about this:
SNO Line No Binary
1 16384 100000000000000
2 32768 1000000000000000
3 49152 1100000000000000
4 65536 10000000000000000
5 81920 10100000000000000
Cheers!
Sanjay
Sanjay,
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 ....
dynamicsgpblogster.blogspot.com/.../scrolling-windows-and-line-sequence.html
Hi
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.
Thanks
David
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.
For example:
8192 = 0.5 line inserted
16384 = 1
32768 = 2
line deleted
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,
LNITMSEQ, ITEMNMBR
from SOP10200
(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??
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
Jump in, show your community spirit, and win prizes!
Expanding mentorship, skilling, and AI innovation
These are the community rock stars!
Stay up to date on forum activity by subscribing.
Dan Liebl 2
Shravan Attelli 1
