汽车检测系统_毕业论文.doc

汽车检修管理系统
第一章 可行性分析
1、1 问题描述
随着世界汽车产业格局的变化，我国汽车产业也迅速发展，汽车维修成为具潜力的行业，但汽车维修管理的规范化，网络化，智能化，使得必须建立起专业的汽车维修管理系统作为管理汽车维修方面的一系列问题成为了必不可少的。运用计算机来管理汽车维修的信息具有公正、严格和高效等诸多优点，从而取代了人工管理模式下由于各种原因出现管理漏洞的可能性，因而减少了工作人员的难度性，提高了工作效率。我们在现行系统初步调查的基础上提出了新系统目标，即新系统建立后所要求达到的运行指标，这是系统开发和评价的依据。
1.2 可行性分析研究
1.2.1 技术可行性
技术上的可行性分析主要分析现有技术条件能否顺利完成开发工作，硬、软件配置能否满足开发者需要等。目前大型汽车维修公司均建有局域网，并且采用PC机作为工作台，其容量、速度能满足系统要求。
根据客户提出的系统功能、性能及实现系统的各项约束条件，根据新系统目
标来衡量所需的技术是否具备，本系统是一个数据库管理和查询的系统，现有的技术以较为成熟，硬件、软件的性能要求、环境条件等各项条件良好，估计利用现有技术条件应完全可以达到该系统的功能目标。
1.2.2 经济可行性
因为通过网络管理汽车维修信息可以不受限制，因此可以节约许多的人力和物力，方便管理，由此可以减少不必要的开支，同时该系统可以提高维修管理的效率，即提高了维修站的经济效益，所以从经济上完全是可行的。
(1) 汽车维修公司有能力承担系统开发费用
开发新系统的工作是一项艰巨复杂的工作，它的投资主要是人力和物力的投资。对于本系统的开发者来说，其主要投资还是在人力和物力两个方面。如果是企业自己安排人手开发系统的话，其主要的投资还是在人力资源上，从系统的业务需求调查到系统的分析编码制作都是需要巨大的人力投入的。软件企业作为一个简短的高科技产业，其员工要求都比一般企业的要求要高，而且对系统开发及软件产业了解比较多，所以在自我开发管理系统的过程中，企业自己比较容易安排人手，这样就可以为企业节约大部分的额外开支。同时软件就其它产品来属于高端行业，无论是产品的价格还是质量都比较高，而经营产品的经销商或者是商家都要求有雄厚的资金支持。所以，在系统的开发过程中，企业完全有能力承担开发费用.
(2) 管理系统将带来经济效益
管理系统是一个信息化、智能化和先进管理理念的集合体。而管理是一个动态过程，在其运行过程中要采取多项措施。所以在管理中获得经济效益是一个综合效益，要对它进行直接定量的分析是比较困难的。一般新系统带来的经济效益是简洁的，其最主要的表现就是减少了企业管理费用和人力开支。而其它一些繁琐的事物都通过新系统来加以分析解决，不仅节省了大量的时间，还为企业的各项决策提供了宝贵的资料，为企业带来巨大的经济效益。
1.2.3 操作可行性
本系统采用基于Windows的图形用户界面，而该系统是大家熟悉的操作系统，对于那些有一般的计算机知识的人员就可以轻松上手。而整个汽车维修管理系统采用友好的交互界面，简洁明了，只需要对使用者进行简单的操作培训就可以使用本系统，来管理汽车的整个检修的流程。不需要对数据库进行深入的了解。
1.3 结论意见
综合以上三方面，无论是从技术上、经济上还是操作上，该系统都具有很高的开发可行性。系统基本上做到了在技术、经济、运行、法律上的可行，因此，相信在按照计划上实施的前提下，全系统的设计将会按时、高质量完成。所以，可以设计该系统的数据流程图，建立数据字典，开始开发系统。

第二章 项目开发计划

