PRD例子07产品需求文档⑦--票据管理需求文档
- 格式:docx
- 大小:91.45 KB
- 文档页数:11
prd文档范例PRD,即产品需求文档,是记录某项产品的所有特性和功能的文档,有助于更好地掌控产品的设计和开发过程。
下面,我们将利用一个最简单的例子,来演示产品需求文档(PRD)的内容和写法。
首先,这里介绍的是一款名为“智能书桌”的产品,它是一款多功能的桌子,可以让用户在学习和工作时使用多种便捷的设备。
第一,PRD文档名称。
文档的名称可以根据产品的名称或它的功能而定,例如:“智能书桌 PRD”。
第二,PRD的背景介绍。
此部分内容一般包含产品的简介、用户需求、市场需求等等,例如:“智能书桌是一款符合现代it生活节奏的多功能书桌,可以满足用户学习和工作的需求,且采用智能化硬件设备,满足现代it用户的多样化需求,并开拓了一个新的市场领域。
”第三,PRD的目标定位。
产品的目标定位应该在每个功能中给出,以便对产品的设计思路有一个清晰的把握,例如:“智能书桌的主要目标是为用户提供更加便捷的学习和工作环境,使用智能化硬件设备,支持一键式便捷操作,提供舒适安全的使用体验,并降低使用者的精力消耗。
”第四,PRD的功能描述。
这部分内容是对PRD的主要功能进行具体描述,包括功能的特点、需要开发的功能、技术实现的方法和要求等,例如:“智能书桌可以支持基本的书桌功能,如桌面照明、桌面电源、桌面散热等;可实现一键式便捷操作,支持智能手机、平板等设备的无线连接;支持红外感应照明,当用户进入房间时,灯光可以自动开启;支持用户定制化的设计,可以根据用户实际情况进行设计。
”第五,PRD的设计要求。
产品的设计要求是在确定功能后写出,以决定产品的整体设计,例如:“智能书桌应采用现代简约的风格,以更好地与客户的室内环境相融合;桌子材质应采用安全环保、耐用舒适的材料,同时要满足坚固耐用的要求;散热系统要采用远红外照明灯,以减少桌面发热。
”第六,PRD的设计原则。
最后,产品设计的原则是指确定产品的最终形态,例如:“智能书桌的设计原则应该是简洁、安全,保持现代简约的风格,突出家庭的温馨舒适的氛围,以及良好的人体工程学,优化产品的使用体验。
[PRD]产品需求文档1. 介绍本文档旨在详细描述产品的需求、功能和特性,以供开发团队参考。
通过该文档,开发团队可以准确理解项目目标,并满足用户需求。
2. 目标产品的目标是创造一个易于使用、功能强大的软件应用程序,满足用户的特定需求。
该应用程序将提供以下主要功能:•提供用户注册和登录功能•允许用户创建个人资料和编辑信息•提供用户发送和接收消息的功能•允许用户搜索并加入兴趣群组•提供活动发布和参与功能3. 功能和特性3.1 用户注册和登录用户可以通过输入邮箱和密码进行注册。
注册成功后,用户可以使用注册的邮箱和密码进行登录。
3.2 个人资料用户可以创建个人资料并编辑相关信息,包括姓名、头像、生日、兴趣等。
用户也可以随时更新个人资料。
3.3 消息功能用户可以发送和接收消息。
用户可以选择发送消息给其他用户、给兴趣群组或者给特定活动。
用户可以在收到消息后进行回复。
3.4 兴趣群组应用程序将提供兴趣群组功能,用户可以搜索感兴趣的群组并加入。
在兴趣群组中,用户可以参与讨论、分享资源和组织活动。
3.5 活动功能用户可以发布自己的活动,并邀请其他用户参加。
用户还可以搜索并参加其他用户发布的活动。
在活动中,用户可以查看活动详情、参与讨论、查看参与人员等。
4. 用户界面设计产品将提供直观且易于使用的用户界面。
以下是主要的界面设计要求:•用户注册和登录界面•个人资料编辑界面•消息收发界面•兴趣群组搜索与加入界面•活动发布和参与界面5. 技术要求产品将使用以下技术和工具进行开发:•前端开发:HTML、CSS、JavaScript、React框架•后端开发:Node.js、Express框架、MongoDB数据库6. 风险与挑战在产品开发中,可能会面临以下挑战和风险:•用户隐私保护:需要确保用户的个人信息安全,并遵守相关法律法规。
•网络安全:需要防范用户注册和登录过程中的网络攻击和数据泄露风险。
•用户体验:需要设计用户友好的界面,提供便捷的操作方式,以满足用户的需求。
PRD需求文档模板PRD (Product Requirements Document) 需求文档模板是一种用于记录产品需求的文档。
以下是一个可能的PRD模板,包括产品概述、用户需求、功能需求和非功能需求等部分。
1.产品概述产品概述提供了对产品的整体目标和作用的简要说明。
-产品名称:[产品名称]-产品目标:[产品目标的简要概述]-主要优势:[产品与竞争对手相比的主要优势]2.用户需求用户需求部分描述了产品应为用户提供的核心功能以及用户期望解决的问题。
-目标用户:[产品所面向的主要用户群体]-用户问题:[用户在使用类似产品时遇到的问题]-解决方案:[产品将如何解决用户问题,提供哪些功能]3.功能需求功能需求部分列出了产品的具体功能或特性,以确保产品能够满足用户需求。
-功能1:[功能的具体描述]-子功能1:[功能的子功能1]-子功能2:[功能的子功能2]-功能2:[功能的具体描述]-子功能1:[功能的子功能1]-子功能2:[功能的子功能2]4.非功能需求非功能需求部分描述了产品的性能、可用性、安全性等方面的要求。
-性能要求:[产品的性能要求,如响应时间、处理能力等]-可用性要求:[产品的可用性要求,如易用性、用户界面友好性等] -安全性要求:[产品的安全性要求,如对用户数据的保护等]5.约束和限制约束和限制部分说明了在设计和开发产品时需要遵守的约束条件和限制性要求。
-时间限制:[产品的上线时间限制]-技术限制:[在开发过程中可能遇到的技术限制]-资源限制:[在开发过程中可能遇到的资源限制]6.使用案例使用案例部分描述了产品的典型使用场景,以便开发团队更好地理解用户需求。
-使用案例1:[使用案例的详细描述,包括用户角色、行为和期望结果]-使用案例2:[使用案例的详细描述7.需求优先级需求优先级部分提供了对各个需求的优先级排序,以帮助团队在开发过程中确定重点。
-需求1:[需求描述]-优先级:[高/中/低]-需求2:[需求描述]-优先级:[高/中/低]请注意,以上是一个可能的PRD模板,具体的需求文档根据产品和项目的实际情况可能会有所不同。
产品经理需求文档(PRD)怎么写作为一个产品经理来说PRD是一个很基础的工作了,也可以说是产品经理用来沟通的重要桥梁。
什么是PRD?PRD是产品经理用来表述产品功能或需求的方式,就像研发人员需要的开发文档一样起到了重要的作用,但是你们产出的PRD是需要交付给公司业务内所有人员的,所以我们撰写的PRD一定需要详细,且可以让他人更好的阅读。
当然,如果你有着明确的需求,可以直观明了的描述出来那么PRD自然而然就形成了。
PRD的好处降低沟通成本:在项目进行时有可能会因为时间推移研发或测试忘记部分需求,然后一遍一遍的过来询问。
这时候就需要有一个文档来向所有成员记录需求信息,从而降低沟通成本。
确定需求:部分公司的产品记录可能会遇到老板经常变更需求的情况,这时候就需要明确PRD,到时候也可以直接拍给老板看看。
也起到了大家约束老板需求的作用。
为新人提供指南:当项目进入新的人员时,可以让新人更快的了解产品需求。
而且也可以供后续产品经理查阅,快速熟悉产品内容。
给予测试验收标准:测试人员可以根据PRD去验收产品质量。
PRD的结构1、产品名称所有给别人看的文档都是得有名称的,不然大家根本无法直观知道自己看的是什么。
要注意的是最好这里直接占满页居中(别问为啥,因为美观)。
2、版本历史写上版本历史的主要用途也就是为了大家在修改或迭代的时候避免出现一些细节性错误,并且可以让研发直观的看出你所修改的地方。
PRD-版本历史如图中的版本历史里面主要包含了修改时间、版本、变更人、描述、修改人;在这里的描述中产品经理需要说明自己修改的需求在目录中的编号,让开发可以直观的查看到本次修改的内容。
3、目录因为PRD文档页面少则几页多则几十页,为了让研发快速定位自己负责的板块,所以目录也是必不可少的。
在Word中直接”引用-插入目录“就可以自动生成目录了。
(具体结构如下)4、项目介绍项目的介绍主要分为3个方向:项目背景:讲述项目/需求产生原因,以及是如何贴合当前公司业务进行的项目。
prd文档模板案例产品需求文档模板1. 介绍产品需求文档(Product Requirement Document,简称PRD)是产品开发过程中的重要文件之一,它记录了产品的功能、性能、特性等各方面的需求信息。
本文档为PRD模板,旨在帮助产品经理或相关人员编写完整、详细的PRD。
2. 文档结构本文档包含以下几个部分:2.1 项目概述:对产品进行整体介绍,包括背景、目标用户、竞争对手等。
2.2 需求列表:列出所有的需求点,并对其进行详细描述。
2.3 功能说明:对每个需求点进行功能说明和实现方式描述。
2.4 性能指标:对产品的性能指标进行说明和评估。
2.5 用户界面设计:对用户界面进行设计和说明。
2.6 数据库设计:对数据库进行设计和说明。
2.7 安全性设计:对安全性方面进行设计和说明。
3. 项目概述在此部分中,需要对产品进行整体介绍。
具体内容如下:3.1 背景介绍:简要介绍该产品诞生的背景及原因。
3.2 目标用户:明确该产品面向的用户群体及其需求。
3.3 竞争分析:分析市场上同类产品的优势和劣势,为产品设计提供参考。
4. 需求列表在此部分中,需要列出所有的需求点,并对其进行详细描述。
具体内容如下:4.1 需求编号:对每个需求点进行编号,方便后续跟踪。
4.2 需求名称:对每个需求点进行简要概述。
4.3 需求描述:对每个需求点进行详细描述,包括功能、性能、特性等方面。
5. 功能说明在此部分中,需要对每个需求点进行功能说明和实现方式描述。
具体内容如下:5.1 功能编号:对每个功能进行编号,方便后续跟踪。
5.2 功能名称:对每个功能进行简要概述。
5.3 功能描述:对每个功能进行详细描述,包括输入输出、流程、逻辑等方面。
5.4 实现方式:对每个功能的实现方式进行说明。
6. 性能指标在此部分中,需要对产品的性能指标进行说明和评估。
具体内容如下:6.1 性能指标名称:列出所有需要评估的性能指标。
6.2 性能指标说明:对每个性能指标进行详细介绍和说明。
产品需求文档范文(PRD)产品需求文档(P R D )标题logo 项目名字部门名称提交日期产品提交人项目负责人当前版本号修改记录日期修订版本说明修改人项目成员项目角色姓名| | 邮箱| | 分机备注项目经理产品经理设计制作研发负责测试负责内容负责客服负责文档及培训负责定稿会签PRD 拟制人产品负责人需求方负责人设计负责人制作负责人开发负责人测试负责人技术部负责人最高决策人意见汇总PRD 拟制人意见汇总:产品负责人:需求方负责人:设计负责人:制作负责人:开发负责人:测试负责人:技术部负责人:最高决策人:文档目录1. 总体说明项目概述项目概述简单描述项目的背景、意义、目的、目标等,描述领域知识#详细填写产品项目意图、目标等#待开发的系统的名称;#本项目的任务提出者、目标用户;#该系统同其他系统或其他机构的基本的往来关系(如CRM CMS 用户中心。
)。
功能范围功能范围给出业务逻辑图,类似BUC:描述各角色的职责、与周边系统的关系、全局商业规则用户范围角色描述(涉及到的actor、system 的描述)#描述本项目所服务的最终用户的特点,用户用例等;#如存在管理用户充分说明操作人员、维护人员的教育水平和技术专长,及预期使用频度。
假定及约束假定及约束项目执行环节存在的影响项目质量、进度的事件列表及应对方案词汇表词汇描述(术语与缩写的描述)#列出本文件中用到的本专业,个性定义,外文首字母组词的原词组等。
非功能需求需求描述数据监控针对一个功能模块级别的监控点,必填,并且功能上线 2 周后需要给出数据分析报告性能用户体验。
其他说明其他说明其他任何需要说明的内容参考资料参考资料列出关联资料或可参考网站2. 功能结构功能模块分功能模块功能点优先级功能模块名称 1 分功能模块名称 1 功能点名称1 1 功能点名称21 功能点名称3 1 3. 业务功能流程#产品整体业务流程图4. 业务对象模型# 所有业务对象/实体对象的组成结构及描述 5. 业务对象状态模型#有状态的业务对象状态、转换及描述 6. 用例场景用例整体说明序号用例编号用例名称简要描述1用例名称1 简要描述该用例的场景2用例名称2 简要描述该用例的场景3用例名称3 简要描述该用例的场景用例具体说明用例名称描述业务描述商业目标,用户目的等业务内容需求描述产品需求,需要实现哪些功能点行为者该用例的Actor 界面描述UI 示意图:页面名称Demo 截图1 # 可以标明参看原型对应的页面截图说明1 功能元素功能名称规则流程描述用例1 流程流程说明用例名称2描述业务描述商业目标,用户目的等业务内容需求描述产品需求,需要实现哪些功能点行为者该用例的Actor 界面描述UI 示意图:页面名称Demo 截图 1 # 可以标明参看原型对应的页面截图说明1 功能元素功能名称规则流程描述用例1 流程流程说明#对单个用例的说明可以结合axure #注1:视觉层面的描述通常直接通过Demo 表达(如页面大小,颜色字体字号等)#注2:界面细节,引用界面规范文档(如表格中的文字对其方式)#注3:交互细节,引用交互规范文档(如出错提示的方式)#注4:文案细节,引用文案规范文档(如各种提示文案)7. 风险规避#项目的风险预估及风险规避方案。
PRD产品需求文档参考模板PRD(Product Requirements Document)是产品经理在开发新产品或升级现有产品时所使用的文档,用于描述产品的功能、特性和用户需求。
它是产品开发过程中的重要参考文档,能够对产品的开发过程进行指导和沟通。
下面是一个PRD的参考模板:1.产品概述-产品名称:XXX-产品简介:描述产品的主要功能和特点,以及产品的目标用户。
-产品背景:解释为什么需要开发或升级该产品,并描述市场需求和竞争优势。
2.目标用户-用户画像:对目标用户进行详细描述,包括其特征、需求、行为等。
-用户需求:列出用户的主要需求,包括功能、体验和性能方面。
3.产品功能-功能列表:列出产品的主要功能和特性,并按照优先级进行排序。
-功能描述:对每个功能进行详细的描述,包括输入、输出、流程和交互等。
4.界面设计-界面结构:描述产品的整体界面结构,包括页面布局、导航和组件等。
-视觉风格:描述产品的整体视觉风格,包括颜色、字体和图标等。
5.数据需求-数据处理:说明对数据进行的处理和分析,并列出数据需求和数据存储要求。
6.性能需求-响应速度:定义产品的响应速度要求,包括页面加载时间、操作响应时间等。
-并发能力:说明产品的并发用户数和并发操作数。
-可靠性:定义产品的可靠性要求,包括系统稳定性和容错能力等。
7.安全需求-用户身份验证:描述产品的用户身份验证方式和安全性要求。
-数据保护:说明对用户数据进行的保护措施和加密要求。
8.使用案例-典型场景:列举几个典型的使用场景,并描述用户在这些场景下的使用流程和操作步骤。
-用户故事:描述用户在实际使用产品时的感受和体验。
9.开发计划-项目规模:估算产品开发的总工作量和时间,并制定详细的开发计划和里程碑。
-人员需求:确定产品开发所需的人员构成和组织结构。
-开发流程:说明产品的开发流程和开发工具的选择。
10.评估标准-成功指标:定义产品的成功指标,包括用户数量、用户满意度、市场份额等。
PRD产品需求文档经典模板PRD(Product Requirement Document)是产品需求文档的缩写,用于定义产品的需求和规格。
PRD的编写是产品开发过程中至关重要的一步,它提供了开发团队理解产品需求的基础,并确保开发出符合用户需求的产品。
下面是一个PRD经典的模板:1.介绍-产品概述:简要介绍产品的目标和功能。
-产品定位:说明产品定位和目标用户群体。
-目标:阐述产品开发的目标和计划。
2.功能需求-功能列表:列出产品的主要功能特性。
-功能描述:对每个功能进行详细的描述,包括输入、输出、流程等。
-优先级:对每个功能确定其优先级和重要性。
3.非功能需求-性能:描述产品的性能需求,如响应时间、吞吐量等。
-安全性:说明产品的安全需求,如数据加密、权限控制等。
-可用性:阐述产品的易用性和用户体验需求。
-可靠性:说明产品的可靠性和稳定性要求。
4.用户界面设计-界面描述:描述产品的用户界面设计,包括页面布局、交互方式等。
-交互流程:说明用户与产品的交互流程和操作方式。
-样式和主题:描述产品的整体样式和主题设计要求。
5.数据管理-数据结构:说明产品的数据结构和数据模型。
-数据流程:描述数据的流动和处理过程。
-数据安全:阐述数据的安全性和保护措施。
6.接口需求-硬件接口:列出产品需要与之交互的硬件设备及相关规格。
-软件接口:说明产品需要与之集成的软件系统和接口要求。
-第三方接口:阐述产品需要使用的第三方服务或API。
7.测试需求-测试范围:描述测试的范围和要求。
-测试用例:列出针对每个功能的测试用例。
-性能测试:说明性能测试的方法和要求。
8.项目计划-里程碑:确定项目的关键里程碑和交付时间点。
-开发周期:阐述产品的开发周期和每个阶段的具体内容。
-团队组成:描述项目的团队组成和成员职责。
以上是一个PRD经典的模板,根据不同的产品需求可能会有所调整和扩展。
编写PRD时应尽量详细和清晰地描述产品的功能和需求,以便开发团队能够准确理解和实现产品。
产品需求文档(PRD)模板产品研究社《项目名》PRD文档更新记录版本号更新时间内容操作人V1.1 XXXX-XX-XX 1、简要列出核心变更内容点 2、XXXXXXXXXXXXX XXV1.0 XXXX-XX-XX 创建文档 XX目录一、概述1.2.3.二、需求说明三、产品结构1.2.3.四、主业务流程五、名词释义六、概述本文档旨在详细描述《项目名》的PRD,包括需求说明、产品结构、主业务流程和名词释义等内容。
需求说明本产品主要解决用户的XXX需求,提供XXXX功能。
具体需求如下:1.需求12.需求23.需求3产品结构本产品包括XXX模块、XXX模块和XXX模块,各模块之间相互独立但又相互关联。
主业务流程本产品的主要业务流程如下:1.流程12.流程2名词释义本文档中涉及到的名词释义如下:1.名词1:定义12.名词2:定义2功能性需求在软件开发过程中,功能性需求是最基本的需求,它们描述了系统应该具备哪些功能。
这些功能通常是在需求分析阶段确定的,并在软件设计和开发阶段被实现。
全局性交互或数据规则在系统中,全局性交互或数据规则是必需的,它们描述了系统中各个部分之间的交互和数据规则。
这些规则通常是在需求分析阶段确定的,并在软件设计和开发阶段被实现。
模块A模块A是系统中的一个重要模块,它负责处理特定的功能。
该模块应该能够准确地执行其任务,并能够与其他模块无缝地集成。
在设计和开发模块A时,应该考虑到其可扩展性和可维护性。
模块B模块B是系统中的另一个重要模块,它负责处理不同的功能。
该模块应该能够准确地执行其任务,并能够与其他模块无缝地集成。
在设计和开发模块B时,应该考虑到其可扩展性和可维护性。
非功能性需求除了功能性需求外,非功能性需求也是软件开发过程中必不可少的。
这些需求包括性能、可靠性、安全性等方面的要求。
在设计和开发过程中,应该考虑到这些需求,并确保系统能够满足这些要求。
数据统计需求数据统计需求是系统中的一个重要需求,它描述了系统应该能够收集和分析哪些数据。
XXXXXXXPRD目录1.项目背景 (4)2.项目评估 (4)3.项目目标 (6)4.项目方案描述 (7)4.1.系统关系图 (7)4.2.业务处理流程 (7)4.2.1.发票处理流程 (7)4.2.2.专票资质处理流程 (9)4.3.系统目录 (10)4.4.用例和权限 (10)5.项目范围 (12)6.项目风险 (12)7.需求来源,用户以及关联负责人 (12)8.功能需求 (13)8.1.大额发票自动拆分 (13)8.2.审核发票 (15)8.3.驳回重开 (19)8.4.审核日志 (21)8.5.添加资质 (23)8.6.资质管理 (26)8.7.导出金税文件 (31)8.8.开票状态回写 (32)9.运营计划 (34)10.质量需求 (34)附录一需求review 评分以及工作量评估 (34)附录二历次沟通意见汇总表 (35)1. 项目背景目前公司使用第三方汉特系统处理票据申请、审核、打印等任务。
调研发现:XX 无法灵活定制新业务属性、每年版权维护费用高昂,并且功能易用性差导致完成任务效率低下,如批量上传票据、历史数据查询、快递单打印功能无法满足公司业务增长。
项目一期已解决各业务线统一入口添加发票的需求,但审核人员仍需登录汉特系统审核导出发票。
二期将解决增值税发票审核、导出金税格式文件、回写至QI的需求。
客户资质维护管理的需求也将在本期实现。
2. 项目评估价值体系●●二期优化发票审核流程,在XXX存在流水号的发票申请,系统自动审核并标记,提升人工处理节点能效。
资质录入和管理功能,减少资质频繁输入和以往资质OA审核的繁杂过程。
提升发票申请到打印完成的整体流转效率:30%-50%。
3. 项目目标票据管理系统作为全公司票据集中处理与流转中心,负责各业务线发票申请打印的接入、发票和专票资质信息的集中管理。
1.一期实现营业税发票增删改查功能,建立发票信息库。
关闭汉特发票添加入口。
2.二期取代汉特审核功能,新增客户资质管理功能。
XXXXXXXPRD版本历史目录1.项目背景..............................................................2.项目评估..............................................................3.项目目标..............................................................4.项目方案描述...........................................................系统关系图.......................................................业务处理流程....................................................发票处理流程...................................................专票资质处理流程................................................系统目录.........................................................用例和权限......................................................5.项目范围..............................................................6.项目风险..............................................................7.需求来源,用户以及关联负责人...........................................8.功能需求...............................................................大额发票自动拆分.................................................审核发票.........................................................驳回重开.........................................................审核日志.........................................................添加资质.........................................................资质管理.........................................................导出金税文件.....................................................开票状态回写....................................................9.运营计划..............................................................10.质量需求.............................................................附录一需求review 评分以及工作量评估.....................................附录二历次沟通意见汇总表 ................................................1.项目背景目前公司使用第三方汉特系统处理票据申请、审核、打印等任务。
调研发现:XX无法灵活定制新业务属性、每年版权维护费用高昂,并且功能易用性差导致完成任务效率低下,如批量上传票据、历史数据查询、快递单打印功能无法满足公司业务增长。
项目一期已解决各业务线统一入口添加发票的需求,但审核人员仍需登录汉特系统审核导出发票。
二期将解决增值税发票审核、导出金税格式文件、回写至QI的需求。
客户资质维护管理的需求也将在本期实现。
2.项目评估价值体系二期优化发票审核流程,在XXX存在流水号的发票申请,系统自动审核并标记,提升人工处理节点能效。
用户角色任务量化现状量化目标发票申请人添加客户资质单次SP申请流转时间>3小时(含添加和审核时间),每月1-3次。
取代SP, QI中完成提交和审核:减少SP登录次数;提升单次添加表单效率;发票审核人审核申请单每天审核1次,每次10-20分钟。
客服XXX申请发票量占60%。
需审核时邮件通知,支持批量审核,每天5-10分钟。
XXX申请发票系统自动审核审核客户资质同“添加客户资质”同“添加客户资质”发票开票人导出发票每日每次筛选、导出、导入到金税,约3-5分钟仅优化交互效率回写发票回写数据量较大,每次10分钟以上增量回写,仅回写变化的数据行。
减少80%以上回写时间。
提升发票申请到打印完成的整体流转效率:30%-50%。
3.项目目标票据管理系统作为全公司票据集中处理与流转中心,负责各业务线发票申请打印的接入、发票和专票资质信息的集中管理。
1.一期实现营业税发票增删改查功能,建立发票信息库。
关闭汉特发票添加入口。
2.二期取代汉特审核功能,新增客户资质管理功能。
导出至金税开发票并回写状态。
3.三期实现营业税发票添加、审核、打印功能,关停汉特系统。
本期需求范围:二期中的功能。
4.项目方案描述系统关系图“营业税发票”对接汉特发票系统的接口1)系统自动扫描新添加“营业税发票”且状态为“财务审核通过”发票并传递到汉特接口;2)系统定时扫描汉特接口,当接口中发票状态变更时,取回发票号、快递信息,变更发票状态。
业务处理流程4.1.1.发票处理流程流程描述:1.【发票申请人】添加发票或导入发票2.【Voice】接收申请,进行合规性判断,如不通过回提示申请人3.【Voice】合规性判断通过后,自动审核通过来自XXX发票申请4.【Voice】未收款开票需业务线Leader审核,已收款开票需财务组审核5.【发票审核人】业务线Leader审核,通过状态变为审核通过,不通过状态变为审核驳回。
6.【发票审核人】财务组审核,通过状态变为审核通过,不通过状态变为审核驳回。
7.【发票开票人】审核通过的,按金税格式导出发票至金税系统。
8.【发票开票人】回写导入发票状态的更新,更新包括发票号、打印状态等信息。
9.流程结束4.1.2.专票资质处理流程流程描述:1.【发票申请人】添加客户资质2.【Voice】接收申请,进行合规性判断,如不通过回提示申请人3.【Voice】合规性判断通过后,状态为待税务审核,邮件通知税务组审核。
4.【资质初审人】税务组审核,通过状态变为待财务审核,不通过状态变为审核驳回。
5.【资质复审人】财务组审核,通过状态变为审核通过,不通过状态变为审核驳回。
6.流程结束系统目录点击进入“发票”频道,默认进入“发票管理”页。
1)发票申请人默认进入“已开票”选项卡;2)发票审核人默认进入“未开票”选项卡;3)发票开票人默认进入“已审核”选项卡;用例和权限5.项目范围Voice汉特金税6.项目风险1)无7.需求来源,用户以及关联负责人注:如果无相关人,明确写上“无”功能需求大额发票自动拆分1)添加发票时拆分功能需求描述: 申请发票时需验证是否超过单张最大面额(¥100,),价格输入框实时校验,超过时提示:“单张发票限额¥100,以内,提交时系统将自动拆分为多张。
”点击按钮“提交发票”完成发票添加,系统自动拆分大额发票(按满足最大金额拆分,如¥110,,拆分为¥100,和¥10,两张),申请单号自动添加后缀S1、S2…Sn。
添加成功弹出模态窗口:点击“查看发票详情”,关闭模态窗口,添加发票页面重置,在新页面打开多个发票详情页;点击“继续添加”,关闭模态窗口,添加发票页面重置。
2)导入发票时拆分导入时自动处理大额发票,逻辑:如果价格超过¥10,,拆分为多张<¥10,的申请,其他信息保持一致,并删除原始数据行。
导入文件校验通过没有错误,显示导入成功提示:成功导入X行数据!有2行大额发票申请自动拆分为5行。
导入批次号:{6位顺序号}点击查看已导入发票管理或下载已校验的Excel文件。
3) XXX/Qreport系统大额处理规则客服或客户申请发票提交时,系统自动拆分大额发票(按满足最大金额拆分,如¥110,,拆分为¥100,和¥10,两张),申请单号自动添加后缀S1、S2…Sn。
弹出对话框告知客户或客户,点击“好的”后再进入发票申请成功页:4)其他系统处理规则规则同XXX,需逐个系统沟通。
审核发票功能需求描述: 发票申请人提交发票后,系统第一步判读是否来自XXX提交发票:XXX发票,自动审核通过;非XXX发票,第二步判断是否已收款发票:已收款申请,发邮件通知发票审核人-财务组审核发票;未收款申请,发邮件通知发票审核人-业务线Leader审核发票。
进入“发票管理”页,选择“未开票”选项卡,发票审核人可对发票单张或批量审核。
1)通知邮件格式2)“未开票”查询结果表格审核对话框交互:审核意见非必填项。
点击“审核通过”关闭对话框,刷新发票管理页,发票状态变更为已审核;点击“驳回”关闭对话框,刷新发票管理页,发票状态变更为已驳回。
批量审核时,审核意见将保留在每条申请中。
XXX/Qreport免审规则:因XXX/Qreport属于已收款申请且包含XXX汇款流水号,提交给Voice后直接置为“已审核”状态。
提交前需要:1)在传递给Voice接口备注中写入汇款流水号。
2)在财务汇款信息表格,增加“已开发票金额”字段。
记录一条流水开票金额,防止开票金额大于流水金额,乱开票现象。
( 开票时发票金额超过流水金额,暂不做强制限制,下期考虑具体限制方案。
超过时,“已开发票金额”字段标红。
)3)Voice收到来自XXX/Qreport发票申请,将申请单状态由“未开票”修改为“已审核”,审核意见为:自动审核通过。
驳回重开功能需求描述: 发票审核人驳回申请后,发票申请人可在“已驳回”选项卡中查看已驳回列表并申请重开。
1)“已驳回”查询结果表格2)编辑申请单页编辑完成,点击“提交重开”,合规校验无误弹出对话框,同添加发票提交成功对话框。
审核日志功能需求描述: 发票详情页新增发票审核日志功能,记录发票申请各状态变化时间、操作人、操作明细。