订单管理信息系统

订单管理信息系统（共8篇）

订单管理信息系统 篇1

一、企业订单信息化管理的现实意义

当今时代, 世界经济已经趋于一体化, 国家提出了供给侧改革, 又进一步对企业的内部管理、订单管理、库存管理等方面提出了新的要求。一直以来, 传统的订单管理方式都是靠手工管理, 其存在诸多缺点, 加大了手工管理者的工作强度和工作量。而且, 传统的手工订单需要耗费大量的纸张, 产生大量的数据资料, 如果一个企业的订单管理模式一直停留在用纸质的基础上, 其已经不能适应信息时代发展的要求, 不能有效地节约资源。现在计算机技术的发展和应用越来越广泛, 也日益成熟, 传统的企业管理发展模式必然要被以计算机为媒介的信息技术管理方式所取代。

二、企业订单信息化管理的目的和范围

传统企业订单管理系统的缺陷和漏洞是显而易见的, 信息化订单管理的主要目的就是根据实际碰到的问题和现实的需要, 建立一套基于计算机应用技术, 因地制宜地为企业发展提供解决方案, 为企业提供智能化的、高效的管理体系。须具备以下特点:

1.提高信息化程度, 包括客户信息、订单信息、财务资料、库存管理、系统设置等各大模块。

2.实现效率的提升, 包括客户资料维护、订单审核、财务审核、信用档案维护、系统日常维护等功能。

3.协助企业管理层形成更加合理高效的决策。一般性的企业信息化管理范围是指公司客户、公司主管、公司财务、公司仓库等部门, 这些部门负责了公司的主要职能, 包括客户录入、客户订单、订单审核、财务价格分析、产品折扣率计算、库存查询、产品信息查询、采购订单出库、财务缴款时间统计、客户信息资料评审等各个方面的内容。

三、企业订单信息化管理的运用分析

1.系统分析。当今的市场经济活动中, 客户的要求越来越严, 快捷高效的质量, 要求企业不得不提高自身的生产效率, 提升企业的管理能力, 订单管理就是很重要的一个方面, 能不能做好企业的订单管理是企业能否有效控制成本, 能否把握优势的关键。把企业的生产流程、操作流程结合数据库功能, 形成一套解决方案, 把生产的信息、市场的信息便捷地传送到各个职能部门, 迅速反馈到公司的管理决策层面。市场经济中企业竞争不断加剧, 需要不断开拓新的市场份额, 管理好财务系统、品质系统、物流系统等各个方面, 企业信息反馈的速度、准确率直接影响公司高层的决策水平, 企业的决策高层们已经意识到合理高效配置企业资源的必要性, 并合理发掘一起可以利用的社会生产要素, 不断调整企业的发展策略, 适应国家政策迎接挑战, 只有如此, 才有可能保持自身的竞争优势, 保证企业不被市场所淘汰。

2.可行性分析 (Feasibility Analysis) 。是在调查研究的基础上, 针对新的困难、新的形势, 对开发新的系统的必要性和可行性的研究分析, 对新系统的开发应用要从各个方面进行研究, 技术、资金、社会因素各个方面都要考虑, 以防投资失败给企业造成损失。可行性研究的目的就是尽量减少代价, 减少成本, 减少时间, 判断能否有效解决问题。

(1) 技术可行性。订单管理系统可以采用C/S模式进行开发, 这是当前的主流系统。Microsoft Visual Basic 6.0作为可视化的Windows语言, 选作前台开发工具, 具有通俗易懂的特点。后台数据的开发则要求处理信息量大, 又能保持数据的完整性, 可以选用SQL sever 2000作为开发工具, 可有效利用许多高级管理功能和数据分配功能。配备这两个强大的开发工具, 再加上接口设备, 作为订单系统的开发在技术上是可行的。

(2) 经济可行性。信息时代充满竞争和挑战, 高效化、系统化、信息化、智能化已经成为企业必不可少的生产要素, 因此一个企业掌握一套适合自己的订单管理系统是相当必要的, 传统订单模式必然无法适应现如今巨大的信息数据运算能力和要求, 面临淘汰, 唯一的解决方法就是设计适应企业自身的订单管理系统, 提高工作效率, 节省人工成本, 以保持企业的市场竞争力。而且, 传统订单模式中, 对人员的数量要求较大较多, 成本高, 错误率也高, 开支巨大, 造成浪费。所以信息化管理系统可以为企业的发展提供新的动力和竞争力, 主要体现在三个方面:

(1) 可以取代人工从事繁杂的社会劳动

(2) 可以节约企业资源, 节省成本

(3) 可以提高企业内部生产要素的生产效率

所以, 一套信息化的订单管理系统可以随着企业的发展和工作环境的变化不断更新, 不断完善, 可以持续使用。一开始投入的成本高些, 可是如果分摊到每一个自然年度, 按一个时期来计算, 其开发成本的性价比也是经济可行的。

(3) 社会可行性。一套完整的系统要进行多次的调试、测试才能投入使用, 这就要求由系统开发人员对用户群进行系统化培训, 以达到熟练掌握的程度, 这是一个系统化的培训和学习过程, 在开发设计的过程中, 尽量使用比较直观的界面视图, 加以文字说明, 可以提高用户群的理解掌握能力, 计算机的基本操作已经不是难事, 用户对计算机系统的操作也是简单的日常化应用, 应该说任何人只要经过一系列的培训都不会成为问题, 都能使用和管理, 所以可以说在系统的操作层面也是可行的。

结束语

如何实现企业订单管理系统的信息化、智能化, 利用信息技术手段与企业资源实现优化组合, 设计出科学高效的系统方案, 得到了企业各界的高度重视。本文从运用与分析方面展开了理论与实践的阐述, 提出了可行性的设计方法, 为下一步面向企业信息化订单管理系统的开发实现提供了必要的构思和想法。