2.1 编写目的
经过可行性分析报告，得出项目可进一步进行下去的结论，在软件继续进一步的开发之前首先给出此软件项目计划。
2.2 项目背景
项目分析单位在接到项目分析员给出的项目可行性分析报告后，在本系统，即车辆维修管理系统开发主管部门的统一下制定用于软件实质开发的软件项目计划，以使软件开发单位理解软件开发要求，进行开发。
2.3 项目概述
1、工作内容
让计算机对车辆维修进行管理，用户可以直接在计算机上实现车辆检修的过程管理，在一定程度上实现信息化、自动化。
2、条件与限制
开发该软件的条件比较简单，以开发单位目前的经济与技术条件已完全具备开发的条件。该系统可在用户要求的期限内完成。
3、产品
1）软件
软件主要是完成之后的可执行文件，能够使用户方便的使用。
2）文档
文档内容包括：系统介绍，使用说明，测试计划及结果等。
4、验收标准
软件的验收标准完全由用户提出的软件需求制定，能保证软件的基本符合用户的要求。
2.4 项目开发计划
1、任务分解
分三个大的阶段进行开发第一阶段完成本系统的数据流图跟E-R图；第二阶段完成概要设计与详细设计；第三阶段书写文档。
2、预算
软件资金投入较少，具体预算分配简略。
3、关键问题
各模块之间的联系和后台数据库的完成。使用目前的设备与现有开发技术完全可以开发出该系统，总的来说该项目没有较大的技术难点与其他的一些风险因素。对于出现的一些小难点总都能得到解决。

第三章 需求分析
3.1 任务需求分析
总的来说，汽车维修管理软件需要满足一下需求：
(1)、该管理软件需要对进维修站的车辆的基本信息进行登记。
(2)、该管理软件需要对车辆的维修过程进行统计和管理。
(3)、该管理软件需要对车辆检修过程中消耗的材料配件进行登记。
(4)、该管理软件需要对车辆维修后所需支付的费用进行统计和计算
(6)、该管理软件需要对车辆维修完成后的出站管理进行登记
(7)、该管理软件需要能完成对车辆检修的过程，维修历史信息的一些综合查询
3.2 数据流图及实体联系图
3.2.1 数据流图
数据流图由四种基本的元素构成：数据流(Data Flow)，处理(Process)，数据存储和数据源（数据终点）。
数据流(Data Flow)：为具有名称且有流向的数据，用标有名称的箭头表示，一个数据可以是记录、组合项或基本项。
处理(Process)：表示对数据所进行的加工和变换，在图中用矩形框表示。指向处理数据流为该处理的输入数据，离开处理的数据为处理的输出数据。
数据存储：表示用文件方式或数据库形式所存储的数据，堆砌进行的存取分别以指向或离开数据存储的箭头表示。
数据源及数据终点：表示数据的来源或数据的去向，可以是一个组织或人员，它处于系统范围之外，所以又称它为外部实体，它是为了帮助理解系统界面而引入的，一般只出现在数据流图的起点和终点。
汽车维修管理系统的数据流图如下：
质检
不合格
合格
材料领料
结算
汽车检修
汽车进站

图 3-1数据流图
3.2.2 实体联系E-R图
根据对数据流图和数据字典分析，我们可以确定应用中的实体，属性和实体之间的关系，并画出如下的E-R图
汽车管理系统的E-R模型如图3-2：
进站管理
汽车编码
车主
进时间
明细表
审核
检修管理
开工时间
完工时间
合格
负责人
检次
类型
材料领料
汽车编码
科目
时间
申请人
付费管理
汽车编码
应付款
实付款
付款日期
操作人
出站管理
汽车编码
审核
日期
拿车人

图3-2 E-R图
系统E-R图说明：
1) 该E-R图只是介绍了每个模块的主要的属性，更加详细的介绍，请参照后面的系统详细设计
2） 材料领用中的一个明细表是说明该表还有一个更详细的明细介绍

第四章 系统概要设计
4.1 总体设计
通过这个阶段的工作将划分出组成系统的物理元素。
系统概要设计的基本目的是用比较抽象的概括方式确定系统如何完成预定的任务，也就是要确定系统的配置物理方案。软件结构设计时应该遵循的最主要的原理是模块独立，让模块彼此间的接口关系应该尽量简单。
4.2 系统功能模块图
可以根据模块独立原理对软件结构进行精化。为了合理的分解，得到尽可能高的内聚、尽可能松散的耦合，最终要的是，为了得到一个易于实现、易于测试和易于维护的软件结构，应该对模块进行再分解或合并。
本检修系统的模块图如4-1
汽车检修管理系统
综合 查询
进出管理
检修管理
结算管理
成本管理
库存管理
基础设置
系统维护
单车查询
月查询
汽车进站
汽车出站
检修过程
检修成本
材料领料
材料退票
材料出库
材料入库

