Hi Marc,

For the first issue with Knnnn,GGG

The G in capitals automatically implies that any leading zeros as part of the G will be 'compressed'

So Knnnn.GGG will be T2025.3

Note that there are two numbers in CM, the Standard 'Record Number' and the 'Long / Expanded Number'.

The expanded number will still be set as T2025.003 underneath but will compress the zeros in the 003 for most 'display' purposes as the general Record Number.

You should also be able to search for the record number T2025.003 or T2025.3 in your scenario and both should return the same result.

For example, in mine, although it presents as G96/3 the Expanded Number is G1996/0003

(Sample searching for the record number with the zeros even though the number has 'compressed' them)

Making your record pattern Knnn.ggg will cause the auto increment part to keep the leading zeros and present with the 003

From the 'Record Type Numbering' help page 

Pattern - the number pattern establishes what the record number will look like for your Record Type - for example, YYYY/GGGG may look like 1998/0001 or 98/1 if using number compression.

To prevent number compression, use a lower-case equivalent in the number pattern, for example, yyyy/ggggg.

I'll double check with the 'based on container' stuff. It should set the record number only at creation time and based on the container property at that point - if you then move the container around it shouldn't renumber the container. That may be why as there may be other AR/858/* numbers in the system?

For reference, which exact CM 9 version? That way I can spin up a version that matches on my side and have a quick look.

-Scotty

Scotty,

Thank you so much for the helpful reply, I appreciate it!

We're on 9.3 (soon upgrading to 24.3 thank goodness).

Best,
Marc