订单管理信息系统 篇2

云飞酒店管理系统如何建立团体预订客单？

方法:进入云飞酒店软件系统，点击主菜单“预订”->“团体预订”，进入团体预订模块,如图：

（团体预订）按“新增”按钮，进入团体预订编辑界面，如图：

（团体订房编辑）在团体预订功能模块上，我们可以完成从订房、排房、入住等一系列工作，下面一一做介绍。

酒店管理系统论文参考之-团体订单 1）建立团体基础资料

团号：系统自动产生，产生规则是：识别码G+年月日+流水号，也可以自己手工更改，原则是不能跟现在的团号相冲突，否则不能保存。

帐号：系统自动产生,识别码G+流水号,不能手工更改。团名：团体名称。

团队类别:比如：自由行或其它旅行团，团队类别可在基础资料里自己增减。人数：旅行团人数。抵达：抵店日期。天数：预计入住天数。

订房人：订房联系人，电话等信息。

其它资料包括：市场码、房价类、合约、应收等信息，可按需要填入。团体基础资料填入完毕。保存信息。

2）建立预订房数 包括：房类、房价、抵达日期、离店日期、房数

(预订房数)按增加按钮 “+” ,进入编辑状态,选择房类，房价由系统自动选择标价,可手工更改,抵达及离店日期默认为团体资料的相应日期。输入房数，按“√”保存当前记录。如果还要增加其它房类，可重复前台动作，直到所有房类都输入完为止。

3）排房 通过第2步，我们完成了预订房数，它只确认了某一房类的数量，还没有具体到每一间房间的确认。通过排房功能，我们可以为团员安排具体房间。如图: 酒店管理系统论文参考之-团体订单

(排房)切换到“排房”页面，选择要排房的房类，点“自动排房”按钮。进入排房界面，如图:

(自动排房)系统按顺序列出当前可售房间，并且默认勾选需要排房的总数，也可以由用户手工选择其它房间。按“排房”按钮就可以完成排房功能。

酒店管理系统论文参考之-团体订单

(已排房/入住)排完房后，切换到“已排房/入住”页面，在当前页面，可以自直接做入住处理。也可以点“修改/入住”登记每一个人的资料，登记完，再入住。4）批量修改团员资料

（团员姓名）点“团员姓名”进入团员信息批量修改模块，4 酒店管理系统论文参考之-团体订单

(团员信息批量修改)

订单管理信息系统 篇3

目前汽车行业越来越广泛采用了多路传输分布式汽车电子电气系统, 在确保满足总装电子电气工艺领域的单件订单化生产的要求情况下, 整车装配完成后还需要实施大量的相关工艺操作和工序内容[1]。在这个过程中总装现场电子电气生产设备提出了大量电子电气订单生产信息的新需求[2], 并且有很高实时性和订单化的要求。因此如何设计建立相关的汽车总装电子电气订单生产信息系统成为整车企业面临的重要现实问题。

1 整车电子电气系统总装阶段工业化的特点

目前的行业趋势是在整车电子电气系统设计时, 主要考虑的是如何在尽可能减少各类零件数量的同时, 实现相关零件的标准化, 而且还能满足不同配置的个性化功能的需要。这比较类似于如今计算机制造业的思路。基于这种思路, 整车电子电气系统在总装阶段的工业化方案设计也提出了新的要求[3]。在相关传统工业化方案设计的基础上, 还应满足的新原则是:

(1) 软硬件分离的设计思路, 将电控单元硬件标准化, 也就是构成电控单元的单板机或单片机硬件系统的设计结构相对固化。同时将功能和配置的差别用软件的方式实现。

(2) 各电控单元的软件加载的现场实时化, 即在整车装配完成后, 根据订单的要求和车辆配置级别要求, 在现场进行软件植入加载操作。这样可以利用相对单一的电控单元硬件加载不同的软件。可以减少电控单元零件的种类, 减少采购成本, 同时便于物流和生产的管理[4]。例如不同的车型采用的是同一电喷系统, 其硬件完全一致, 只是在总装生产线上实时的加载不同的发动机控制软件, 以满足其不同驾驶特性。

(3) 电控单元系统的编码配置的现场实时化, 即在电控单元软件加载完成后, 通过设置电控单元中某些参数的值, 使得该电控单元系统能够完全与每台车辆的配置和装备情况一致, 而这些配置可能是订单化的。例如很多高端车型的不同配置水平差别较大, 但其关键性核心电控单元采用的统一的零件, 只是在生产现场根据车辆的配置订单情况, 实时的对其参数进行设置 (多时可达数百甚至上千个参数) , 确保与整车配置情况协调一致。使得车型以其丰富灵活的配置组合满足了用户个性化的需求。

(4) 对于需要精密电子控制的场合, 实施现场自学习操作。这样既可以达到精确控制的目的, 又降低了对相关控制部件的制造精度要求, 节约了相关的制造成本。例如电子稳定程序控制系统 (ESC) 需要精确的车辆直线行驶时的方向盘角度位置, 由于每台车和组成部件不可避免的制造误差, 这些误差的累积使得不可能给出一个统一的零位值。为此需要在现场根据每台车进行方向盘的零位学习记忆。从而确保了ESC系统的精确和可靠的运作。

2 总装电子电气订单生产信息需求

基于上节所述的工艺设计思路, 总装现场工序的完成需要实施生产相关产品和工业化信息的传递和导入, 在生产线上对每个订单车辆实施电子加载和电子编码工艺操作, 以及电子电气相关自动化检查 (以下简称“电检”) 时, 必然会遇到一个订单车辆识别和信息的获取和传递的问题。尤其是针对国内多数整车企业总装生产线车型高度混流的现状, 既有不同系列和级别的车型, 又有同一车型内不同配置和档次的车辆混流[3]。在实施电子加载和编码操作时必须能够准确的获取待加载订单车辆的车型和配置信息, 同时必须正确获得每个电控单元的配置参数设置信息, 以便完成其电子编码的操作。