图4-1系统的模块图
本系统一共包含以下几大模块：
1、综合查询
(1) 单车信息的查询
主要包括查询看这个车辆是否在本维修站，现在的检修状态，历史记录
(2) 月查询
查询本检修站一个月的业务情况
2、进出管理
(1) 汽车进站
填写汽车的进站信息
(2) 汽车出站
填写汽车的出站信息
3、汽车检修管理
(1) 汽车检修过程管理
汽车检修开，完工时间的记录，及主要负责人
4、结算管理
(1) 检修结算
对检修完成车的付费的管理
5、成本检修管理
(1) 材料领料
对检修的车办理材料领料
(2) 材料退票
6、库存管理
(1) 材料出库
(2) 材料入库
7、基础设置
(1) 员工维护
8、系统维护
(1) 数据库备份
(2) 程序升级，数据库升级
4.3 数据库概念设计
数据库一般分为三级模式：外模式、概念模式和内模式。外模式也就是不同用户所对的数据视图，它将数据库内部抽象的数据及其互相之间的关系表示为简单、直观的应用界面。概念模式是数据库中全部数据的逻辑结构和特征描述，通常以某种数据模型为基础。内模式是对数据的物理结构和存储方式的描述。
在这里将要设计的是数据库的概念模式，通过对车辆维修管理系统的内容和数据流程分析及E-R图，设计如下数据项和数据结构。（主要的业务表）
1) 汽车进站表(主键，单击ID，进车时间，汽车编号，车主，审核，审核人，审核日期，是否作废，作废人，作废日期，备注）
2) 汽车出站表(主键，进车主键，出车日期，提车人，审核日期，审核，审核人，作废，作废人，作废日期，备注）
3) 检修表(主键，进车主键，开工时间，完工时间，负责人，是否合格，检修检次，检修类型)
4) 结算表(主键，进车主键，应付款，实付款，付款日期，操作人)
5) 领料主表（主键，进车主键，单据ID,开单日期，申请人，操作人，审核，审核日期，审核人，作废，作废日期，作废人，科目，备注）
6) 领料明细表（主键，主表主键，物资编码，物资单价，物资单位，领用数量，审核人，审核，审核日期，作废，作废人，作废日期，备注）
4.4 数据库逻辑结构设计
在数据库设计中相当重要的一步就是将概念模型转化为计算机上DBMS所支持的数据模型，例如，将E-R图模型转化为关系模型，道理很简单，我们设计概念模型基本上都是一些抽象的关系，在再数据库设计的实现过程中，在计算机上有效地表示出这些关系就成了数据库设计的关键，根据机车检修系统的功能要求，选取了oracle9i做为后台的数据库
在上面的实体和实体之间的E-R图设计的基础上，形成数据库中的表及表结构之间的关系下列图：
1、进车表结构：（by_car_come）

图4-2
其中关键字段介绍：
Pk_id ：本表的主键生成是根据oracle提供的sys_guid（）函数生成的一个长度为32位的唯一标示，它所担当的功能除了是本表的唯一主键外，它还是其他业务表中的外键，其它业务表中都记着这个字段，通过这个字段来解决的问题是当同一个车辆在不同次的检修时能进行区分，
2、检修表结构：（by_car_repair）

图4-3
其中关键字段介绍：
Come_pkid：进车表的主键，通过它实现检修表和进车表的关联；Is_verify： 通过它来来确定这次检修的车是否是合格的；Repair_type：检修类型，主要是来用来区分本次检修的车是否需要付费，它主要取一下的值：(检修，返修，其他)，这三种类型的值,当检修类型是检修时则需要正常付费，当它取值为 返修，其他时则它的这次检修可能是本检修站造成的不需要支付本次的检修费用。
3，材料领料表：（by_car_op_outdepot）

