分支/汇总（Split/Join）
活动具有前驱条件（Join）和后继条件（Split）两个属性，可通过Split/Join-AND/XOR属性组合为过程的选择、并行结构进行建模。加上顺序和循环，这四个基本结构就可描述大多数过程结构。同时，工作流引擎还支持两种反向流转模式：驳回和弃审（参见3.4节）。 抢占和会签
审批活动的一个属性。会签：只有审批活动的参与者中所有用户完成审批后，该审批活动才能结束。抢占：只要审批活动的参与者中任何一人完成审批后，该审批活动即结束。 可指派
审批活动的一个属性。如果审批活动定义了可指派属性，则该审批活动的实际执行者需要从其参与者中手工选择。指派的分支优先被选择。 流程限定
审批活动的一个属性。用于设定前后两个活动的参与者之间的关系。支持“同公司”和“同部门”两种类型。只可为参与者为『角色』和『动态组织』的审批活动设置流程限定属性。
代理人（Agent）
审批活动的一个属性。制单活动不可设置代理人；只可为参与者为『操作员』类型的审批活动设置多级代理人；代理人只可为『操作员』。 消息配置（Message Config） 审批活动的一个属性。可为每个审批活动配置额外的消息通知机制。即在满足触发条件时，以消息、短信、邮件方式通知相关人员。
可以为每个审批活动配置额外的消息发送机制。对于制单活动，发送条件必须为“无条件”。对于审批活动，发送条件可为“无条件”、“审核通过”和“审核不通过”三种（注：对于审批活动，“无条件”即该审批活动完成之后就发送）。
在消息内容中我们可以使用宏表达式来获取一些业务相关数据。目前可从系统获取的宏对象变量仅有：
operater==当前登录操作员PK vo==当前操作的单据VO
vos==当前操作的单据VO数组
paravo==当前单据的审批流参数VO
参数VO可直接访问的变量列表。
第 23 页
这样，在我们的宏表达式中可以直接引用这些对象变量，并调用这些对象的方法（注：完全支持Java语法）。比如： 宏表达式 %%paravo.m_billNo%% %%paravo.m_workFlow.getCheckNote()%%
含义 当前单据号 当前审批步骤的批语 %%vo.getParentVO().getAttributeValue(“dwbm”)%% 当前单据VO中的某数据 3.1.2增删改
审批流程是基于单据类型（+业务类型）来定义的，由各个公司各自定义。选中某个单据类型（+业务类型），就可为其新增一个审批流程。一个单据类型（+业务类型）下不能存在两个同制单人的审批流程。 如果某流程定义已经拥有了流程实例，则不允许删除。 如果某流程定义已经拥有了流程实例，修改该定义后保存时会重新产生一个流程定义。原有的流程定义处于无效状态，不可再次编辑。
3.1.3导入/导出
在审批流定义-浏览界面，选中某个流程，可导出为本地XPDL文本文件。
1． 不导出包定义。
2． 一次只能导出一个流程。
从本地XPDL文本文件导入流程定义到当前单据类型包下：
1． 如果包定义不存在，则先新建包定义保存，再保存导入的流程定义。
2． 在导入含子流程的XPDL时，提示“导入的XPDL文件中含有对N个子流程的引用，
导入后需要修改流程以重新建立引用关系，是否继续？”。 3． 不能导入同制单人的流程定义。
3.1.4流程定义的选择
对于某个单据类型（+业务类型），根据制单人的不同，可定义多个审批流程定义。由于制单人类型支持『操作员』、『角色』和『动态组织』三类，一个操作员制单后，究竟走哪条流程定义，系统按照如下顺序优先选择流程定义： 1． 制单人为『操作员』类型的流程；
2． 制单人为『角色』类型的流程——若制单人委派了多个角色，则只找第一个角色定义的
流程；
3． 制单人为『动态组织』类型的流程。
第 24 页
3.2 工作项
工作项是是工作流引擎在流程流转过程中，对活动的参与者根据基本组织单元（操作员）进行任务分配的产物。
3.2.1分配策略
工作流引擎将产生的工作项直接推给用户，同时用户登录后可选择优先执行哪些任务。参与者出差后，审批工作项将会分配到代理人。动态代理人设置。
图 26用户出差和动态代理人管理
3.2.2标题定制
工作项的标题可由从单据元模型中获取到的信息组成，以便更人性化的显示在待办事务中。
第 25 页
图 27工作项内容定制
3.2.3关联UI
5.0版本中，工作项与UI的关联全部采取功能节点方式。风格一致，业务处理更加方便。工作项与哪个UI关联是由单据类型决定的（参见1.1节）。同时关联的UI必须实现5.0新增的UI关联接口（参见第三章4.6.4节）。
3.3 流程结果与单据状态
对于审批流程来说，流程实例正常结束后，必然会有一个审批结果。而单据的审批状态与流程结果密切相关。 工作项的审批结果 即登录到NC系统的操作员对流程平台分配给他的工作项的审批处理意见。包括“批准”、“不批准”、“驳回到制单人”三种。
活动的审批结果 对于角色/岗位类的参与者执行的审批活动，如果是会签属性，则只有所有会签操作员都审批通过，该活动结果才为审批通过，任何一个会签人审批不通过，该活动结果就为审批不通过；如果是抢占属性，则活动结果为抢占人的审批结果。
流程的审批结果 恒等于最后一个活动（即流转到结束节点的活动）的审批结果。恒等于最后一个审批人的审批结果。
一旦单据送审到审批流中，单据便处于某个审批状态。在审批流内部，单据的内部审批
第 26 页
状态有5种：
表 1单据审批状态
常量 取值 含义 自由态 提交态 审批进行中 审批通过 审批不通过 IPfRetBackCheckInfo.NOSTATE -1 IPfRetCheckInfo.COMMIT 3 IPfRetCheckInfo.GOINGON IPfRetCheckInfo.PASSING IPfRetCheckInfo.NOPASS 2 1 0
业务单据根据自己的业务需求也可定义自己的单据业务状态，但不可与上述5种状态相冲突。比如UI模式化开发包中就定义了更多的单据状态。
表 2单据业务状态
常量 IBillStatus.FREE IBillStatus.COMMIT IBillStatus.CHECKGOING IBillStatus.CHECKPASS IBillStatus.NOPASS IBillStatus.DELETE IBillStatus.CX IBillStatus.ENDED IBillStatus.FREEZE 取值 含义 自由态 提交态 审批进行中 审批通过 审批不通过 作废状态 冲销状态 终止(结算）态 冻结状态 8 3 2 1 0 4 5 6 7
自由态
即单据尚在编写中（已保存或尚未保存）并未提交到审批流的状态。
提交态
通过执行单据动作SAVE或EDIT，将单据送审后的状态。提交态是审批流内部的一个状态，它的回写并不通过审批流检查类进行。只能由业务组通过SAVE动作脚本自己对单据状态进行设置。所以有的业务组的单据并没有提交态的概念。
审批进行中
流程实例正处于运行中的状态。
审批完成
如果流程实例正常运行完成，该单据的审批过程即完成。审批流程结束后具有最终审批结果：通过或不通过，这也是单据的最终审批结果。
审批状态转换图如下所示：
第 27 页