总装电子电气订单生产信息传递基本路径见图1。产品及其制造信息由计算机主机通过内部工业网络和后面要介绍的无线方式传输到专用的诊断设备上, 如ODISSEE现场专用诊断仪。然后由诊断设备将信息进行处理, 转化成相应的KWP2000或UDS服务语句, 然后按CAN诊断协议的标准将数据帧发送到车辆的诊断口, 最终针对某一特定的电控单元零件进行电子加载和电子编码等操作。

3 总装电子电气订单生产信息系统

3.1 系统总体结构和运行流程

为了适应这些产品和制造信息的转化和传输, 整车企业需要建立和调整相应的计算机系统, 以确保能将需生产订单车辆的电子电气信息传送到现场工业设备上。

总装电子电气订单生产信息系统的基本结构见图2。在制造信息处理系统中根据市场部门维护到车辆订单系统的订单需求信息, 提取相应的电子电气产品和制造信息, 并按照车辆打包传输到生产计划排产系统中。订单车辆上线装配时就可以实时获得这些信息, 以进行相应的电子电气工艺操作。从生产信息系统传到专用诊断设备的方式为2D即二维条码的方式。在数据初始化工艺程序里面对电子加载和编码的操作的输入信息完全是来自上游信息系统。而在电检工序使用一维31位条码的方式传递信息, 具体编码信息的检查, 则需要工艺人员将各电控单元的纸质编码定义表的内容维护到工艺电检程序中去。采用两种模式以便进行印证一致性检查。

3.2 条码式车辆识别子系统

在进行数据初始化操作时需要输入的信息包括:车辆识别码 (VIN) 、防盗系统密码、ODISSEE信息码。图3是电子电气工艺程序中对他们的处理流程图。

其中ODISSEE信息码中包含的信息很多, 如电子电气系统配置情况, 部分店空单元的软件零件号, 全部电控单元的配置参数编码信息等, 这些都是进行ODISSEE数据初始化操作不可缺少的, 总的信息量可达数千字符。为了便于操作, 诊断设备一般都是属于便携性的, 操作者可以携带设备对一定区域内的车辆进行电子电气工艺操作, 对于电子电气返修工序来说, 甚至包含整个返修区域。为了将大量的信息实时传送到设备中, 在实践中可以采用1D (一维) 和2D (二维) 条码系统并用。

在VIN号、防盗密码和电检码上采用1D条码, 因为信息量不大, 完全可以胜任。而对于多达数千字符的ODISSEE信息码则可采用2D条码的方式, 如图4是一个2D条码的简单例子, 其表示的字符是:“#ID11010LD-CC43X2950190300;111CB5A4HAT550A060M0ZRQ1FC;01202;1310420UW10252;01401;046B50;04700;24AMM6;4BBSI;24FRD4;24GCCD;24JCLI;24KCMB;24LAFF;4MAC4;24PESP;24RAAS;24SVMF;24YEPC;24ZEPP;6BBSM;26HBCD;26JALA;6UDIR>020877#”, 可见一个条码可表达数百个字符, 根据订单车辆的复杂情况, 一般用5到6个条码来载录和传输信息。

3.3 在线实时无线数据导入子系统

上述的2D条码系统似乎解决了大量数据向移动式诊断设备的传输问题, 整车企业在车型试生产阶段又可能遇到了新的能力瓶颈问题。由于纸质2D条码的扫描对纸质和扫描枪的要求很高, 加上又要扫描多个2D条码, 再加上2D条码的生成和打印时间, 使得实际操作工时大大超出了要求。

在如何解决信息传输瓶颈问题上可采用无线数据传输的方案。方案实不但节约工时, 还能避免扫描质量不稳定的问题。图5是该设计方案的结构框图。可以采用双网卡的工控机系统, 其一端接到工业网上, 另一端则连接两个无线接入集线器, 同时接两台打印机。ODISSEE便携诊断仪加装了无线网卡。工控机负责信息的发送接收校验、无线通讯网的冲突和优先级的管理等。

ODISSEE诊断仪在为订单车辆做数据初始化时, 首先扫描该车随车卡上的VIN条码, 获取VIN码之后就通过无线网络和交换机发送给工控机, 接着工控机通过公司内部工业网连接到生产排产系统 (SPPV) , 从SPPV系统中取出对应该VIN码的数据初始化数据信息, 然后电子电气数据信息又通过交换机和无线网络传给了ODISSEE诊断仪, 这样诊断设备就获得了数据初始化所需要的数据。ODISSEE数据初始化结束之后, 诊断设备会将结果信息再次通过无线网络和交换机发送给对应的打印机来打印数据初始化结果。这样就完成了整个数据初始化操作。

当ODISSEE数据初始化无线输入系统出现了问题不能正常工作时, 设备将可以进入降级工作模式, 即放弃使用无线传输系统。直接向工控机扫描输入车辆VIN码, 工控机从SPPV系统获取2D条码信息之后, 直接通过打印机将2D条码打印出来。ODISSEE数据初始化时设备直接按顺序逐一扫描打印出来的2D条码获得数据初始化数据。数据初始化结束后将ODISSEE设备与打印机通过RS232串行口直接连接打印数据初始化结果。此降级方案大大加强的整个系统的安全性。

另外方案还设置了数据初始化结果数据库, 以便对该工序的工作状态进行监控和分析, 便于开展电子电气工艺质量的持续改进工作。同时方案还预留了一些数据接口, 为以后的功能扩展打下了很好的基础。

4 结论

