全国营销管理信息系统详细设计报告

全国营销管理信息系统详细设计报告TOC\o"1-3"1 前言 31.1 设计目标 31.1.1 总体目标 31.1.2 本期目标 31.2 采取的策略 31.3 设计依据 32 摘要 43 营销治理分系统详细设计 43.1 营销治理分系统详细需求分析 43.1.1 功能详细需求分析 43.1.2 性能详细需求分析 93.1.3 信息详细需求分析 103.2 营销治理分系统功能模型 123.3 营销治理分系统子系统和功能模块划分 153.4 分系统界面设计 243.4.1 外部界面设计 243.4.2 用户界面设计 244 数据库系统设计 264.1 设计要求 264.2 信息模型设计 264.2.1 信息模型设计使用的符号讲明 264.2.2 信息模型设计 284.3 数据库设计 284.3.1 数据访咨询频度和流量 284.3.2 数据库选型 284.3.3 异构数据库的连接与数据传递方式 294.3.4 数据安全性及保密性设计 304.3.5 数据字典设计 305 网络通信系统设计 315.1 设计要求 315.2 网络设计方案 316 信息编码设计 327 关键技术 377.1 提升查询速度 377.2 保证系统安全 397.3 数据一致性及安全 408 系统配置 408.1 运算机硬件与网络配置 408.2 数据库及软件配置 409 限制 409.1 VAX机的WWW服务器 409.2 通讯线路的选择 419.3 数据库在线容量的限制 419.4 数据库主机的选择 4110 组织机构及人员配置 4111 工程实施打算 4111.1 实施内容与进度打算 4111.2 测试及验收 4212 参考和引用资料 4213 附录 4213.1 附录1公司集团营销治理系统功能模型 4213.2 附录2公司集团营销治理系统信息模型 4213.3 附录3公司集团营销治理系统实体属性表 42公司-CIMS营销治理分系统详细设计报告前言营销治理分系统是公司集团CIMS工程（公司-CIMS）中的一个应用分系统。营销治理分系统涉及到冰箱、空调等产品的销售和售后业务治理工作。营销治理分系统设计按照公司集团的总体进展目标，以及公司集团CIMS工程的总体要求，在对企业现有状况进行广泛调研的基础上提出。营销治理分系统的详细设计与实现工作，由公司集团CIMS工程技术依靠单位之一的项目组承担。设计目标总体目标建立覆盖国内各中心/办事处的运算机网络系统。建立既能满足公司目前销售治理模式的需要，又能在一定程度上习惯公司集团进展变化需要的网络化、分布式公司集团营销治理系统。达到增强公司集团开拓国内外市场(第一是国内市场)的系统整体支持能力的目的。本期目标建立集团公司营销治理系统在网络环境的支撑下建立分布式数据库系统和营销治理系统。提供对仓库治理、销售治理和产品销售过程的跟踪治理能力；实现仓库治理（包括成品仓、中转仓和售后仓）、销售治理、售后服务治理、财务治理的集成；实现市场营销过程治理与售后服务治理的功能与信息集成；借助营销系统网络加速市场信息收集整理。建立1-2个省级中心/办事处营销治理系统并实现与集团公司的互连。采取的策略在软件工程生命周期法的大框架下，利用快速原型法进行营销治理系统软件的开发。使用功能模型设计工具（BPwin）和信息模型设计工具（ERwin）进行系统的详细设计，既能够保证设计工作的规范性，又能够提升详细设计工作的效率。采纳扫瞄器/服务器模式和面向对象的程序设计方法，确保系统的可靠性和先进性。严格的模块测试和集成测试，为系统正确性提供保证。设计依据公司集团CIMS工程联合设计组，公司集团CIMS工程初步设计报告，1998。李伯虎，运算机集成制造系统（CIMS）约定、标准与实施指南，兵器工业出版社，1994。摘要营销治理分系统详细设计报告，在系统需求分析和初步设计的基础上，对系统的功能、性能和信息等方面进行了更详细的需求分析。在此基础上，建立了营销治理分系统功能模型、信息模型数据库系统，对数据库系统、网络通信系统以及信息编码等做了详细设计。提出了营销治理系统开发实施中的各项关键技术，并对可能的限制条件进行了分析。营销治理分系统详细设计营销治理分系统详细需求分析为了能够深入细致的开展营销治理分系统的详细需求分析工作，由项目组研究开发人员和企管部电脑科技术人员共同组成了四个详细调查与设计小组，按照公司集团现有销售业务划分和治理模式分别对冰箱公司和空调公司的销售业务和售后业务进行了详细调查了解。对冰箱公司和空调公司各自业务的深入了解，有助于对公司集团整体业务特点的归纳。因此，对系统的详细需求分析亦按照现有销售业务划分和治理模式进行分别描述。公司集团的销售及售后业务处理工作目前差不多上集中在公司总部完成。公司集团的RSR系统为销售和售后工作提供了部分支持功能。由于系统环境从集中式向分布式的迁移，因此RSR系统也要随之更换。新系统既要完成RSR系统中的功能，又要对其进行改进和补充以习惯新的系统环境和新的销售与售后业务处理流程，使销售和售后服务治理工作提升到更高的新水平。功能详细需求分析冰箱销售部分功能详细需求分析在CIMS环境下，冰箱销售部分要实现（公司）冰箱公司的销售治理信息的集成及实时处理，要求准确、快速地提供打算、运输、库存以及财务等信息，要求及时地对冰箱销售业务进行处理。它包括打算治理、发运治理、仓库治理、综合治理和财务治理五个部分。打算治理打算治理要紧负责对各地分公司上报的分公司进、销、存表进行统计分析，制定出（三个月）滚动打算；按照分公司上报的商业单位的发货申请单制定动身货打算，之后再按照实际运输中的发运打算执行表实装数修改发货打算，形成实际的发货打算；按照发货打算以及商业单位的货款情形开（正）调拨单，按照审批后的退货单据开（负）调拨单，此外还要按照（售后的）的调换新机发货审领单开调拨单，在开调拨单时，还要考虑到冰箱销售业务本身对灵活性和习惯性的要求，因此要同时考虑对“先款后货”和“先货后款”这两种方式的处理；按照商业单位的货款回笼情形和公司既定的业绩运算方法对各商业单位的业绩进行评判，运算出商业返利；在必要时按照实际需要制定出调仓打算，开调仓单给各仓库，在各仓库之间调剂余缺。发运治理发运治理要紧负责按照审核后的发货申请单进行打算划分（铁路或汽车运输），分别制定出铁路发运打算表和汽车发运打算执行表；关于汽运采取“先发货后开单”的方式，先由车队到仓库提货，再按照实装情形开调拨单，当车队将物资送达，返回经商业单位签收的发货证明单回执，再进行核对入帐；对铁路运输采取“先开单后发货”的方式，先开出调拨单，由车队从仓库提货送至火车站装车发运，如果发生掉装的情形，还要将掉装的物资送回仓库，并将掉装凭证返回，以重新开调拨单；同时还要按照实际的发运情形进行运输费用及保险费用的核算。仓库治理仓库治理要紧负责成品仓和各地中转仓的治理，治理下线冰箱入库和铁路运输中的掉装入库，按照发货证明单的销售出库和按照调仓单的调仓出库，以及成品仓的帐务和实物治理；治理各地中转仓的调仓入库和退货入库，销售出库和各地售后服务中心所需的三包箱出库，以及中转仓的帐务治理和费用治理。综合治理综合治理要紧负责广告费及外部人职员资的审核，冰箱区域流向信息的治理，以及进行必要的统计汇总工作。财务治理财务治理要紧负责按照调拨单和其它发货单据开销售发票；按照销售发票的使用情形生成发票销存表（及数据文件）报税务局；按照各种原始单据生成凭证，包括按照销售发票生成销售凭证，按照银行来款证明生成来款凭证，按照返销发票生成返销凭证，按照折让单生成折让凭证，还有按照其它调整的需要生成的调整凭证（无对应原始单据）；对各种凭证及原始单据记帐，形成一、二级总帐和单位明细帐；对各级帐和发货登记表、发货单据以及仓库进、销、存汇总表进行统计分析形成帐龄分析表等各种财务统计报表。冰箱售后部分功能详细需求分析冰箱售后部分实现对冰箱售后服务的治理功能，冰箱售后业务的性质决定了冰箱售后治理将是一个由省级用户服务中心的售后服务治理与公司集团冰箱用户服务部的售后服务治理共同组成的治理系统。冰箱售后工作包括：修理费用结算治理、用户信访治理、物料治理、质量反馈及分析和中心/网点信息治理等五部分。修理费用结算治理修理费用结算治理模块应完成如下功能：各省级用户服务中心录入修理凭证，并进行运算机审核和生成本中心（包括下属网点）的月份费用汇总表；各中心把通过审核的修理凭证数据通过远程运算机网络传送到公司公司总部；用户服务部对各中心传来的数据进一步审核，对不符合审核条件的记录要显示出来以便人工处理，将审核后合格的修理凭证对不同的修理网点分类别进行费用汇总，打印结算通知单；用户服务部给修理网点支付结算费用后，可在系统中做核销标记；按中心/修理网点编码、日期范畴、冰箱型号、机身编码、故障编码和分厂等各种条件进行修理记录凭证查询、故障统计、更换零配件统计、修理费用统计。用户信访治理用户信访治理模块应完成用户来信、电话和投诉的录入和修改，用户档案查询，信访信息统计，信访服务质量统计，信访重大投诉统计；修理后用户访咨询表和咨询卷的录入和修改，用户访咨询表统计，用户访咨询表咨询卷部分的统计。物料治理物料治理模块应包括零配件治理和三包成品箱治理。零配件治理应完成用户服务部、中心、网点三级配件仓治理，在中心建立本中心及其下属各网点的配件帐，用户服务部建立售后配件仓的配件帐，用户服务部可查询各中心和各网点的配件帐，同时，用户服务部和各中心将分别完成配件的入/出库治理；各级零配件申领治理，应包括各级申领单的录入，查询零配件库存量，通过运算机远程网络传送申领单、发运单、实收信息等；调换、非调换类零配件三包耗用治理，应由各中心录入的修理记录凭证的更换配件信息中统计出各网点的调换、非调换类零配件三包耗用，分别生成汇总表，关于非调换类零配件三包耗用，经审核后由售后仓为各中心作冲帐，关于调换类零配件三包耗用，等相应的旧件退回后，由售后仓为各中心作冲帐；三包外零配件耗用治理，售后仓按照各中心录入系统的三包外零配件耗用汇总表为各中心作冲帐。三包成品箱治理应完成用户服务部成品仓和各中心成品仓的治理，用户服务部和各中心分别建立新旧成品箱帐，分别治理本成品仓的入/出库，用户服务部应可查询各中心成品仓的帐目；用户服务部向销售部借领成品箱和各中心申领成品箱的治理，应包括借据凭证或申领单的录入，查询成品箱库存量，通过运算机远程网络传送申领单、实收信息等；处理、报废箱的治理，应完成对报废周转箱、毁损箱和专门故障箱的冲帐，对沉淀箱、退换箱和运损箱销售后的汇总、冲帐。质量反馈及分析质量反馈及分析模块应完成各种质量信息的统计，包括质量反馈信息表，各类故障统计表，各类故障冰箱修理量统计表，A类件修理故障分类统计表。中心/网点信息治理中心/网点信息治理模块应完成建立中心/网点台帐，对中心/网点信息的统计，包括资产配置统计，学习培训统计，财务费用的统计，人事档案统计，工资统计等，以及中心/网点信息编码的爱护。空调销售部分功能详细需求分析在公司公司营销系统中，空调销售部分实现对空调销售业务各方面的治理，包括销售业务治理、仓库治理、销售财务治理和销售综合治理等。它不仅提供对销售日常业务的支持，还为各部门提供治理信息和辅助决策手段。由于销售业务受市场状况、治理决策等诸多因素的阻碍，空调销售部分对销售业务已有的和可能有的各种情形都给予了考虑，尽量满足销售业务对灵活性、习惯性的较高要求。例如，发货治理不仅要考虑目前采纳的先款后货方式发货治理，还要考虑今后可能使用的先货后款方式发货治理。销售业务治理销售业务治理销售业务治理包括发货治理，处理机、三包机销售治理，调仓治理，已付款机退货治理和未付款机退货治理。其中，发货治理和调仓治理是最要紧的业务。销售业务治理一方面要习惯销售业务现有的和可能有的变化，一方面要提升开调拨出仓单的效率，辅助治理，辅助决策。关于先款后货方式发货治理，如果是成品仓供货，按照商业单位的发货申请单，要通过要货打算平稳和（汽运/铁运）储运平稳，然后生成调拨出仓单。要货打算平稳时，要看仓库库存量是否足够供货以及商业单位余额是否足够支付货款（有批文的要专门处理），在两者都满足的情形下，公司综合治理科可能还要按照销售策略等对供货打算予以调整。满足要货打算平稳条件后，还要进行储运平稳，这是因为成品仓供货要由公司公司送货上门。储运平稳要检查商业单位所要的产品是否满足送货条件（例如，产品是不是够装一车）并安排发货时刻。如果是中转仓供货，按照商业单位的发货申请单，只需查商业单位余额是否足够支付货款（有批文的要专门处理）。如果商业单位余额足够，即可开调拨出仓单。所以，不管是成品仓发货依旧中转仓发货，在商业单位余额不够支付货款，然而差额专门小的情形下，应灵活处理。例如，能够设定一个数值较小的额度，规定只要商业单位的余额加上那个数值足够支付货款即可开单。关于先货后款方式发货治理，业务流程类似于先款后货方式发货治理，只是要货打算平稳环节有所不同。在先货后款方式下，按照商业单位的具体情形，如资产、信誉等，给每个商业单位都规定了一个最大赊销额，赊销产品总价值不能超过那个额度。要货打算平稳时要看商业单位的累计赊销额是否超过了最大赊销额（有批文的要专门处理）。只要未超过最大赊销额，就能够开调拨出仓单。储运治理也是发货治理的一部分。储运治理的功能大致有开送货单，对返回的有回执的送货单进行核对、统计，运算运费、保险费，以及提供相应的统计信息等。调仓指产品从公司公司的一个仓库到另一个仓库（成品仓—中转仓，中转仓—中转仓），它与产品销售的区别是调仓不运算价格，也确实是讲，调仓能够看成是价格为零的产品销售。先要依据仓库（调出仓库和调入仓库）库存量等条件对调仓要求进行审核，然后按照审核后的调仓要求开出调仓入库单和调仓出库单，分别作为调出仓库产品出库的凭证和调入仓库产品入库的凭证。在处理机、三包机销售治理中，关于处理机，按照财务发票，开调拨出仓单。关于三包机，要按照空调售后部门提交的审核后的三包备用周转机申请表开相应的调拨出仓单。已付款机退货治理指按照已付款机退货单和退回的相应的发票或折让证明，开出退货用调拨出仓单。未付款机退货治理按照未付款机退货单开退货用调拨出仓单。仓库治理仓库治理包括成品仓(包括厂区仓库和子仓库)和中转仓的入库、出库治理，记录仓库帐目以及统计库存信息等功能。仓库治理一方面要代替原先的手工帐，为销售部门提供实时库存信息，提升仓库入、出库治理能力，另一方面要增加产品条码帐，入、出库都要记录每台产品的条码，为仓库帐龄分析、成本分析提供基础数据。仓库入、出库治理实时记录仓库入库帐和仓库出库帐，关于一张调拨出仓单多次提货的情形，还能反映出实际提货情形。此外，还要记录仓库结存信息和仓库盘盈亏信息，并按照用户要求输出成品仓（包括厂区仓库和子仓库）和中转仓的入、出库统计信息，仓库库存信息，仓库盘点信息。销售财务治理销售财务治理包括销售业务帐治理和销售财务帐治理，它在原有系统的基础上增加了对应对款的治理。销售财务治理在整个销售分系统中占有重要的地位，它对系统的可靠性和数据的准确性要求专门高。销售业务帐治理提供商业单位货款传真件的录入、查询，先货后款方式下贴息额的运算和销售业务帐爱护三个功能。销售业务帐爱护包括按照开出的调拨出仓单减少商业单位余额，收到银行到款通知后对相应的款项做标记，先货后款方式下对在途货款额的治理（如：减少商业单位现有赊销额等）。销售财务帐治理包括原始数据录入、查询、爱护，开发票，生成凭证，记帐，生成各种财务报表以及输出帐目统计信息等几项功能。原始数据包含银行往来帐，审核后的运费、保险发票，科目信息和商业单位开户信息。开发票功能要紧是按照调拨出仓单和空调售后部门返回的配件报废单开出相应的发票，同时能够查询、打印发票内容。生成凭证是财务治理的要紧业务之一，它要按照各种发票及审核后的安装修理网点用款申请单编制销售凭证、银行来款凭证等原始凭证。记帐按照生成的凭证修改相应的帐目，包括总帐，单位往来明细帐，银行往来明细帐，商品销售明细帐等。帐目统计信息和各种财务报表的输出是财务治理的重要方面，帐目统计信息包括总帐余额，二级总帐余额，明细帐余额，应收款/应对款单位明细帐余额，各地区应收款一览等信息，要紧财务报表有产品销售统计表（按照财务帐目得出），帐龄分析表，发票销存表等。销售综合治理销售综合治理包括商业单位进、销、存统计分析，市场信息收集，打算准确率考核，专卖店/专柜监督治理，广告业务综合治理，合同治理，产品信息治理，单位信息治理。销售综合治理是按照需要新加进空调销售分系统中的功能，是原有系统所没有的。它加大了公司对各地办事处的治理，提升了信息收集速度，减少了信息收集过程中的重复录入，提供了对广告费用等的考核手段。商业单位进、销、存统计分析提供对各地办事处提交的月度商业单位进、销、存统计表的录入、修改、查询和统计功能。市场信息收集提供对各种市场信息的录入、修改、查询和统计。这些市场信息要紧包括各地月度要紧空调品牌畅销型号调查表，各地月度要紧空调品牌价格快报，商业单位月度要紧空调品牌零售信息，月度商业单位要货打算等。打算准确率考核比较各办事处提出的要货打算和各地实际销售情形，从而对办事处提出的要货打算的准确率进行考核。专卖店/专柜监督治理实现的功能包括按照空调售后部门返回的空调安装单，统计各专卖店/专柜的销售实绩，对申请专卖店/专柜信息（专卖店/专柜开点申请单）的统计，以及对有关专卖店/专柜建设（售点工程预算表，售点工程决算表）的信息的统计。广告业务综合治理包括广告费用治理，广告信息统计和促销人员治理。广告信息统计包括对户外广告（大型广告牌/灯箱街）运作表，空调样机发放领用签收表，户外广告投放打算等的录入、查询、统计。促销人员治理包括促销人员信息，促销人员业绩考核和促销人职员资治理。合同治理提供对合同的录入、查询、统计，并能按照经销单位销售实绩监督合同的实际执行情形。产品信息治理包括产品信息的录入、查询、爱护功能，单位信息治理包括对商业单位、办事处、仓库等的信息的录入、查询、爱护和打印功能。空调售后部分功能详细需求分析在CIMS环境下，实现整个空调售后系统所属各部门（包含公司用户服务部，各治理中心及各安装、修理网点）工作过程一体化和治理信息的集成，快速、准确、集中地反映整个售后工作中有关安装、修理、结算治理、配件治理等工作的信息以及用户信访和产品质量反馈信息，满足售后服务工作业务流程的要求，为用户服务部各级职能部门（要紧包含结算科，配件科，技术科，综合治理组和各省级治理中心）提供治理信息及辅助其制定工作决策的手段，提升工作效率，改进工作方法，并加大对各个下属部门的监控，同时为生产和销售治理部门提供来自用户的产品产量和质量信息，以更有效的作好空调售后的服务工作，关心生产和销售部门调整产量，提升质量，改进营销策略，从而完善整个空调公司的工作。空调售后治理部分包括用户服务部、治理中心和安装修理网点三级治理，在功能上分成结算治理，配件治理，用户信访治理和质量信息反馈治理四个部分。结算治理结算治理包含各种结算凭证的录入，审核，对网点的考核（包括违章扣罚和不定期的安装奖励）以及包含配件申领和耗用有关费用在内的各种费用的结算。结算凭证包含安装凭证、修理凭证，换机凭证以及检测凭证，这些凭证每月由安装修理网点汇总后送交所属治理中心，治理中心进行初步审核，并完成数据录入工作。治理中心经授权可完成各类凭证在本中心所辖区域的审核，将合格部分经网络远程传送至售后结算科，关于不合格部分则将已录入信息删除，并将原始单据退回网点；未经授权的治理中心直截了当将原始数据传送至结算科，等待结算。结算科按照来自中心的数据完成费用结算工作。结算科将对这些信息进行更大范畴（那个地点的范畴既包含时域上的，也包含地域上的），多方面的审核。按照审核结果，视网点违章情形予以扣罚。结算科还能够不定期的统计网点在一定时刻内的安装量，对安装量超过一定数额的网点予以奖励。同时，结算过程中考虑此次结算期内网点申领和三包期内耗用配件的情形，参考此次结算金额，扣除或返还配件费。结算完毕，开具结算通知书交网点。结算科按照网点开出的发票，向销售财务提出用款申请，付款给网点。配件治理配件治理实施对三级仓库（售后，中心，网点）的两级治理（售后，中心），在功能上又分成新配件和新三包备用周转机的申领与发放，旧配件和旧三包备用周转机的耗用与返厂，配件与三包备用周转机的入出库和修理等，它集成了三级仓库的库存，结存，和进出库的帐目信息，并为结算工作提供网点配件申领的信息。正常情形下，下一级部门定期填写配件或三包备用周转机申领表，向上级部门（网点向治理中心，治理中心向售后，售后向配件公司）申领备用配件或三包周转机，上级部门按照提出申请的下级部门库存和本级仓库库存情形，确定实际发放数量，发出物资，记本地仓库帐。网点更换下来的旧配件或三包周转机随旧件返厂登记表，全部经中心返回售后配件仓库。相伴配件或三包周转机的流淌过程，各级部门完成入出库操作，记各自的库存帐。配件的修理工作仅发生在售后配件仓库，三包机修理发生在售后和中心两级。用户信访治理用户信访治理收集来自用户的信息，完成对相应事务的处理和监督，按照不同的统计条件产生各类统计报告。信访治理收集的信息要紧分成以下几类：对治理中心或安装修理网点的投诉，对工作人员的投诉，对产品的投诉，用户报装、报修，用户咨询，建议与夸奖，用户来信、来电购买配件等。信访治理中关于收到用户要求而未及时处理的情形应向操作员发出警告信息。质量信息反馈治理质量信息反馈治理要紧统计来自修理凭证和质量反馈调查的信息，生成有关售出产品质量的各种统计报告，供有关部门参考。性能详细需求分析响应时刻系统应具有较高的响应速度，由于系统需要输入大量的出仓单、安装单、修理单、申领单等各种单据，即数据录入工作量专门大，因此需要系统对录入数据的提交有专门快的响应。用户进行各种查询、统计时，应能够及时、准确地获得所需要的数据。响应速度应达到分钟级。安全性系统应具有良好的安全性，关于各种数据的操作，都应当设置相应的用户权限级别，防止非法用户对数据查看、修改或删除。不仅应对各职能部门的查询、操作设置权限级别，对各部门内的登录的用户也应当设置更细的权限级别，幸免非法用户对数据的查看和修改。具体地，在保证集团公司的有关职能部门以及各地分公司能够方便地查询其权限范畴内的信息并进行承诺的操作的同时，要保证各地分公司只能查看与本分公司有关的数据，只能对本分公司的数据进行操作，没有修改集团公司及其他分公司数据的权限。同样，各中心只能看到本中心及其下属各网点的信息，而不能看到其他中心和用户服务部的信息，用户服务部能够看到所有中心/网点的数据。各中心无权作配件或三包机的冲帐，修理费用的结算、付款后的核销、仓库的结存等操作都必须由具有相应权限的专门人员进行。可靠性系统应具有良好的可靠性。因为许多数据直截了当关系到费用结算、配件和三包机的数量，因此数据的正确性、可靠性尤为重要。在用户录入数据时，应做合法性检查，不合法数据不能提交，从而保证录入的数据的正确性，提升事务处理的效率和准确性。开放性采纳公布的标准和协议，具有良好的开放性。用户友好程度系统应有统一、友好、图形化的用户界面，操作简单，易学易用，无须复杂的培训，用户即可使用。同一类型的用户界面保持统一的风格，在用户操作过程中，应有尽可能多并尽可能详细的提示信息，例如在用户退出修改或录入界面之前，提示用户进行存盘，用户录入数据有误或非法时及时向用户报警，从而方便用户的使用。同时，系统应具有良好的可扩充性、可爱护性。信息详细需求分析冰箱销售部分信息详细需求分析信息类型冰箱销售部分的信息是冰箱销售各部门信息的集成。包括销售信息、财务信息、仓库信息、储运信息、市场信息、营销治理信息、广告信息等。也能够按照信息的功能划分为业务信息、产品信息、帐目信息、进销存信息、人员信息、用户权限信息、统计信息等。精度要求产品的价格数据精确到小数点后两位；打算、生产数据 为整数；财务处理金额数保留到小数点后两位；百分比均保留到小数点后两位；冰箱售后部分信息详细需求分析信息类型冰箱售后部分的信息包括修理记录信息、更换配件信息、结算费用信息、各类故障信息、用户信访信息、物料治理信息、中心/网点信息等。需要手工录入的数据有修理记录凭证、配件或三包机的申领单、三包外配件或处理机销售汇总表、用户来信、电话或投诉、用户咨询卷、各中心A类件故障缘故统计表等。精度要求结算费用、配件或三包机单价等金额数据保留到小数点后两位百分比均保留到小数点后两位传输及存放要求冰箱修理记录信息、更换配件信息、结算费用信息等由中心输入，并存入中心自己的数据库中。由于用户信访有多种形式，用户信访信息有多种类型，其中有些需要由中心输入，有些需要又集团公司输入。例如，用户的来信有可能投到中心，也有可能投到集团公司。同样，用户的信访电话和投诉电话有可能打到中心，也有可能打到集团公司。因此，中心和集团公司都应能够输入并储存信访信息。时效性系统应具有一定的时效性。仓库库存量应随着配件或三包机入库或出库实时变化，反映实时库存。由于集团公司期望能够把握完整的用户信访信息，因此中心的信访信息应定期（每月）传回集团公司。冰箱修理记录信息、更换配件信息、结算费用信息定期（每月）传回集团公司。空调销售部分信息详细需求分析信息类型空调销售分系统的信息是空调销售各部门信息的集成，它在整个系统中占十分重要的地位，为完成系统的功能提供了必要的前提和基础。按部门分，有销售信息、财务信息、仓库信息、储运信息、市场信息、营销治理信息、广告信息等。按功能分，有业务信息、产品信息、帐目信息、进销存信息、人员信息、用户权限信息、统计信息等。精度要求财务处理金额数保留到小数点后两位百分比均保留到小数点后两位运费、保险费等保留到小数点后两位实时性要求仓库库存量应随着产品入库或产品售出实时变化，反映实时库存。开出调拨出仓单后，商业单位业务帐应及时改变。空调售后部分信息详细需求分析信息类型本部分涉及的信息分成以下几类：原始信息，来自原始单据的信息；统计信息，对原始信息按照不同标准进行统计生成的各类信息；运算信息，工作过程中（要紧是结算工作）进行了有关处理后生成的信息；治理信息，部门信息和有关的治理方法与规定；外部信息，来自用户或其他部门的信息。信息涉及的范畴营销治理分系统是整个营销系统要紧信息的综合。空调售后治理部分的信息的流通范畴要紧是售后用户服务部结算科，配件科，技术科，综合治理组，各治理中心等职能部门。按信息分级治理需要分类公有信息，该类信息在整个空调售后范畴内可自由流淌，如有关网点、治理中心的信息，安装修理信息等。这些信息供各职能部门作为参考，未经授权不得改动。用户服务部治理信息，该类信息只能由用户服务部特定职能部门及人员进行扫瞄和修改。治理中心级信息，该类信息对用户服务部有关职能部门是可扫瞄的，除非在特定情形下，用户服务部无权直截了当修改中心数据。治理中心只对与本中心有关的信息有查询和修改的权限，信息不能跨中心流淌。系统级信息，该类信息由系统治理员爱护，其余人员未经授权不得访咨询。信息精度要求结算处理金额数据 一样保留到小数点后两位统计数据一样保留到整数位，其中涉及运算数据保留到小数点后2位百分比均保留到小数点后两位营销治理分系统功能模型在进行系统详细需求分析的同时，采纳IDEF0方法，利用BPwin功能模型设计软件，建立了公司营销治理系统的功能模型。建立功能模型的过程差不多上分为：了解系统现有业务流程；建立现有系统功能模型；分析改进现有业务流程；建立新系统功能模型。在对现有业务流程进行深入了解的基础上，对业务流程加以认真分析，提出新的流程以解决存在的咨询题和习惯新的系统环境。例如，现在的销售开单工作全部集中在公司销售部进行，开单过程中需要与各地中心/办事处通过传真件的往返进行信息传递，由于传真件的字迹模糊不清专门容易引起差错，而且降低了工作效率（如图1所示）。结合公司网络系统建设，对销售开单业务流程重新规划，得出新的销售开单业务流程（如图2所示）。新流程中将开单业务分散到各中心/办事处，公司仅保留对直提要货的开单工作。在开单权下放的同时，也加大了对开单的操纵。第一是加大了对产品价格修改权的操纵，对任何产品的价格各中心/办事处都只能查询，而无权修改。幸免中心/办事处在价格方面的出错。其次是加大了对客户货款余额的审查与操纵，将客户货款余额作为开单的关键条件，关于货款余额不足的客户，系统将拒绝为其开单。因此从系统的角度、采纳技术手段对不符合要求的操作进行检查和拒绝，使系统的安全性得以保证。