图4-4
其中关键字段介绍：
Come_pkid：是进车表的主键，记这个字段的主要目的是能区分同一车牌号的车辆在本检修站的多次维修问题。
O_id_apply：申请人字段，这个字段主要用来以后和这个人在本检修站的工作表现以及评优，工资，奖金等相关联。
Subject_id ：科目这个字段主要在财务上用来区分维修站在一个月，或季度中在不同方面的材料支出，现在它的取值有：检修，售后，其他。
4，材料领料明细表：（by_car_op_outdepot_ list）

图4-5
其中关键字段介绍：
Materal_price：物资单价，因为本系统是一个维修管理系统，而本系统需要在一次检修完成时，就要统计本次检修所需要的费用，所以该单价记录的是检修当时所用材料的单价，而不是采用的当检修完成付费时在计算该物资在库存中的数量，这样的好处是能更准确反映该车辆在当时检修是所耗用的费用，而不是按现在的库存单价，这样也更能赢的客户的满意，提高自己检修站的声誉，从而产生更好的效益。
Material_uit：物资单位，这也是一个需要详细设计的字段，因为本系统在算车辆在本次检修的费用时，就是统计的本表中所领用的消耗材料的费用，这个字段所可能遇到问题是：比如该物品在采购时使用的单位是百个（或者是盒），而在领用的过程中所按的单位是个，在这样两次操作过程中假如数量列都是 1，而采购时单位是百个，这样总数量就是100个，而在领用时单位是个，总数量就是1个，这样一来总金额就产生了很大的差别，数据库中的数据就不能保证完整性，所以在本系统中所给出的解决方案是单位同一，都用个，这样在后台中处理数量则就能避免这样的问题。这中问题隐蔽性很强不易被发现，所以在设计工程中要时刻注意这种问题。
Main_pkid：和主表的关联外键。
5，付款表（by_car_pay）

图4-6
其中关键字段介绍
Come_pkid：解决重复问题
S_pay：在实际当中客户所支付的材料消耗费用一般情况下跟实际消耗的材料费用是不相等的，所以这里记下了客户所支付的金额。
6，库存表（by_car_mateial_kc）

图4-7
这里只是列举了一个简单的库存表，主要目的是来阐述一下，库存表中到底是数量，金额，还是记录数量，单价。本系统采用的是前者，也推荐采用前者，下面来做一个简单的介绍
一般的仓库表中都要涉及到的三个字段就是，数量，金额，单价。而且存在这样的等式关系：金额 = 数量*单价。在数据库设计中是没有必要这三列都存储的可以根据其中的两个来计算第三者，（实际中数量必选，在金额和单价之间选择）但是当你选择在数据库中存储单价时就可能产生很多问题，比说当你选择存储单价，小数位留几位的问题，一般觉得留2位就够了，可是在实际中涉及到的物资的单位可能有很多种，比如说库存中单位有是吨（t），而也有单位是克（g）的，这种情况下单价的小数位如果只有两位那么这两着的总金额可能就会产生很大的区别，你可能会用增加单价的小数位来解决这个问题，可是库存中还有很多其他的物资的，他们的单位不可能用到很多位，这样一来数据库中将会产生很多的一列不好读懂的数据，而且处理起来也会引起很多的问题。所以我们将在库存中存，数量和金额，在我领用材料时，我们来计算该物资的平均单价，当办理材料出库时，我们分别来更新金额和数量，这样长时间的平均下来我们库存中的材料价额也能反映现在市场上这种物资的价格走势。所以在本系统中存储的是数量和总金额
7，出车登记表（by_car_out）

图4-8
其中关键字段介绍：
Out_Date：记录该车这次检修出维修站的时间，好用来统计该车的总的检修时间以及该维修站的工作效率
4.5 连接数据库的特点
当开发环境通过连接到数据库上之后，在设计中使用数据库画笔可实现对该数据库中表格，视图等的操作，如创建表,修改表，删除表，增加/删除记录。
设计中设计数据窗口的时候，通过对话框实现与数据的连接。在应用程序中
则一般是在应用程序对象中书写连接数据库的程序代码，使得应用程序开始运行并实现与数据库的连接

第五章 程序详细设计