整车企业汽车总装电子电气订单生产信息系统的建立, 不但满足了其总装电子电气工艺领域的单件订单化生产的要求, 大大提高了生产效率和生产一次合格率水平, 而且还可以实现产品生产过程逐一记录并可追溯, 同时通过与企业生产系统和售后服务系统的互联形成完整的产品质量管控链条, 保证了企业产品的高质量、多样化且可追溯, 大大提高了其市场竞争力。

摘要：通过对整车电子电气系统总装阶段工业化的特点的分析, 确定了大量总装电子电气订单生产信息对于总装现场生产活动的必要性。设计建立了适应现场需求的汽车总装电子电气订单生产信息系统, 并包含条码式车辆识别和在线实时无线数据导入两个子系统。本系统的建立实施不但满足了总装电子电气工艺领域的单件订单化生产的要求, 大大提高了生产效率和生产一次合格率水平, 而且保证了企业产品的高质量、多样化且可追溯, 大大提高了其市场竞争力。

关键词：汽车总装,电子电气,订单生产,信息系统

参考文献

[1]冯艳双.现场总线的特点及其应用研究[J].科技传播, 2011 (18)

[2]汝刚.Web混合模式下面向订单装配的生产管理系统[J].中国管理信息化, 2011 (17)

[3]饶运清, 李培根, 李淑霞, 朱传军, 张超勇, 金愿华, 张晴.制造执行系统的现状与发展趋势[J].机械科学与技术, 2002 (06)

订单管理信息系统 篇4

1 系统业务分析与工作流设计

1.1 业务分析

1.1.1 样板试制与确认

服装样品试制包括确认样试制或试样试制两项内容。其中, 确认样试制又分实样制作和确认样制作两种, 根据客户的服装样板进行样品试制, 称为实样制作;根据客户的款式图进行样品试制, 称为确认样制作。而根据客户的修改意见以及生产的可行性研究进行实物标样试制, 称为试样制作[3]。

订单员收到客户的确认样或试样制作订单后, 根据客户订单信息填写“打样表单”, 包括款式、规格、包装等参数, 所需的材料、设备、工具等条件以及工艺操作工序记录到系统中, 并将样品或图片、物料色卡寄送到打样工厂, 所有寄出物品都有电子档案留存[4]。如果是客户来料, 应记录相关信息。样品生产过程中, 如客户提出修改, 要重新录入打样表单, 并撤消原有打样信息。样品生产好后寄给客户, 客户收到样品后填写“样品确认单”。客户如果不确认样品, 要登记修改版本, 重新进行打样过程, 直到客户最终确认。

1.1.2 跟单

合同签订后, 应将相关信息记录在系统中, 同时保存合同电子档案。

1.1.3 物料采购、入库

接下定单后, 跟单员根据定单分别填写“生产通知单”、“材料耗用明细表”、“仓库发料通知单”以及“物料采购单”, 分发给供应链上采购、生产和仓库等单位。根据生产能力, 确定是否外包生产, 如需外包生产, “生产通知单”将被发放给多个工厂。

一张定单通常对应一张材料耗用明细表, 当一张定单中包含多个服装款式时, 一般一款一张“材料耗用明细表”。如果某些物料由客户提供, 需在“材料耗用明细表”中标明, 同时对客户物料到厂情况进行追踪[5]。“仓库发料通知”与“材料耗用明细”基本相同。

“物料采购单”中的数据来源于“材料耗用明细表”上的“所需用量”与“仓库存量”栏数据, 其中服装材料损耗量要减去客户提供的物料数量。

1.1.4 生产过程

服装生产过程跟踪主要包括服装物料裁剪的跟踪, 对粘合工艺、缝制工艺的跟踪, 对熨烫工艺、后整理与包装的跟踪等几个方面。

1.1.5 信用证审核

跟单员收到信用证以后, 将信用证的有关信息录入系统, 系统提供与合同的比对工作。

1.1.6 出货跟踪

出货跟踪主要包括制作装箱单跟踪、报验货物跟踪、货柜选择跟踪。

1.1.7 催单结汇

信用证、合同中签订的有关时间信息系统将提供提醒功能, 以帮助跟单员催单结汇。

1.2 业务定义成工作流

不同于一般的面向数据和面向服务的系统开发过程, 基于工作流驱动的系统关注的是系统中的流程, 而不是数据。因此, 首先应该将分析得到的业务转化成工作流定义, 如图1所示, 服装贸易企业根据其职能可以划分为询价、采购、订单、品管、单证、产品开发、货款结算等流程。

借助j BPM的图形化流程设计工具 (GPD) 定义各个工作流模板。JBPM使用JBoss j BPM Process definition language (j Pdl) 作为工作流定义语言。j Pdl把一个商务流程看作一个UML状态图。j Pdl详细定义了这个状态图的每个部分, 如起始状态、结束状态以及状态之间的转换, 通过图型化的流程定义, 直观地描述业务流程[8]。示例如下。

1.2.1 起始节点, 以及下一步的流向

1.2.2 多任务分支节点

1.2.3 结束节点

<end-state name="结束"></end-state>

3 系统设计实现

3.1 架构设计

为了进行业务逻辑处理, 一般部署多个应用服务器, 以实现负载均衡和分布处理, 使系统具有更好的响应速度。本系统采用四层架构模型, 包括表现层, Web服务器层, 应用服务器层和数据层, 其关系如图2所示。其中表现层采用jsp技术, 中间层采用流行的Struts+Spring+Hibernate, 数据层采用SQLServer。

Web服务器层扮演的是MVC模式里面的“C” (controller) 的角色, 控制业务逻辑层与表现层的交互, 负责业务逻辑层的调用, 并将业务数据返回给表现层, 该层采用Struts框架实现[9,10]。