商业单位中心/办事处商业单位中心/办事处销售/要货打算审查要货申请要货打算要货申请财务/业务帐货款余额产品库存量库存量储运/要货打算平稳审核后的直提要货打算承运单位运输能力销售/开电脑出仓单平稳后的直提要货打算审核后的中转仓提货要货打算成品仓直提电脑出仓单中心/办事处中转仓提货电脑出仓单需要调整的要货打算中转仓不能满足的要货打算商业单位不能满足的要货打算要货打算调整要求电脑出仓单，要货打算图1现空调销售开单业务流程打款证明打款证明领导/批示批文营销/产品价格产品价格商业单位商业单位中心/办事处销售/要货打算审查要货申请直提要货打算货款余额成品仓/产品库存量库存量储运/要货打算平稳审核后的直提要货打算承运单位运输能力销售/开电脑出仓单平稳后的直提要货打算审核后的中转仓提货要货打算成品仓直提电脑出仓单中心/办事处需要调整的要货打算不能满足的要货打算商业单位不能满足的要货申请需要调整的要货申请电脑出仓单图2新空调销售开单业务流程中转仓/产品库存量库存量中转仓中心/开电脑出仓单财务/业务帐货款余额打款证明打款证明运算机远程通讯：营销/产品价格产品价格领导/批示批文现在的产品库存治理是以产品类型和规格为单位进行治理，在这种治理方式下只能对某种产品的存放地点、库存量以及出入库数量等信息进行治理，不能实现对单台产品的跟踪治理。在详细调研中，治理人员和业务人员从不同的角度提出了一些涉及到产品单台跟踪咨询题的需求，如产品流向跟踪，产品库龄分析等。为了严格仓库治理、加快产销信息衔接、提供更准确的产品销售分析信息，应该在产品销售过程中采纳条形码技术。要采纳条码技术还需要第一解决两个咨询题，一是包装箱上应该有条码；二是在成品仓、中转仓甚至较大的销售单位配备条码设备和运算机设备。所以，销售业务处理流程也要进行相应的改变。从库存治理业务看，现在的空调入出库治理业务流程如图3所示；图4描述了实行条码治理后的空调入出库治理业务流程。生产车间生产车间仓管员/清点仓库/库存帐产品入仓单销售/开电脑出仓单仓管员/开入仓单产品数量仓管员/清点/贴流向码电脑出仓单仓库产品产品商业单位产品产品数量，电脑出仓单销售/流向码帐区域流向码图3空调入出库治理业务流程生产车间生产车间条码扫描设备仓库/条码帐产品销售产品数量条码扫描设备电脑出仓单仓库产品产品商业单位产品产品数量仓库/库存帐产品条码产品条码电脑出仓单电脑出仓单入仓单入仓单入仓单图4空调入出库条码跟踪治理业务流程按照国家863/CIMS应用工程的要求，建立了公司营销系统的功能模型。该模型由48张不同层次的IDEF0图构成。公司营销治理系统功能模型参见附录1。营销治理分系统子系统和功能模块划分按照公司营销治理系统的总体实现模式，营销治理分系统分为集团公司营销治理和中心/办事处营销治理两大部分。集团公司营销治理部分的软件运行于集团公司的服务器上，用于支持集团公司各销售治理部门的各项业务，以及支持各地中心/办事处需要与集团公司保持实时联系的各项业务。中心/办事处营销治理部分运行于中心/办事处的服务器上，用于支持中心/办事处的本地业务和不需要与集团公司保持实时联系的各项业务。集团公司销售治理部分又分为销售治理子系统，运输治理子系统，售后治理子系统，市场治理子系统，财务治理子系统，系统治理子系统等。中心/办事处营销治理部分又分为销售治理子系统，售后治理子系统，市场治理子系统等。详细的功能模块划分如图5所示。

