每个业务系统都有单据，每张单据都要有个编号。编号规则往往在开发时随手定下，用起来之后才发现有各种不合适，而这时候改编号已经涉及大量历史数据。
定规则之前，先想清楚编号要承担什么功能。
一、编号要不要包含业务信息
一种做法是纯流水号，只保证唯一，不承载任何含义。这种最灵活，业务规则怎么变都不用改编号。缺点是从编号上看不出任何信息。
另一种做法是把业务信息编进去，比如前缀是业务类型、中间是年月、后面是流水。这种一眼能看出类型和时间，沟通和归档时方便。
实际用得最多的是折中方案，几个关键信息加上流水号。类型占一两位，年月占四位或者六位，剩下的给流水。既有序号的意义，也不会太长。
要注意的是，编进去的信息一旦变了就会很麻烦。比如编了部门代号，后来部门撤并了，编号里的代号就成了历史遗留。所以编进去的信息要挑那种基本不会变的。
二、要不要连续
连续编号看着整齐，但实现代价不小。多人同时提交时，要保证号码不重复不错漏，就需要加锁或者用专门的序号表，并发高的时候会互相等待。
连续编号还有一个问题，单据作废之后这个号码空着，后面就不连续了。要做到真正的连续，就得允许重复使用作废的号码，但这在审计上是不合适的，因为同一个编号会对应两张单据。
现实中的做法通常是允许跳号，但保证不重复、单调递增。这既避免了锁竞争，也符合审计要求。如果业务上确实要求连续，那就在提交环节控制并发，接受性能上的代价。
三、跨单位跨年度怎么处理
多个单位用同一套系统时，编号要不要带单位标识。带的好处是各单位的编号互不干扰，也便于从编号看出归属。不带的话，所有单位共用一个流水序列，编号会很快变大。
年度问题也一样。年月编在编号里，每年重新计数，编号不会越来越长。不编年月的话，流水号会一直增长，几年后变成很长的一串数字。
处理跨年度时要注意一个细节，跨年的单据怎么算。十二月三十一号发起、一月一号完成的单据，编号按哪一年。这个要在业务上明确，通常是按提交时间算。
四、几处实际要考虑的
编号的生成时机。是在用户打开新建页面时就生成，还是提交时才生成。提前生成的话，用户开了页面又没提交，号码就浪费了。提交时生成更合理，但要注意并发处理。
编号补录的场景。纸质单据要补录到系统里，编号用原来的还是系统重新生成。用原来的更符合实际，但要确认原来的编号不会跟系统的重复。
编号要能修改吗。多数系统不允许改编号，因为编号是单据的唯一标识，改了会引起混乱。确实要改的，做成特殊的权限，并且记录改动日志。
最后一点，编号规则要写进文档。后来接手的人不知道该按什么规则生成，可能写出不一样的东西。规则、示例、边界情况都写下来，比口头交代可靠。