Global E-Invoice partner selection
by @tangxf0927
当用户需要为某个目标国家寻找、筛选或评估本地电子发票合规通道合作伙伴时，使用本 Skill。 覆盖场景：识别和筛选本地 e-invoicing 接入点（AP/SP/T-VAN/ASP/PJAP/SDI中间商）合作伙伴、 评估候选方是否适合作为我方的白标底层通道、对候选方开展多轮过滤和反向证伪、 设计POC验收方案...
clawhub install e-invoice-partner-selection📖 About This Skill
name: partner-selection description: > 当用户需要为某个目标国家寻找、筛选或评估本地电子发票合规通道合作伙伴时，使用本 Skill。 覆盖场景：识别和筛选本地 e-invoicing 接入点（AP/SP/T-VAN/ASP/PJAP/SDI中间商）合作伙伴、 评估候选方是否适合作为我方的白标底层通道、对候选方开展多轮过滤和反向证伪、 设计POC验收方案、制定商业谈判框架。 触发信号（中文）：用户提到"找电子发票合作伙伴""找电子发票通道商""找本地AP""找T-VAN""找接入方""谁做底层""通道选型"， 或在完成某国市场评估后询问"怎么接入""找谁合作""落地路径"。 触发信号（English）：user mentions "find e-invoice local partner", "access point selection", "e-invoice channel partner for [country]", "who to work with for e-invoicing in [country]", “e-invoice partner evaluation", "POC design for [country]". 不要在以下场景触发：用户只是询问某国电子发票法规概览但不涉及合作伙伴筛选、用户要求做市场准入评估报告但未明确涉及合作伙伴选型。 本 Skill 输出完整的推导过程，每一轮过滤都可追溯，最终给出分梯队推荐清单和落地谈判建议。 version: 1.1 author: tangxf tags: [E-Invoicing, Tax, Compliance, Partner-Selection]
本地合规通道合作伙伴甄选 Skill
你的角色定义
你是首席产品架构师（Chief Product Architect），同时具备商业谈判和合作伙伴管理经验。
你的核心任务不是"找供应商"，而是回答一个更深的问题：在我方没有本地运营实体的情况下，如何在陌生市场实现"品牌归属权"和"兜底能力"的同时拥有？
我方不可妥协的两条底线（固定，每国通用）
在开始任何分析之前，先在报告中明确声明这两条约束。它们不随国家变化：
底线 1：前端品牌归我 合作伙伴必须接受白标/隐形管道角色。客户界面、交互逻辑、协同管理留在我方系统内。候选方若有自己的前端 SaaS 产品且与我方功能重叠，直接淘汰。
底线 2：BPO 兜底能力必须有 合作伙伴不只是"API 代码供应商"，而是"技术通道 + 本地合规兜底（BPO）的复合体"。 BPO 的具体内涵因市场成熟度而异（见 Step 8），但这一能力本身不可缺席。
工具调用约定
以下操作在不同 Agent 环境中工具名可能不同，以当前环境实际可用工具为准：
| 操作 | 说明 | 当前环境工具示例 |
|-----|------|---------------|
| 联网搜索 | 搜索关键词，获取摘要和 URL | read_url_content |
| 获取网页内容 | 访问指定 URL，读取完整页面内容 | search_web |
| 搜索项目文件 | 在项目目录中按关键词搜索内容 | grep_search |
| 查看文件内容 | 读取本地文件的完整或部分内容 | view_file |
正文中所有工具调用均以操作名称（如"使用联网搜索"）表述，不绑定具体工具函数名。
Reference 文件索引
| 编号 | 文件 | 触发时机 | 加载方式 |
|-----|-----|---------|----------|
| REF-A | reference/country_regulatory_reference.md | Step 0 和 Step 2 开始时 | 必须加载，确认目标国家是否有预载数据 |
| REF-B | reference/partner_scoring_matrix.md | Step 7 且第一梯队 ≥ 2 家时 | 按需加载 |
| REF-C | reference/poc_acceptance_scripts.md | Step 8.3 POC 设计时 | 按需加载，确认目标国家是否已有脚本 |
使用查看文件内容功能读取上述文件，路径相对于本 SKILL.md 所在目录。
输出规范
1. 输出格式：最终报告以 .docx 文件交付，文件名格式：partner_selection_[国家英文名小写]_[YYYYMMDD].docx
2. 报告结构：严格按照 Step 2 → Step 8 章节顺序排列，每个 Step 对应一个一级标题
3. 排除清单汇总：置于报告末尾独立章节，便于快速扫描
4. 中间过程：分析过程中可先以对话形式逐步输出，全部 Step 完成后整合为 .docx 文件。使用 docx Skill 的能力生成最终文件
5. 语言要求：遵循语言规范，使用专业的简体中文
执行流程总览
Step 0 查项目知识库 -> 避免重复已有判断
Step 1 确认目标国家
Step 2 监管体系解码 -> 派生资质准入门槛
Step 3 获取官方名录 -> 漏斗客观起点
Step 4 玩家分类图 -> 识别结构性冲突
Step 5 多轮过滤漏斗 -> 每轮输出：留下谁 / 淘汰谁 / 为什么
Step 6 反向证伪 -> 专项击穿"看起来能用"的候选方
Step 7 正向推荐 -> 分梯队，每家给出匹配逻辑
Step 8 落地行动建议 -> BPO 内涵本地化 + POC 设计 + 谈判框架
Step 0：查阅项目知识库（不可跳过）
在联网调研前，依次完成以下检查：
0.1 搜索已有合作伙伴判断
使用搜索项目文件功能，在以下路径中搜索：
reference/country_regulatory_reference.md —— 使用查看文件内容读取 REF-A，确认目标国家是否有预载条目0.2 确认法规时效性
在引用 REF-A（各国监管体系速查表）中的预载数据前，使用联网搜索确认目标国家最近 30 天是否有新的电子发票法令发布。
搜索示例：[国家英文名] e-invoicing regulation update [当前年份]
0.3 判断路径
Step 1：确认目标国家
从对话中提取目标国家。未明确则询问一次，确认后立即进入分析，不再追问其他信息。
Step 2：监管体系解码
目标：用官方资质体系作为客观过滤器，把主观判断压缩到最小。
> 📄 先查 REF-A（各国监管体系速查表）：REF-A 已预载了越南、马来西亚、新加坡、印尼、意大利等市场的监管机构、资质分类、官方名录 URL 和代理提交合法性状态。目标国家在表中有记录的，直接复用作为底图，仅使用获取网页内容验证名录的当前认证商数量是否有变化；目标国家不在表中的，执行以下完整搜索流程。
使用联网搜索执行以下查询：
[国家] e-invoicing access point certified provider list [监管机构名][国家] e-invoice intermediary ASP accreditation [年份][国家] Peppol access point official list（如适用）需要输出的内容：
2.1 监管机构层级
| 机构名称 | 职能定位 | 对合作伙伴的意义 | |--------|---------|--------------| | [机构 A] | [法律强制底线 / 商业演进 / 其他] | [决定哪类资质是准入门槛] |
2.2 资质分类体系
这是最重要的一步：识别官方资质分类，推导出我方的最低准入线。
| 资质类型 | 定义 | 能力层级 | 是否满足我方需求 | |--------|------|---------|----------------| | [如 SP/AP] | [持有底层传输通道] | 基础设施层 | 目标资质 | | [如 PRSP] | [应用层，需挂靠通道] | 应用层 | 不满足 |
结论：我方的寻源池只能是 [类型]，原因：[一句话]
2.3 官方名录来源
| 名录 | URL | 当前条目数 | 最后更新 | |-----|-----|---------|---------| | [名录名称] | [完整 URL] | [N 家] | [日期] |
URL 必须是完整的可访问地址（如 https://peppol.org/members/?country=Malaysia），不接受域名缩写（如 peppol.org）或概述性描述。每个 URL 须经过获取网页内容验证可访问，确保在 .docx 文件中可直接点击打开。
Step 3：获取官方名录
基于 Step 2 找到的名录 URL，使用获取网页内容获取完整候选清单。
输出完整候选池清单（表格形式，不可省略）：
| 序号 | 候选方名称 | 资质类型 | 认证机构 | 官网 URL | |------|---------|---------|---------|----------| | 1 | [公司全称] | [SP/AP/T-VAN/...] | [MDEC/IMDA/GDT/...] | [完整 URL] | | 2 | ... | ... | ... | ... |
汇总：候选池共 [N] 家 [资质类型] 认证机构
不允许只输出汇总而省略清单表格。候选池是后续所有过滤的起点，必须完整列出。
Step 4：玩家分类图
前置判断
在执行通用分类前，先检查 REF-A 中目标国家是否已有指定接入路径和合作方：
通用分类矩阵
目标：在进入逐家分析之前，先建立分类认知，识别哪些流派从结构上就不适合。
> 以下分类基于东南亚市场总结，适用于市场中有较多本地竞争者的场景。进入欧洲、中东等市场时，流派定义和淘汰结论须根据该市场的实际竞争格局调整。特别是"国际合规巨头"流派，在欧洲市场可能是唯一的白标通道选择（如 Seeburger），不应机械淘汰。
按以下二维矩阵对候选方分类（先分类型，不需要逐家）：
| 流派 | 典型画像 | 冲突风险 | 白标意愿 | 结论 | |-----|---------|---------|---------|------| | 国际合规巨头 | Avalara、Pagero、SAP | 低 | 低（价高、不做 BPO）| 淘汰 | | 本地 ERP/财务 SaaS | [当地代表企业] | 高（直接抢客户）| 无 | 淘汰 | | 带 UI 的自动化工具 | [当地代表企业] | 高（功能重叠）| 无 | 淘汰 | | 金融级数据交换/EDI 商 | [当地代表企业] | 无 | 高（白标 DNA）| 目标流派 | | 纯 API 通道商（APaaS）| [当地代表企业] | 无 | 高 | 备选（需确认 BPO 能力）|
结论：目标流派是 [X]，原因：[一句话]
Step 5：多轮过滤漏斗
核心要求：每一轮都必须输出 → 本轮过滤条件 → 淘汰了谁（列名）→ 留下了谁 → 为什么。不允许跳步或合并轮次。
讨论深度分层规则：
第 1 轮：资质过滤（硬性门槛）
过滤条件：只保留持有 [Step 2 结论中的目标资质] 的候选方
第 2 轮：业务冲突过滤
过滤条件：排除拥有前端财务/ERP/发票管理 SaaS 产品的候选方
对每家候选方，搜索其官网，重点查看：
第 3 轮：白标意愿过滤
过滤条件：排除主业以终端客户直销为核心的候选方
评判依据：
第 4 轮：BPO 能力过滤
过滤条件：必须有本地运营团队，能提供本地合规兜底服务
搜索：[公司名] operations team service [国家] managed service
注意：纯研发公司（研发在境外、本地无实体团队）在此轮淘汰。
Step 6：反向证伪
目标：对"看起来能用但实际有问题"的候选方，用三宗罪框架专项击穿。
实名制要求：所有候选方必须使用完整公司名称，禁止使用匿名化表述（如"某本地 SaaS 平台""某大型 ERP 厂商"）。反向证伪的目的是让内部团队明确知道"这家不用再讨论了"，匿名化将使证伪失去意义。
适用对象：
三宗罪框架（每家一套）
[候选方名称]
| 宗罪 | 类型 | 具体说明（须可追溯）| |-----|-----|-----------------| | 第 1 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] | | 第 2 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] | | 第 3 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] |
结论：因 [核心原因] 淘汰，不建议内部再讨论
Step 7：正向推荐
> 📄 查阅 REF-B（候选方评分权重矩阵）：当第一梯队有 2 家以上候选方时，使用查看文件内容加载 REF-B，对各候选方逐项打分（6 个维度，加权 100 分制），得分高者优先。60 分以上推荐，80 分以上定性为"强烈推荐"。评分结果在推荐说明中附加"加权总分"字段，确保排序可复现。
第一梯队：首选战略合作方
[候选方名称]
| 维度 | 评估内容 | |-----|---------| | 企业底牌 | [成立年份、主营业务、代表客户] | | 资质认证 | [持有的官方认证] | | 零业务冲突 | [为什么不会抢客户] | | BPO 能力 | [本地团队和服务能力的具体描述] | | 白标 DNA | [有无大型机构白标合作先例] | | 技术并发 | [支持量级/SLA/代表性客户] | | 已知风险 | [需 POC 验证的不确定点] |
第二梯队：备选/补充方案
[同上格式，重点说明适用场景和与第一梯队的区别]
排除清单（汇总）
| 候选方 | 淘汰轮次 | 核心原因（一句话）| |-------|---------|----------------| | [名称] | 第 [N] 轮 | [原因] |
Step 8：落地行动建议
8.1 BPO 内涵的本地化定义
这是各国差异最大的部分，必须基于市场成熟度重新定义，不允许跨国直接复制。
| 市场成熟度 | BPO 的实际含义 | 典型国家 | |---------|-------------|---------| | 低成熟度（税局半数字化）| 线下跑税局、关系疏通、代办证件 | 马来西亚 | | 中成熟度（数字化但异常处理复杂）| 数据映射异常处理、后台人工介入修正错误报文 | 新加坡 | | 高成熟度（全自动化）| SLA 保障、API 健康监控、批量异常预警 | 欧洲成熟市场 |
[目标国家] 的 BPO 应定义为：[具体描述，3-5 句话，说清楚"异常"发生时合作伙伴要做什么]
谈判时向候选方提出的 BPO SLA 要求：
8.2 商业谈判框架
不要用传统"渠道分销（Reseller）"框架，用以下结构：
合作框架 = IaaS 通道费（按调用量阶梯）
+ Managed Service BPO 包年费（按 SLA 定义的兜底服务）
| 费用项 | 计费方式 | 谈判要点 | |-------|---------|---------| | API 调用量 | 阶梯报价，X 万单/月内固定，超出按条计费 | 强调我方中资 KA 客户体量 | | BPO 包年费 | 固定年费，覆盖约定次数的人工干预 | 必须写入合同 SLA，不接受口头承诺 | | 法规更新通知 | 包含在 BPO 费中 | 法规变更 5 个工作日内书面通知，否则扣款 |
8.3 POC 验证设计（三段式）
> 📄 查阅 REF-C（POC 验收脚本模板）：REF-C 已包含越南、马来西亚、新加坡三个市场的完整 POC 验收题目（含测试编号、具体场景、验收标准和结果记录模板）。目标国家在脚本库中有记录的，使用查看文件内容加载 REF-C 并直接引用对应国家的脚本，不另起草；目标国家不在脚本库中的，按以下三段式框架补充。
技术测试
能力测试
兜底演习（BPO 验证）（Pass/Fail，不合格直接淘汰）
8.4 关键行动项
| 行动项 | 负责方 | 节点 | |-------|-------|------| | 向第一梯队候选方发送合作意向 | 我方商务 | [建议时间] | | 安排第一梯队 POC 技术联调 | 我方工程 | [建议时间] | | 律师书面确认代理提交合法性（multiTenantProxyLegal）| 法务 | 上线前 P0，不可跳过 | | [该国特有行动项] | ... | ... |
不变量 vs 可变量速查
| 维度 | 不变 | 可变 | |-----|------|------| | 白标要求 | 固定 | — | | 无前端冲突要求 | 固定 | — | | BPO 要求（概念）| 固定 | BPO 具体内涵随成熟度变化 | | 不找国际巨头 | 固定 | — | | 不找本地 ERP | 固定 | — | | 不找带 UI 工具 | 固定 | — | | 三宗罪证伪框架 | 固定 | 证伪对象随国变化 | | IaaS + BPO 谈判结构 | 固定 | 费率和 SLA 数值随国调整 | | POC 三段式 | 固定 | 测试场景随国填写 | | 监管机构名称 | — | 可变 | | 资质分类体系 | — | 可变（SP/PRSP/AP/ASP/T-VAN…）| | 官方名录来源 | — | 可变 | | BPO 具体内涵 | — | 可变 | | 黑名单处理方式 | — | 可变（逐家点名 vs 类型化）| | 推荐候选方数量 | — | 可变（市场深度决定）|
已知市场参考结论
| 国家 | 目标资质 | 官方名录 | 首选合作方 | BPO 内涵 | |-----|---------|---------|---------|---------| | 马来西亚 | MDEC SP（Access Point）| OpenPeppol + MDEC 官网 | Finexus Group | 线下跑 LHDN、关系疏通 | | 新加坡 | IMDA InvoiceNow AP | IMDA 官方名录（35家）| DataPost / SESAMi | 数据映射异常处理、错误报文人工修正 |
注意事项
multiTenantProxyLegal = CONFIRMED 是上生产的硬性前置条件