营销治理分系统营销治理分系统集团公司营销治理部分销售治理子系统成品仓（中转仓）治理成品入仓治理成品出仓治理成品调仓治理成品库存查询统计产品销售治理发货申请单审核制定发货打算开出仓单销售单位治理增加销售单位修改销售单位注销销售单位销售单位信息查询统计运输治理子系统承运单位治理增加承运单位修改承运单位注销承运单位承运单位信息查询统计产品运输治理要货打算平稳开送货单送货单回执审核运费审核运输保险售后治理子系统售后治理子系统产品安装治理费用审核结算治理产品销售区域审核安装单审核修理单审核打印结算单安装单治理输入安装单修改安装单删除安装单安装单查询统计产品修理治理输入修理单修改修理单删除修理单修理单查询统计打印用款通知书结算核销结算费用统计分析配件治理制定配件/三包机申领打算配件/三包机领用信息统计售后仓配件/三包机查询中心配件/三包机帐查询网点配件/三包机帐查询售后仓治理配件入仓治理配件出仓治理配件库存查询统计三包机入仓治理三包机入仓治理三包机出仓治理三包机库存查询统计质量信息治理输入质量信息修改质量信息删除质量信息质量信息查询统计中心/网点信息治理输入中心/网点信息修改中心/网点信息删除中心/网点信息中心/网点信息查询统计用户信访治理输入信访/回访信息修改信访/回访信息删除信访/回访信息信访/回访信息查询统计市场治理子系统市场信息治理本公司产品近期销售打算销售打算汇总销售打算查询统计本公司产品销售信息治理本公司产品销售信息汇总本公司产品销售信息查询统计其它公司产品销售信息治理其它公司产品销售信息汇总其它公司产品销售信息查询统计销售渠道治理销售渠道治理销售网点业绩治理销售专柜业绩治理广告信息治理广告信息汇总广告信息查询统计财务治理子系统财务科目治理凭证治理专用凭证治理调整（通用）凭证治理帐务治理总帐（一/二级）单位明细帐财务统计报表治理应收帐统计应对帐统计业务帐银行来款统计商品明细帐统计报税发票统计会计治理原始单据治理发票治理返销发票治理银行来款证明治理(含承兑汇票)折让单治理系统治理子系统代码爱护用户权限设置用户权限设置系统参数设置中心/办事处营销治理部分销售治理子系统成品仓（中转仓）治理成品入仓治理成品出仓治理成品调仓治理成品库存查询统计产品销售治理发货申请单审核制定发货打算开出仓单产品安装治理安装单治理输入安装单修改安装单删除安装单安装单查询统计产品修理治理输入修理单修改修理单删除修理单修理单查询统计售后治理子系统配件仓治理配件入仓治理配件出仓治理配件库存查询统计三包机入仓治理三包机入仓治理三包机出仓治理三包机库存查询统计质量信息治理输入质量信息修改质量信息删除质量信息质量信息查询统计网点新配件治理输入网点新配件申领单修改网点新配件申领单删除网点新配件申领单网点新配件申领信息查询网点配件治理网点三包周转机治理输入网点三包机申领单修改网点三包机申领单删除网点三包机申领单网点三包机申领单信息查询网点旧配件治理输入网点旧配件返厂单修改网点旧配件返厂单删除网点旧配件返厂单网点旧配件返厂单汇总网点三包坏损机治理输入网点三包坏损机返厂单修改网点三包坏损机返厂单删除网点三包坏损机返厂单网点三包坏损机返厂信息查询网点旧配件返厂信息查询网点配件帐报表治理网点配件帐报表治理中心网点信息查询统计中心网点信息治理市场治理子系统市场信息治理本公司产品近期销售打算输入销售打算修改销售打算删除销售打算销售打算查询统计本公司产品销售信息治理输入本公司产品销售信息修改本公司产品销售信息删除本公司产品销售信息本公司产品销售信息查询统计其它公司产品销售信息治理输入其它公司产品销售信息修改其它公司产品销售信息删除其它公司产品销售信息其它公司产品销售信息查询统计广告信息治理输入广告信息修改广告信息删除广告信息广告信息查询统计图5营销治理分系统功能模块划分系统治理子系统代码爱护用户权限设置系统参数设置分系统界面设计外部界面设计公司营销治理分系统与MRPⅡ系统之间存在有产品、配件、价格、销售打算等信息交换；与成本治理分系统之间存在有产品库存以及资金占用等信息交换；与条形码输入系统之间存在有产品、仓库、商业单位等信息交换。用户界面设计公司营销治理分系统采纳Browser/Server模式体系结构，客户端应用只需使用扫瞄器即可，系统以WWW网页方式与用户进行交互，具有统一、友好、图形化的用户界面，操作简单，无须复杂的培训，用户即可使用。因为此系统要紧是对数据库操作，用户的操作要紧包括数据录入、查询、修改和删除等，为方便用户的使用，同一类型的用户界面应保持统一的风格，在用户操作过程中，应有尽可能多并尽可能详细的提示信息，例如在用户未执行储存操作而退出修改或录入界面时，要提示用户进行存盘，用户录入数据有误或数据不合法时要及时向用户报警，要求重新输入。图6为输入数据出错时系统提示的例子。图6用户录入错误时的信息提示关于数据查询操作，用户输入查询条件（如日期范畴、编号范畴等），然后单击“查询”按钮便可进行查询。查询结果的显示多采纳HTML的TABLE（表格）形式，显示界面整齐美观（如图7所示）。若需显示的结果数据专门多，以至于一屏显示不下时，屏幕下方将显示导航条和页数信息，便于用户的查阅。图7数据查询结果显示关于数据录入操作，用户输入必需的各项数据，然后单击“储存”按钮储存当前记录。单击“添加”按钮可连续输入下一条记录。数据录入的用户界面的外观如图8所示。图8数据录入界面示意数据库系统设计设计要求鉴于公司营销系统的业务特点和公司集团对营销治理系统的要求，营销治理系统所采纳的数据库系统应满足如下要求：分布式关系型能储备和处理公司集团庞大的产品及有关数据能保持集团公司数据库数据和中心/办事处数据库数据的一致具有备份数据与复原数据的能力较高的查询响应速度具有完善的安全治理机制信息模型设计信息模型设计使用的符号讲明信息模型设计中使用的图形符号完全服从IDEF1x方法规范。实体公司营销治理系统涉及到两类实体：独立实体和从属实体。实体名独立实体：实体的每一个实例能被唯独标识且又不依靠于它与其它实体的联系。图形表示为方角矩形框。实体名从属实体：实体的每一个实例的唯独标识依靠于该实体与其它实体的联系。图形表示为圆角矩形框。联系实体名可标定联系：子女实体的每一个实例差不多上由它与双亲的联系而确定，即子女实体的主键中包含双亲实体的主键。实体名