详细设计阶段的根本目标是确定应该如何具体地实现所要求的系统，包括了用户界面设计、程序过程设计等步骤。
5.1 系统的设计和开发环境
操作系统：WindowsXP。
数据库系统：oracle9i
开发工具：PowerBuilder10.5
PowerBuilder是著名的数据库应用开发工具生产厂商Sybase Inc.的子公司PowerSoft于 1991年6月推出的数据库应用开发工具 .PowerBuilder除了能够设计传统的高性能、基于客户/服务器（Client/Server）体系结构的应用系统外，也能够方便地构建和实现分布式系统，还可以开发基于Internet的应用系统。
PowerBuilder采用了面向对象和可视化技术，提供可视化的应用开发环境，使得我们利用PowerBuilder，可以方便快捷地开发出利用后台服务器中的数据和数据库管理系统的数据库应用程序。用PowerBuilder不仅能够开发客户端应用程序，而且还可以轻而易举地构造应用服务器，从而形成分布式应用。PowerBuilder支持多种平台，并能生成机器代码的可执行文件
5.2 用户界面设计
5.2.1 一般交互设计
一般交互涉及信息显示、数据输入、和系统整体控制等方面。
1、一致性
为客户交互界面中的菜单选择、命令输入、数据显示以及众多的其他功能，使用一致的格式。在设计的过程中，基本上保持了系统的格式一致。
2 、行有较大影响的操作前提示用户确认
在设计过程中，如果用户要执行作废操作，以及对数据库的读写操作时，都会有窗体弹出询问继续操作或者予以提示
3、减少操作间需要记忆的内容
为了避免用户为下一步操作而记忆大量数据，所以在设计过程中在需要数据传递的窗体中设置结构变量，来传递数据。
4、允许错误
允许用户的误操作尽量不对系统造成伤害
5.2.2 信息显示设计
应当尽量为用户提供的界面显示时完整的、明确的和容易理解的。这样才能满足用户的需求。使用不同的方式显示信息：用文字、图形、颜色和符号等方式传达信息。
1、只显示与当前工作有关的信息
在用户操作有关系统的特定功能的信息时，不必看到与之无关的数据、菜单和图形。
2、使用便于用户迅速吸收数据的方式来表示数据
在系统设计的过程中，较多地使用了图表的形式表示数据，例如在分析中就使用了折线图形式表现了复杂的数据。这样，用户可以直观的体会到图表所表示的含义。
3、使用一致的标记、标准的缩写和可预知的颜色
为了使系统所表达的含义准确、无误，就必须适用一致的标记、标准的缩写和可以预知的缩写，这样用户就无需参照其他信息源就能理解，而正确地适用软件。
5.2.3 输入界面设计
用户的大部分时间用在选择菜单命令、键入数据和向系统提供输入。在系统中，键盘是主要的输入介质，因此我们要做到保证显示信息和数据输入的数据之间的一致性，尽量少的改变程序界面的风格，
5.3 系统的主要功能及实现
根据上面的需求分析，设计好数据库系统，然后开发应用程序可以考虑的窗体的系统，每一个窗体实现不同的功能，可以设计下面的几个模块。
5.3.1 进出管理
汽车进站：
功能：本模块的主要功能是对进入维修站的车辆管理登记，包括对新来的车辆进行添加，作废，导出，打印。
具体实现：当有新的维修车辆进入维修站时，需要办理添加，车牌号，车主等信息
汽车进站按钮在主界面的位置

图5-1
点击这个按钮后可以看到该菜单下的两个主要的模块，汽车进站和出站，点击进站可以看到如下的界面

系统的默认时间段

图5-2
在打开主界面时系统会有一个默认的时间，一般是本月的一号到系统的当前时间，系统会将在这个时间段内的数据通过左侧的数据窗口对象将数据过滤出来，呈现到用户的界面前，数据有三种颜色，灰色-数据未审核，蓝色-数据已审核，红色-数据已作废，不同颜色的实现是通过动态获得数据窗口对象字段的取值，根据不同的取值来显示字体的不同颜色。
当点击添加时，系统会弹出新的进车添加窗口
保存时生成
审核提示

