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

KINGDEEEAS软件需求规约DOCID：KDSP_RD_T_V2.0第1页共22页EAS采购订货原型系统软件需求规约修改记录Ver.No发版日期作者审核人改动的章节号1.0朱涛初始版本KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第2页共22页目录1.概述31.1读者42.总体说明42.1业务流程43.详细需求53.1采购申请（purchaserequisition）53.1.1业务说明53.1.2业务逻辑53.1.3业务对象73.1.4界面原型83.2采购订单（purchaseorder）143.2.1业务说明143.2.2业务逻辑143.2.3业务对象153.2.4界面原型163.3统计报表183.3.1订货汇总表（Goodsorderedsheet）183.3.2业务逻辑193.3.3业务对象193.3.4界面原型194.补充规约225.术语表22KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第3页共22页EAS样板工程采购订货原型系统1.概述采购订货原型系统是从EAS采购系统中抽取出来的一个功能子集。采购系统是EAS系统的核心功能之一，其主要功能是维护供应商的主数据（包括基础信息、财务信息等）、采购计划的制定与修改、采购订单的处理、采购申请的汇总、采购询价、采购收货、采购结算（包括采购发票与采购订单的对应等）和采购报表等。EAS采购系统与销售、计划、生产、仓库、财务等系统有着密切的关系。在业务管理上，只有采购人员按计划把原材料采购入库，生产部门按计划安排领料生产，然后完工入库，才能满足销售的需求。本文描述的采购订货原型系统是EAS采购系统的一个精简的子集，其中所涉及的业务需求、应用场景和逻辑约束已经从样板工程的角度做了极大的简化，并不能代表真实采购系统的完整的业务需求，只能称为是一个原型系统。但是从样板工程的角度来说，已经足够通过这个案例熟悉整个EAS产品的设计开发流程。本案例描述的业务需求主要在四个方面进行了简化：一、业务流程的简化：本案例只包括采购申请、采购订单两个个主要业务用例；而且这两个个业务用例也对其中包含的业务逻辑进行了极大的简化；只描述最基本的业务逻辑；二、协同应用的简化：本案例除了EAS基础系统以外，不考虑跟其他业务系统的接口，例如不考虑跟预算系统、资金系统、总账系统、应收应付系统、生产管理系统的相关协同和接口，只是一个封闭的、单纯的业务系统原型；三、统计查询的简化：采购报表也做了极大简化，只有一个采购订货汇总表。本文描述的案例是在参照EAS已有系统的基础上进行设计的。作为样板工程，本原型系统的设计开发必须参照EAS目前的模型体系、基础数据、框架结构进行，对于本原型系统所涉及到的这些相关内容，本案例将不再赘述，请参考EAS相关需求和设计文档。KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第4页共22页1.1读者EAS设计人员EAS开发人员2.总体说明2.1业务流程采购订货原型系统的业务流程主要包括：提出采购申请下达采购订单采购订货统计，具体见下图：采购订货原型系统的主要目标是根据各个部门、各个组织单元提出的采购申请制定采购订单进行订货（为了简化培训案例，这里省去了对供应商选择、比价、询价、还盘、采购提前期等业务要素的考虑），然后根据采购订单的下达情况统计采购申请的已订货数量和未订货数量，出统计报表。KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第5页共22页3.详细需求3.1采购申请（purchaserequisition）3.1.1业务说明采购申请是财务组织为了有效控制采购活动而采取的手段之一，任何部门或人员要求外购物品（包括原材料、办公用品、机器设备、维修配件等），都要提出申请，由相应的主管领导审核批准，之后交由采购部门进行采购。采购申请单可以由申请部门或人填写，申请部门或人可以实时跟踪查询申请单的执行状态，了解申请物品的采购情况以及相应的库存明细。3.1.2业务逻辑单据生效采购申请单必须审核后才能正式生效，没有审核的采购申请单被认为是临时单据，可以随时删除、修改，不参与后续任何业务流程，报表统计不考虑未审核的采购申请单。未审核的采购申请单也不能关联生成采购订单（不能订货）。至于审核条件（例如金额大于1000元必须由高级主管审核）、审核人选、需要几级审核等等由用户在工作流系统中自行配置。已审核的申请单不允许删除、修改。如果采购申请已经被采购订单关联（已经下推生成过采购订单）,那么采购申请单不允许反审核，单据状态采购申请单有如下几种状态：制单、下达、关闭。采购申请单录入保存以后的状态为“制单”；通过审核以后的状态为“下达”；当采购申请单上所有分录行上的物料的申请数量已经全部订货完毕（即已全部关联采购订单并且已经关联的采购订单已经下达）时，采购申请单的状态为“关闭”就是说当采购申请单关联的采购订单已全部下达时，必须反写采购申请单状态，自动置为“关闭”状态；关闭时系统自动填写关闭人、关闭日期、置单据头状态为“关闭”状态。采购申请单的单据状态不仅在单据头有，在分录行上也有。单据头的“关闭”状态必须参照分录行上的“关闭”状态；当所有分录的状态都是“关闭”的时候，系统必须自动设置单据头的状态为“关闭”；当“采购申请单.分录行.申请数量”等于“采购申请单.分录行.已订货数量”时，分录行状态自动置为关闭。不允许超量采购，也就是说不允许采购订单的订货数量超过关联的采KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第6页共22页购申请单的申请数量。制单、下达、关闭三种状态是依次顺序转换的，只有审核后的申请单才能下推生成采购订单（执行订货）。当订货完毕后（申请单上所有物料的未订货数量为零），才能置为关闭状态。单据关联采购申请单审核以后就可以进行订货了，也就是说可以关联下推生成采购订单了，关联生成采购订单的时候，必须把相应的单据信息带过去，减少用户的录入工作量。可以携带的信息有：供应商、采购组织、币种（如果申请单上有就携带）、物料编码、物料名称、规格型号、计量单位，这些字段采购申请单和采购订单是完全相同的，可以复制过来；采购订单分录上的订货数量必须经过计算携带，计算方式如下：采购订单.分录行.订货数量＝采购申请单.分录行.申请数量－采购申请单.分录行.已订货数量（即默认携带申请单上尚未订货的数量）。采购申请单分录行上的需求日期默认携带到采购订单分录行上的交货日期。关联后，采购订单和采购申请单必须彼此能关联查询到对方（通过BOTP进行关联转换并记录关联关系），关联生成采购订单后必须累加反写采购申请单分录行上的“已订货数量”字段；反写逻辑如下：采购申请单.分录行.已订货数量＝采购申请单.分录行.已订货数量＋本次关联数量采购申请单关联生成采购订单，可能是部分关联，就是说允许一张采购申请单的部分分录行关联生成采购订单；所以采购申请单和采购订单是一对多的关系。如果采购申请单上的分录行上的状态已经为“关闭”（即申请数量小于等于已订货数量）则不允许被关联，关联生成采购订单的时候，只能选择处于“下达”状态的分录行。关联生成的采购订单的分录行上的订货数量（采购订单.订货数量）就是采购申请单本次被关联的数量，如果用户在订单生成以后修改了订单上的订货数量，那么必须同时改写反写采购申请单的已订货数量，重新累加。单据操作采购申请单的相关操作有：新增（包括录入和保存）、修改、查看、删除、审核/反审核、、关KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第7页共22页联、查询关联单据（查询关联的采购订单）；根据单据状态不同可以进行的操作不同，如下：制单状态的采购申请单可以修改、查看、删除、审核；下达状态的采购申请单可以查看、反审核、关联、查询关联单据；关闭状态的采购申请单可以查看、查询关联单据；3.1.3业务对象采购申请单属性及相关说明：位置属性名称类型说明及约束可录入必录项1单据头申请单号字符申请单号是采购申请单的唯一性表示，不能重复，如果已经定义了采购申请单相应的编码规则，则在新增时根据编码规则自动填写单据编号是是2采购组织字符指定本次采购申请交由哪个采购组织采购。不可为空，用户可以选择或手工输入采购组织编码。用户只能录入或者选择采购组织类型；是是3供应商字符有些采购申请单需要指定供应商。如果需要指定则录入，如果不需要则不用录入供应商。用户可以从已经供应商列表中选择或者手工录入供应商编码是否4币种字符如果需要在分录行上填写建议采购单价，在必须在单据头填写币种。用户可以从币别表选择或者手工录入币种编码是否5申请部门字符申请采购的部门或组织。用户可以从行政组织架构中选择或手工输入行政组织编码是是6申请人字符用户可以从人员表中选择或输入人员编码，但必须是系统已经定义的人员。申请人所属的行政组织必须跟申请部门一致；是是7申请时间日期申请采购的时间。由系统自动根据当前时间录入。是是8用途文本描述本次申请采购物料的用途，可以为空是否9状态字符用户不可维护，系统自动填写，有关说明参照3.1.2业务逻辑中的采购申请单的单据状态部分；否是1单据体（分行号数值由系统自动填入，用户不可输入或修改。否是2物料编码字符用户可以从物料表中选择或手工输入物料编码是是3物料名称字符根据物料编码自动携带否是4规格型号字符根据物料编码自动携带否否5计量单位字符根据物料编码自动携带物料的基本计量单位，用户可更改。用户可以从计量单位列表中选择或手工输入计量单位编码是是KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第8页共22页6录）申请数量数值当前分录行上的物料需要申请采购的数量。不可为空，必须大于零是是已订货数量数值已行采购的数量。这个数量用户不可手工编辑，每次采购申请单关联生成采购订单的时候，系统根据本次关联的数量累加反写过来。已订货数量可以大于申请数量。否是7建议采购单价数值供实际采购部门参考的单价，可以不填写；必须大于等于零，单价精度参照物料上定义的精度；如果单据头录入了币种，则此栏可以录入；是否8金额数值如果填写了建议采购单价，那么就根据数量×单价计算金额，金额的精度参照币种表中设置的精度；如果单据头录入了币种，则此栏可以录入；是否9需求日期日期生产或销售需要用到此物料的日期。不能小于申请日期；是是10状态字符枚举型：下达/未下达。在执行下达动作以前，系统自动设置行状态为“未下达”，执行下达动作以后，系统自动置为“下达”状态；有关说明参照3.1.2业务逻辑的单据状态部分否是1单据尾制单人字符新增单据时系统根据当前登录用户帐号对应的用户实名自动填写否是2制单日期日期新增单据时系统根据系统当前日期自动填写否是3修改人字符修改单据时系统根据当前登录用户帐号对应的用户实名自动填写，如果单据被多次修改，则每次记录最后一个修改人否是4修改日期日期修改单据时系统根据系统当前日期自动填写否是5审核人字符审核单据时系统根据工作流中配置的审核执行人对应的用户实名自动填写，如果存在多级审批，则记录最后审核人否是6审核日期日期审核单据时系统根据审核的当前日期自动填写否是7关闭人字符如果是系统自动关闭，关闭人则为空；如果是用户手工关闭，则根据当前执行关闭动作的用户帐号对应的用户实名自动填写否是8关闭日期日期系统根据关闭时的系统当前日期自动填写否是3.1.4界面原型采购申请单涉及到的界面原型主要有两个：采购申请单序时簿（ListUI）和编辑窗口（EditUI）。KINGDEE软件需求规约DOCID：KDSP_RD_T_V2.0第9页共22页一、采购申请单ListUI如下图（序时簿界面）：序时簿用途：采购申请单序时簿用于对所有采购申请单据进行集中管理。不可在序时簿界面上对单据直接进行修改，序时簿界面本身是个只读界面，相关操作必须通过功能菜单和按钮在相应的界面中进行（此处描述同样适用于采购订单序时簿，后面不再赘述）。序时簿字段：序时簿上显示采购申请单单据头、单据尾和分录行上的全部字段；因为每张单对应的单据头、单据尾只有一条记录，而