可标定联系图形表示为：实体名实体名实体名双亲实体子女实体非标定联系：子女实体的每个实例都能被唯独的标识，不需要通过联系识别。实体名双亲实体实体名双亲实体实体名子女实体完全分类联系：一样实体的一个实例仅与一个分类实例相联系。实体名实体名实体名实体名实体名实体名一样实体分类实体鉴别器属性属性表示事物的一种特点或性质。每个属性仅属于一个实体，为实体所继承的属性只能是关键字属性。一个实体的候选关键字属性能够由一个或多个属性组成，它唯独确定或标识实体的每一个实例。如果实体存在多个候选关键字，必须指定一个为“主关键字”，用PK表示，其它为候选关键字，也称为“次关键字”。由于公司营销治理系统选用是关系型数据库其数据模型为关系模型，因此设计中没有考虑候选关键字或次关键字。在确定联系和分类联系中，双亲实体或一样实体的主关键字要被子女实体或分类实体继承，这些被子女实体和分类实体继承的属性称为“外来关键字”，用FK表示。信息模型设计在系统详细调查的基础上，按照关系数据库设计方法和理论，对公司营销治理系统所涉及到的台帐、报表、单据等信息进行分析整理，利用信息模型设计工具ERwin，对实体、实体属性、关键字以及实体之间的联系进行设计。设计出了包含180多个实体（不包含视图）的公司营销治理系统信息模型。ERwin基于图形用户界面实现并扩展了IDEF1x方法，ERwin提供了逻辑视图和物理视图两种模式，并能够与ORACLE等数据库相连接，能够直截了当完成由实体联系图到ORACLE物理数据库的转换工作。另外，ERwin还能够对数据库的完整性约束条件等进行设计，如属性的非空性、缺省值、有效性、触发器、增加及删除的约束等。视图、储备过程和触发器等都能够储备在ERwin文件中，在进行实体联系图到物理数据库转换时能够将视图、储备过程和触发器等一并生成。公司营销治理系统信息模型的实体联系图和实体属性讲明表，参见附录2，附录3。数据库设计数据访咨询频度和流量从数据被访咨询的频繁程度看：产品库存数据、产品价格数据、业务帐数据、用户信访数据等需要经常输入与查询，因此数据的访咨询比较频繁。而产品安装数据、产品修理数据、运输与保险费用数据等通常是集中一定数量（或积存一定时刻）的单据，以成批处理的方式进行，因此数据访咨询频度比较低。从数据的流量大小看：产品库存数据、产品安装数据、产品修理数据、运输与保险费用数据等都与产品有关，专门是实施产品单台跟踪后数据流量专门大。数据库选型公司营销治理系统目前涉及到冰箱和空调的全部产品库存信息和产品销售信息。而且数据库中的数据量将随着时刻的推移而逐步增加。如果按照年产冰箱360万台和年产空调120万台来估算，公司营销系统数据库不久将变得专门庞大。另外，公司营销系统对系统数据的安全性和数据处理速度都有有专门高的要求。因此在数据库选型时应充分考虑系统对数据库的设计要求。在大型商业化关系数据库产品中，ORACLE数据库具有：*采纳标准的SQL结构化查询语言。*具有丰富的开发工具，覆盖开发周期的各时期。*支持超大型数据库，能支持在一个数据库中的数千G的储备，数据类型支持数字、字符、大至4GB的二进制数据，为数据库的面向对象储备提供数据支持。*具有第四代语言的开发工具（SQL*FORMS、SQL*REPORTS、SQL*MENU等）。*通过SQL*DBA操纵用户权限，提供数据爱护功能，监控数据库的运行状态，调整数据缓冲区的大小。*分布优化查询功能。*具有数据透亮、网络透亮，支持异种网络、异构数据库系统。并行处理采纳动态数据分片技术。*支持客户机/服务器体系结构及混合的体系结构（集中式、分布式、客户机/服务器）。*实现了两时期提交、多线索查询手段。*支持多种系统平台（HPUX、SUNOS、OSF/1、VMS、WINDOWS、WINDOWS/NT、OS/2）。*数据安全爱护措施：采取快照SNAP方式完全排除了分布读写冲突。自动检测死锁和冲突并解决。*数据库内模支持多字节码制，支持多种语言文字编码。ORACLE数据库所具有的这些特点，能够满足公司营销治理系统的要求。因此数据库系统选择ORACLE公司的ORACLE8数据库。异构数据库的连接与数据传递方式营销治理系统不是一个孤立的系统，它与其它系统之间存在着不同程度的数据交换。专门是与公司集团的MRPⅡ系统之间的数据交换咨询题需要加以研究解决。由于公司集团的MRPⅡ系统采纳CA公司的MANMAN软件，其数据库系统为网状数据库，因此与关系数据库之间的信息交换比较困难。方案一为了使营销治理系统与MANMAN系统有机的结合在一起，我们拟在NTWWW服务器上编写CGI程序。由该CGI程序启动VMS系统的FORTRAN程序，该FORTRAN程序通过与MANMAN的接口读取MANMAN中的数据，再将数据传回给NT的CGI，再由CGI传送主页给最终用户。数据交换示意图如图9所示。CGI程序CGI程序NTWWWFORTRAN程序VMSMANMAN软件用户扫瞄器图9营销治理系统与MANMAN软件数据交换方案一然而这一方案存在的咨询题是，处于NTWWW服务器上的CGI程序是否能够启动VMS上FORTRAN程序还需要做进一步的实验。因此，这一方案能否实现目前还没有十分的把握。方案二第一，在VMS系统上配置WWW服务器（需公司集团方面协助实现）。然后将CGI程序直截了当放到VMS上（利用FORTRAN与MANMAN接口直截了当编写CGI），如此用户就能够直截了当连到VMS上，由CGI程序猎取MANMAN中的数据，这一方案能够大大提升整个系统的工作效率。数据交换示意图如图10所示。此项工作需和电脑科的技术人员加以和谐。CGI程序CGI程序（FORTRAN）VMSWWWMANMAN软件用户扫瞄器图10营销治理系统与MANMAN软件数据交换方案二数据安全性及保密性设计公司营销治理系统对数据的安全性和保密性都有专门高的要求。为了能够达到这些要求，营销治理系统将从多个方面、分层次的采取安全措施。数据安全性设计数据的安全性要紧体现在：可不能由于人为因素，使系统数据遭到破坏；可不能由于系统故障，导致系统数据的大面积破坏和丢失。使用数据库备份机制定时备份数据库中的数据，以便数据库丢失时复原。数据保密性设计数据的保密性要紧体现在：任何使用者都不能看到与其业务无关的数据，更不能更换这些数据。例如：冰箱公司只能看到该公司自己的数据，而空调公司也只能看到该公司自己的数据；不同的中心/办事处只能看到与该中心有关的数据，集团公司只能查看而不能修改中心/办事处的数据等。数据字典设计ERwin提供了丰富的处理文档的功能，有关实体、属性、联系、域及其相互之间的关系都能够用多种形式建立并打印出来，同时还能够将这些文档转换到选定的数据库中。科营销治理系统数据库设计中，所有的实体（表）名、属性名差不多上以英文形式显现。因此，为每个实体（表）建立了包含实体（表）名的中英文对比、属性名中英文对比、属性类型、长度、主键和外键等内容的实体表。实体表作为实体联系图的必要补充，既是实体联系图的有效的辅助讲明，又是程序设计人员编写程序时必不可少的重要资料。详细的实体属性表参见附录3。网络通信系统设计设计要求公司营销治理系统网络的设计，要紧考虑下列差不多原则：保证网络的先进性，同时要兼顾网络的经济性和可行性保证网络的开放性和可互连性保证网络系统的可靠性和安全性保证网络的可扩展性和可升级性充分考虑和利用现有网络设施，降低网络建设成本基于上述差不多原则，考虑到公司集团差不多建立了覆盖集团总部和各分公司的主干网，因此营销治理系统网络只需要对公司主干网进行必要的扩充。公司集团营销治理系统涉及到分布在全国各地的中心/办事处、营销网点、安装修理网点，因此营销治理系统的网络设计应充分考虑其特点，同时要兼顾到网络建筑费用、网络运行费用、网络通讯速度、信息传输可靠性等因素。网络设计方案为了找出比较好的实现方案，对各种可能的组网方案的优点及存在的咨询题做了分析比较，并与企管部电脑科的技术人员进行了讨论交流，提出了一套可行的实现方案。各地中心/办事处与集团公司之间、各网点与中心/办事处之间采纳电话线拨号上网方式进行通讯。因此，集团公司主干网应配备ModemPool及多条电话线。由于营销治理系统采纳扫瞄器/服务器模式开发，因此集团公司主干网上需要增加一台WWW服务器。各地中心/办事处能够建立自己的局域网和WWW服务器，经Modem和电话线与集团公司连网。各销售网点、修理网点能够只设一台PC机，经Modem和电话线与该地区中心/办事处连网。具体实现方案如图11所示。

