在介绍条形码系统也ERP的接口方式及其比较之前,我们先介绍下什么是条形码技术和ERP及其特点:
条形码的基本思想是利用图像存储数据,并且能够通过某种方式识读。码最早出现在20世纪40年代,但得到实际应用和发展还是在20世纪70年代左右,80年代是条形码及时磅礴发展的时期。条形码欧美、日本和我国的发展、应用的时间也不尽相同。总体说来美国最早、欧洲和日本次之、我国最晚,到20世纪80年代初才开始研究,1988年12月28日,“中国物品编码中心”成立,负责研究、推广条码技术;同意组织、开发、 协调、管理我国的条码工作。使我国的条形码技术得到磅礴发展。
ERP是从库存管理发展而来的。早在40年代,为解决库存控制问题,人们提出了订货点法。为了解决这个问题,60形成MRP(Material Requirements Planning),即物料需求计划,70年进一步发展出闭环MRP,解决采购、库存、生产、销售的管理,发展了生产能力需求计划、车间作业计划月以及采购作业计划理论。80年代,随着计算机网络技术的发展, MRP的各子系统也得到了统一,形成了一个集采购、库存、生产、销售、财务、工程技术等为一体的子系统,发展了MRPⅡ理论。这一阶段的代表技术是CIMS(计算机集成制造系统)。
进入90年代,MRPⅡ主要面向企业内部资源全面计划管理的思想,逐步发展成为90年代怎样有效利用和管理整体资源的管理思想,ERP(Enterprise Resources Planning企业资源计划)随之产生。
ERP强调供应链的管理。除了传统MRPⅡ系统的制造、财务、销售等功能外,还增加了分销管理、人力资源管理、运输管理、仓库管理、质量管理、设备管理、决策支持等功能;支持集团化、跨地区、跨国界运行,其主要宗旨就是将企业各方面的资源充分调配和平衡,使企业在激烈的市场竞争中全方位地发挥足够的能力,从而取得更好的经济效益。
但是由于历史及原因,ERP(MRP、MRPⅡ)在设计的时候并没有考虑采用条形码技术。例如SAP,在进销存、生产管理方面没有采用好用的条形码技术,数据的及时性和正确性很难得到保证,而且数据采集效率也是非常低。
1、物料管理:
现代化生产物料配套的不否协调较大地影响了产品生产效率,杂乱无序的物料仓库、复杂的生产备料及采购计划的执行几乎是每个企业所遇到的难题。
条码技术的解决思想:
2、生产管理:
条码生产管理是产品条码应用的基础,它建立产品识别码。在生产中应用产品识别码监控生产,采集生产测试数据,采集生产质量检查数据,进行产品完工检查,建立产品识别码和产品档案。有序的安排生产计划,监控生产及流向,提高产品下线合格率。
3、品质追溯
通过条形码技术,在生产过程中收集产品的关键部件(批次或单品)信息、加工流程信息,建立产品资料库。最后达到同位产品的唯一序列号能追溯到产品生产过程中的所有关键部件信息、加工工艺信息、不良处理信息等;也可以通过关键部件的批次或者唯一编号反向追溯使用该批次或该唯一编号的关键部件的所有产品,解决出现问题是问题产品快速定位、召回,减少企业的损失,同时分析问题所在,改进生产,提升产品品质和企业竞争力。
ERP和条形码系统各自的特点。
管理对象方面:ERP涵盖制造、财务、销售、分销、人力资源、运输、仓库、质量、设备、决策支持等功能,其主要宗旨就是将企业各方面的资源充分调配和平衡,是对企业的管理;而条形码系统则侧重于对物品的管理,主要管理物品的标识,物品进销存、物品加工生产、物品资料库建立、物品追溯、物品的流通。
侧重点不同:ERP的重点在于为企业引进好用的管理方式,管理理念,偏向于对企业的持续改善;而条形码系统则注重自动识别技术、无线实时扫描、批处理扫描等,目标是提高物品进销存、物品加工生产、物品资料库建立、物品追溯、物品的流通的效率的质量。
从业务功能来看:条形码系统功能是ERP功能的子集,条形码系统管理的对象也是ERP系统管理对象的一个子集。条形码系统是在进销存、生产管理等领域比ERP更加高效、更加精细的管理。条形码系统和ERP系统存在共通的地方,如物料、采购入库、销售出库、生产单等。所以条形码系统和ERP的对接十分重要和有意义:
通过上面的分析,条形码系统和ERP分别在自动识别和企业管理方面充分发挥各自的特点和优势,双方以一种互补的姿态,为企业的决策层、员工、管理者提供高效优质的服务。但是对于条形码系统和ERP共通的部分:物料、采购入库、销售出库、生产单等,条形码系统如何获取ERP的最新物料信息;条形码系统的入库单、出库单、发货单等信息如何高效、及时、正确的反应到ERP系统;如何保证条形码系统和ERP不因为数据同步互相影响,甚至造成系统的不稳定、不正确。下面将对条形码和ERP对接的方式进行介绍和比较,可以作为条形码系统和ERP对接的参考。
ERP提交单据同时或延迟写条形码系统临时表
分工:
1、条形码系统提供临时表
2、ERP 实现提交单据时同时或延迟写条形码系统临时表
优:
1、如果ERP提交单据并同时写条形码系统临时表,可实现数据实时同步。
劣:
1、条形码系统系统故障时难以区分责任?
由于临时表是个共享表,条形码系统要不停访问,ERP也要往其写数据,
可能会由于服务器资源紧张、数据库事务、并发、死锁等问题导致条形码系统运行故障,甚至导致其崩溃,生产停止,
当故障发生,需分析双方的程序(包括 ERP 写临时表的逻辑)判断问题所在,但程序各自实现,很难操作,难以区分责任方。
2、如 ERP 提交单据同时写条形码系统临时表,则可能会由于条形码系统故障、服务器、网络等问题使写临时表失败,导致单据无法提交。
3、如 ERP 提交单据后不立刻写条形码系统临时表,而是定时触发写到条形码系统临时表,不会导致单据无法完成提交,
但会使得数据无法实时同步到 条形码系统,可能导致条形码系统因无法读到应有数据而在投换料验证不通过而导致生产停止。
4、由于需求变更等原因需变更临时表结构,则接口程序要做修改,产生新的开发成本。
5、ERP 提交单据的操作比之前慢些许
ERP提交单据同时或延迟调用条形码系统 Web Service 把数据同步到 条形码系统
分工:
1、条形码系统 实现 Web Service
2、ERP 实现提交单据同时或延迟调用 Web Service 把数据同步到条形码系统
优:
1、实现简单、ERP开发工作量小
2、如 ERP 提交单据并同时调用 Web Service,可实现数据实时同步。
3、双方系统通过 Web Service 中间接口隔开,互不影响,责任容易区分。
4、可通过设计灵活的 Web Service 接口以避免未来需求变更时接口程序的变更。
劣:
1、如ERP提交单据同时调条形码系统Web Service,可能会由于条形码系统故障、服务器、网络等问题调 Web Service 失败,导致单据无法提交。
2、如果ERP提交单据后不立刻调用 Web Service,而是过后通过其他方式定时触发调用 Web Service,不会导致单据无法完成提交,
但会使得数据无法实时同步到 条形码系统,可能导致条形码系统因无法读到应有数据而在投换料验证不通过而导致生产停止。
3、ERP 提交单据的操作比之前慢些许(但在局域网内,且数据量也不是很大,基本上影响很小的,一般最多延迟1、2秒)
ERP提交单据同时写 ERP 的临时表,条形码系统 定时主动访问 ERP 临时表
分工:
1、ERP 提供临时表
2、ERP 实现提交单据同时写 ERP 的临时表
3、条形码系统 实现定时访问 ERP临时表 同步到条形码系统数据库
优:
1、实现简单、ERP开发工作较小
2、ERP 提交单据要多加写临时表的处理,但在同一系统速度影响不大。
劣:
1、条形码系统出现系统问题时可能难以区分责任
由于临时表是个共享表,条形码系统要不停访问,ERP也要往其写数据,
可能会由于服务器资源紧张、数据库事务、并发、死锁等问题导致 ERP 运行故障,
当故障发生,需分析双方的程序(包括条形码系统读临时表的逻辑)判断问题所在,但程序各自实现,很难操作,难以区分责任方。
2、条形码系统 需要定时去读 ERP 临时表,则可能会由于 ERP 故障、服务器、网络等问题无法读到临时表
导致数据无法及时同步到 条形码系统,可能导致条形码系统因无法读到应有数据而在投换料验证不通过而导致生产停止。
3、由于条形码系统或 ERP 需求变更等原因需变更临时表结构,则双方接口程序要做修改,产生新的开发成本。
ERP提交单据时先把数据暂存到临时表,条形码系统 定时调用 Web Service, WebSerice 实现从临时表查询数据
分工:
1、ERP 实现 Web Service
2、ERP 实现提交单据时先把数据暂存到临时表,实现 Web Serice 从临时表查询数据
3、条形码系统 实现定时调 ERP WebService 把数据同步到条形码系统
优:
1、双方系统通过 Web Service 中间接口隔开,互不影响,责任容易区分。
2、可通过设计灵活的 Web Service 接口以避免未来需求变更时接口程序的变更。
3、ERP 提交单据要多加写临时表的处理,但在同一系统速度影响不大。
劣:
1、条形码系统 需定时调用 ERP Web Service,则可能会由于 ERP 故障、服务器、网络等问题调用失败,
导致数据无法及时同步到条形码系统,可能导致条形码系统因无法读到应有数据而在投换料验证不通过而导致生产停止。
方式 |
对生产的影响 |
双方系统耦合度 |
ERP 因接口故障的责任区分 |
PTS 因接口故障的责任区分 |
对ERP提交单据的影响 |
实时性 |
ERP开发工作量 |
写条形码系统临时表 |
较高 |
高 |
-- |
难 |
较高 |
高 |
较大 |
调条形码系统Web Service |
最低 |
低 |
-- |
易 |
较低 |
高 |
最小 |
读条形码系统临时表 |
最高 |
高 |
难 |
-- |
最低 |
低 |
较小 |
调条形码系统Web Service |
较低 |
低 |
易 |
-- |
较低 |
低 |
较大 |
考虑选择那种接口方式,考虑各要素的优先顺序应该:
首先是,对生产的影响,生产停止,损失重大;
然后是,双方系统的依赖度,系统关联太紧发生问题时责任难以区分,且程序未来变更的可能性徒增;
接着是,对ERP提交单据的影响,但 ERP 单据提交速度慢些许或偶尔的延迟提交不会对生产产生太大影响,远没有前面2点重要。
最后是,实时性,ERP开发工作量等等,这些应该是最后考虑的。
所以,接口采用方式的优先顺序应该是:
调条形码系统Web Service > 调 ERP Web Service > 读 ERP 临时表? > 写条形码系统临时表
综合来看,调条形码系统Web Service 是首先推荐采用的方式,因为:
对生产影响小、双方系统的依赖度低、出问题责任容易区分、实时性也很高、开发工作量最小,
对客户、ERP、条形码系统 三方来说是较好的方式。
而 读 ERP 临时表 、 写条形码系统临时表 都不是推荐的方式,因为:
对生产影响较大、双方系统的依赖度高、出问题责任难以区分,未来接口程序变更可能性大。
作为条形码系统和ERP对接的较好方式,但遗憾的并非所有ERP都提供。作为全球性的ERP,SAP分SAP Business One(SBO)、R/3等版本。下面介绍一下SBO API接口。
SAP Business One 是个开放的系统,它提供灵活的开发工具包:SAP Business One SDK,能让合作伙伴或客户在低成本的条件下进一步扩展SAP Business One 的产品功能,并可以与外部的行业解决方案集成。SDK 的 DI API可以让你在业务数据级别访问 SAP Business One,几乎所有在 SAP Business One 客户端中的业务对象都被复制到了DI API中,这样就可以被外部的应用程序访问,外部应用程序通过 COM 访问业务对象,避免了对 SBO 内部复杂业务逻辑细节的处理。
DI API介绍
SBO? Data Interface API(DI? API) 是一组以DLL形式提供,三层结构工作模式的开发工具,目的是合作伙伴提高而且扩充 SBO 和用 SBO 整合外部的解决发案。
SBO DI API 能用来存取SBO 应用程序在数据库层次上的数据, 扩充它的功能性, 以便和第三方的解决方案连接, 扩展 SBO 的功能满足客户的需要。
DI API体系结构
提供关于 DI API 的软件体系结构的明细中:所有的函数功能被包含在一个实现层 (OBServerDLL.DLL) 之中。DLL 以 SBO 客户端的现有源码为基础,也就是说, SBO 用户端的业务对象被复制到这个 DLL 中。通过SAPbobsCOM.DLL 接口能够存取 SBO 客户端对象的方法、属性等。
如下图所示逻辑:
存取模式
下图所示:它主要展示业务对象在结构中的真正对象。 第三方应用程序如何去连接对象。我们所描述的数据是多层的。 这些层使用 COM 技术,不管是外部的应用程序存取数据,还是第三方应用程序如果要访问SBO? 数据,都必须通过DI_API来访问, DI_API 是一个以 COM 技术为基础的业务对象库。 这些业务对象能被一些开发语言 ( 如 Visual Basic,C语言/C语言++,Delphi语言) 任何一个支持 COM 技术的工具所利用除此之外,DI_API 也被Java语言编写为包。 这意味这你也能使用 Java语言存取业务对象。它为我们提供了大多说的访问业务数据的函数、属性、方法。
业务数据对象
DI_API支持几乎所有的业务数据对象,如科目、联系人、合作伙伴、物料、产品结构、Documents、Stock Transfer等。但有些数据对象DI_API没有开放,如审批流。如果第三方系统需要使用SBO的审批流,需要去研究并直接读写审批流相关的表。
XML技术
XML文件是一种可扩展标示语言,它是一种储存数据技术,因为数据传输安全、快捷被广泛使用。SBO 的数据对象可以保存为xml,使SBO数据库和客户的数据库之间能够进行大规模的数据交换 (不管数据类型)。
事务
DI API 支持二种不同类型的事务
1、Single Transaction
每个数据操作的执行对象都启动一个事务,操作结果依赖对象得执行结果 (成功或失效), 系统自动地提交或回滚当前数据操作。如果操作是成功,那么整个过程将被提交。?
2、Global Transaction
在这个事务中,你能执行很多步数据操作,如果某一步的数据操作失败,那么整个事务将自动地被迫回滚。 开始和结束一个事务,我们用对象Company中的下面2个对象来处理:
Company.StartTransaction
EndTransaction[wf_RollBack,wf_Commit]
有关SBO DI API更多信息,请参考 SAP 公司提供的官方 << SAP? Business One 中文版培训教材 -SDK >>资料。