应用服务器层即业务逻辑层, 负责业务逻辑实现。该层以数据层为基础, 通过对DAO组件的正面模式包装, 完成系统所要求的业务逻辑。数据层包括DAO层和持久化对象两级, DAO层负责与持久化对象交互, 该层封装了数据的增、删、查、改操作[11]。系统采用Hibernate作为ORM框架。Spring的作用贯穿整个中间层, 将Web层、Service层、DAO层及PO无缝整合。

3.2 工作流运行实现

工作流的运行包括以下几个过程:流程部署、启动流程实例、执行等待状态、结束流程实例。系统定义一个接口Work Flow Manager处理流程相关的所有操作[12,13]。

通过Work Flow Manager接口调用JBPM的流程管理功能, 进行流程流转与控制。如图3所示。

以增加流程实例为例, Order Manager调用Work Flow Manager的add Process Instance方法, add Process Instance通过Jbpm Context获取工作流引擎的上下文, 从中检索出流程定义的对象。通过流程定义描述创建流程实例Process Instance, Work Flow Manager获得实例ID返回给Order Manager, 流程实例增加成功[14]。

3.3 实现举例

工作流管理系统是一个真正的“人-机”系统, 用户是系统中的基本角色。图4是订单流程流转到打样员角色, 由打样员添加打样信息的实现效果图[15]。

4 结语

订单管理信息系统 篇5

关键词：SAP,采购订单,供应商,变更管理

一、前言

生产制造企业通过引入ERP (Enterprise Resource Planning) 产品来提交企业的竞争力, SAP (Systems, Application and Products in Data Processing) 是ERP的代表产品, 世界五百强有80%以上的公司使用SAP的解决方案, SAP是集成的企业资源计划系统, 它包括财务、采购、库存、生产销售、质量、人力资源管理等功能模块, 企业运用采购模块来实现原材料的采购。生产工厂生成采购订单后, 经常发生订单被删除, 以及订单的数量货值金额交货期被更改的情况, 造成了供应商生产的产品不能满足需求、超过需求或者延误交货的情况, 影响了生产企业的正常生产。为了解决这一状况, 本文给出了的基于SAP平台的采购订单变更管理系统的构建, 本方案能有效解决这些问题。

二、系统设计

采购订单变更管理系统充分考虑了生产工厂和供应商的管理需求, 既满足了生产工厂进行生产计划变更, 及时调整生产计划;又能满足工厂生产需求的采购订单能够及时反馈给供应商, 使供应商能够在第一时间接到变更的请求, 及时根据需求调整供货数量以及交货的时间。

系统主要是对生产订单的修改进行限制, 采购员若需要对采购订单进行变更, 则需要进行变更申请。申请的数据会传送到供应商的系统, 由供应商对申请的数据进行确认, 确认后的结果传回到SAP系统会, 系统程序会自动将通过申请的数据对相应的采购订单进行变更, 主要流程如图1所示。

三、主要功能特点

系统方便了生产企业和供应商之间的沟通。系统不但使生产企业的采购计划变得快捷容易, 提高了工作效率, 降低了管理, 而且使供应商备货量和供货日期更加准确高效。系统可以及时地变更采购货物的数量、供货日期, 具体来讲, 系统主要具有以下功能。

3.1

变更例外情报管理功能, 加强使用订单变更管理系统的灵活性, 在生产工厂系统和供应商的系统之间的传输发生问题的时候, 能够及时进行订单的变更, 增加了一个例外处理的情报, 在例外处理情报系统中输入表1所示字段, 注册了这些字段以后, 订单可以不通过订单变更管理系统也能够进行采购订单的变更。

3.2

变更请求申请功能, 当用户通过变更程序进行变更请求的时候, 系统调出所有的采购订单, 然后检查设置例外处理数据, 去掉例外处理的数据以后, 再减去入库数据和生成付款凭证的数量, 这时候的数据可以进行订单变更管理, 订单变更的数量是根据前面几项的数据计算生成的, 算法如表2所示。

3.3

变更确认功能, 供应商在收到变更请求后通过程序进行确认, 可以拒绝变更请求, 并且输入相应的原因代码;在同意变更请求的情况, 对变更请求进行确认, 同意相同数量的变更。确认变更完成以后, 拒绝或者同意的数据会被传回到采购方的系统, 然后根据确认的代码进行相应的改变。

四、不足与展望

系统是基于SAP与SAP之间的操作系统, 不适合对供应商没有采用SAP系统的公司, 因此系统具有一定的局限性。将来可以对系统进行完善, 增加能够处理SAP系统和非SAP系统之间的数据交换, 以满足多家供应商的不同系统能够实现采购订单变更的请求。

参考文献

[1]SAP AG.Purchsing (MM-PUR) [S], 2001.

[2]Martin Murray.SAP MM-Functionality and technical configuration[M], 2006.

[3]周旋.SAP R/3技术与实现[J], 2001.

订单管理信息系统 篇6

近年来, 随着互联网技术的发展、移动计算设备性能的提高和高速移动网络的普及, 基于移动互联网的智能设备和服务在人们的生活中起着越来越重要的作用。餐饮行业作为一个典型的传统行业, 与人们的生活密切相关。在传统的餐饮行业中, 存在着大量的中小型餐饮企业, 其员工数量较少且店面营业面积较小, , 无法在店面内为大量的顾客提供就餐服务。因此, 这些中小型餐饮企业需要提供外卖服务来增加营业额。在传统的外卖订单模式中, 用户需要通过电话询问外卖菜品并下订单, 商家使用纸笔记录用户的需求, 并派人将菜品送至用户处。整个过程效率低下且容易出错。