图11公司营销治理系统网络设计方案图11公司营销治理系统网络设计方案信息编码设计营销治理系统要紧用到以下信息分类编码：产品编码代码结构××××××××××大类标志小类颜色等级代码类型 字符型代码长度 10应用范畴 营销治理分系统零配件编码冰箱零配件编码空调零配件编码产品分类属性编码冰箱产品分类属性编码a.代码结构×××××××工质系列型号改型b.代码类型 字符型c.代码长度 7d.应用范畴 售后治理子系统（冰箱）空调产品分类属性编码a.代码结构××××××××××××品牌单冷/冷暖结构类型变频一拖一/二功率投产年度改型等级预留b.代码类型 字符型c.代码长度 12d.应用范畴 售后治理子系统（空调）故障编码

冰箱故障编码a.代码结构×××××× 故障第一层细分故障第二层细分故障 第三层细分故障 流水号b.代码类型 字符型c.代码长度 6d.应用范畴 售后治理子系统（冰箱）空调故障编码a.代码结构××××系列号流水号b.代码类型 字符型c.代码长度 4d.应用范畴 售后治理子系统（空调）冰箱故障现象编码a.代码结构××系列号b.代码类型 字符型c.代码长度 8d.应用范畴 售后治理子系统（冰箱）空调故障现象编码特约修理单位编码冰箱修理单位编码a.代码结构××××××××国区省市(县)中心识别码流水号b.代码类型 字符型c.代码长度 8d.应用范畴 售后治理子系统（冰箱）空调修理网点编码a.代码结构××××××××省市流水号b.代码类型 字符型c.代码长度 8d.应用范畴 售后治理子系统（空调）产品条形码冰箱条形码a.代码结构××××××××××××××××冰箱型号生产线号颜色/等级年月日流水号b.代码类型 字符型c.代码长度 16d.应用范畴 售后治理子系统（冰箱）空调条形码a.代码结构×××××××××××××型号代号生产线代号年月日流水号（当日）b.代码类型 字符型c.代码长度 13d.应用范畴 售后治理子系统（空调）销售单位编码（空调、冰箱共用）a.代码结构××××××××国内/外省市流水号b.代码类型 字符型c.代码长度 8d.应用范畴 营销治理分系统生产单位编码公司产品生产部门编码另配件生产厂家编码仓库编码a.代码结构××A/C顺序号b.代码长度 2c.代码类型 字符型d.应用范畴 销售治理子系统仓库类别编码省级中心和办事处编码运输单位编码铁路车站编码 采纳GB10302-88汽车队编码a.代码结构××××省流水号b.代码长度 4c.代码类型 字符型d.应用范畴 销售治理子系统行政区域编码（建议采纳国标GB2260-90）冰箱地区编码a.代码结构×××××国区省市(县)b.代码长度 5c.代码类型 字符型d.应用范畴 营销治理分系统空调地区编码a.代码结构××××××省市b.代码长度 6c.代码类型 字符型d.应用范畴 营销治理分系统销售区域编码a.代码结构×（字母）省b.代码长度 1c.代码类型 字符型d.应用范畴 营销治理分系统产品类别码a.代码结构 ××b.代码长度 2c.代码类型 字符型d.应用范畴 营销治理分系统人事信息编码a.代码结构 采纳国标码b.应用范畴 营销治理分系统关键技术提升查询速度使用并行服务器选件要求运行在多处理器运算机上，从而使多个现场（Instance）能并行的访咨询一个单独的数据库。使用并行查询选件要求Oracle数据库服务器运行在多处理器运算机上，Oracle利用查询和谐器及查询服务器把一个复杂的数据库操作划为逻辑子任务，并将这些子任务交给多个处理器，这些处理器并行工作，从而大大缩短了数据库操作所需的总时刻。采纳分区表及索引技术为了能提升专门大的表的查询速度，Oracle提出了分区表及索引技术。该技术将大表分成若干较小的较易治理的子分区。如此对该表进行查询时，并不是访咨询具有同样的字段名、约束定义及其他属性，即所有的子分区具有相同的逻辑分区，而实际上位于不同的物理分区（甚至能够位于不同的表空间）。采纳分区表技术并不增加最终用户的负担，用户完全透亮的访咨询数据。其优点时不但可大大加快查询速度，而且当某一分区发生故障时，并不阻碍其他分区的操作，便于各分区的独立备份和复原，另外可按照情形，适当将各分区放在不同硬盘上，从而可平稳I/O负载。使用MTS（MicrosoftTransactionServer）技术为了提升整个Broswer/Server系统的阻碍速度，我们使用了MTS（MicrosoftTransactionServer）技术。MTS可有效地利用运算机资源，专门是我们系统所需使用的三种系统资源（线程、对象、ODBC连接）都提供了缓冲池（Pooling），而这三种系统资源的合理调用直截了当阻碍到站点的执行效能。第一MTS按照内部定标特性，提供多线程技术能力来治理同时进入站点的多个用户线程；同时MTS能建立一个所有用户能分享的对象实例库来幸免系统资源的白费；另外MTS将ASP页面上移走数据访咨询而将其转移到一个单独的商务对象中，以便其他支持DCOM的应用程序可重复使用该商务逻辑，从而达到ODBC的集成库。通过一些精心设置的ASP编码，及对MSIIS进行一系列的配置，MTS和IIS可有机地无缝地联合工作，可大大提升B/S系统的性能。合理分配服务器与客户端的负荷分配主页表单为用户提供了向服务器提交信息的手段，当要对用户的某些信息进行一些限制（如在一个文本框中只能输入数字，或在一个文本框内输入有长度限制的字符串等），可在服务器端设置一个对用户提交信息进行检验的程序。当用户输入不符合规定的信息，服务器会提醒用户重新输入，如此做的缺点是专门明显的，用户需花较长的等待时刻且加重了网络的信息流量。我们采纳了均衡服务器和客户端负荷的方法，充分利用客户机的运算能力，在主页中插入一些脚本，由客户扫瞄器来验证用户输入信息的合法性。下面是一些脚本片段，用以完成上述工作（验证数字域）：CheckOK="1234567890"CheckStr=theForm.Control1.ValueFori=1toLen(CheckStr) ch=Mid(CheckStr,i,1) If(InStr(CheckOK,ch)=0)Then allValid=False ExitFor EndIfNext………If(NotallValid)Then………使用批提交技术当前主页编写时，一样使用表单。表单关于处理单条记录的查询、修改、插入时是专门便利的。但在实时工作时，操作员可能需一次同时录入多条记录后，再统一执行一次提交操作。这种操作方式不仅符合工作模式，也可节约网络信息的流量。为了克服表单只能提交一条记录的缺点，我们开发了一个数据库表格控件。该控件遵循微软公司的DCOM规范，利用ODBC和ADO连接到目标数据源。该控件可显示多条记录，设有第一条记录，最后一条记录，前一记录，后一记录，修改、插入、取消等多种方法。将此控件放在主页上，即可实现类似于PowerBuild的GridDatawindow的功能，从而达到我们的设计要求。使用自动系列号技术关于一样的应用程序来讲，在数据库中生成唯独的系列号是一件专门苦恼的工作，一样是将当前数据库中的最大系列号取出，再加上一增量作为新系列号，但当多用户插入同一表时，有时会发生系列号不唯独的错误。这种方法不仅需查询大量数据，从而造成操作延误，而且经常由于系列号不唯独，使用户操作时极不方便。我们利用下列的数据库端操作来自动生成系列号：CreateSequence0CustomerIDincrementby1startwith1000;当需插入新记录时，只需执行下列SQL语句即可；InsertintoCUSTOMER(Name,Contact,ID) Values('项目组','张三',CustomerID.NextVal);这种方法大大提升了操作速度，而且能保证多用户插入时可不能发生冲突。RAS的客户端编程公司营销系统是建立在以电话网为基础的广域网上，远端用户需拨号登录到主机上，才能连通运算机，达到扫瞄的目的。目前拨号上网的软件专门多，但都不能满足我们的需求。我们需要的是在远程运算机的主页上点取某一超级链接时，能自动拨打相应的电话号码，并自动实现TCP/IP的连接，从而达到扫瞄操作的功能。为了实现上述目标，我们编写了RASDial操纵，该操纵按照Modem的初始化记录，能拨打正确的电话号码，实现PPP连接，从客户机能正确连接到主机上。当用户关闭扫瞄器时，能自动切断电话。利用RASDial可实现用户操作透亮化，大大减轻了最终用户操作的复杂性。保证系统安全采纳多级口令保证系统安全（关封匿名用户）为了保证系统安全运行，防止非法用户侵入，我们设置了