14EAS50_总体规范_样板工程_采购订货原型系统_软件需求规约.docx

KINGDEEEAS软件需求规约DOCID：KDSP_RD_T_V2.0EAS<采购订货原型系统>软件需求规约修改记录Ver.No发版日期作者审核人改动的章节号1.0朱涛初始版本编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：目录1.概述41.1读者52.总体说明52.1业务流程53.详细需求63.1采购申请（purchaserequisition）63.1.1业务说明63.1.2业务逻辑63.1.3业务对象83.1.4界面原型103.2采购订单（purchaseorder）163.2.1业务说明163.2.2业务逻辑163.2.3业务对象173.2.4界面原型183.3统计报表203.3.1订货汇总表（Goodsorderedsheet）203.3.2业务逻辑213.3.3业务对象213.3.4界面原型214.补充规约245.术语表24EAS样板工程采购订货原型系统概述采购订货原型系统是从EAS采购系统中抽取出来的一个功能子集。采购系统是EAS系统的核心功能之一，其主要功能是维护供应商的主数据（包括基础信息、财务信息等）、采购计划的制定与修改、采购订单的处理、采购申请的汇总、采购询价、采购收货、采购结算（包括采购发票与采购订单的对应等）和采购报表等。EAS采购系统与销售、计划、生产、仓库、财务等系统有着密切的关系。在业务管理上，只有采购人员按计划把原材料采购入库，生产部门按计划安排领料生产，然后完工入库，才能满足销售的需求。本文描述的采购订货原型系统是EAS采购系统的一个精简的子集，其中所涉及的业务需求、应用场景和逻辑约束已经从样板工程的角度做了极大的简化，并不能代表真实采购系统的完整的业务需求，只能称为是一个原型系统。但是从样板工程的角度来说，已经足够通过这个案例熟悉整个EAS产品的设计开发流程。本案例描述的业务需求主要在四个方面进行了简化：一、业务流程的简化：本案例只包括采购申请、采购订单两个个主要业务用例；而且这两个个业务用例也对其中包含的业务逻辑进行了极大的简化；只描述最基本的业务逻辑；二、协同应用的简化：本案例除了EAS基础系统以外，不考虑跟其他业务系统的接口，例如不考虑跟预算系统、资金系统、总账系统、应收应付系统、生产管理系统的相关协同和接口，只是一个封闭的、单纯的业务系统原型；三、统计查询的简化：采购报表也做了极大简化，只有一个采购订货汇总表。本文描述的案例是在参照EAS已有系统的基础上进行设计的。作为样板工程，本原型系统的设计开发必须参照EAS目前的模型体系、基础数据、框架结构进行，对于本原型系统所涉及到的这些相关内容，本案例将不再赘述，请参考EAS相关需求和设计文档。读者EAS设计人员EAS开发人员总体说明业务流程采购订货原型系统的业务流程主要包括：提出采购申请下达采购订单采购订货统计，具体见下图：采购订货原型系统的主要目标是根据各个部门、各个组织单元提出的采购申请制定采购订单进行订货（为了简化培训案例，这里省去了对供应商选择、比价、询价、还盘、采购提前期等业务要素的考虑），然后根据采购订单的下达情况统计采购申请的已订货数量和未订货数量，出统计报表。详细需求采购申请（purchaserequisition）业务说明采购申请是财务组织为了有效控制采购活动而采取的手段之一，任何部门或人员要求外购物品（包括原材料、办公用品、机器设备、维修配件等），都要提出申请，由相应的主管领导审核批准，之后交由采购部门进行采购。采购申请单可以由申请部门或人填写，申请部门或人可以实时跟踪查询申请单的执行状态，了解申请物品的采购情况以及相应的库存明细。业务逻辑单据生效采购申请单必须审核后才能正式生效，没有审核的采购申请单被认为是临时单据，可以随时删除、修改，不参与后续任何业务流程，报表统计不考虑未审核的采购申请单。未审核的采购申请单也不能关联生成采购订单（不能订货）。至于审核条件（例如金额大于1000元必须由高级主管审核）、审核人选、需要几级审核等等由用户在工作流系统中自行配置。已审核的申请单不允许删除、修改。如果采购申请已经被采购订单关联（已经下推生成过采购订单）,那么采购申请单不允许反审核，单据状态采购申请单有如下几种状态：制单、下达、关闭。采购申请单录入保存以后的状态为“制单”；通过审核以后的状态为“下达”；当采购申请单上所有分录行上的物料的申请数量已经全部订货完毕（即已全部关联采购订单并且已经关联的采购订单已经下达）时，采购申请单的状态为“关闭”就是说当采购申请单关联的采购订单已全部下达时，必须反写采购申请单状态，自动置为“关闭”状态；关闭时系统自动填写关闭人、关闭日期、置单据头状态为“关闭”状态。采购申请单的单据状态不仅在单据头有，在分录行上也有。单据头的