发放月饼业务需求Word文件下载.docx
《发放月饼业务需求Word文件下载.docx》由会员分享，可在线阅读，更多相关《发放月饼业务需求Word文件下载.docx（23页珍藏版）》请在冰豆网上搜索。
工作流或任务被作废，流或任务所有相关表单、过程均视作无效。
（3）终止。
工作流或任务在不应结束时，由外界干预强行终止。
<
终止>
应记录终止原因。
7.流转方式：
当任务下存在子任务，那么这一属性明确子流程之间的关系。
分为：
（1）串行：
子任务按前继值排序，顺序执行。
（2）并行：
子任务同时执行。
（3）分支：
根据父任务产生的分支条件值，确定哪些子任务要执行（并行方式）。
8.反馈：
当任务下存在子任务时，父任务是否需要等待子任务全部完成后才可以进入下一个兄弟任务环节执行。
9.子任务先行：
当任务下存在子任务时，确定是先执行子任务还是先执行父任务。
10.激活方式：
任务由<
发起>
状态变为<
待办>
状态称为激活，激活的方式有：
（1）人工激活。
通过系统<
提交>
功能实现任务的激活。
（2）定时激活。
通过设置预定时间触发任务的激活。
（可以设置预定后的延时时间）。
（3）外界激活。
其他在系统预置的条件获得满足时激活任务。
11.回退：
由当前一个激活任务回退到指定的任务环节，回退过程中涉及的所有任务均置于<
保留>
状态，被回退到达的任务，作为新的任务添加到工作流实例作为当前激活的任务。
12.事件：
工作流在运行时可能产生的一些动作，这些事件涉及时间或自动条件判断的由系统事件服务组件提供支持，分为：
（1）任务跳转：
当满足预设条件时，指定的任务被激活。
（2）工作流终止：
当满足预设条件时，触发工作流被终止的事件。
以上功能实际实现请参照技术需求标准，竞价书中应就如何完成工作流维护平台给出基本的数据库设计、组件运行流程图和组件接口规范设计。
二、集约化议事流程：
（一）功能概述：
对于工作流的某个任务，需要进行讨论决定的问题，可以通过将任务绑定议事流程的方式最终形成决议达成共识，并使流程可以顺利地进入下一个环节。
（二）流程图：
（三）模块说明：
1.集约化联动联席会议。
通过多个部门进行集中会议讨论的方式，形成最后的统一认识，其间应经过会议通知、会议纪要等合法形式完成一次联席会议。
2.征询意见流。
通过书面征询的方式实现业务讨论，对于不能解决的问题还可以通过发起联席会议进一步达成决议。
（四）表证单书：
1.会议通知：
会议通知
部门或人员名称>
：
<
召开会议依据>
，现定于<
时间>
于<
地点>
请<
与会对象>
参加<
会议名称>
会议议程及内容概要>
与会者需要准备的事项>
其他需要说明的情况>
是否需要回执>
联系人>
联系方式>
<
落款>
<
通知发布日期>
表式说明：
本表用以发起一次会议，会议是否需要审核，由所属任务定义决定。
是否需要回执：
与会者在接到通知后是否需要向会议组织者确认。
2.会议纪要
会议纪要
时间：
地点：
人员：
会议名称：
会议摘要：
会议内容简述>
。
一、领导讲话：
二、工作汇报：
记录要素：
根据工作布置情况负责人就工作情况、进度及相关协调事宜予以记录。
>
三、工作布置及决议：
工作布置：
布置人、工作名称、工作目标、内容、参与的部门、人员及职责、预定完成工作的时间节点。
决议：
形成决议的内容。
<
<
发布时间>
本表用以记录会议内容并备案。
3.征询意见书
征询意见书
联动编号
联动属性
征询项目名称
项目概要
附件名称：
附件名称
概述
上传日期
编写人
意见回复区：
部门：
三、各种级别审批流程：
对于所有的业务流程，审批流程是一个复用性极高的流程，是为了配套各种专属工作流中针对一些需要各级领导终审的任务预先制定的各级终审审批模式，分为：
居委领导审批、分管领导审批、主任终极审批三类。
1.审批：
审批人员根据报告意见及下级审批结果，选择审批意见（如果不是终审分为：
拟同意/拟不同意/退回，如果是终审则分为：
同意/不同意/退回），并按要求填写文字审批意见，完成审批动作。
2.提交：
如果此级审批不属于终审，应将现有的审批结果提交至工作流模板中预置的上级人员进行审批。
回收
工作环节审批表
所属联动项目编号
所属工作表单编号
工作表单名称
审批人
审批日期
审批结果
同意（拟同意）不同意（拟不同意）退回
审批意见：
1.本表为单一审批步骤表式，一个审批流根据审批流的定义由多个这样的表式组成；
2.本表不单独存在，总应与某一工作表单相结合；
3.后一个审批环节可以看见前到所有审批环节的结果；
4.审批结果中如本环节属于终审环节则为同意/不同意，过程审则为拟同意和拟不同意；
5.在实际审批过程中可不签署审批结果，直接执行回退功能，要求修改前一环节的工作内容；
6.审批流种类可以进行预定义，在集约化联动平台中审批流种类枚举：
1）所级终审。
发起部门领导审
2）科级终审。
发起部门领导审科员审科长审
3）局级终审：
发起部门领导审科员审科长审局长审
4）联动办终审：
发起部门领导审联动办业务组负责人审联动办数据组负责人审联动办副主任审
5）联动办领导小组终审：
发起部门领导审联动办业务组负责人审联动办数据组负责人审联动办副主任审联动办领导小组常务副组长审；
所属联动项目编号、所属工作表单编号和工作表单名称指明该审批环节审批的工作表单，在系统中应替换显示为整个工作表单的实际内容。
四、各类业务信息化需求处理流程：
信息化需求处理流程主要包括业务需求填写、技术需求填写、需求审批、需求办理四个模块。
主要是通过项目管理需求规划实现各部门之间的工作流程周转，实现对这些需求任务的工作标准、工作期限、数据结果等内容的固化，用信息化的手段去督促各个项目需求模块保质保量的完成自己的工作任务。
（二）模块说明：
1．业务需求填写：
业务需求填写模块的功能是针对一些单个的、专项的业务的需求进行填写、制发新的业务需求。
操作人员：
管理员、相关业务科人员、部门领导。
业务需求的填写是整个项目需求的源头，填写的主要要求：
（1）需求填写时，包括如下信息内容：
发起岗位、业务来源、业务类别、业务小类、需求类别（一般类、指标类）、需求名称、需求处理时限、需求内容要求、办理结果获取方式（可以设定自定义格式）等；
以及纳税人明细信息：
纳税人名称、纳税人识别号、纳税人所属税务机关、主管税务员等等和附件，附件一般为OFFICE格式。
注：
对于一般类的业务需求，如果是针对具体的管理所发起的，由管理所部门领导终审同意即可；
如果没有针对特定的管理所发起需求，需要通过相关业务科室来提交业务需求。
对于指标类的业务需求，需要由局领导审核。
（2）如果多个部门同时提交了大致相同业务需求的，业务需求分配人员可根据需求的版式，按部门生成任务，即相同的业务需求只需要提交一次即可。
下一次在需要类似的业务需求时，可根据上次的需求直接提交。
（3）业务需求的填写需要根据模板进行定制，需要对业务来源、业务类型、业务处理时限、工作表单等内容的定制。
业务需求填写具体可以实现的功能：
（1）对于相似的业务需求可以实现业务的横向、纵向流转。
（2）可以根据不同的业务需求的类别、来源将不同的需求转入相应的部门去处理，实现对每一部门需求完成情况的结果统计。
（3）可以对业务需求进行结果统计，可以根据模块中已定义的表单，也可以自定义不同的表单格式；
如果没有自定义的时候默认为模块中的表单格式。
（4）可针对某项需求，选择结果的处理方式，如是否需要反馈等。
业务需求填写的方式：
业务需求填写主要是指各级人员根据实际工作中的需要，需要通过对业务需求表的手工填写，自行设定需求的内容、时限、结果格式。
通过业务需求表可以实现管理员、业务科室人员、项目小组成员自行发起需求功能的实现。
2．技术需求填写
技术需求填写模块是在业务需求填写之后进行填写，主要包含三方面的需求表：
数据处理、工作台账、预警方案。
技术需求填写的主要要求：
数据处理表：
发起岗位、数据来源、数据处理目的、数据处理时限、数据处理要求、数据处理结果格式（可以自行定义格式），附件等。
工作台账表：
发起岗位、提议人、台账的使用范围、台账明细数据的来源、台账的输入格式（自行定义）、台账的权限分布、台账的查询格式、台账的汇总格式等。
预警方案表：
发起岗位、提议人、预警方案名称、预警级次（一级、二级、三级）的设置、预警的数据来源、方案的解释、各个参数的解释、指标条件的输入等。
对于数据处理表的需求，如果是针对具体的管理所发起的，由管理所部门领导终审统一即可；
对于工作台账表的建立需求，需要通过相关业务科室来提交业务需求；
对于预警方案的技术需求，需要由预警方案对应的部门提出并提交局领导审核。
（2）技术需求可以针对同一个业务需求形成一个或多个不同的处理结果，可以根据不同的需求填写。
（3）技术需求的填写需要根据模板进行定制，需要对数据来源、需求类型（数据处理、工作台账、预警方案）、需求处理时限、工作表单等内容的定制。
技术需求填写具体可以实现的功能：
（1）对于相同的技术需求可以实现不同的数据处理。
可以对数据做到充分的分析运用。
（2）可以根据不同的技术需求的类别将不同的需求转人相应的模块去处理，实现对每一技术需求情况的分类别管理。
3．需求审批
项目审批主要是对业务需求、技术需求的审批，使用标准审批流过程。
4．需求办理
项目办理模块主要是对需求项目制发的操作，实现需求的转发、分配功能。
具体功能如下：
（1）需求转发
可以将业务、技术需求直接转发给小组内其他人员，如果有增加或修改的内容要求，可以通过附件文档修改。
在需求遇到了特殊情况认为无法完成时应当终止，终止原因需要在需求表上写明，以便能够增加以后需求填写的科学性、可行性。
（2）需求分配
需求分配包括小组内直接分配和分管局长需求分配两项。
要求如下：
✧小组内直接分配：
可指定专人直接办理。
✧分管局长需求分配：
可以把需求任务逐条选择主管人员，或选择指定人员进行分配。
✧对已分配办理的任务，如因人员特殊情况不能处理的，可将已分配的任务转其他人员办理。
（三）相关表单：
业务需求申请表（通用）
项目名称：
项目编号：
申请部门
提议人
部门负责人
填表日期
目的要求
具体内容：
意见
签（章）
分管局长
信息技术科负责人
信息技术科经办人员落实情况
申请部门反馈情况
指标体系业务需求表
指标名称
编号
归属部门
版本号
分析目的
计算公式
指标格式
时间属性
数据来源
结果分析
处理意见
负责人
科室经办人员落实情况
归属部门反馈情况
四，指标体系业务需求填表说明：
1．归属部门：
为发出申请提出指标需求的部门
2．编号：
自动生成
3．版本号：
为指标按测试修改后的第几次改动作相应的版本号的规定。
4．抽取数据结果的形式：
（明细查询/汇总统计）列明抽取数据结果中包含的各字段
若为明细表，列明5条明细记录作为数据参考
5．抽取数据结果中包含的字段：
行次：
（例如：
时间，税号，代码，名称，所别，专管员，状态，国名经济行业等）
列次：
6.时间：
yyyymmdd（含/不含）——yyyymmdd（含/不含）
时间属性：
（财政年度/会计年度），（申报日期/入库日期/所属期/）
8.抽取数据范围：
（所/全局）
9.分类方式：
按哪个字段分类（例如：
税种，所别）
10.数据字段的注解（可用举例的形式表示）或数据来源（抽取数据中重要字段的注解或数据在系统中可查询到的位置）
字段：
税号，举例：
对应数据库中表v_hk_qyjbxx表中NSRSBM字段
抽取数据来源：
如：
310109133122343上海虹口金属建材公司系统中位置（征管系统——一户式查询——申报信息——已申报明细——企业所得税月季度申报A类（非总非分），所属日期始2009-01-01，所属日期止2009-03-31——企业所得税A类主表——利润总额（行次3），累计金额（列次2）
11．结果分析：
在结果分析中反映若为异常数据的条件，并表明异常数据显示的形式。
工作台账需求表
发起岗位
使用目的
使用范围
数据来源格式、输入格式
使用权限分布
查询格式
汇总格式
预警方案需求表
方案名称
方案说明
指标配置
指标代码
权重公式
最大取值
最小取值
级别描述
级别
描述
取值范围
参数说明
参数名
参数解释
参数格式
默认值
填表说明：
1．归属部门：
2．编号：
3．版本号：
4．方案说明：
简述该方案的功能目标等基本情况。
5．指标配置：
说明该方案所配置用的指标信息。
其中：
指标代码为该指标的唯一编号，权重公式为该指标值在本方案中所占权重的表达式，其计算结果用于判断预警级别。
最大/最小取值为权重公式计算结果的阀值。
6．级别描述：
描述该方案的预警级别信息。
取值范围中填写属于本级预警的分值，分值由指标配置中权重公式计算得出。
7．参数说明：
定义该方案输入的参数。
参数格式为数据输入的形式，如以‘201012’表示2010年12月。
默认值为提供的默认参数，可在实际使用时按需要修改。
8．结果分析：
该方案运行结果的简要说明。
应用系统需求变更申请表
系统名称
问题类别
□界面□功能
问题描述：
更新建议：
1．软件名称：
希望修改的软件的名称
2．问题类别：
界面——仅修改软件的界面外观，不涉及到具体功能；
功能——对某个模块的具体功能进行补充，修正。
3．问题描述：
简单描述当前软件的现状，可以以截图的形式在附件中辅助说明。
4．更新建议：
对软件进行更改的方式。
若涉及软件功能的更改，则需提供新功能的详细说明。
技术需求部分：
一、基本技术需求：
1.数据库环境：
使用ORACLE11作为后台管理数据库。
2.应用系统环境：
Web方式后台应用使用MicrosoftIIS6.0建立，客户端使用IE6.0以上浏览器。
应用程序方式必须满足部署于WindowsXP/Windows2000/Windows2003操作系统之下。
3.系统开发环境：
使用MicrosoftVisualStdio.Net作为程序开发工具。
二、区局信息技术一体化需求：
区局历年来的信息化项目开发逐步积累了起一套成熟的数据库管理软件开发标准以确保系统的安全性和可持续应用性，
1.数据库建设标准：
所有工作流内使用的实体数据表（包括工作表单）依据数据库五范式和安全原则均应遵循下列原则：
（1）数据正表与数据历史表同存：
每张数据表（称为正表）都对应一张历史表，数据结构与正表完全相同，其命名规则为H_<
正表名称>
，主要存储被修改前或已经删除的正表数据内的记录。
（2）每个数据表均有三个保留字段：
字段名：
RecordID；
类型：
数字型12位
作用：
唯一标识记录身份,必须是正整数，记录每进行一次修改，现有记录的RecordID获取P_MaxCode中与RecordID相关的MaxCode的值（MaxCode值此时自动+1），原RecorID记录移动存入历史表；
记录删除
字段名:
StateFlag;
数字型4位
标识记录的状态。
枚举：
0.有效/1.保留/2.删除
AutoCode;
数字型12位
唯一标识业务身份，记录修改RecordID发生变动，但AutoCode不发生变动。
（3）每一用户下具备步长分配表（P_MaxCode）和安全日志表（P_SafeLog）。
表名：
P_MaxCode为需要系统自动取值的字段提供当前可用的值。
字段名
类型
长度
刻度
说明
MaxCode
数字型
12
FieldName所列字段可以当前可以使用的值，应用程序提供维护该字段值。
TableName
文本型
50
字段所属数据表名称，必须大写
FieldName
255
字段名称，必须大写，其中RecordID属于所属用户下全局分配值。
表名：
P_SafeLog为所用工作流、工作表单存储历史操作踪迹信息。
EmployeeCode
操作记录用户标识（本系统使用域用户名）。
InputDate
日期型
记录被编辑的时间
RecordID
当前有效记录的RecordID。
PerRecordID
修改前的RecordID，如果是添加记录则为0，如果是删除记录则RecordID*-1
记录所属数据表名称
以上数据表标准的部署均由委托方提供的数据字典工具完成。
受托方需按上述规则完成数据库的编辑操作（包含新增、修改、删除）。
2.人员及权限应用标准：
区局网络采取域管理方式，并使用统一的人员、权限信息配置系统，并由委托方提供统一的.Net组件调用接口，系统开发过程中仅需对获取的人员、权限配置信息进行功能实现。
3.各类数据汇总应用标准：
伴随区局数据仓库的初步建立，所有用于数据分析应用的数据查询SQL、DDL语句或存储过程调用均统一置入委托方提供的数据处理工具中，同时委托方提供统一的.Net组件调用接口供开发执行使用。
4.资源发布标准：
系统内所有的界面、功能、人员信息、权限等等可由人员在前台操作控制的模块均可称为资源，这些资源均需通过分类分级管理后在前台界面展示，分类分级的内容均应统一存在于标准的表结构，结构如下：
StTreeInfo标准<
树>
主表，存储各类树型结构的主表,其与<
StNodeInfo>
表共同构成完整的树描述。
用于标识记录的唯一。
StateFlag
记录状态
AutoCode
标识树的唯一。
TreeName
树名称
StenoCode
速记符，树的代码表现形式
TreeType
4
树类型，根据不同应用程序自行定义。
StNodeInfo标准<
节点表、详细描述树的节点信息,各节点均应与<
StTreeInfo>
主表中的记录形成隶属级联关系。
标识节点的唯一。
NodeTitle
节点标题。
ParentCode
父节点代码，本表中表示本节点的父节点的<
AutoCode>
父节点为根节点的则为<
0>
PrevCode
1
升级会员 