NCV5-流程平台技术红皮书.doc

流程平台技术红皮书NC-UAP 5.0用友NC-UAP2019-11-191第 页目 录第一章工作流与BPM11.信息系统的演变12.企业业务流程13.工作流24.BPM2第二章流程平台31.单据元模型31.1单据类型41.2单据动作及脚本71.3单据函数91.4单据UI111.5单据项目111.6单据VO对照122.业务流平台132.1业务类型142.2流程配置152.3单据VO交换193.审批流平台213.1流程定义213.2工作项253.3流程结果与单据状态263.4反向流转283.5流程监控293.6短信审批30第三章开发规范311.平台缓存数据312.动作处理322.1UI端调用-PfUtilClient342.2BS端调用382.3返回值393.动作脚本393.1执行脚本编写403.2返回值424.审批流平台434.1审批状态回写与查询434.2送审434.3审批454.4弃审484.5删除504.6审批流相关接口505.业务流平台565.1动作驱动565.2单据VO交换575.3单据UI菜单填充与响应585.4业务流相关接口61第四章开发流程67附录681.NC5.0短信服务681.1应用模式681.2短信发送691.3短信接收70第 70 页第一章 工作流与BPM1. 信息系统的演变从简单的办公信息系统，到事务处理系统，再到复杂的知识管理和决策支持系统，我们可以看到，越来越多的通用任务已被从应用程序中分离出来并放入分解的管理系统中。图1说明了这种演进。图 1通用功能分解1975-1985 分离的应用信息系统由被分解的应用组成，每个应用都有自己的数据库和定义。1985-1995 数据库管理将数据管理从应用程序中抽取出来。关系数据库的出现。1995-2002 用户界面管理将用户界面从应用程序中抽取出来。人机工程。1998-2005 工作流管理将业务过程从应用程序中抽取出来。跨企业，跨系统。2. 企业业务流程企业的经营过程是指企业为了实现一定的经营目标，在组织机构和人员的参与下，利用企业资源（设备、计算机软硬件等），按照预先确定的业务规则，在参与者之间进行文档、信息、任务的传递与处理。企业的经营管理也是遵循一定规律的，其业务也需要按照一定的业务规则运行。业务按照一定的业务规则运行或处理就形成了企业的业务流程。图 2企业经营过程3. 工作流The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules(WFMC).工作流是一个能够完全或部分自动执行的业务过程，根据一系列过程规则，文档、信息或任务能够在不同参与者之间传递和处理（WFMC）。比如保险索赔、抵押申请、税收申报、产品设计生产过程等。工作流管理系统（Workflow Management System，WFMS）的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程中的任务（活动）以及群体成员之间的信息交互。强调的是业务过程的自动化。4. BPM业务过程管理（Business process management），非企业绩效管理（Business Performance Management）。包括了过程建模、过程自动化、企业应用集成、业务活动监控与优化的全生命周期。强调的是业务过程的分析与优化。比较常用的分析项为：1 业务流程的瓶颈在哪？2 给定时间内有多少案例（Case，也可称作实例）可被处理？3 改变案例数量后，需要增加多少资源？4 案例的平均完成时间？第二章 流程平台NC流程平台包括业务流程和审批流程两个部分。图 3业务流程框架整个业务流程框架的核心是工作流引擎。它负责解释执行由业务流设计器和审批流设计器设计的流程定义。流程定义可以引用NC系统建立的功能模型、组织模型以及各种元数据。NC用户可从工作列表中查看到工作流引擎分配给他的工作项。通过单据动作（比如提交、审批、弃审、驳回等）来处理工作项，从而驱动流程流转。工作流引擎在流转过程中还可以调用各种自动应用，包括电子邮件、脚本以及Web服务等。业务流程框架还提供了管理监控工具对运行中的流程实例进行状态查询和管理。对于流转过程中涉及到的数据交换，工作流引擎将调用交换引擎根据规则进行数据映射。1. 单据元模型业务单据是描述企业业务信息的载体，是对业务数据的抽象。通过业务单据，可以清楚地反映企业的业务发生情况。企业中如请购单、采购订单、报销单、付款单等均为业务单据。在NC系统中，一张业务单据的实现包括许多内容，比如单据类型、单据VO、单据UI、单据动作等。我们把这些用于描述某单据的信息统称为单据元模型。其组成如图4所示。图 4单据元模型1.1 单据类型单据类型是对单据的分类。单据的元信息都是基于单据类型来定义。在定义单据类型时，单据类型必须属于某个系统类型。单据类型的注册信息比较多，由功能点客户化-二次开发工具-单据管理-单据类型管理维护，如图5所示，一般由各个产品组预置。图 5单据类型管理项目说明： 类型代码：手工输入，最大长度为4个字符，可以输入字母和数字，不允许重复。 类型名称：业务单据名称，手工输入，不允许重复。 单据大类：表示单据类别（应收应付101-），用于区分单据类型的主子关系（参见1.1.2节）。 单据对应类：标识单据类型的关联UI，一般为关联的审批维护类功能节点编码。 主表参照的固定条件语句：被其它单据参照时自己填写的固定的SQL条件语句。 参照查询对应的DMO类：用于查询单据VO数据的业务逻辑类。必须实现接口nc.bs.pub.pf.IQueryData以及nc.bs.pub.pf.IQueryData2（参见第三章5.4.6节）。 审批流检查类：通过编写审批流检查类，并在该类中实现审批流相关接口，来达到使用审批流管理业务单据以及控制审批流行为的目的（参见第三章）。实现IcheckState，IbackCheckState(可不实现)的接口的DMO类文件 会计平台类：财务会计平台所需的类。实现IaccountProcMsg IAccountRetVoucher的接口的DMO类文件 是否项目核算：NC210以后不再使用。 是否为根节点：针对单据大类，用于实现单据主子关系。 是否发送会计平台：用于财务会计平台。如果该单据不直接传送财务会计平台，则不选择 节点编号：标识单据类型的关联UI，一般为关联的审批维护类功能节点编码。 自定义1(def1)：流程配置的单据业务关联（业务流程）更新后的处理类。 自定义2(def2)：存取会计平台的产品组自定义查询。 自定义3(def3)：动作执行前的UI端处理类。如果单据类型关联了多个功能节点，该类还需要实现节点查找接口（参见第三章4.6节）。1.1.1系统类型对业务系统的分类。5.0版本中，每个系统必须属于某个模块。由功能点客户化-二次开发工具-会计平台-系统类型定义维护，如图6所示。图 6系统类型定义项目说明： 系统类型编码：自定义输入，禁止重复。 系统类型名称：自定义输入，禁止重复。 是否专项管理：勾选此项，表示此业务系统将向管理会计平台传送数据。 是否发送到会计平台：勾选此项，表示此业务系统将向财务会计平台传送数据，在财务会计平台的凭证模板节点，可以对此业务系统的单据进行操作。 系统使用的业务类型：在进行凭证模板或成本单据模板定义时，该系统的业务单据使用的业务类型档案。 模块名：标识该系统所属的产品模块。对应于NC_HOME/modules/下的目录名。 相关节点编码：标识哪些功能节点号与产品模块的关联关系。一般用于参数设置中。1.1.2主子关系单据类型之间可存在主子关系，这通过isroot和billstyle两个属性来判定。图 7单据类型主子关系如图7所示，D1的父单据类型为F1；D2的父单据类型为F2。1.2 单据动作及脚本是对单据业务处理行为的抽象，具有可定制的动作脚本。业务单据正是通过单据动作与流程平台进行交互的，从而驱动流程的流转。可对应于单据UI上的某个菜单。由功能点客户化-二次开发工具-单据管理-单据动作管理维护，如图8所示。图 8单据动作管理项目说明： 动作选择：提供四种动作各供选择：保存、审核、推式动作、其它。保存、审核是单据的基本动作，动作代码有严格规定；推式动作表示该动作可被其他单据推式驱动。 动作编码：当前单据动作的编码。注意，当动作选择为“保存”时，动作编码必须为以“SAVE”结尾；而当动作选择为“审核”时，动作编码必须为以“APPROVE”开头。长度限制为20个英文字符。 动作名称：当前单据动作的显示名称 动作执行前提示：如此处输入文字，则在该动作被触发时，会弹出一个带有提示性文字的对话框，如：是否保存？ 动作控制：提供三个选项：动作可配置、进行驱动配置、进行约束检查。勾选“动作可配置”，表示该动作可在流程配置中进行配置；勾选“进行驱动配置”，则该动作在流程配置中可以对其他单据动作进行推式操作，驱动其他单据；勾选“进行约束检查”，则此动作要根据业务流程的配置在执行前进行条件检验，满足条件动作才执行，否则就不执行。图 9单据动作执行脚本单据动作的处理统一由平台API来调用。详见第三章第3节。1.2.1单据动作组对单据动作的分组。由功能点客户化-二次开发工具-单据管理-单据动作组管理维护，如图10所示。图 10单据动作组管理1.3 单据函数服务于单据的业务功能的抽取，是进行业务逻辑处理的组件。可用于动作脚本和条件判定。由功能点客户化-二次开发工具-流程配置-数据交换管理维护，如图11所示。图 11单据函数(组件)管理项目说明： 函数说明：函数所实现的功能的说明性文字，建议尽量说明清晰，以便于系统实施。如果以“”括起来，表示自定义函数。 返回类型：该功能函数返回数据的类型。 函数类名称：功能函数所属的全路径类名。 函数方法名称：该函数在类中所对应的方法名称。 函数参数：该函数正确调用所需的参数。参数的格式见下。 是否组件：标识该方法是否为组件。单据组件一般是没有返回值的一段业务处理逻辑，它不可应用于审批条件、动作约束、工作项配置中。1.3.1参数格式函数参数以逗号“，”隔开，每个参数具有特定的格式。参数分为运行参数、属性参数和VO参数三种。格式示例：nc.vo.pub.AggregatedValueObject:01nc.vo.pub.AggregatedValueObject:01,OBJuser:OBJECTnc.vo.po.OrderVO:21&sAction:STRING,nc.vo.pub.AggregatedValueObject:01注意：VO参数和属性参数的实际值由工作流上下文在运行时赋予。运行参数可在动作脚本中赋值。1.4 单据UI单据的界面展现模型，包括四大模板以及UI工厂等。每个单据还与一个维护它的功能节点对应，这个信息需要注册到单据类型中（参见1.1节）。1.5 单据项目是对单据业务数据的描述。一般与单据的VO模型对应。由功能点客户化-二次开发工具-单据管理-单据项目管理维护，如图12所示。图 12单据项目管理项目说明： 属性名：单据VO模型中的属性名称。 多语资源ID：属性的多语ID号。 专项类型：属性的数据类型。 默认名称：属性的中文名称。1.6 单据VO对照描述了流程平台所需的信息（比如制单人、审批人、单据ID等）在单据VO模型上的对应关系。由功能点客户化-二次开发工具-单据管理-单据VO对照管理维护，如图6所示。图 13单据VO对照项目说明： 主子VO类名称：单据VO模型中的主子VO类名称。 单据VO类名称：单据聚合VO类名称。 主表的关键字段：单据物理模型中主表的主键字段。 子表编码：？ 审批人：单据VO模型中表示审批人的属性名称。 制单人：单据VO模型中表示制单人的属性名称。 单据ID：单据VO模型中表示单据ID的属性名称。 业务类型：单据VO模型中表示业务类型的属性名称。 对于数据库表：注册单据主子物理表名称。 单据编号：单据VO模型中表示单据号的属性名称。2. 业务流平台NC业务流平台进行了简化，其设计思想是基于以下认识：业务流程是由单据组成的，而单据是由动作驱动的，动作又是由组件组成的；单据、动作以及组件可以由业务系统开发实现。NC业务流提供一种平台机制，在此可以根据用户的实际业务重新组织这些单据、动作及组件，包括每种单据的来源单据是什么、又驱动生成哪些单据、完成什么动作、动作生效的约束条件以及动作生效后将配置哪些组件等，以此更好满足企业个性化的需求。图 14普通采购流程2.1 业务类型对业务流程的分类。各个公司可定义自己的业务流程，5.0支持集团业务类型，即在集团定义业务类型，然后各个子公司使用。比如集中采购流程：请购单-采购订单-到货单-入库单-采购发票-应付单。由功能点客户化-流程配置-业务类型管理维护，如图15所示。图 15业务类型管理2.2 流程配置一个业务流程由相互关联的多个单据组成，通过定义单据间来源与动作驱动关系来定义业务流程。图 16流程配置项目说明： 单据代码：该字段为参照选择，参照内容为NC安装过的功能模块的所有单据类型。每个业务类型每张单据只能选择一次。 单据名称：显示选择的单据代码的名称，不能编辑，选择单据代码后自动带入 参照单据：勾选此项，表示该单据的业务数据可以参照其他单据（来源单据）的数据生成（将进行单据VO交换）。勾选此项，在流程配置中才可配置该单据的来源单据，否则不可配置。 自制单据：勾选此项，表示该单据的业务数据可以手工输入。 权限控制：设置每个单据有权限的参与者。在单据UI界面，业务类型下拉菜单中，只有有权限的用户才可看到该业务类型（参见第三章5.3.1节）。同时还控制了下游消息的接收者范围。 下游消息：上游单据审批通过后，会给下游单据的参与者发送拉式消息。上游单据的推式动作执行完后会驱动下游单据的动作，并给下游单据的参与者发送推式消息。流程配置由5个向导工具组成，分别阐述如下：2.2.1单据权限配置5.0新增的配置，配置业务流程中每个单据有权限的参与者。用于业务类型的权限控制，以及下游消息的接收者范围。图 17单据权限配置2.2.2单据来源配置是对当前单据类型的数据来源单据进行定义的界面。被定义为当前单据来源单据的业务单据，可以在业务流程中为当前单据提供业务数据（使用单据VO交换），以保持业务数据的一致性。图 18单据来源配置2.2.3动作约束配置配置业务单据的单据动作（可能为单据界面上的某些功能按钮）在发生前需要进行的条件检查。若发生的业务满足定义的条件，则该单据动作将被执行，否则不允许执行。流程配置通过本步骤，即可实现对当前业务环节的事前控制。图 19动作约束配置2.2.4动作事件控制配置为业务流程配置个性化动作脚本。在这里，用户可以针对不同业务类型对公共的单据动作执行脚本（参见第三章第3节）进行定制。使单据动作按照自己定义的规则来执行，以此来完善企业的业务流程，并对当前业务环节实现事中控制。图 20动作脚本定制2.2.5动作驱动配置配置单据之间的动作驱动关系。具体参见第三章5.1节。左树列示了当前单据在单据动作管理中被定义为“进行驱动配置”的单据动作（参见1.2节）。图 21动作驱动配置项目说明： 目的单据：在当前单据动作完成时，将要进行动作处理的单据。 操作员相关：选择与操作员或角色有关，则该动作仅在所选择的操作员或角色执行时，才会驱动目的单据的动作。 动作：参照选择，选择目的单据被驱动的动作，该类动作在单据动作管理中被定义为“推式动作”（参见1.2节）。2.3 单据VO交换单据类型之间存在相互转换的需求，平台提供了定义单据VO模型间的相互转换规则的机制。单据之间的上下游关系保存在表pub_billtobillrefer中，转换规则作为class文件保存，比如“nc.ui.pf.changedir. CHG21TO30”、“nc.bs.pf.changedir.CHG21TO30”等。单据VO交换可发生在前后或后台，并在交换后可进行特殊的业务处理。详细见第三章5.2节。图 22 单据交换信息项目说明： 被参照单据类型：来源单据类型。 用于显示来源单据的UI类：参照来源单据时，使用的来源单据显示UI。默认为“nc.ui.pub.pf.BillSourceDLG”。 用于查询来源单据的模板ID或UI类：查询来源单据需要使用的查询模板ID或UI。格式有“”、“SO30TO31000000000000”和NULL（默认查询模板）。 用于查询来源单据的节点标识：被参照的来源单据的Nodekey，用于选择查询模板。单据间的交换规则支持简单属性和公式定义，以及额外的交换后业务处理。图 23单据交换规则3. 审批流平台审批流平台为单据的审批处理提供平台支持。基于任务驱动的执行引擎使得流程流转与用户交互分离开来，具有更强的健壮性。支持分支/汇总（Split/ Join）、优先级（Priority）、子流程（Subflow）、可指派、抢占/会签、消息配置、代理人、弃审等流程特性。3.1 流程定义NC5.0的审批流定义模型遵循WfMC的XPDL1.0过程定义规范，具有严格的语义和丰富的描述能力。图 24审批流定义-浏览图 25审批流定义-设计审批流定义按照单据类型（+业务类型）进行了分类。用户可以基于单据类型定义审批流，也可以基于单据类型+业务类型（如果配置了业务流程）来定义审批流。一个单据类型（+业务类型）下可以定义多个审批流，这里可以把单据类型（+业务类型）理解为过程包的概念。3.1.1流程模型过程（Process）由许多被执行的活动和一系列决定活动执行次序的转移构成。活动（Activity）审批流程中的一个个步骤统称为活动（或任务），包括制单活动、审批活动、虚活动、子流程。第一个拖放到审批流设计器中的参与者所属的活动为制单活动。虚活动主要用于对分支/汇总进行建模。子流程可实施流程重用。参与者（Participant）活动的一个属性，即活动的执行者，是对系统中组织模型的引用。目前支持操作员、角色和动态组织三种类型的参与者（HR岗位就是一种动态组织实现）。第一个拖放到审批流设计器中的组织元素为制单活动的参与者。在设计器中，活动和参与者由同一个图元来展现。转移（Transition）活动间的流转，是两个活动间的有向连接。每个转移都具有转移条件（Condition），只有满足条件的转移才可流转。转移条件表达式除了审批结果表达式、单据函数表达式，5.0新增加了单据项目表达式。每个转移还具有优先级（Priority），优先级高的转移分支将被优先选择。分支/汇总（Split/Join）活动具有前驱条件（Join）和后继条件（Split）两个属性，可通过Split/Join-AND/XOR属性组合为过程的选择、并行结构进行建模。加上顺序和循环，这四个基本结构就可描述大多数过程结构。同时，工作流引擎还支持两种反向流转模式：驳回和弃审（参见3.4节）。抢占和会签审批活动的一个属性。会签：只有审批活动的参与者中所有用户完成审批后，该审批活动才能结束。抢占：只要审批活动的参与者中任何一人完成审批后，该审批活动即结束。可指派审批活动的一个属性。如果审批活动定义了可指派属性，则该审批活动的实际执行者需要从其参与者中手工选择。指派的分支优先被选择。流程限定审批活动的一个属性。用于设定前后两个活动的参与者之间的关系。支持“同公司”和“同部门”两种类型。只可为参与者为角色和动态组织的审批活动设置流程限定属性。代理人（Agent）审批活动的一个属性。制单活动不可设置代理人；只可为参与者为操作员类型的审批活动设置多级代理人；代理人只可为操作员。消息配置（Message Config）审批活动的一个属性。可为每个审批活动配置额外的消息通知机制。即在满足触发条件时，以消息、短信、邮件方式通知相关人员。可以为每个审批活动配置额外的消息发送机制。对于制单活动，发送条件必须为“无条件”。对于审批活动，发送条件可为“无条件”、“审核通过”和“审核不通过”三种（注：对于审批活动，“无条件”即该审批活动完成之后就发送）。在消息内容中我们可以使用宏表达式来获取一些业务相关数据。目前可从系统获取的宏对象变量仅有：operater=当前登录操作员PKvo=当前操作的单据VOvos=当前操作的单据VO数组paravo=当前单据的审批流参数VO 参数VO可直接访问的变量列表。这样，在我们的宏表达式中可以直接引用这些对象变量，并调用这些对象的方法（注：完全支持Java语法）。比如：宏表达式含义%paravo.m_billNo%当前单据号%vo.getParentVO().getAttributeValue(“dwbm”)%当前单据VO中的某数据%paravo.m_workFlow.getCheckNote()%当前审批步骤的批语3.1.2增删改审批流程是基于单据类型（+业务类型）来定义的，由各个公司各自定义。选中某个单据类型（+业务类型），就可为其新增一个审批流程。一个单据类型（+业务类型）下不能存在两个同制单人的审批流程。如果某流程定义已经拥有了流程实例，则不允许删除。如果某流程定义已经拥有了流程实例，修改该定义后保存时会重新产生一个流程定义。原有的流程定义处于无效状态，不可再次编辑。3.1.3导入/导出在审批流定义-浏览界面，选中某个流程，可导出为本地XPDL文本文件。1 不导出包定义。2 一次只能导出一个流程。从本地XPDL文本文件导入流程定义到当前单据类型包下：1 如果包定义不存在，则先新建包定义保存，再保存导入的流程定义。2 在导入含子流程的XPDL时，提示“导入的XPDL文件中含有对N个子流程的引用，导入后需要修改流程以重新建立引用关系，是否继续？”。3 不能导入同制单人的流程定义。3.1.4流程定义的选择对于某个单据类型（+业务类型），根据制单人的不同，可定义多个审批流程定义。由于制单人类型支持操作员、角色和动态组织三类，一个操作员制单后，究竟走哪条流程定义，系统按照如下顺序优先选择流程定义：1 制单人为操作员类型的流程；2 制单人为角色类型的流程若制单人委派了多个角色，则只找第一个角色定义的流程；3 制单人为动态组织类型的流程。3.2 工作项工作项是是工作流引擎在流程流转过程中，对活动的参与者根据基本组织单元（操作员）进行任务分配的产物。3.2.1分配策略工作流引擎将产生的工作项直接推给用户，同时用户登录后可选择优先执行哪些任务。参与者出差后，审批工作项将会分配到代理人。动态代理人设置。图 26用户出差和动态代理人管理3.2.2标题定制工作项的标题可由从单据元模型中获取到的信息组成，以便更人性化的显示在待办事务中。图 27工作项内容定制3.2.3关联UI5.0版本中，工作项与UI的关联全部采取功能节点方式。风格一致，业务处理更加方便。工作项与哪个UI关联是由单据类型决定的（参见1.1节）。同时关联的UI必须实现5.0新增的UI关联接口（参见第三章4.6.4节）。3.3 流程结果与单据状态对于审批流程来说，流程实例正常结束后，必然会有一个审批结果。而单据的审批状态与流程结果密切相关。工作项的审批结果即登录到NC系统的操作员对流程平台分配给他的工作项的审批处理意见。包括“批准”、“不批准”、“驳回到制单人”三种。活动的审批结果对于角色/岗位类的参与者执行的审批活动，如果是会签属性，则只有所有会签操作员都审批通过，该活动结果才为审批通过，任何一个会签人审批不通过，该活动结果就为审批不通过；如果是抢占属性，则活动结果为抢占人的审批结果。流程的审批结果恒等于最后一个活动（即流转到结束节点的活动）的审批结果。恒等于最后一个审批人的审批结果。一旦单据送审到审批流中，单据便处于某个审批状态。在审批流内部，单据的内部审批状态有5种：表 1单据审批状态常量取值含义IPfRetBackCheckInfo.NOSTATE-1自由态IPfRetCheckInfo.COMMIT3提交态IPfRetCheckInfo.GOINGON2审批进行中IPfRetCheckInfo.PASSING1审批通过IPfRetCheckInfo.NOPASS0审批不通过业务单据根据自己的业务需求也可定义自己的单据业务状态，但不可与上述5种状态相冲突。比如UI模式化开发包中就定义了更多的单据状态。表 2单据业务状态常量取值含义IBillStatus.FREE8自由态IBillStatus.COMMIT3提交态IBillStatus.CHECKGOING2审批进行中IBillStatus.CHECKPASS1审批通过IBillStatus.NOPASS0审批不通过IBillStatus.DELETE4作废状态IBillStatus.CX5冲销状态IBillStatus.ENDED6终止(结算）态IBillStatus.FREEZE7冻结状态自由态即单据尚在编写中（已保存或尚未保存）并未提交到审批流的状态。提交态通过执行单据动作SAVE或EDIT，将单据送审后的状态。提交态是审批流内部的一个状态，它的回写并不通过审批流检查类进行。只能由业务组通过SAVE动作脚本自己对单据状态进行设置。所以有的业务组的单据并没有提交态的概念。审批进行中流程实例正处于运行中的状态。审批完成如果流程实例正常运行完成，该单据的审批过程即完成。审批流程结束后具有最终审批结果：通过或不通过，这也是单据的最终审批结果。审批状态转换图如下所示：状态转换触发条件自由态-提交态制单后通过执行单据动作SAVE/EDIT将单据送审。提交态-进行中送审后只要有人已审核，即为进行中进行中-完成态流程实例按照定义一步步审批，直至正常流转结束。完成态-自由态一弃到底自由态-完成态提交即审批通过完成态-进行中逐级弃审提交态-自由态驳回到制单人进行中-自由态1 驳回到制单人；2 流程流转到制单活动；3 第一个审批人弃审在各个状态下对单据的业务处理（比如是否可删除、是否可编辑等）由业务组自己控制。流程正常结束时，单据如果审批通过，会给制单人发送“审批通过”的通知消息；单据如果审批不通过，则给参与流程的所有人员发送“审批不通过”的通知消息。3.4 反向流转工作流引擎支持两种反向流转模式：驳回和弃审。驳回是审批人直接将单据退回到制单人，导致单据处于自由态，但流程实例仍运行中。制单人收到驳回工作项，双击可打开单据UI。制单人修单后提交，不会新启实例，但会重新产生工作项；若是其他人修单（更改了制单人），如果找到审批流定义，则新启实例，删除旧实例。如果找不到审批流定义，则删除旧实例，走直批模式。弃审是审批人审批完成后，再撤销自己的操作。有两种弃审模式：逐级弃审和一弃到底，这由单据VO是否实现了逐级弃审接口（参见第三章4.6.3节）来决定。弃审是通过调用“UNAPPROVE”动作来实现的，具有特殊的动作脚本（参见第三章4.4节）。第一个审批人弃审会将单据置为自由态。修单后再提交，会新启实例，旧实例被删除。必须在单据审批完成后才可一弃到底，一弃到底将单据置为自由态，但不会向制单人发送通知消息，修单后再提交不会新启实例。3.5 流程监控对于系统中运行的审批流程实例，可监控它们现在所处的状态，并强制终止。同时还可查询到某单据的审批状态。当前操作员可查询的审批记录受审批查询权限（由审批流用户管理功能节点维护）的限制。图 28单据审批情况查询图 29流程图与审批情况3.6 短信审批NC系统产生的各种消息可通过短消息方式发送到手机用户，并且用户可通过回复的方式直接对单据进行审批，以及其他的业务处理。审批流运转过程中会为流程中的不同用户产生工作项。这些任务项可以通过短信方式发送给对应用户（可配置是否需要这样发送）。用户可回复类似“-p ? N 不同意，金额过大。”或“N 不同意，金额过大。”的审批指令，NC系统会调用审批插件进行后台的审批处理。注意，由于后台审批没有前台交互，所以不支持“指派”特性。具体的实现细节可参考附录。第三章 开发规范1. 平台缓存数据流程平台在前后台对一些频繁访问且不经常更新的数据都有缓存。详细可参考PfDataCache和PfUIDataCache类的Javadoc文档。前台缓存：基本档案表bd_bdinfo的缓存，获取方法：/*返回基本档案VO*/BasedocVO nc.ui.pf.pub.PfUIDataCache.getBdinfo( String strPk) /主键PK单据类型对照信息表pub_billtobillrefer的缓存，获取方法：/*返回单据类型相互参照VO*/BilltobillreferVO nc.ui.pf.pub.PfUIDataCache.getBillInfo( String currentBillType, /目的单据类型PK String billType) /源单据类型PK单据VO对照表pub_votable的缓存，获取方法：/*返回该单据类型主表的PK字段名*/String nc.ui.pf.pub.PfUIDataCache.getBillPK( String billType) /单据类型PK单据类型表bd_billtype的缓存，获取方法：/*返回单据类型VO*/BilltypeVO nc.ui.pf.pub.PfUIDataCache.getBillType( String billType) /单据类型PK币种信息表bd_currtype的缓存，获取方法：/*返回币种VO*/CurrtypeVO nc.ui.pf.pub.PfUIDataCache.getCurrType( String strPk) /币种的PK后台缓存：单据类型参照信息表pub_billtobillrefer的缓存，获取方法：/*返回单据类型相互参照VO*/BilltobillreferVO nc.bs.pf.pub.PfDataCache.getBilltoBillRefer( String billType, /目的单据类型PK String sourceBillType) /源单据类型PK单据VO对照表pub_votable的缓存，获取方法：/*返回单据类型对照VO*/VotableVO nc.bs.pf.pub.PfDataCache.getBillTypeToVO( String pk_billType, /单据类型PK boolean isMain, /是否为主表VO String itemCode) /废弃参数单据类型表bd_billtype的缓存，获取方法：/*返回单据类型VO*/BilltypeVO nc.bs.pf.pub.PfDataCache.getBillTypeInfo(String dataSource, /数据源名称String billType) /单据类型PK2. 动作处理动作处理时序图1：图 30非审批类动作处理动作处理时序图2：图 31审批类动作处理2.1 UI端调用-PfUtilClient1 单据动作处理（非APPROVE）Object nc.ui.pub.pf.PfUtilCcessAction(Container parent, String actionName, String billType, String currentDate, AggregatedValueObject vo, Object userObj, String strBeforeUIClass, AggregatedValueObject checkVo ) throws Exception功能：1 判断是否进行动作前提示2 动作执行前的事前处理 3 如果是新增单据后保存(动作为SAVE)，或修改单据后保存(动作为SAVE或EDIT)，则可能需要指派信息 4 后台执行动作处理- PfUtilBO.processAction()5 如果动作执行的返回值为IProcActionRetObject，则进行事后前台处理 6 如果上述过程发生异常，且异常为IPfRetException，则判断异常是否需要进行业务处理后继续执行事后处理 7 判断返回对象是否为PfUtilActionVO，然后前台显示参数说明：参数名含义及取值parent父UI容器actionName动作编码，比如“SAVE”、“EDIT”billType单据类型PK，比如“D2”currentDate处理时间vo单据聚合VOuserObj用户自定义对象strBeforeUIClassUI端数据校验类checkVo待校验聚合VO，如果为null，则checkVo=vo2 单据动作处理，但不启动审批流Object nc.ui.pub.pf.PfUtilClient. processActionNoSendMessage (Container parent, String actionName, String billType, String currentDate, AggregatedValueObject vo, Object userObj, String strBeforeUIClass, AggregatedValueObject checkVo ) throws Exception功能：1 判断是否进行动作前提示2 动作执行前的事前处理 3 后台执行动作处理-PfUtilBO.processAction()4 如果动作执行的返回值为IProcActionRetObject，则进行事后前台处理 5 如果上述过程发生异常，且异常为IPfRetException，则判断异常是否需要进行业务处理后继续执行事后处理 6 判断返回对象是否为PfUtilActionVO，然后前台显示参数说明：参数名含义及取值parent父UI容器actionName动作编码，比如“SAVE”、“EDIT”。但不可为“APPROVE”billType单据类型PK，比如“D2”currentDate处理时间vo单据聚合VOuserObj用户自定义对象strBeforeUIClassUI端数据校验类checkVo待校验聚合VO，如果为null，则checkVo=vo3 单据动作处理（APPROVE）Object nc.ui.pub.pf.PfUtilCcessActionFlow(Container parent, String actionName, String billType, String currentDate, AggregatedValueObject vo, Object userObj, String strBeforeUIClass) throws Exception功能：1 判断是否进行动作前提示 2 动作执行前的事前处理 3 如果单据动作以APPROVE开头，检查该单据是否处于审批流中并打开审批对话框 4 后台执行动作处理- PfUtilBO.processAction()5 如果动作执行的返回值为IProcActionRetObject，则进行事后前台处理 6 如果上述过程发生异常，且异常为IPfRetException，则判断异常是否需要进行业务处理后继续执行事后处理 7 判断返回对象是否为PfUtilActionVO，然后前台显示参数说明：参数名含义及取值parent父UI容器actionName动作编码，比如“APPROVE”、“UNAPPROVE”billType单据类型PK，比如“D2”currentDate处理时间vo单据聚合VOuserObj用户自定义对象strBeforeUIClassUI端数据校验类4 单据动作批处理（非APPROVE）Object nc.ui.pub.pf.PfUtilCcessBatch(Container parent, String actionName, String billType, String currentDate, AggregatedValueObject voAry, Object userObjAry, String strBeforeUIClass) throws Exception功能：1 判断是否进行动作前提示2 动作执行前的事前处理 3 后台执行动作处理- PfUtilBO.processBatch()4 如果返回对象为IProcActionRetObject，则按照事后业务进行处理5 如果上述过程发生异常，且异常为IPfRetException，则判断是否需要进行业务处理后继续进行动作处理 参数说明：参数名含义及取值parent父UI容器actionName动作编码，比如“SAVE”、“DELETE”billType单据类型PK，比如“D2”currentDate处理时间voAry单据聚合VO数组userObjAry用户自定义对象数组strBeforeUIClassUI端数据校验类5 单据动作批处理（APPROVE）Object nc.ui.pub.pf.PfUtilCcessBatchFlow(Container parent, String actionName, String billType, String currentDate, AggregatedValueObject voAry, Object userObjAry) throws Exception功能：1 判断是否进行动作前提示 2 动作执行前的事前处理 3 如果单据动作以APPROVE开头，检查第一张单据是否可被当前操作员审批并打开审批对话框 4 后台执行批动作处理- PfUtilBO.processBatch()5 如果动作执行的返回值为IProcActionRetObject，则进行事后前台处理 6 如果上述过程发生异常，且异常为IPfRetException，则判断异常是否需要进行业务处理后继续执行事后处理 7 判断返回对象是否为PfUtilActionVO，然后前台显示参