职业角色供应链/财务运营使用的灵基能力Work Skillshipment-audit-receivable-v2适用场景职能管理发货审核与风控一、应用场景及解决的痛点问题发货审核是供应链流转中的关键卡点——发货通知单从已提交到已审核背后需要审核人员确认客户信用是否充足、应收账款是否正常、回款流水是否健康。这件事的难点不在于判断本身而在于数据分散在四个不同的业务模块里。我负责的发货审核工作每次拿到一张发货通知单需要依次完成以下操作打开销售管理模块查发货通知单详情和客户信息切到信用管理模块查客户信用额度和可用余额再切到应收管理模块查该客户的应收单据和核销状态最后切到出纳管理模块查近期收款流水。四个模块来回切换逐项核对后才能决定是否放行。一张单子走完整个流程快的话十几分钟遇到应收异常需要追溯逾期天数和收款计划时耗时更长。更麻烦的是多系统切换过程中很容易遗漏关键信息——比如客户有一笔逾期5天的应收款未核销如果审核时只看了信用额度没查应收明细这个风险点就漏掉了。发货审核不是走个流程盖个章它直接关系到企业资金安全和坏账风险漏掉一个维度就可能造成损失。二、实践过程【核心能力】本次实践使用了灵基的 Work 模式调用 shipment-audit-receivable-v2 技能Skill。该技能封装了发货审核全链路的十步流程通过 5 个 MCP 接口串联销售管理、基础资料、信用管理、应收管理和出纳管理五个业务模块实现从发货通知单查询到收款建议生成的全自动化审核。具体用到的 MCP 接口- 发货通知单批量查询sm_delivernotice_batchquery- 客户信息查询bd_customer_querycustomer- 客户信用额度查询credit_getcustcreditbalance- 财务应收单查询ar_finarbill_query- 出纳收款单查询cas_recbill_query【实现思路】整体思路是把审核人员手工执行的十步操作固化为技能流程让灵基按步骤自动调用对应接口采集数据再通过综合判定逻辑输出审核建议。关键设计在于——不是简单地把数据查出来堆在一起而是按照信用额度、应收账款、收款流水三个维度分别判定最后综合给出“通过/不通过/有条件通过”的结论。【关键步骤】1. 查询发货通知单调用发货通知单查询接口按单据编号和发货组织筛选待审核的发货通知单获取单据状态、客户信息、物料明细和金额信息。这一步确定了后续所有查询的客户主体和发货金额。1. 查询客户基本信息根据发货通知单上的客户编码调用客户信息查询接口获取客户状态、客户分组、收款条件等基础信息。这一步的目的是确认客户档案是否正常——比如客户是否被冻结发货、是否属于优质客户分组。1. 查询客户信用额度调用信用额度查询接口传入发货组织编码和客户编码查询客户的授信额度、已占用额度、可用余额、逾期金额等信用指标。判定逻辑是如果可用余额大于等于本次发货金额信用检查通过否则不通过。实际执行中信用查询返回了 ccm.30012 错误——“没有查到信用数据”。这说明该组织未启用信用管理模块或客户未配置信用方案。技能的处理策略是跳过信用额度检查标记为“未配置”不作为审核通过的依据提示用户手工核查。这个降级处理很关键——不能因为查不到信用数据就直接放行也不能因为查不到就阻断整个流程。1. 查询应收账款情况调用财务应收单查询接口按结算组织和客户编码查询该客户的应收单据。这一步关注两个维度是否有大额未核销应收款、是否有长期逾期款项。查询结果很有价值客户A有两笔应收单一笔64,000元已核销另一笔56,637.17元处于未核销状态且已逾期5天。客户B则没有任何应收记录。这些信息直接影响了后续的综合判定。1. 查询收款流水调用出纳收款单查询接口查询该客户近期的收款记录核实客户是否有正常的回款动作。查询结果显示客户A在近期有一笔64,000元的收款记录回款正常客户B无收款流水记录。1. 综合判定技能将以上三个维度的检查结果汇总对每条发货通知单做出综合判定。以客户A的发货单为例信用维度跳过未配置信用方案应收维度警告存在5天逾期56,637.17元收款维度通过近期有64,000元正常回款——综合判定为“有条件通过”建议人工确认信用状况后审核。1. 用户确认与审核执行综合判定结果展示给用户确认后技能调用发货通知单提交接口和批量审核接口将发货通知单从已提交B状态流转为已审核C状态。审核完成后重新查询确认状态变更成功并记录本次发货金额作为信用额度使用记录。1. 生成收款建议审核完成后技能根据发货金额和客户应收情况自动生成收款建议。对于客户A建议催收逾期款项后再安排后续发货并按“预收30%货到收款70%”的收款条件跟进预收款对于客户B建议关注首单回款风险确认收款条件后跟进收款。三、效果与价值【亮点与价值】1. 全链路自动串联十步审核流程从发货通知单查询到收款建议生成5个MCP接口按预设逻辑自动调用审核人员不需要在四个模块之间手动切换。原来需要逐个打开系统、逐项核对的操作现在一句话触发技能即可完成全链路数据采集和判定。2. 多维度交叉风控不是单一维度判断“能不能发货”而是信用额度、应收账款、收款流水三个维度交叉验证。本次实践中信用维度因模块未启用而无法自动评估但应收维度发现了客户A存在5天逾期未核销应收款56,637.17元——这个风险点在手工审核时很容易被遗漏因为审核人员通常会优先看信用额度应收明细需要额外切换系统才能看到。3. 降级处理而非阻断信用管理模块未启用时技能没有直接报错阻断而是跳过信用检查并明确提示“需手工核查”。这种设计保证了流程的连续性——其他维度应收、收款的检查仍然正常执行审核人员可以基于已有信息做判断同时被明确告知哪个维度需要补充人工核查。4. 产物可追溯技能执行完成后生成两类产物——结构化JSON数据文件和可视化HTML报告。JSON文件记录了每一步的接口调用参数、返回结果和判定逻辑HTML报告以表格和卡片形式展示全流程详情。审核人员可以把报告存档后续追溯审核依据时直接查阅。【可量化数据】维度数据串联的MCP接口数5个跨5个业务模块自动执行的审核步骤10步本次审核的发货单数2条发现的逾期应收风险56,637.17元逾期5天生成的产物文件2个JSON HTML报告发货审核的本质不是盖章是风控。把多系统数据采集交给技能审核人员才能真正做风险判断——而不是把时间花在来回切换系统找数据上。四、总结1. 降级处理是技能设计的关键能力实际业务环境中不是所有模块都已启用、不是所有客户都配置了信用方案。技能设计时必须考虑“查不到数据怎么办”——不能因为一个维度缺失就阻断整个流程也不能默认通过。shipment-audit-receivable-v2 的做法是跳过该维度、明确标记“无法评估”、提示手工核查同时继续执行其他维度的检查。这种降级策略保证了技能在非理想环境下仍然可用。1. MCP接口参数类型需要特别注意实践过程中踩了一个坑应收查询接口的 org_number 和 asstact_number 参数是字符串类型直接传编码值即可而信用查询接口的 org 和 customers 是对象类型需要包装为 {number: 编码} 的格式。不同接口的参数类型不一致技能文档中已明确标注但初次使用时容易混淆。建议后续在技能描述中增加参数类型的对比说明。1. 多维度交叉判定的价值远大于单维度检查本次实践中最有价值的发现来自应收维度——客户A的信用额度无法评估模块未启用如果只查信用维度结论是“无法判断”。但应收维度查出了5天逾期未核销56,637.17元收款维度确认了近期有正常回款64,000元。三个维度交叉后审核人员得到的不是“能不能发货”的二选一而是“信用待核查、应收有逾期、回款正常”的立体画像——这才是做审核决策需要的信息。五、其他附件材料• 可视化HTML报告shipment-audit-full-report.html以表格和卡片形式展示全流程详情含十步步骤展开、综合判定结果和JSON标准输出