<0>简述

套打中支持获取对应单据审批路线和流程节点的数据，以下内容描述套打中对应工作流数据的取数逻辑和干预数据包接口的数据结构

演示数据如下：

<1>套打中工作流的实现

第一步，根据业务对象标识和单据内码获取当前运行流程实例Id，

根据业务对象标识和单据内码能够获得多个流程实例，需要考虑历史流程终止的处理场景。

以当前单据为例，对应有三个流程，可以通过状态获取最终有效的流程，也可以通过流程发起时间最晚的流程.

第二步，根据流程实例Id获取所有流程审批任务的处理结果（套打特定流程下的节点数据）

以某个节点验证数据正确性，内容参考【套打】套打取工作流指定流程的节点信息

<2>套打非默认版本的节点信息

对应66节点审批节点2，两个处理人，李员工和demo；

在套打中中流程节点结果的数据显示：

备注：会签/加签情况下处理人的打印顺序在2012 11月修复 PT-146861  [7.6.0.202011]；注意考虑子项审批任务的主键为string，需要强制指定按子项处理时间排序（见sql）

备注2：由于目前流程还在运行中，因此不会归档，对应能够直接在表中查询数据；一旦流程归档，无法通过该SQL获取流程节点数据，对应的数据表归档迁移

T_WF_APPROVALITEM -> T_WF_APPROVALITEMHIS

T_WF_APPROVALASSIGN -> T_WF_APPROVALASSIGNHIS

T_WF_APPROVALASSIGN_L -> T_WF_APPROVALASSIGNHIS_L

T_WF_ASSIGN -> T_WF_ASSIGNHIS

t_wf_actInst -> T_WF_ACTINSTHIS

附：查找对应单据关联的所有流程模板和当前运行流程模板指定版本元数据

<3>套打干预数据包接口及套打工作流数据包的数据结构

套打干预数据包接口，能够获取数据源标识和单据内码，并根据数据源标识能够判断审批路线取数或流程节点取数；

（0）套打工作流数据包仅在工作流数据有效下才存在，有可能存在工作流流程实例但是套打工作流数据为空的逻辑（流程被终止且反审核，该流程不会套打），建议严格按照数据包是否为空进行代码处理

（1）套打审批路线的数据包结构：

对应字段标识为 ac_approve_{fieldkey}；

ac_approve_FActivityName——节点名称

ac_approve_FActivityStatu——节点状态

ac_approve_FStartActivity——开始节点

ac_approve_FTargetActivity——目的节点

ac_approve_FActionName——动作主题

ac_approve_FReceiverName——处理人

ac_approve_FActionResult——审批项

ac_approve_FDisposition——审批意见

ac_approve_FCompletedTime——处理时间

ac_approve_FConsignNames——委托人

ac_approve_FReceiverESignature——处理人签章（PT-146836  [7.5.1.202005]新加）支持打印流程节点的处理人签章，需要在流程节点中启用电子签章审批

ac_approve_FESignaturePermission——处理人签章权限（PT-146836  [7.5.1.202005]新加）由于不启用电子签章审批和启用审批处理人签章为空时，图片均为空，为了针对启用电子签章审批但没有处理人签章的时候打印文本内容，增加了权限字段（参考图片控件的为空输出文本页签）

备注：审批路线数据包为完整数据包结构，不考虑模板上绑定的字段；

（2）套打流程节点的数据包结构：

对应字段标识为 ac_{activityid}_{fieldkey}，其中activityid为流程节点内码；

ac_{activityid}_ReceiverNames——处理人

ac_{activityid}_Disposition——处理意见

ac_{activityid}_Result——处理结果

ac_{activityid}_CompletedTime——处理时间

ac_{activityid}_ReceiverESignature——处理人签章，打印一个，备注：对应处理人和处理意见对应的输出顺序修正了，但是处理人签章不做修正，目前还是按照历史逻辑渲染（主键顺序首个处理人），可能与处理人不对应

备注：流程节点数据包为完整数据包结构，不考虑模板上绑定的字段，同时所有节点以平铺形式放置在数据包中；

附件：SQL文件和插件代码示例

WorkFlow.rar