图5-3
在这里面进行汽车进站的添加、修改、等操作。
单据ID在新界面打开时是不会赋值的，当确定添加的保存时才会生成，这样做的好处就是避免了同时操作数据库时生成相同的单据号，能更好的减少程序的并发执行，保存时执行了数据窗口的update语句，同时更改数据窗口为只读属性dw_1.Modify("DataWindow.readonly=yes")，
对于保存成功的单据就可以进行审核操作了，通过sql的update语句将刚才更新到数据库记录的审核标记更改为已审核，同时执行数据存储过程
DECLARE lp_pro PROCEDURE FOR pkg_carout.in_carout(:ls_guid,:ls_carcode)；
EXECUTE lp_pro；向出车表里面添加数据，更新出车表。
审核时同时操作了数据库里面的两张表，只有当这两个表的更新都成功执行后
我们才能执行commit；语句，将所有的数据一次性的全部提交到数据库中，当当者有一个更新没有成功时，我们都要对数据操作进行rollback操作，提示用户操作失败，只有这样我们才能保证数据库中的数据完整的。
当审核后下面的审核提示就会显示，当我们退出这个界面时我们就会在主界面中看到我们添加的数据。

新添加的数据行

图5-4
因为系统是按进车日期降序排列的，所以我们新添加的数据会显示在第一行，由于数据窗口是继承孙老师的数据窗口控件，支持点击数据窗口表头进行排序。
查询按钮
查询条件随意组合
当点击是系统就会按照左侧的查询条件进行随意的组合快速的找到我们需要的，
图5-5
单据，我们就可以对单据进行修改了。
这里主要用到了PB里面通过ls_original_select = dw_1.GetSQLSelect( )动态的获得数据窗口对象的where条件，通过新添加的条件我们可以修改where条件，在将我们新生成的where条件和select语句关联再用dw_1.SetSQLSelect(ls_select)语句将数据窗口中的数据进行重新提取。
汽车出站：
前提条件：已办理结算付款
功能：对将要离开本检修站的车辆提车人和出车时间进行登记
出车管理主界面：
双击该行
组合查询条件

图5-6
同样我可以根据左侧的查询条件快速找到我们需要办理出车登记的车辆，双击该行时会打开新的窗口

图5-7
这个窗口我们使用freeform格式的数据窗口对象，根据双击事件中的脚本OpenWithParm(w_car_comeadd_read,ls_guid)的guid参数，我们使用带参数的数据窗口提取数据找到我们需要的数据，我们就可以添加数据项，保存时用数据窗口的update语句，将我们更改的数据 更新到数据库中。审核后根据得到值将字体的颜色改变：if( is_verify ='1',rgb(0,0,255),if( is_destory='1', rgb(255,0,0), rgb(0,0,0) ))
退出后刷新主数据窗口将我们的数据提取到界面供用户查看， 对于审核后的数据我们不能再进行修改了。
5.3.2 汽车检修管理
检修过程
前提条件：已办理进车登记，并审核
功能：主要对车辆检修过程中，开工，完工，检修类型，汽车主要故障录入，数据的导出，打印等。
条件快速找到

图5-8
左侧数据窗口检索数据的条件是车辆已经进站并且已经审核。单击需要的车辆后我们可以在右侧的数据窗口中显示我们需要的检修车辆的信息。
在这里面我们需要输入的开工的日期和完工的日期，这两个在系统中我们使用的是pb中提供的日期控件，这样我们能减少用户的输入，从而能减少用户输入数据时产生的错误。
当我们点击开工时系统会提示是否将开工时间设定为输入的值，因为我们现在定义数据库时有一个字段标记了是否开工，当填入数据保存后系统不再提供修改本时间的窗口，所以该时间需要用户谨慎填写。点击开工后调用数据窗口的update语句更新数据。
当车辆修竣完成时，需要填写的信息主要有本次检修类型，本次检修故障，在设计填写检修故障时考虑到用户输入数据习惯点击这个按钮。
这里

图5-9
系统会弹出新的故障录入界面如下
录入故障

