I have an item with a serial number — say 1234.

I want to create a number of sub items — say three — with serial numbers 1234-1, 1234-2 and 1234-3.

I can’t seem to figure out how to do this.

How important is it to follow this exact format? You could easily number the sub-items (presumably in their own child table) with their own serial number and combine the two serials so that you would end up with say:

1234-1
1234-2
1234-3
1235-4
1235-5
1236-6
...

Otherwise you would need to script the process or at least a part of it.

P.S. Resist the temptation to rely on counting sibling records. It can easily lead to producing duplicates when two users create records in the same time frame.

For something like this I would script all record creation and use this

https://scalefm.com/sequence-generator/

But I too would not try to give too much meaning to sub-sequences

See also:
https://fmforums.com/topic/97905-multi-part-composite-serial-number-for-items/#findComment-445025

12 hours ago, comment said:

How important is it to follow this exact format? You could easily number the sub-items (presumably in their own child table) with their own serial number and combine the two serials so that you would end up with say:

1234-1
1234-2
1234-3
1235-4
1235-5
1236-6
...

Otherwise you would need to script the process or at least a part of it.

P.S. Resist the temptation to rely on counting sibling records. It can easily lead to producing duplicates when two users create records in the same time frame.

Yes. I could see that option but, unlike your example, I would want 1236-1, not 1236-6

6 hours ago, millmaine said:

unlike your example, I would want 1236-1, not 1236-6

Then you'll have to put some work into it, as I explained in the other thread.

BTW, you did not explain why you need this and in what context. Both of the replies assume this is meant to serve as a unique and immutable identifier of the child record. It should be mentioned that in a report you can easily number child records sequentially "on-the-fly" using a summary field with restart. But these numbers will depend on the current found set and sort order. If you delete or omit a record, its following siblings will move up and close the gap.

I've ended up writing a script where the original item ID is saved as a variable, then the secondary numbers are add using "Serial increment".

The purpose of is to be able to separate certain sections of items for use outside Filemaker, while retaining an easy way of identifying where in Filemaker those items can be found.

50 minutes ago, millmaine said:

the original item ID is saved as a variable, then the secondary numbers are add using "Serial increment".

That can work provided that all sub-items of an item are created at the same time, once and for all.

15 hours ago, comment said:

That can work provided that all sub-items of an item are created at the same time, once and for all.

Got around that in following manner: The script finds whether sub-items exist. If they do, it sorts them by sub-item ID then new sub-item is next increment from the last existing one.

5 hours ago, millmaine said:

Got around that

Let me just point out how your workaround differs from FM's native serial numbering. The auto-entered serial number generator will never issue the same number twice. In your solution, if you delete the last sub-item of an item, the next new sub-item will recycle the deleted sub-item's ID.

Even more concerning is the following scenario:
Suppose item 1234 already has 3 sub-items. Now user Alice adds a 4th sub-item and is issued the ID of 1234-4. While Alice is working to complete the new record, user Bob adds a 5th sub-item to the same parent item. Since Alice's record is not yet committed, your method will not detect it and it will end up assigning the same ID to both sub-items.

Edited May 6May 6 by comment

2 minutes ago, comment said:

Let me just point out how your workaround differs from FM's native serial numbering. The auto-entered serial number generator will never issue the same number twice. In your solution, if you delete the last sub-item of an item, the next new sub-item will recycle the deleted sub-item's ID.

Even more concerning is the following scenario:
Suppose item 1234 already has 3 sub-items. Now user Alice adds a 4th sub-item and is issued the ID of 1234-4. While Alice is working to complete the new record, user Bob adds a 5th sub-item to the same parent item. Since Alice's record is not yet committed, your method will not detect it and it will end up assigning the same ID to both sub-items.

I understand.

Your first point is actually an advantage for us. For the person who deals with the item and sub-items after Alice or Bob, they can see that the sequence is continuous and there are no missing items. (There are other failsafes in the solution that ensure this, but the unbfroken sequence of ID numbers is a simple visual check).

Your second point does require some further thought. The sub-items are automatically committed within the script — before Alice adds any specific detail. So Bob would have to be working lightning fast to create a sub-item at the same time as Alice, plus, in the way they work, it's highly unlikely that they would be working on the same item at the same time. However, I don't like leaving the possibility there, so will give it further consideration.

Consider also this:
Alice has created a new sub-item 1234-4 and is working on it. Since you say the record has already been committed, when Bob adds another sub-item it will get the ID of 1234-5. But now Alice changes her mind and decides not to add her sub-item after all.

5 minutes ago, comment said:

Consider also this:
Alice has created a new sub-item 1234-4 and is working on it. Since you say the record has already been committed, when Bob adds another sub-item it will get the ID of 1234-5. But now Alice changes her mind and decides not to add her sub-item after all.

Fair point — my unbroken sequence is now broken. I can see advantages and disadvantages to all options. I'm going to have to think more about how it will work in practice.