RE: How Line No. is populated in Sales Line Table for any Document Type?
It's a design pattern in the app. You will find a lot of places where there is a parent-child relationship between two tables, and the 'child' table has a compound primary key that ends with an Integer type field called "Line No.". Examples are Purchase Header and Purchase Line, Sales Header and Sales Line, but also the Journal Line tables like General Journal Line and Item Journal Line.
In code, you have to take care of the "Line No." values yourself by incrementing them by 10,000. It doesn't really matter, you can increment them by whatever value you want, it is not relevant. The reason why there is an increment of 10,000 in the standard app is that way there is room to insert records between existing ones.
The numbers in the app are automatically generated by the page object. Look at the standard Sales Order page (page number 42) and the Sales Order Subform page (page number 46). The PK on the Sales Header table is "Document Type" and "No.", and the PK on the Sales Line is "Document Type", "No.", and "Line No.". The subform page is a part control on the sales order page called "SalesLines" and it points to the "Sales Order Subform" with a link between the two. The link is on the "No." field (the subform has a filter on Document Type = Order).
From the standard "Sales Order" page:
The property that sets the line number is 'AutoSplitKey'. Another important property is DelayedInsert. Normally a page will insert the record as soon as the PK fields are entered, DelayedInsert causes the page to wait until you move away from the record.
AutoSplitKey sets the "Line No." field to the next 10,000 when you add a new one at the bottom of the screen. When you insert a record between two existing ones, it will split the difference. So if you insert one between 10,000 and 20,000, it will set the line number to 15,000. You can insert 13 lines like that until the difference is too small to split
To make AutoSplitKey work, you must have a compound PK on the 'child' table where the last field is an integer field. It won't work if the integer field is not the last field.