图5-10
从这里我们可以很方便的录入本次检修车辆的故障，单击确定后系统将文本传回数据窗口对应的行。
录入完成后可以点击完工，调用数据窗口的update语句更新检修表同时执行存储过程：
If (ll_rtnm = 1) THEN
dw_2.Object.end_flag[ll_row] = '1'
If (1 = dw_2.Update()) THEN
String ls_guid,ls_carcode
ls_guid = dw_2.Object.PK_ID[ll_row]
ls_carcode = dw_2.Object.CAR_CODE[ll_row]
DECLARE lp_pro PROCEDURE FOR pkg_carrepair.UP_CARREPAIR(:ls_guid,:ls_carcode);
EXECUTE lp_pro;
COMMIT;
……
这里完工时再次更新了多张数据库中的表，所采用的机制还是当所有的更新数据库的语句全部执行成功后，在一次性提交全部数据，当有一条语句没有更新成功时，所有的更新语句全部rollback；这样来保证数据库中数据的完整性。

5.3.3 检修成本管理
材料领料：
前提条件：已检修开工，并且没有检修完成
功能：对正在检修的车辆进行检修领料，审核，作废，导出，打印。
通过主界面选择检修成本管理后，
系统默认时间

图5-11
材料领料主要是对在修机车所领用的材料进行的统计，当打开主界面时右侧的数据窗口将会过滤出领料时间在这段时间内的数据供用户查看，也可以更改右侧的查询条件，如：单据编号，汽车编码这两个条件都是包含当所输入的内容是配包含在数据中时，会检索出数据来，审核是被审核的单据将被检索出来，作废是作废的单据将会被检索出，
保存产生
当点击添加按钮时，将打开新的添加界面如下

图5-12
单据ID、新打开的窗口不会得到单据ID，只有在保存时才会产生新的单据ID这样能最大限度的避免同时操作产生相同的单据号。
汽车编码、这一列所用的是一个下拉的数据窗口对象，而这个子数据窗口对象得到数据的条件是车辆已经开工，并且还未完工，从而这样能更好的控制材料的领料，保证了材料的领用时有控制的，并且也能及时的得到正在检修的车辆，而不会影响维修站的工作效率。
科目、这一列用的也是下拉数据窗口对象，这样在财务部门改变了财务的支出科目时能及时的得到反映，从而能正确的统计维修站各项的费用支出，
开票人、申请人，这两列用的也是下拉数据窗口对象，并且是通过pb提供的操作数据源的改变到数据源但中

图5-13
这样做的好处是在以后也需要用到人员时，直接在编辑格式里面选择即可，方便以后编写程序。
领料记录框，当选择了车号时，选中这个复选框时，动态的获得明细数据窗口的位置和大小，同时改变它的位置和大小，使历史记录的数据窗口显示出来。
通过

图5-14
三种检索方式一种快速的找到需要办理领料的材料，双击该材料将添加到领料明细表里面的这里需要处理的一种情况是在同一个数据窗口中不能有相同的物资出现在不同行，因为这样只能有一条数据被更新到数据库中，解决办法，在同一张出料明细上不允许有相同物资占用不同的行，加上如下的判断：
IF dw_2.Find("material_code = '"+ls_material_code+"'",1,ll_rowcount) <= 0 THEN
……
ll_price=wf_calc_price(LL_MATERIAL_AMOUNT,LL_MATERIAL_ZJE)
if (ll_price<=0) then ll_price = 0
//填写信息
……
END IF
这里保存的时候同样的处理的多张数据，同样当所有的更新数据全部的成功执行后才进行一次提交，否则提示用户失败，全部回滚数据不对数据库进行任何的更新。
5.3.4 结算管理
检修结算
前提条件：已检修完成
功能：对已完成检修的车辆办理检修结算
单击主界面的结算管理打开界面如下：
检索条件

