采购系统分析.docx
《采购系统分析.docx》由会员分享，可在线阅读，更多相关《采购系统分析.docx（39页珍藏版）》请在冰豆网上搜索。
采购系统分析
一、采购管理系统分析
采购系统的分析主要用于对系统的整理和设计思路的明确。
这里主要包括功能模块的结构的分析和程序实现功能所使用技术的分析。
1.系统基础结构与初始化的分析
整个采购管理系统由前台和后台的两部分组成，前台用于预算单位和财政的业务数据的科理，而后台则主要是用来对系统进行初始化和基础数据的录入整理。
1.1后台系统初化包括菜单和角色
1.1.1数据库与发布目录的配置
系统需要运行必需的为首先配置tomcat下的root.xml文件，并存放于\Tomcat5.0\conf\Catalina\localhost\root.xml
然后配置发布的源文件。
1.1.2系统模块菜单的设置与角色分配
系统运行后，由系统已设好的系统管理员administrator用户口令888888777777,来进行系统模块的设置，这里首先要进行模块设置，角色定义，管理员设置。
●模块设置：
在这里增加系统的菜单模块,以及各个模块的下面的子菜单所对应的连接，并指出各个模块的的入口点以及其它的动作脚本等。
●角色定义：
是对系统的不同的用户进行分类后得出的操作人的类别。
则不同的类别可以操作不同的菜单模块的权限，并对所操作的菜单时行指定保存。
●管理员设置：
对于这都一步的执行必需先在另一个系统管理员999999，口令888888,先去设置、用户、用户所属部门、所在机构，以及对当前的部门中的用户进行分组，后才能在这里确定当前的这个用户是一个什么样的角色，来决定这个用户所能操作的模块的菜单。
1.2系统基础数据管理
1.2.1首先得初始化且来原于其它的系统的数据
用户信息、机构名称、预算单位、代理机构、业务科室、财政管理单位、部门类型、部门名称、部门分组（主要针对财政的各业务科室和采购科进行的业务的分组）、用户角色，是已从其它的系统中来的。
●用户信息：
系统除掉两个系统管理员外，其它的是由具体的用户角色分类来产生用户，包括用户名，口令，以及此用户所属部门名称，如果此部门有分组则就要具体到此部门的某一个组中，没有则是这个部门名称中的人，然后就是此部门应所属的机构名称，此部门所属的部门类型。
●机构名称：
所谓的机构名称就是一个单位组织的名称，例如预算单位名称，预算单位上级管理组织的名称,孝感市财政局等，我们都称之为机构名称；反过来一个机构里面可以分解成几个部门如预算单位的财务科，孝感市财政局的采购科，教科文科等我们称之为机构的部门。
●预算单位：
预算单位是指进行采购业务的实际的用户，它属于被管理的对像它的数据是进行审批、科理、统计的，所以它在独立出来进行一些属性的设置，如它有单位级别、上级单位、所属管理部门、所属行业、所属行业主体类别等。
同时它也是机构的一个子集，因为机构里还包括孝感市财政局、湖北省采购代理中心、采购供应商等。
这里的所属管理部门是指此部门的类型为”财政部门主管业务科室”,那么此所属管理部门即是财政主管业务科室的部门.
●代理机构：
实现政府采购代理实施实际采购的操作机构，它的性质是等同于预算单位的同属于机构的集合内的子集。
它的实体例如湖北省采购代理中心。
●业务科室：
是属于孝感市财政局的业务科室，它是一个管理者。
这里的各个业务科室可以理解为部门名称，即一个机构里所分出来的部门。
●财政管理单位：
这里财政的管理单位主要是孝感市财政局。
●部门类型：
是为了将一些性质比较相似的部门如财务科它就是一个预算单位管理的部门，那么我们将它们归纳为一个类型即叫“预算单位采购管理部门”，同理类推，孝感市财政局下面也有许多的部门将它们按性质也可以划分为“财政主管业务科”，“财政主管采购科”等；此参数是部门名称的一个属性。
●部门名称：
一个机构里专门用来做某一类别工作的组织，我们称之为部门，并给其取一个名称为部门名称，如预算单位有一个部门为“财务科”，在湖北科财政厅有部门名称如“预算科”、“采购科”、“企业科”、“商贸科”,还例如在代理机构“湖北省孝感市政府采购中心”它有一个部门就是“业务部”等。
●部门分组：
如果一个部门的工作分成几个组来做，那么就要对部门进行分组，则同是一个部门可能不同的组做的是不同或是存在相同的范围内的工作，这里要部门分组的名称暂时定为如“部门一组，部门二组”等。
财政的采购科进行分组就是一个典型的例子。
●用户角色：
是对用户的操作范围包括操作模块，菜单，数据以及各用户之间的业务关系来确定的类别。
则确定后的角色将有自己的模块，菜单，以及所能查看和科理的数据，以及如何与其相关的用户之间进行科理数据信息的传递如审批计划的流程。
1.2.2再次初始化各个数据之间的关系
有了上面的基础数据之后，就要对各个数据之间的关系进行设置如部门分组、业务科室权限设置、采购科室权限设置。
●部门分组：
这里主要针对业务比较多的部门如财政的采购科这个部门将分成几个组来科理不同的管理对象，这里的对象就是来自于各个业务科室或是预算单位。
●业务科室权限设置：
即对孝感市财政局的各个业务科室（部门）的具体的用户，而且此对业务科室进行了分组的用户，设置它所管理的预算单位。
●采购科室权限设置：
即针对孝感市财政局的采购科（部门）的具体的用户，而且对此采购科室进行了用户的分组，设置它所管理的孝感市财政局其它各个业务科室。
这样就继承了其它的各个业务科室所管理预算单位的用户的权限。
1.3系统初始化过程
经过上面的对结构以及各个基础元素和对象的分析可以大致的得出此系统的初始化的一个大致的流程。
1.3.1首先清掉系统中无用的表数据（表示不是基础数据的表）
1.授权过程表O_AuthorizeProgress（可以清掉）
2.授权结果表O_AuthorizeResult（可以清掉）
3.预算项目表O_BudgetProject（系统初始化表,来源于集中支付系统）
4.预算科目表O_BudgetSubject（系统初始化表,来源于集中支付系统）
5.（业务）省财政厅监管考核表O_CCheckAgency（可以清掉）
6.（业务）审核过程表O_CheckProgress（可以清掉）
7.（业务）合同函表O_ContractLetter（可以清掉）
8.（业务）合同函审核表O_ContractLetterCheck（可以清掉）
9.（业务）合同函发送表O_ContractLetterSend（停用）
10.（业务）合同函模板表O_ContractLetterTmp（系统初始化,根据财政需求设置）
11.（业务）采购科用户对应业务科表O_CUserYDept（系统初始化,即采购科对业务科室的权限设置）
12.（业务）专家-品目表O_ExpGoods（可以清掉）
13.（业务）专家抽取记录表O_ExpTakeInfo（可以清掉）
14.（业务）档案表O_File（可以清掉）
15.（业务）档案审核表O_FileCheck（可以清掉）
16.（业务）档案明细表O_FileDetail（可以清掉）
17.（业务）品目-品牌对应O_GoodsTrade（可以清掉）
18.（业务）指标信息表O_GuideInfo（停用）
19.（业务）指标来源表O_GuideSource（系统初始化,来源于集中支付系统）
20.（业务）资金性质表O_MoneyKind（系统初始化,来源于集中支付系统）
21.（业务）采购计划表O_Plan（可以清掉）
22.（业务）采购计划审核表O_PlanCheck（可以清掉）
23.（业务）采购计划明细表O_PlanDetail（可以清掉）
24.（业务）采购计划函表O_PlanLetter（可以清掉）
25.（业务）采购计划函审核表O_PlanLetterCheck（可以清掉）
26.（业务）采购计划函发送表O_PlanLetterSend（可以清掉）
27.（业务）采购计划函模板表O_PlanLetterTmp（系统初始化,根据财政需求设置）
28.业务）采购计划执行情况表O_PlanProgress（可以清掉）
29.（业务）项目表O_Project（可以清掉）
30.（业务）项目专家表O_ProjectExpert（可以清掉）
31.（业务）项目品目表O_ProjectGoods（可以清掉）
32.业务）供应商诚信档案表O_ProviderGenuine（可以清掉）
33.（业务）供应商品目表O_ProviderGoods（可以清掉）
34.（业务）采购方式变更表O_StockChange（可以清掉）
35.（业务）采购方式变更审核表O_StockChangeCheck（可以清掉）
36.（业务）采购方式变更明细表O_StockChangeDetail（可以清掉）
37.（业务）采购方式变更理由表O_StockChangeReason（系统初始化,根据财政采购法来初始化）
38.（业务）采购方式变更理由对应表O_StockChangeReasonItem（可以清掉）
39.（业务）省政府采购中心业务经费审核表O_TAgencyMoney（可以清掉）
40.（业务）省直单位评价表O_YCheckAgency（可以清掉）
41.（业务）业务科用户管辖预算单位表O_YUserBudgetOrg（系统初始化,即实现业务科室对所管理的预算单位部门的权限）
42.（公用）代理机构表P_AgencyOrg（系统初始化,来源于财政的审批合格的代理机构）
43.（公用）预算单位表P_BudgetOrg（系统初始化,来源于集中支付系统）
44.（公用）部门表P_Dept（系统初始化,由预算单位机构,财政管理机构,采购代理机构等的部门组成）
45.（公用）部门分组P_DeptGroup（系统初始化,由财政管理机构里的部门内人员的业务需求而分组）
46.（公用）专家信息表P_Expert（系统初始化,来源于财政审批通过的采购评审专家s）
47.（公用）品目表P_GoodsItem（系统初始化,来源于财政年初公布的本市的采购品目,以及要求集中采购的品目等）
48.（公用）日志表P_Log（可以清掉）
49.（公用）机构表P_Org（系统初始化,来源于预算单位,代理机构,财政管理机构）
50.（公用）组织形式P_OrgForm（系统初始化,来源于财政采购法所规定的采购组织形式）
51.（公用）单位类型P_OrgKind（系统初始化,来源于财政对供应商单位性的规定）
52.（公用）参数表P_Param（系统初始化,不能删除,只能按实际情况作适当的修正）
53.（公用）支付方式表P_PayMode（系统初始化,来源于财的支付方式）
54.（公用）职称表P_PostTitle（系统初始化,来源于人事职称信息）
55.（公用）提示信息表P_Prompt（可以清掉）
56.（公用）供应商表P_Provider（系统初始化,来源于财政对采购评审通过的供应商）
57.（公用）区域表P_Region（系统初始化,来源于对区域的划分,数据来源于集中支付系统）
58.（公用）学历表P_Schooling（系统初始化,来源于对学历的划分）
59.（公用）采购方式表P_StockMode（系统初始化,来源于政府采购法对采购方式的规定）
60.（公用）行业主体分类P_TradeMainKind（系统初始化,来源于国家财政对事业单位的行业分类标准）
61.（公用）品牌表P_TradeMark（系统初始化,来源于财政对采购品牌的需求）
62.（公用）行业部门分类P_TradeSubKind（系统初始化,来源于国家财政对事业单位的部门分类）
63.（公用）用户表P_User（系统初始化,首先内置系统管理员999999,实现对基础数据的管理能为初始化其它的用户和用户与用户之间的管理权限关系,它包括系统管理员,预算单位用户,财政业务科室用户,财政采购科用户,采购代理机构用户,供应商用户等）
64.（公用）常用词汇表P_Word（系统初始化,来源于财政审批中的常用语）
65.（权限）模块信息表RB_Module（系统初始化,使用系统中原有的数据）
66.（权限）模块动作表RB_ModuleAction（系统初始化,使用系统中原有的数据）
67.（权限）角色表RB_Role（系统初始化,使用系统中原有的数据）
68.（权限）角色权限表RB_RoleRight（系统初始化,使用系统中原有的数据）
69.（业务）指标额度信息表G_budget（可以清掉）
70.（业务）政府采购预算科预算_业务科室查询G_budget_ys_cs（可以清掉）
71.（业务）政府采购预算科预算_预算单位查询G_budget_ys（可以清掉）
1.3.2初始化基础用户及表数据
0.首先要初始化登录系统的超级用户administrator,它是写在配置文件中的
E:
\GovStock\web\WEB-INF\config\administrator.properties
#WedApr0610:
18:
53CST2005
admin=administrator
password=513A086D1ECC9A8E14D05F55FA726A2D
这里是加密后的口令,实院的为888888777777
有了此超级用户到系统的P_user中生成一个系统用户999999系统用户,它必须内置
口令888888=21218CCA77804D2BA1922C33E0151105
所存表为P_user
记录为{[]}
用此用户来建立其它的角色以及分配菜单等
1.模块设置：
设置系统所有的各个模块，及各个模块下面的具体的子菜单，以及作为各个叶子节点的子菜单的入口动作连接，以及其它的相关动作的连接。
2.角色定义：
对系统的所有的用户进行分类后得出的角色的类别并设置各个类别的角色所管理的模块及具体的菜单。
也就是角色是对应菜单来进行分配权限的.
在这里要建立用户角色,所存表为rb_role（rolecode,rolename,rolekind）
这里的rolekind是系统设计最初就定义好了,便于后面在科理业务数据时对于同一个类型下面的不同的角色来作科理的,其初始化对应的值为
{[A1:
预算单位经办人],[A2:
预算单位负责人],[B1:
财政业务科经办人],[B2:
财政业务科分管负责人],[B3:
财政业务科负责人],[C1:
采购科经办人],[C2:
采购科分管负责人],[C3:
采购科主管负责人],[D1:
代理机构经办人],[D2:
代理机构分管负责人],[D3:
代理机构负责人],[S1:
系统管理员],[Z1:
其他]}
因此在初始化时直接建立上面的值就可以了.
3.机构内置:
系统中的财政管理机构是内置的也就是直接在数据库表中先录入此记录,在本系统中内置的机构为”孝感市财政局”,它的机构类型为’C’所在的表为P_org.（orgcode=0,orgname=孝感市财政局,orgkind=C）.下面是一个相关的介绍:
系统中的机构类型有三种即p_org.orgkind=[C,Y,D]
C:
表示财政管理机构单位,一般系统中只有一个财政管理机构单位;
Y:
表示财政预算单位,系统中的此类单位较多且按级别分为一级,二级,三级,以及按单位的上下级关系又有上级单位的属性,此属性表现在预算单位表P_budgetorg表中.
D:
表示财政代理机构单位,系统中此类单位比较的少.它的主要来源于p_agencyorg表中的数据.p_agencyorg（agencyorgcode,agencyname）.
4.部门管理:
在这里要按照部门的类型来建立此类型下的部门,以及此部门所属的机构.首先部门存放的表为P_dept（deptcode,deptname,orgcode,deptkind）分别对应为部门表（部门代码,部门名称,所属机构编码,部门类型）,其中这里的P_dept.deptkind=[A,B,C,D,E,F]=[预算单位采购管理部门,财政部门主管业务科,财政部门政府采购管理科,财政部门国库科,代理机构采购业务部,供应商采购部门]
那么首先要建的部门为:
B财政部门主管业务科即财政的那几个业务科室部门.即[办公室,预算科,国库科,行政政法科,科教文科,农业科,经济建设科,社保科,企业科,商贸科,综合科,农业综合开发办公室,社保离退休,国库支付中心].
然后接着要建的就是:
C财政部门政府采购管理科的部门,这里只有一个即[政府采购科]
{注:
这里的C类部门也是内置的,即要手工从后台录入具体的记录如下:
P_dept（deptcode=0,deptname=政府采购科,orgcode=0,deptkind=C）,其它类别的可以通过前台程序来建立}
这里的B,C类型的部门它们的所属机构就是开始手工在P_org表中设立的财政管理机构”孝感市财政局”.
这里还有A,D,E,F没有建立部门那它们的情况是这样的:
A类部门:
要先去录入预算单位P_budgetorg,同步产生预算单位机构p_org表中预算单位的记录且p_org.orgkid=’Y’,有了这些记录后就可以为此类部门的名称了,我们这里都设A类部门的部门名称为”财务科”.{这里的预算单位的信息来源于国库集中支付系统中的预算单位信息由接口程序自动科理后导入}
E类部门:
要先去录入代理机构,可以通过系统的前台录入录入后生成记录存于P_agencyorg表中同时同步产生一份代理机构的信息存于P_org表中它的类型即P_org.orgkind=’D’,有了代理机构的信息后就可以给它新建部门名称了,本系统建立的信息为
P_dept（deptcode=974,deptname=业务部,orgcode=D1,deptkind=E）
这里还剩下D,F两类部门类型的部门还没有建立,在本系统中暂时不使用.
5.区域信息:
录入区域信息.信息将存于P_region表中（regioncode,regionname,superregion）
{[430000,湖北省,000000],[430074,武汉,430000],[443000,宜昌市,430000]}
6.行业部门分类:
它是预算单位的一个属性,用于说明此采购预算单位所属的行业部门分类,现有系统中的数据为:
p_tradesubkind（tradesubkindcode,tradesubkindname）
{[1,行政管理部门],[2,公检法司部门],[3,农林水气象部门],[4,工业交通等部门],[5,文体广播部门],[6,教育部门],[7,卫生部门],[8,科学部门],[9,抚恤社保部门],[10,其他]}
7.行业主体分类:
它是预算单位的一个属性,用于说明此预算单位所属的行业主体分类,现有系统中的数据为:
P_trademainkind（trademainkindcode,trademainkindname）
{[1,国家机关],[2,事业单位],[3,团体组织],[4,企业单位],[5,其他]}
8.预算单位：
录入预算单位的信息；这里可以手工录入也可以由程序从集中支付系统中导入,由于单位是分级别了的,那么应首先录入一级预算单位,再才能录入二级预算单位,依此类推.因此最好的方法是先由外部程序导入后,对于没有导入进去的个别预算单位可以手工录入.
9.单位类型:
它是代理机构单位的一个属性,用于说明此代理机构单位的类型,它存于P_orgkind（orgkindcode,orgkindname）
{[1,行政事业],[2,企业]}
9.代理机构单位：
录入代理采购实施单位的信息；
10.部门分组：
主要对机构---孝感市财政局的下面的财政部门主管业务科,财政部门政府采购管理科两个部门类型下面的部按照办理业务的要求进行分组,所存记录于P_deptgroup（deptgroupcode,deptgroupname,deptcode）=（部门分组代码,部门分组名称,被分组的部门代码）
11.用户信息:
按照最初前面定义好的用户角色来新建用户,并首先指明此用户的角色,然后指明此用户所属的单位机构,再指明此用户所在此机构的那个部门,如果这个部门存在部门分组则还要指定它所在的部门分组,这里作为预算单位用户角色的经办人和负责人等是没有分组的.只有先产生了用户信息,特别是财政部门如财政部门主管业务科,财政部门政府采购管理科两个部门的用户先建立后才能建业务科室权限设置,因为业务科室权限设置,是首先选中财政部门主管业务科室的某个用户后,再来选他所能管理的单位的.同理采购科室权限设置之前也是要先给它先建立用户,然后选中具体的某个用户后来再选它所管理的财政部门的业务科室部门.所存表为P_user（usercode,username,password,deptcode,deptgroupcode,rolecode）=（用户代码,用户姓名,用户口令,用户所在部门代码,用户所在部门分组代码,用户角色代码）
12.业务科室权限设置：
即设置财政部门的主管业务科室部门内各个部门的分组内的用户所管理的预算单位；
13.采购科室权限设置：
即设置财政部门的采购科部门的分组内的用户所管理的财政部门的主管业务科室。
14.参数信息:
用于在审批计划时设置的审计划的一些分析的参数所存表为:
P_parm（paramcode,value,content）=（参数代码,参数值,参数内容提示）
这是一个内置表,一般只能修改其参数值的范围,不能修改参数代码.而且只能增加参数,不能删除参数.现初始化数据为
{[P1,500000.00,校验计划中项目采购方式的金额限额，单位元]
[P2,1,档案审核控制日期，单位天]
[P3,3,跨业务科上报计划控制日期，单位天]}
15.预算项目:
用于在填写采购计划时说明采购计划资金是来于财政的那个预算的项目所存表为O_budgetproject（budgetprojectcode,budgetprojectname,）=（预算项目代码,预算项目名称）
它的初始化的数据是来源于财政的集中支付系统,下面是初始化的数据:
{[001,基本支出],[001001,人员支出],[001002,公用支出],[001003,个人和家庭补助],[002,项目支出],[002001,行政事业项目],[002002,基本建设项目],[002003,其他项目],[003,转移项目],[004,往来项目]}
16.预算科目:
用于在填写采购计划时说明采购计划资金是来于财政的那个预算科目,所存表为O_budetsubject（subjectcode,subjectname）,它的来源是集中支付系统,即从集中支付系统中导出预算科目到本地表中,并且排列的序列不要变化.
17.资金性质:
用于在填写采购计划时说明采购计划资金是来于财政的什么样的资金性质,所存表为O_moneykind（moneykindcode,moneykindname）,它的来源是集中支付系统,即从集中支付系统中导出资金性质到本地表中,并且排列不要变化.
这里有一个它的初始化的数据为
{[001,预算内],[001001,经费拨款（补助）],[001002,政府性基金],[001003,列收列支收入],[002,预算外],[002001,政府性基金],[0020
升级会员 