信息化同传统产业结合以提高传统产业生产效率是近年来社会发展的一个大趋势, 上述问题同样可以采用信息化的方法来解决。文献[4]中景鑫设计了一种采用Android客户端通过WIFI网络进行远程下单的方法, 该方法实现了点单、下单、备货、出货等一系列操作, 并能通过PC机客户端实现统计功能。文献[5]中张志德实现一套Android客户端软件和完善的后台服务功能来完成餐饮服务功能。该系统主要包括后台数据库服务器、Web服务器、无线网络、An-droid前端等部分。客户端Android系统智能手机具有前端处理与计算能力, 而且通过无线网络访问Web服务器。文献[6]中李宽介绍了如何使用Flash技术, 在Android平板电脑上设计实现餐饮业的电子点餐系统。

但是上述研究成果都没考虑到外卖订单管理问题。为此, 本文设计与实现了一个基于Android的餐饮外卖订单管理系统, 以优化菜品发布、点单、订单确认和送货的流程。本系统整合了菜品发布、客人点单、订单管理、配送分配等功能, 利用Android平台的成熟性、开发便捷性和经济性, 为小型餐饮企业提供一个良好的外卖订单管理解决方案。

2 系统设计

2.1 系统的逻辑结构

本系统由数据库层、系统接口层、逻辑层和应用表示层组成四层逻辑结构。采用分层结构能够提高系统的可维护性, 充分利用Java语言的可重用性, 降低系统开发难度, 提高开发效率。每一层的功能如下:

(1) 数据库层, 用于存储本系统涉及的各种数据内容。包括各种订单记录的历史记录, 菜品类型和价格记录, 配送人员信息等。

(2) 系统接口层由系统所使用的开发平台下的各种标准组件构成, 例如Android SDK中的应用程序框架和库函数。

(3) 逻辑层运行于Web服务器的运行空间, 使用JSP完成动态内容的显示。

(4) 应用表示层是运行于Android客户端的应用程序, 用于收集用户的操作请求并显示操作结果。

2.2 系统技术选型

在本系统的实现中, Android客户端使用Java SE, 基于Android SDK开发。服务器容器采用Apache Tomcat。服务器端采用ASP开发, 使用Servlet技术对客户请求进行响应。

数据库采用My SQL和SQLite数据库, 其中My SQL数据库是整个系统的后台数据库, Android客户端通过JDBC对My SQL数据库的内容进行远程访问。SQLite是一个轻量级数据库, 用于存储Android客户端上的本地数据。

本系统的系统结构如图1所示。

2.3 系统的数据库设计

My SQL数据库维护着以下4张数据表, 数据模型如图2所示。

dishtbl (菜品数据表) :主键为id (菜品编号) 。

ordertbl (订单数据表) :主键为id (订单编号) , 外键为date (订单日期) , dish1 (菜品1编号) , dish2 (菜品2编号) ...dish10 (菜品10编号) , customerid (顾客编号) 。

historytbl (历史记录表) :主键为date (日期) 。

usertbl (用户数据表) :主键为id (顾客编号) 。

3 系统实现

基于Android的餐饮外卖订单管理系统主要包含以下功能模块。

(1) 菜品信息管理模块:用于对企业每日提供的菜品信息进行添加、删除、修改、查询。并能够根据提供的菜品组合出不同的套餐。

(2) 菜品信息发布模块:将每日午餐和晚餐提供的菜品和套餐发布至系统的Android客户端和Web端。

(3) 订单信息管理模块:对生成的用户订单信息进行添加、删除、修改和查询。

(4) Android客户端的人机交互模块:用于显示发布的菜品信息、用户个人设置信息等, 并将用户的订单和个人信息提交至Web服务器。

(5) Web服务器端的人机交互模块:用于显示和设置菜品信息、订单信息、人员信息等。

(6) 外卖配送模块:用于将不同的订单分配给合适地外卖配送员工。

4 总结与展望

本文设计的基于Android的餐饮外卖订单管理系统, 通过优化中小型餐饮企业的菜品发布、点单、订单确认和送货的流程, 提高中小型餐饮企业的效率和竞争力。在未来的工作中, 将会结合地理信息系统, 进一步提高外卖配送的效率。

摘要：本文设计与实现了一种基于Android的餐饮外卖订单管理系统。系统分为Android客户端、Web服务器端两部分。针对中小型餐饮企业的传统外卖订单模式存在的效率低、易出错的特点, 该系统通过优化中小型餐饮企业的菜品发布、点单、订单确认和送货的流程, 提高中小型餐饮企业的效率和竞争力。

关键词：Android系统,外卖,订单管理

参考文献

[1]余圣寅.关于餐饮小店外卖配送系统的优化[J].电子技术与软件工程, 2014 (11) :216-216.

[2]蔡奕彬, 陈智威, 杨沛钊等.基于Web Service的Android餐饮点菜系统的设计与实现[J].计算机与现代化, 2013 (04) :120-124.

[3]谢馨瑶, 李沈鑫, 毛炎等.基于Android系统的餐饮推荐系统的开发[J].硅谷, 2014 (03) :31-32.

[4]景鑫.基于Android的餐饮点单系统的设计与实现[J].电子商务, 2012 (05) :33-34.

[5]张志德.移动云计算之Android餐饮服务系统开发[J].科学技术与工程, 2012, 20 (3) :687-689.

[6]李宽.餐饮业Flash电子点餐系统的设计开发[J].价值工程, 2012, 31 (1) :155-155.

订单管理信息系统 篇7

关键词：Petri网,客户订单系统,工作流

随着3G时代的来临和电信市场的逐步开放与电信运营商之间的竞争日趋激烈, 为了在竞争中占领主动地位, 要求传统电信运营商面向新型信息需求, 丰富自身业务功能, 提供综合化、多元化的信息化实现手段, 从以提供语音业务为主向提供综合信息服务的方向转变。这是全球电信业发展的大趋势, 更是全新市场环境下电信业面临的机遇与挑战。