图5-15
左侧的数据窗口对象在打开时会将已经检修完成，还没有进行结算管理的车辆过滤出来，通过条件检索出需要办理结算的车辆，双击以后会将车辆的基本信息填写到相应的位置，有些信息是只允许查看的，将他们的属性设置成只读的。
其中得到本次检修所消耗的材料的sql为
SELECT S.DJ_ID,
S.MATERIAL_CODE,
S.MATERIAL_PRICE,
S.MATERIAL_AMOUNT,
S.MATERIAL_UNIT,
M.MATERIAL_NAME,
N.CK,
M.MATERIAL_STAND
FROM BY_CAR_OP_OUTDEPOT_LIST S, BY_CAR_MATERIAL M, BY_CAR_MATERIAL_KC N
WHERE S.MAIN_PKID IN
(SELECT T.PK_ID
FROM BY_CAR_OP_OUTDEPOT T
WHERE T.COME_PKID = :as_comepkid)
AND S.MATERIAL_CODE = M.MATERIAL_CODE
AND S.MATERIAL_CODE = N.MATERIAL_CODE
AND N.CK = '20'
统计出车辆本次检修所用消耗材料的费用。结算后将数据保存到结算表
5.3.5 综合查询
单车查询
功能：根据给出的车辆编号查询该车是否有在本站检修历史，和是否是在修车，如果是在修车则当前的检修状态
单车查旬界面：

图5-16
这个界面设计的主要目的是当有客户来维修站查询车辆的一些信息时就可以通过输入车号来查询，首先判断的是车辆是否在本维修站有过记录，没有则提示用户，如果在本站有记录，则判断该车辆是否是在修机车，如果是则判断该车目前的具体检修状态，在相应位置做标记如：

图5-17
从而能及时的反馈给客户车辆的最新状态，否则显示车辆在本站以前的检修记录。
月查询
功能：根据给出的月查询该月的检修车辆数
5.3.6 导出和打印
1、导出
系统中多出用到了导出功能，其实现主要用的同样的技术相同，其的实现部分代码如下：
/存入Excel
integer filevalue,li_Ret
string filepath,filename
OLEObject xlApp,xlSub
Long ll_r_count //行数
dec ll_j
any ls_dat
String ls_path
ls_path=GetCurrentDirectory( ) //当前目录
filevalue = GetFileSaveName("保存文件", &
+ filepath, filename, "Excel", + "Excel Files (*.xls),*.xls" )
ChangeDirectory(ls_path) //还原目录
//adw_1 = idw_1
if filevalue<>1 then return
if FileExists (filepath) then
if MessageBox("确认选择","文件已存在,覆盖吗?",Question!,YesNo! )<>1 then
return
end if
end if
// 创建OLE对象
xlApp = CREATE OLEObject
// 连接Excel
li_Ret = xlApp.ConnectToNewObject( "Excel.Application" )
IF li_Ret < 0 THEN
MessageBox("系统提示","连接Excel出错,不能正常存取!")
RETURN
END IF
xlApp.Application.Workbooks.Add()
xlSub = xlApp.Application.ActiveWorkbook.Worksheets[1]
dec j,columncount ,ll_k,ll_cnum
string ls_colname[],ls_label[],ls_type,ls_obj[]
ll_cnum =dec(dw_1.Object.DataWindow.Column.Count)
// 将列名转化为中文名称，即标题头名称
for j = 1 to ll_cnum
ls_obj[j] = dw_1.describe("#"+string(j)+".name")
ls_label[j] = dw_1.describe(ls_obj[j]+"_t"+".text")
next
//添加列标题
FOR ll_j = 1 TO ll_cnum
xlSub.cells[1,ll_j] = ls_label[ll_j]
NEXT
//添加数据内容
ll_r_count=idw_1.rowcount()
for ll_k = 1 TO ll_cnum
ls_type=idw_1.Describe(ls_obj[ll_k]+ ".ColType" )
CHOOSE CASE Left(ls_type,4)
CASE "char"
for ll_j=1 to ll_r_count
ls_dat=dw_1.GetItemString( ll_j, ls_obj[ll_k])
xlSub.cells[ll_j+1,ll_k]=ls_dat
next
CASE "date"
for ll_j=1 to ll_r_count
ls_dat=idw_1.GetItemDatetime( ll_j, ls_obj[ll_k])
xlSub.cells[ll_j+1,ll_k]=ls_dat
next
CASE ELSE
for ll_j=1 to ll_r_count
ls_dat=dw_1.GetItemNumber( ll_j, ls_obj[ll_k])
xlSub.cells[ll_j+1,ll_k]=ls_dat
next
END CHOOSE
next
xlApp.ActiveSheet.Columns("A:Z")