Hi Felix,

You can indeed use the IncrementHelper to get the next value for a given incrementer by ID. When you use the AutoIncrementFieldDescriptor, the same underlying API is used by the DOM manager to get the next value. With this helper, you could build your own incrementing ID by hooking into the 'create' actions with a CRUD script and update the DOM instance with your custom ID. Keep in mind though that this does mean every create will result in another update, increasing the load on the system for every create action. As the script is executed asynchronously, you may also have a situation where the ID field would not be populated yet if you for example would create the DOM instance in a form and then have a table refreshed right after the save.

I see in your post that you would prefer to avoid hard-coding the year, but in a way, this does provide a more performant solution in general. A simple script could be made which is run around the new year period with a scheduled task that would update the AutoIncrementFieldDescriptor with the new year every time.

Note that with the CRUD script approach, the same limitation applies here as mentioned in the 'Important' section on the docs page for that FieldDescriptor. In some very rare cases where there would be database issues, you may run into having the same ID being returned by that incremementer. We have only seen this issue once in the past, but keep in mind that it would be safer to not have your solution/code rely on these IDs being 100% unique. Ideally, these IDs are used as a visual indication to easily find the DOM instances back, where it would not be a system-breaking issue if two instance would be found in very rare cases.

There are plans to make the AutoIncrementFieldDescriptor obsolete for that exact reason. A new field descriptor may be added in the future instead which also makes it possible to generate a unique human-readable string. (But it won't be a number incremented by one each time)