解析大型.NET ERP系统 单据编码功能实现
单据编码是ERP系统中必备的功能,用于生成各种单据的流水号,常常借助于日期时间等字符来生成一个唯一的单据号码。从软件的角度来说,就是为生成数据表的主键值(参考编号),从用户的角度来说,就是给业务单据制定编码规范。之后做到见名知意,比如销售订单号是SO201508190001,采购订单号码是PO201508190001。
1 基础单据编码 Document serialization basic
单据编码主表,用于存放单据及其编码规则。
CREATE TABLE [dbo].[DocumentSerialization]( [SeriesCode] [NVARCHAR](8) NOT NULL, [Description] [NVARCHAR](40) NOT NULL, [Suspended] [NVARCHAR](1) NULL, [SerialLength] [DECIMAL](2, 0) NULL, [PrefixLength] [DECIMAL](2, 0) NULL, [Prefix] [NVARCHAR](12) NULL, [NextSeqNo] [DECIMAL](10, 0) NULL, [AllowOverride] [NVARCHAR](1) NULL, [CreatedDate] [DATETIME] NULL, [CreatedBy] [NVARCHAR](10) NULL, [RevisedDate] [DATETIME] NULL, [RevisedBy] [NVARCHAR](10) NULL, [WithReset] [NVARCHAR](1) NULL, [PrevResetDate] [DATETIME] NULL, [PrefixDefault] [NVARCHAR](12) NULL, CONSTRAINT [PK_DocumentSerialization] PRIMARY KEY CLUSTERED ( [SeriesCode] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO
举例说明,这些字段值的含义。
SeriesCode | Description | Suspended | SerialLength | PrefixLength | Prefix | NextSeqNo |
SLSOSC | Sales Order Cancellation | N | 12 | 6 | SC@Y@M | 55 |
SLSOSO | Sales Order Entry | N | 12 | 6 | SO@Y@M | 4 |
SLSOSQ | Sales Quotations Processing | N | 12 | 6 | SQ@Y@M | 2 |
处理销售订单功能SLSOSO,它的单据编码总长度是12,序号前缀长度是6,序号前缀规则是SO@Y@M,@Y表示两位数的年,@M表示两位数的月份,下一个单据编码流水号是4,所以当产生处理销售订单的单据编码时,它是SO1508000004。
2 宏处理 Macro
有时候我们需要根据情况选择一种或多种序列号生成方式,在生成序号的时候弹出窗体,让我们选择要哪一种前缀编码方案,比如采购订单的编码规则,有时候是PO201508180001,有时候是OE201508180001,它们的前缀(Prefix)是不一样的。为达到这种目的,我们给DocumentSerialization增加子表。
CREATE TABLE [dbo].[DocumentSerializationDetail] ( [Index] [int] NOT NULL, [SeriesCode] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [Prefix] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [TextPattern] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT , [NextSeqNo] [decimal] (10, 0) NULL, [CreatedDate] [datetime] NULL, [CreatedBy] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [RevisedDate] [datetime] NULL, [RevisedBy] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [Suspended] [varchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[DocumentSerializationDetail] ADD CONSTRAINT [PK_DocumentSerializationDetail] PRIMARY KEY CLUSTERED ([Index], [SeriesCode]) ON [PRIMARY] GO ALTER TABLE [dbo].[DocumentSerializationDetail] ADD CONSTRAINT [FK_DocumentSerializationDetail_DocumentSerialization] FOREIGN KEY ([SeriesCode]) REFERENCES [dbo].[DocumentSerialization] ([SeriesCode]) GO
参考下面的数据例子来理解这个表的含义:
SeriesCode | Prefix | TextPattern | NextSeqNo |
SLSOSO | ??@Y@M | PO | 9 |
SLSOSO | ??@Y@M | OE | 17 |
使用问号作为占位符,在运行时弹出窗体让用户选择哪一种单据编码方案,用户选择PO,则生成PO201508前缀的采购订单编码,如用户选择OE,则生成OE201508前缀的采购订单编码。
为了加深对占位符号的理解,举例说明以下几种情况。
1 前缀定义值是 ??ABC,用户选择XY,则返回前缀结果XYABC。
2 前缀定义???ABC,用户选择XY,返回结果前坠XY_ABC,对于不多余的占位符号用下划线替代。
3 前缀定义@D@M@YABC,当前日期是2015年8月19日,则生成的前缀值是150819ABC。
3 基于用户的需要编码方案 User-based document serialization
有时候不同的用户有不同的单据编码规则,我们需要依照用户来创建编码规则。先创建数据库。
CREATE TABLE [dbo].[DocumentSerializationUser] ( [Index] [int] NOT NULL, [SeriesCode] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [UserId] nvarchar(10) NOT NULL COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [Prefix] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [TextPattern] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT , [NextSeqNo] [decimal] (10, 0) NULL, [CreatedDate] [datetime] NULL, [CreatedBy] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [RevisedDate] [datetime] NULL, [RevisedBy] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [Suspended] [varchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ) ON [PRIMARY] GO
这个表也是序号编码DocumentSerialization的子表,主键增加了用户编码字段UserId,记录每个用户要编码规则。
在系统中,优先使用基于用户的编码规则,其次是宏替换处理,最后才是应用基础的编码规则。
4 并发处理 Concurrency
当两个并发用户同时创建或保存一张同样的业务单据时,系统会返回两个相同的单据编码,产生了并发问题。
A 方案
打开业务功能时,立即为当前单据创建单据编码,比如产生单据编码SO15080004,在单据保存时,发现这张单据编码被其它的用户使用过,则重新产生一个新的业务单据编码SO15080005,如有发现此编码仍然被占用,依此向下搜寻,直到找到可以保存的单据编码。
这种方案的优点是总是可以保存单据,缺点是界面中看到的单据编码,不一定是最终保存的单据编码。
B 方案
打开业务功能时,不产生单据编码,只有在单据保存时才产生单据编码。避免了单据并发冲突。
这种方案优点是没有并发冲突,缺点是只有单据保存之后才可以看到单据编码。
5 编码规则程序设计 Document serialization programming
在单据保存时,调用接口产生编码规则,参考下面的程序片段。
EcnEntity ecn..... if (ecn.IsNew && seriesCode != string.Empty) { IDocumentSerializationManager serializationManager =ProxyInstance<IDocumentSerializationManager>(); ecn.EcnNo = serializationManager.GetNextSerialNo(sessionId, seriesCode, ecn.EcnNo, ecn); }
如果业务单据的实体保存时发生异常,则需要重置用户编码,清除产生的序号编码。
catch { adapter.Rollback(); if (ecn.IsNew && string.CompareOrdinal(ecn.EcnNo, currentRefNo) != 0) { try { ecn.EcnNo = currentRefNo; serializationManager.ResetNextSequenceNo(seriesCode); } catch { } } throw; }
6 固定编码规则 Fixed document serialization
以上实现了基于流水号的单据编码规则,如果单据的编码规则相对固定,则以上方法行不通。请先阅读下面的需求说明:
接到客户订单,订立合同编号:HT201508003;接着做合同评审,产生一个合同评审单号PS201508003;合同评审通过以后,再到ERP系统中做销售单,销售单号是XSD201508003;如果一个合同分三个销售订单下单,则会分别产生XSD201508003-01,XSD201508003-02,XSD201508003-03 三个销售订单号。继续为销售订单发货,销售订单XSD201508003所产生的发货单号应该是XSFH201508003,如果销售订单XSD201508003分三次发货,则依次产生的三张销售发货单号是XSFH201508003-01,XSFH201508003-02,XSFH201508003-03。
销售合同 |
合同评审 |
销售订单 |
销售发货 |
备注 |
HT201508003 |
PS201508003 |
一张销售订单 XSD201508003 三张销售订单 XSD201508003-01 XSD201508003-02 XSD201508003-03 |
一张销售发货单 XSFH201508003 二张销售发货单 XSFH201508003-01 XSFH201508003-02 |
单据编号201508003从销售合同到销售发货都是同一个单据号,只是编码前缀不同。 |
这种编码方案要求一个单据号码贯穿整个流程,单据编号从起始点业务单据传递到最终业务单据,仅仅是前缀不同。
要实现这种固定格式的单据编码,需要对流转的每个单据进行编程处理,业务单据也应该有固定的下推流程,做不到通用性,但是优点是很明显的,一个号码贯穿整个业务单据,非常清晰明了。