某省电信运营商从2000年开始开发业务流程计算机化的建设工作, 客户数量从2000年的900万, 增长到2008年的1 800万客户[1]。由于前期业务支撑系统建设都是面向生产、面向企业内部的, 并且多数系统的实施是在卖方市场情况下实施的, 从某种程度上来说, 已经不再适合以客户为中心的企业经营模式。

2 Petri网技术

Petri网技术最早是在1962年被CarlAdam Petri作为一种过程建模和分析的工具提出来的, 它是一种图形化描述过程的强有力的工具, 使用它可以直观地描述一个工作流过程[2]。Petri网有着严格的数学基础和表述方式, 同其他许多图表技术不同, 它是完全形式化的, 也正是因为这样, 我们才可能对被建模过程的性质进行准确的判断。目前针对Petri网的技术分析和工具已经得到广泛的发展[3]。

Petri网是对工作流的抽象表示, 也是对经营管理过程的抽象表示。Petri网管理建立阶段的主要功能是完成经营过程中的形式化定义, 也就是完成工作流的建模任务。

经典的Petri网是一个简单的过程模型, 由两种节点:库所 (Place) 和变迁 (Transition) , 及有向弧, 以及令牌 (Token) 组成的。我们用圆圈表示库所, 用矩形表示变迁, 用黑点表示令牌。两个库所或两个变迁之间不允许有弧, 只能是库所到变迁或者是变迁到库所。库所中可以拥有任意数量的令牌 (Token) 。

图1是一个简单的Petri网, 它由三个库所 (claim, under consideration, ready) 和三个变迁 (record, pay, send letter) 组成。这个Petri网是对保险索赔过程进行了建模, 当一个索赔达到库所claim时, 就首先被记录下来, 随后选择进行赔付或发信说明拒绝理由。

Petri网中的库所和变迁可以用有向弧连接, 如图1所示, 库所claim和变迁record被一个从前者指向后者的箭头连接。

变迁是Petri网中的主动因素, 通过实施变迁, 过程从一个状态转变到另一个状态, 因此变迁经常表示事件、操作、转换或传输等。库所是Petri网中的被动因素, 它们不能改变网的状态。库所经常表示媒介、缓冲器、地理位置、 (子) 状态、阶段或条件。令牌通常表示对象, 这些对象可能是具体的事物, 也可能是抽象的信息。Petri 网不光抽象了经典的过程模型, 并描述了完备的支撑过程调度的算法。

如果一个变迁的每个输入库所 (input place) 都拥有令牌, 该变迁即为被允许 (enable) 或就绪。一个变迁被允许时, 变迁将发生 (fire) , 输入库所 (input place) 的令牌被消耗, 同时为输出库所 (output place) 产生令牌[4]。

Petri网应用于工作流技术领域的主要优点有:

1) 、兼顾了严格语义和图形语言两个方面, 直观且易懂, 使建模人员能够比较方便地针对模型的含义与最终用户进行交流;

2) 、Petri网是一种基于状态的建模方法, 这种方法有更多的柔韧特性, 而这些特性对于工作流系统来说是必不可少的;

3) 、Petri网技术具有强有力的分析技术与手段, 利用一些成熟的Petri网仿真工具, 可以对同一过程的不同Petri网模型进行评价, 以便选择性能最优的一种来运行。

3 客户订单管理中的Petri网建模

电信客户订单管理系统需要实现电信自身商品的销售管理和SP商品销售的管理, 订单管理包含的处理环节可以抽象为客户身份认证、商品选择、号码选择、商品属性录入、支付计划确认、订单审核、收费、回单处理和竣工处理等多个环节。下面详细地讨论了如何利用Petri网对e8商品销售流程进行工作流建模。

3.1 e8商品的正常销售流程

e8商品的正常销售流程如下所示。

客户身份认证→商品选择→号码选择→商品属性录入→支付计划确认→订单审核→收费→回单处理→竣工。

图2是e8商品正常销售流程的Petri网工作流模型。

3.2 异常销售流程

在实际工作中, 如出现异常情况时则应按照异常流程运行。

(1) 回单处理时如提示所号码局向有错, 则执行如下的异常流程:

回单处理→重新号码选择→号码选择→后同正常流程。

(2) 回单处理时提示宽带速率无法满足, 执行如下的异常流程:

回单处理→重新商品属性录入→商品属性录入→后同正常流程。

图3为e8商品异常销售流程图。

4 结总及分析

某省电信基于Petri网的客户订单管理系统的建设是目前国内电信行业重点关注的项目之一。Petri网是一种具有强有力的分析技术, 它可以用来分析模型的各种特性, 如:安全性、活性 (不死锁) 等, 也可以用来分析计算模型的各项指标, 如占有率、响应时间等, 这些指标反映了电信企业经营过程中的各项数据, 可以为电信企业重组经营流程, 提高管理水平提供有力的支持。

本系统的设计在某省的实施中取得了预期的效果, 实现了真正意义上的全业务受理, 省内各县、地州电信都已经纳入了系统运行, 这说明将电信行业中的这些环节通过本管理系统以数字化的形式集中统一管理的可行性。此系统采用的架构方案亦有效地提高了软件系统的安全性、稳定性、健壮性, 提高了开发效率, 为系统的进一步发展以及其他类似软件系统的开发提供了借鉴作用。

参考文献

[1]马骏.中国电信业竞争分析.当代通信, 2003; (16) :49—53

[2]范玉顺.工作流管理技术基础, 北京:清华大学出版社, 2001

[3]袁崇义.Petri网原理与应用.北京:电子工业出版社, 2005

物流订单信息平台的分析与设计 篇8

