请假
任务类型:提交类(需要确认) processType="OA_LEAVE"
触发条件
用户提到"请假"等关键词。
需要收集的信息
- 请假类型:事假 / 婚假 / 产假 / 工伤假 / 丧假(只有这5种请假类型)
- 开始日期:哪天开始请假?(请把用户输入转换为 YYYY-MM-DD 的格式)
- 开始半天:开始当天从上午还是下午开始?
- 结束日期:哪天结束?(请把用户输入转换为 YYYY-MM-DD 的格式)
- 结束半天:结束当天上午还是下午结束?
- 合计天数:根据开始/结束日期及半天信息自动推算,无需向用户询问
- 请假事由:请假原因是什么?
- PS工号:从 system 消息中的[用户信息]获取PS工号字段,无需向用户询问
- 申请人组织编码:从 system 消息中的[用户信息]获取组织编码,无需向用户询问
- 申请人岗位编码:从 system 消息中的[用户信息]获取岗位编码,无需向用户询问
参数收集注意事项
- 若用户说"请两天假"、"三天",限定了合计天数的,无需询问用户"开始半天"和"结束半天",自动设置为"开始半天"为"上午","结束半天"为"下午","合计天数"为用户输入的天数。
- 若用户说"明天请假"、"后天请假",一般认为"合计天数"为 1,自动设置为"开始半天"为"上午","结束半天"为"下午","开始日期"和"结束日期"根据系统时间自动计算。
- "生病"、"身体不舒服"、"回家探亲"、"朋友、亲戚等非本人结婚",都属于"事假"范畴。
执行方式
python3 scripts/oa-leave.py \
--processType OA_LEAVE \
--initUserAcc {PS工号} \
--orgBranchCode {申请人组织编码} \
--positionCode {申请人岗位编码} \
--leaveType {请假类型} \
--leaveStartTime {开始日期} \
--leaveStart {上午|下午} \
--leaveEndTime {结束日期} \
--leaveEnd {上午|下午} \
--countDay {合计天数} \
--assigneeContent {请假事由}
调休
任务类型:提交类(需要确认) processType="OA_CPSLEAVE"
触发条件
用户提到"调休"等关键词。
需要收集的信息
- 剩余调休天数:员工剩余的调休天数,根据
oa-cpsleave-query.py脚本返回的信息中获取。 - 开始日期:哪天开始调休?(请把用户输入转换为 YYYY-MM-DD 的格式)
- 开始半天:开始当天从上午还是下午开始?
- 结束日期:哪天结束?(请把用户输入转换为 YYYY-MM-DD 的格式)
- 结束半天:结束当天上午还是下午结束?
- 合计天数:根据开始/结束日期及半天信息自动推算,无需向用户询问
- 调休备注:调休原因或备注信息
- PS工号:从 system 消息中的[用户信息]获取PS工号,无需向用户询问
- 申请人组织编码:从 system 消息中的[用户信息]获取组织编码,无需向用户询问
- 申请人岗位编码:从 system 消息中的[用户信息]获取岗位编码,无需向用户询问
参数收集注意事项
- 用户要调休,第一步先调用
oa-cpsleave-query.py查询用户的剩余调休天数,若剩余调休天数为 0,则提示用户无法进行调休申请,不再进行调休申请的参数收集。然后看用户的输入。 - 若用户说"调休两天"、"三天",限定了合计天数的,无需询问用户"开始半天"和"结束半天",自动设置为"开始半天"为"上午","结束半天"为"下午","合计天数"为用户输入的天数。
- 若用户说"明天调休"、"后天调休",一般认为"合计天数"为 1,自动设置为"开始半天"为"上午","结束半天"为"下午","开始日期"和"结束日期"根据系统时间自动计算。
查询剩余调休天数
python3 scripts/oa-cpsleave-query.py \
--processType OA_CPSLEAVE_QUERY \
--initUserAcc {PS工号}
执行方式
python3 scripts/oa-cpsleave.py \
--processType OA_CPSLEAVE \
--initUserAcc {PS工号} \
--orgBranchCode {申请人组织编码} \
--positionCode {申请人岗位编码} \
--remainingTime {剩余调休天数} \
--startTime {开始日期} \
--startTimeRange {上午|下午} \
--endTime {结束日期} \
--endTimeRange {上午|下午} \
--totalTime {合计天数} \
--assigneeContent {调休备注}
补卡
任务类型:提交类(需要确认) processType="OA_ABSENCE_REPAIR"
触发条件
用户提到"补卡"、"忘记打卡"、"漏打卡"等关键词。
需要收集的信息
- 补卡月份:需要补哪个月的卡?(根据缺卡记录和用户输入,自动转换格式为 YYYY-MM,无需向用户询问)
- 当月或上月:补卡月份是当月还是上月?(只有每月1、2号才可以选择上月)
- 缺卡时间:具体哪天缺卡,从查询结果中获取(示例:"2026-03-03星期二上班卡,2026-03-03星期二下班卡",多个用","隔开)
- 补卡理由:为什么需要补卡?
- 已经补卡次数:从查询结果中获取,无需向用户询问
- 剩余补卡次数:从查询结果中获取,无需向用户询问
- PS工号:从 system 消息中的[用户信息]获取PS工号,无需向用户询问
- 申请人:从 system 消息中的[用户信息]获取用户名,无需向用户询问
- 申请人ID:从 system 消息中的[用户信息]获取,无需向用户询问
- 申请人组织编码:从 system 消息中的[用户信息]获取组织编码,无需向用户询问
- 申请人岗位编码:从 system 消息中的[用户信息]获取岗位编码,无需向用户询问
参数收集注意事项
- 用户要补卡,第一步先判断当前日期,若是每月1、2号才可以选择上月和当月,否则只能选择当月。第二步调用
oa-absence-query.py脚本获取用户的缺卡信息,然后根据查询结果进行参数收集 - "当月"对应 monthType="0","上月"对应 monthType="1"(只有每月1、2号才可以选择上月)
- 缺卡信息需要通过调用查询脚本获取,包括缺卡时间、缺卡类型、剩余补卡次数等
- 若用户的剩余补卡次数为 0,则提示用户无法进行补卡申请,不再进行补卡申请的参数收集
- 若用户缺卡次数大于剩余补卡次数,则只让用户选择剩余补卡次数的补卡申请,并提示用户无法进行多余的补卡申请
查询缺卡信息
在收集补卡申请前,需要先调用查询脚本获取用户的缺卡信息:
python3 scripts/oa-absence-query.py \
--processType OA_ABSENCE_QUERY \
--initUserAcc {PS工号} \
--initUser {申请人} \
--initUserId {申请人ID} \
--monthType {0|1}
查询结果会返回:
- 剩余补卡天数
- 已补卡次数
- 缺卡记录列表(包含缺卡时间、缺卡类型等)
请把缺卡记录按照如下示例格式进行输出,上班卡和下班卡分开展示:
- 缺卡时间:2026-03-01(星期日),缺卡类型:上班卡
- 缺卡时间:2026-03-01(星期日),缺卡类型:下班卡
- 缺卡时间:2026-03-02(星期一),缺卡类型:上班卡
- 缺卡时间:2026-03-03(星期二),缺卡类型:上班卡
执行方式
python3 scripts/oa-absence-repair.py \
--processType OA_ABSENCE_REPAIR \
--initUserAcc {PS工号} \
--orgBranchCode {申请人组织编码} \
--positionCode {申请人岗位编码} \
--count {已经补卡次数} \
--last {剩余补卡次数} \
--bkNowDateType {当月|上月} \
--bkNowDate {补卡月份} \
--leaveEndTime {缺卡时间} \
--assigneeContent {补卡理由}
终止流程
任务类型:提交类(需要确认) processType="OA_CANCEL"
触发条件
用户提到"终止流程"等关键词,或从 result 卡片点击"终止流程"按钮。
上下文说明
当用户从 result 卡片点击"终止流程"按钮时,这是一个全新的独立操作:
- 系统需要重新进入信息收集阶段,收集流程号和终止原因
- 用户可以在参数收集过程中随时取消该操作
需要收集的信息
请依次向用户确认以下信息(已知的跳过):
- 流程号:提交申请后返回的 processInstanId
- 终止原因:终止流程的原因
执行方式
python3 scripts/oa-cancel.py \
--processType OA_CANCEL \
--processInstanId {流程号} \
--ediaHtml {终止原因}
出差申请
任务类型:提交类(表单收集,需要确认)
触发条件
用户提到"出差"、"出差申请"等关键词。
处理流程(表单收集类,使用 triggerForm,无需确认)
严禁通过对话逐步询问参数,必须使用 triggerForm 工具触发前端表单。
前端表单已包含校验和确认逻辑,提交即视为确认,严禁调用 requestConfirmation。
第一步:鉴权查询出差类型
识别到出差意图后,先调用鉴权脚本查询该用户适用的出差类型(PS系统ID从 system 消息中的[用户信息]获取):
python3 scripts/oa-didi-auth.py \
--processType OA_DIDI_AUTH \
--empId {PS系统ID}
鉴权结果说明:
- 返回
{"data": "1"}→ 滴滴出差 - 返回
{"data": "2"}→ 普通出差
重要约束:鉴权结果是强制性的,必须严格遵循,不允许跨类型发起申请:
- 若鉴权为1(滴滴出差):用户只能发起滴滴出差申请,绝不允许发起普通出差申请
- 若鉴权为2(普通出差):用户只能发起普通出差申请,绝不允许发起滴滴出差申请
- 若用户明确要求与鉴权结果不符的出差类型(如鉴权为1但要求普通出差),必须告知用户:"根据您的权限,您只能发起XX出差申请,无法申请其他类型"
第二步:触发对应表单
根据鉴权结果调用 triggerForm 工具,通过 processType 告知前端渲染哪种表单:
| 鉴权结果 | processType | title |
|---------|-------------|-------|
| data=1 | OA_BUSINESS_TRIP_DIDI | 滴滴出差申请 |
| data=2 | OA_BUSINESS_TRIP_COMMON | 普通出差申请 |
调用后只输出一句引导语(如"请在弹出的表单中填写出差信息"),不再询问任何参数。
第三步:解析表单数据并按参数要求执行脚本
- 用户填写表单后,前端会发送以
[出差申请]开头的消息,后接 JSON 格式参数。 - 收到后直接解析 JSON,根据出差类型执行对应脚本,严禁调用
requestConfirmation或再次调用triggerForm。 - 必须校验表单类型与鉴权结果一致:若出现鉴权为1但收到普通出差表单数据,或鉴权为2但收到滴滴出差表单数据,必须拒绝执行并提示"您没有权限发起该类型的出差申请"
第四步:展示结果
脚本执行完毕后,调用 showResult 展示结果卡片。
执行方式(滴滴出差,data=1)
python3 scripts/oa-business-trip-didi.py \
--processType OA_BUSINESS_TRIP_DIDI \
--initUserAcc {PS工号} \
--orgBranchCode {申请人组织编码} \
--positionCode {申请人岗位编码} \
--tripMode {出行方式} \
--companySubject {公司主体} \
--companyTaxIDNumber {公司税号} \
--startTime {出差开始日期} \
--endTime {出差结束日期} \
--totalTime {合计天数} \
--isInternational {国内|国际} \
--startingPoint {出差起点} \
--startingPointId {出差起点ID} \
--endPoints {出差地点} \
--endPointsIds {出差地点ID} \
--assigneeContent {出差理由及工作内容}
--extJsonData {同行人信息Json数据}
执行方式(普通出差,data=2)
python3 scripts/oa-business-trip-common.py \
--processType OA_BUSINESS_TRIP_COMMON \
--initUserAcc {PS工号} \
--orgBranchCode {申请人组织编码} \
--positionCode {申请人岗位编码} \
--tripMode {出行方式} \
--startTime {出差开始日期} \
--endTime {出差结束日期} \
--countDay {合计天数} \
--outMoney {预计出差费用} \
--addf {出差起点} \
--addr {出差地点} \
--assigneeContent {出差理由及工作内容}
查看流程详情
任务类型:查询类(无需确认)
触发条件
用户提到"查看详情"、"查看流程详情"、"我的申请到谁审批了"等关键词。
需要收集的信息
- 流程号:可从上下文获取或向用户询问
执行方式
不需要执行脚本,直接将流程号拼接到 URL 并用 img 标签输出: <img src="{OA_BASE_URL}/app/ProcessImageController/getImage?proInstId={流程号}&colorStr=FFFFFF" />
注意:{OA_BASE_URL} 是系统自动注入的环境变量,实际输出时请直接使用该占位符,系统会根据当前环境自动替换为正确的 OA 地址。
Scan to contact