Skill: tangxf0927/e-invoice-partner-selection (version 1.1.1)

--- 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 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 中目标国家是否已有**指定接入路径和合作方**： - **REF-A 中已指定合作方路径**：跳过通用分类，直接进入 Step 5，将 REF-A 指定的合作方作为已锁定的第一梯队，仅补充验证（是否仍满足两条底线 + 有无新增替代方案） - **REF-A 中无指定路径，或标注为"评估中"**：执行以下通用分类矩阵 ### 通用分类矩阵 目标：在进入逐家分析之前，先建立分类认知，识别哪些流派从结构上就不适合。 > 以下分类基于东南亚市场总结，适用于市场中有较多本地竞争者的场景。进入欧洲、中东等市场时，流派定义和淘汰结论须根据该市场的实际竞争格局调整。特别是"国际合规巨头"流派，在欧洲市场可能是唯一的白标通道选择（如 Seeburger），不应机械淘汰。 按以下二维矩阵对候选方分类（先分类型，不需要逐家）： | 流派 | 典型画像 | 冲突风险 | 白标意愿 | 结论 | |-----|---------|---------|---------|------| | 国际合规巨头 | Avalara、Pagero、SAP | 低 | 低（价高、不做 BPO）| 淘汰 | | 本地 ERP/财务 SaaS | [当地代表企业] | 高（直接抢客户）| 无 | 淘汰 | | 带 UI 的自动化工具 | [当地代表企业] | 高（功能重叠）| 无 | 淘汰 | | 金融级数据交换/EDI 商 | [当地代表企业] | 无 | 高（白标 DNA）| 目标流派 | | 纯 API 通道商（APaaS）| [当地代表企业] | 无 | 高 | 备选（需确认 BPO 能力）| **结论**：`目标流派是 [X]，原因：[一句话]` --- ## Step 5：多轮过滤漏斗 **核心要求：每一轮都必须输出 → 本轮过滤条件 → 淘汰了谁（列名）→ 留下了谁 → 为什么。不允许跳步或合并轮次。** **讨论深度分层规则**： - **第 1 轮**（资质过滤）：候选池最大，允许按类型批量淘汰（如“以下 N 家仅持 PRSP 资质，批量淘汰”），但必须**逐一列出每家公司名称** - **第 2-4 轮**：候选池已缩小，必须**逐家分析**，每家给出具体判断依据（官网产品页信息、白标案例、新闻来源等），不允许使用“经分析不符合”等笼统表述 ### 第 1 轮：资质过滤（硬性门槛） 过滤条件：只保留持有 [Step 2 结论中的目标资质] 的候选方 - 淘汰：[列出被淘汰的公司名] — 原因：仅持有应用层资质，无自有传输通道 - 留下：[N] 家，名单：[...] ### 第 2 轮：业务冲突过滤 过滤条件：排除拥有前端财务/ERP/发票管理 SaaS 产品的候选方 对每家候选方，搜索其官网，重点查看： - 产品页是否有发票仪表盘、三单匹配、供应商门户等前端功能 - 是否直接面向企业终端用户销售 - 淘汰：[列出名称 + 一句话冲突说明] - 留下：[N] 家 ### 第 3 轮：白标意愿过滤 过滤条件：排除主业以终端客户直销为核心的候选方 评判依据： - 官网是否强调"白标（White-label）"、"API-first"、"B2B2B" - 是否有银行、政府机构、大型平台作为 B 端客户的背书 - 是否有明显的品牌占有欲 - 淘汰：[列出名称 + 理由] - 留下：[N] 家 ### 第 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 要求： - [具体要求 1] - [具体要求 2] - [具体要求 3] ### 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 并直接引用对应国家的脚本，不另起草；目标国家不在脚本库中的，按以下三段式框架补充。 **技术测试** - 模拟单日 [N] 万单并发，验证税局接口限流时的队列缓冲能力 - 验证 Token Pool / 认证刷新在多租户高并发场景下的稳定性（如适用） **能力测试** - 提交含错误 [该国特有字段] 的报文，验证前置校验拦截准确率 - 模拟 [该国特有异常场景]，验证降级路径 **兜底演习（BPO 验证）**（Pass/Fail，不合格直接淘汰） - 问：「如果客户被税局锁死账号，贵司能承诺几小时内通过 [具体路径] 解决？」 - 要求书面 SLA，不接受口头回答 - 验证本地团队在该国是否有真实运营实体，不接受境外远程支持作为 BPO 承诺 ### 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 | 数据映射异常处理、错误报文人工修正 | --- ## 注意事项 - **联网搜索不可省略**：官方名录实时更新，训练数据不可靠，必须使用**获取网页内容**访问实际名录页面 - **每轮过滤必须输出被淘汰名单**：不允许只说"留下 N 家"而不说淘汰了谁 - **反向证伪必须有事实依据**：每条"宗罪"需可追溯来源（官网信息 / 官方数据库查询结果） - **BPO 内涵必须本地化**：直接复用马来西亚的 BPO 定义到新加坡是错误的 - **代理提交合法性是 P0 阻断项**：`multiTenantProxyLegal = CONFIRMED` 是上生产的硬性前置条件 - **谈判框架坚守 IaaS + BPO 结构**：不用 Reseller 模式，保住定价主动权 - **POC 兜底演习必须书面化**：口头 SLA 承诺无效，必须进合同


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)