物流业是系统服务性行业, 车辆资源是其重要的基础资源, 其中的大部分车辆资源集中于个体手中。为了更好的整合社会物流车辆资源, 充分将社会中个体和企业车辆投入物流运输中, 可以针对其建立物流订单的信息平台。托运人也可以扩大选择范围, 从该平台中选择适合的承运人。为保证信息的真实性, 平台将对托运人和承运人进行身份认证审核。

在本文中, 首先介绍该系统的需求, 然后对系统进行需求分析和系统设计, 结合UML相关图形, 建立面向对象分析设计模型, 其中详细说明系统的用例模型, 静态模型和数据库概念模型。

2 系统需求

(1) 托运人在需要发货时, 可以及时查看各类承运人的信息, 包括资质、联系方式、历史记录评价、车辆状态等信息, 便于快速对比选择和联系, 用最短的时间找到最合适的承运人。

(2) 承运人可以随时查看各类托运人发布的信息, 选择适合的订单联系托运人, 降低空车时间, 提高收入水平。

(3) 提供了对托运人和承运人真实身份的审核认证, 避免虚假信息, 保证交易双方的诚信。

(4) 访客在进行身份审核认证之前, 无法看到包含托运人和承运人联系方式的具体信息。

(5) 为交易双方提供评价机制, 建立评价档案, 既能约束双方高效优质的完成订单过程, 又可以为日后其他各方提供参考。

(6) 托运人和承运人之间订单交易中的资金由本平台的网站运营方托管, 保证双方不会因为资金原因无法完成订单。订单交易记录 (包括资金记录) 可以作为纠纷发生时的证据。

(7) 为保证运输安全, 对承运人收取一定的保证金, 保证金额可以由托运人指定, 在交易成功后退回, 保证金由本平台的网站运营方托管。

(8) 提供纠纷管理机制, 发生货运事故时, 双方可以提供货运事故记录等证据的扫描件, 由本平台的网站运营方进行协调处理, 最大限度的保证双方利益。

3 需求分析建模

(1) 用例模型

业务参与者包括系统管理员、承运人、托运人和访客。系统管理员是指整个网站系统的管理者。承运人是指使用汽车从事货物运输并与托运人订立货物运输合同的经营者。托运人是指与承运人订立货物运输合同的单位和个人。承运人和托运人均包括个体和企业两种类型。

系统管理员负责系统基础数据管理, 账号权限等系统管理, 对用户进行身份认证审核管理等。托运人和承运人均需要进行身份认证, 在审核通过后托运人才可以下托运订单, 承运人才可以接托运订单。承运人在托运人下订单后, 可以查看托运人信息, 承接适合的托运订单。托运人在托运人接订单后可以查看承运人信息, 选择适合的承运人。订单意向达成后, 托运人需委托系统进行运费托管, 承运人也需要向系统提交保证金。如运输过程中发生各类事故导致订单货物出现问题, 则双方进行货运事故处理。托运人确认订单标志订单完成, 双方可以进行评价。双方也可以对订单进行各类统计。访客无需进行身份认证, 可以直接浏览业务信息, 但无法查看包含托运人和承运人联系方式的完整信息。

可以使用业务用例图对整个系统进行业务分析建模, 如图1所示:

(2) 静态模型

从用例分析中提取系统相关的名词, 使用类图中的类进行描述, 分析类与类之间的关系, 使用关联、继承等关系连接两个类, 系统分析类图如图2所示:

4 系统设计

(1) 体系结构设计

采用领域驱动建模方法进行体系结构设计, Repository层实现对数据库的访问操作, Model层实现系统模型, Service层实现业务服务, 使用Web Service方法具体实现, Web UI层实现界面操作。

(2) 数据库设计

考虑静态类之间的关系, 按照以下原则进行数据库设计:

a.当关联关系中两个类之间为1:1关系时, 两个实体类合并为一张数据表, 比如人员信息和认证信息、居民身份证、账户之间的关系均为1:1, 所以合并为1张人员信息表 (Member) 。

b.当关联关系中两个实体类之间为1:n关系时, 两个类对应两张数据表, n方增加对1方的外键引用, 比如托运订单和托运订单明细之间的关系为1:n, 所以对应两张表, 即托运订单表 (Order) 和托运订单明细表 (Order Detail) , 托运订单明细表中增加Order ID属性关联托运订单表。

c.当关联关系中两个实体类之间为m:n关系时, 两个类对应三张数据表, 每个类对应一张表, 增加一张关系表, 比如权限和人员信息类 (人员信息与账户为1:1关系) 为m:n关系, 所以对应人员信息表 (Member) 和权限表 (Authority) , 再增加关系表Member Authority。

d.继承关系采用将父类和子类合并为一张数据表的方法, 比如企业信息 (父类) 和个体工商户 (子类) , 企业法人 (子类) 合并为一张企业信息表 (Enterprise) 。

使用E-R图对整个系统进行概念模型建模, 如图3所示。

5 结束语

本文运用面向对象的分析与设计方法, 分析设计了一个物流订单平台系统, 为同类系统的分析设计过程提供了参考, 具有一定的理论意义和现实价值。

摘要：物流订单信息平台旨在整合社会车辆资源, 帮助托运人和承运人之间建立物流订单相关的信息平台。本文介绍了该系统的需求内容, 使用UML用例图建立用例模型, 使用UML类图建立静态模型, 以描述系统的需求模型。在系统设计阶段, 设计了该系统的软件体系结构和数据库。

关键词：物流订单,OOAD UML

参考文献

[1] (英) 克里斯托弗著, 何明珂等译.物流与供应链管理 (第4版) .北京:电子工业出版社, 2012

[2]邵维忠, 杨芙清.面向对象的分析与设计.北京:清华大学出版社, 2013

[3] (英) 萨默维尔著, 程成等译.软件工程 (原书第9版) .北京:机械工业出版社, 2011

[4]谭云杰.大象——Thinking in UML (第二版) .北京:水利水电出版社, 2012