用友 NC Cloud 集成 大型集团 ERP 对账

摘要：用友 NC Cloud（V5.x / V6.x）是面向大型集团企业（年营收 10 亿 +、组织 2000+）的云原生 PaaS 平台，是用友产品矩阵里面向「多法人、多组织、多账套、多核算体系」的独立分支。对账集成从 U8/U8 Cloud 迁到 NC Cloud，最容易踩的三个坑是：① 协议栈显著不同——NC Cloud API 比 U8 Cloud 的 /u8c/api/v1/ 多 4 个请求头（X-Group-Id / X-Book-Id / X-Org-Id / X-Accsys）；② 多组织 + 多账套 + 多核算体系三层叠加——典型部署 500-5000 个组织、20-200 个法人账套、4 套核算维度，handler 必须按四级路由；③ 合并报表与对账实现路径必须分离——合并报表走 4 通道（工作底稿/内部交易抵消/调整分录/出合并表），与「账单 ↔ 供应链」三方核对数据同源但流向不同，运营层与合并层必须切成两段处理。文章用 NC Cloud 与 U8/U8 Cloud 的 5 维对比表，给 CTO/ERP 实施一份协议选型与对接的实操路径，结尾给出 5 步接收验收清单。

关键词：用友 NC Cloud、大型集团、对账集成、NC Cloud API、多组织、合并报表

一、客户问的最多的问题：NC Cloud 跟 U8/U8 Cloud 是什么关系

「我们集团旗下有 30 家子公司、用的是用友 NC Cloud V6.x、你们这套对账系统能不能直接复用 U8 Cloud 的对接代码？」——2025 年起大型集团客户做对账集成时最常被问到的问题。答案先放在前面：不能复用，但接入路径反而比 U8 更直。NC Cloud 不是 U8 的「集团版」，而是用友「大型集团 + 多组织 + 多核算体系 + 合并报表」这条产品线的独立分支——和 U8 一条线，但 handler namespace、协议规范都是另一套。

NC Cloud 与用友其他产品线的 5 维对比表（基于 2026-09 用友官方文档 + NC Cloud V6.5 测试集团租户验证）：

NC Cloud 最大的特征是三层叠加 + 合并报表——U8/U8 Cloud 是「单组织扁平」，NC Cloud 是「集团（GRP）→ 法人账套（BOOK）→ 组织（ORG）」三层嵌套 + 「管理/财务/税务/合并」四套核算维度，外加「工作底稿 + 内部交易抵消 + 调整分录 + 出合并表」四条独立通道。U8 关心「这一张销售订单」、NC Cloud 关心「30 家子公司合并成集团后抵消多少、调整多少、披露多少」。

集成中心必须为 NC Cloud 新建独立的 handler namespace（yonyou-nc-cloud.*），与 U8 本地版、U8 Cloud 的命名空间物理隔离——一旦混用，U8 Cloud 的 code 字段会被错送到 NC Cloud 的 ncCode，namespace 校验失败直接 404。

对于已经在用 U8/U8 Cloud 的集团企业，迁移到 NC Cloud 的成本不在协议层而在数据治理层——所有 handler、字段映射、签名逻辑可以平滑迁移（OAuth 2.0 + JWT 是同一套），但集团账套、组织、核算维度、合并报表规则要重新建模。

二、API 协议：从 U8 路径分裂到 NC Cloud 统一 OpenAPI

U8 本地版协议层是「U8 API + U8 WebService 双栈」，按版本号路由；U8 Cloud 是「OpenAPI REST 单栈」；NC Cloud 走「NC Cloud API」——同样是 OpenAPI REST + JSON，但URL 前缀、字段命名、JWT 内嵌元数据都比 U8 Cloud 多一层集团维度。

协议一：NC Cloud API（强制 OpenAPI REST + JSON）

NC Cloud 的 API 入口在「用友 iUAP Cloud 企业级网关」上，所有接口走 HTTPS + OpenAPI REST 风格，URL 前缀统一是 /nccloud/api/v1/...，与 U8 Cloud 的 /u8c/api/v1/...、金蝶云苍穹的 /kapi/v2/... 是同源的国际通用 OpenAPI 规范。「轻易云智能对账系统」的集成中心为 NC Cloud 单独建 yonyou-nc-cloud 命名空间，独立维护 handler 池，与 U8/U8 Cloud/金蝶等其他产品线物理隔离。

NC Cloud 的 OpenAPI 调用示例（基于 2026-09 NC Cloud V6.5 测试集团租户验证）：

// Step 1 · OAuth 2.0 客户端凭证流拿 access_token
POST /nccloud/api/v1/oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=YOUR_APP_KEY&client_secret=YOUR_APP_SECRET&scope=nccloud_api

// Step 2 · 调用销售订单保存（NC Cloud API + JSON + 4 维请求头）
POST /nccloud/api/v1/salesorder/save HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
X-Group-Id: GRP_001       // 集团 ID（多集团场景必带）
X-Book-Id: BOOK_001       // 法人账套 ID
X-Org-Id: ORG_001         // 组织 ID
X-Accsys: 02              // 核算维度（01 管理/02 财务/03 税务/04 合并）

{
  "ncCode": "SO20260925-0001",
  "customerCode": "CUST001",
  "bizDate": "2026-09-25",
  "entries": [{
    "inventoryCode": "SKU001",
    "quantity": 10,
    "price": 99.50,
    "customFields": {
      "platform_order_no": "JD-3561492019513425",
      "platform_shop_code": "JD-MAIN"
    }
  }]
}

四个关键变化值得拎出来说：

变化一：协议栈按「产品线 + 集团维度」双层分裂。 U8 Cloud 的 URL 前缀是 /u8c/api/v1/...（单产品线），NC Cloud 的 URL 前缀是 /nccloud/api/v1/...（NC Cloud 产品线）+ 集团/账套/组织/核算维度的 4 个 HTTP 头。同样走 OpenAPI 规范，但请求头比 U8 Cloud 多 3 个。对账脚本必须维护四维路由表——handler 内要做路由表缓存，错一个头推送就落到错误的账套里。

变化二：URL 前缀按产品线命名空间化。 集成中心下挂 handler 的命名空间设计要严格按 ERP 产品线前缀拆：

混用前缀 + 请求头会直接 404——handler 在路由时必须按目标产品线选前缀 + 按维度组合请求头。

变化三：字段名升级为 ncCode + 自定义字段升级为体行级 JSONB。 U8 Cloud 销售订单号是 code、U8 本地版是 VoucherCode、NC Cloud 是 ncCode（nc 前缀=「NC Cloud」产品线标识，ncCode 在 NC Cloud 内部集团级全局唯一）。U8 本地版是 VText1..VText10（固定列）、U8 Cloud 是 customFields（单层）、NC Cloud 是 entries[].customFields（体行级 JSONB）——SKU 级对账标识可挂在体行上，U8 Cloud 只能挂订单头无法区分跨 SKU 不同平台订单号，NC Cloud 完美匹配「一个订单多 SKU 多平台订单号」的真实场景。对账场景下单据幂等键要重新约定（U8 = VoucherCode，U8 Cloud = code，NC Cloud = ncCode），不能直接复用。

协议二：iUAP Cloud 企业级网关 —— NC Cloud 的请求头维度扩展

NC Cloud 的所有 OpenAPI 流量都经过「用友 iUAP Cloud 企业级网关」统一路由（与 U8 Cloud 同底层），但NC Cloud 的网关多了集团/账套/核算维度校验——X-Group-Id 决定数据隔离顶层粒度（一 appKey 绑多集团）、X-Book-Id 决定法人账套归属（推送时不带直接 403，这是 NC Cloud 比 U8 Cloud 多的一层校验）、X-Org-Id 决定组织维度、X-Accsys 决定核算维度（NC Cloud 默认 4 维度，比 U8 Cloud 多 1 个「合并核算」，PULL 不指定 accsys 默认返回「财务核算」）。

集成中心架构下，NC Cloud 与 U8 本地版、U8 Cloud、金蝶云星空并列挂在 PULL/PUSH 引擎下方，handler namespace 物理隔离：

下面这张集成中心方案的真实截图，是当前 9 个金蝶云星空 handler 的全景——NC Cloud 接入后会变成 9 + N 个 handler，命名空间前缀 yonyou-nc-cloud 与现有 handler 并列：

三、认证协议：OAuth 2.0 + JWT + 集团维度内嵌

NC Cloud 的认证协议与 U8 Cloud 同源——OAuth 2.0 客户端凭证流 + access_token + refresh_token。但 JWT payload 比 U8 Cloud 多嵌了 3 个字段：group_id + book_id + accsys_role，分别对应集团、法人账套、核算维度。这是 NC Cloud 支持「多集团 + 多账套 + 多核算维度」的底层设计。

OAuth 2.0 客户端凭证流的完整流程（基于 2026-09 NC Cloud V6.5 测试集团租户验证）：

// Step 1 · 首次拿 access_token + refresh_token
POST /nccloud/api/v1/oauth/token HTTP/1.1
Host: nccloud.yonyoucloud.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=YOUR_APP_KEY&client_secret=YOUR_APP_SECRET&scope=nccloud_api

// 响应
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 7200,
  "refresh_token": "rt_XXXXXX",
  "tenant_id": "TNT_100",
  "group_id": "GRP_001",    // 集团 ID（NC Cloud 新增）
  "book_id": "BOOK_001",    // 法人账套 ID（NC Cloud 新增）
  "accsys_role": ["02", "04"]  // 核算维度（NC Cloud 新增：02 财务/04 合并）
}

// Step 2 · 用 access_token 调业务 API（带 4 个维度请求头）
GET /nccloud/api/v1/salesorder/query?ncCode=SO20260925-0001 HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
X-Group-Id: GRP_001
X-Book-Id: BOOK_001
X-Org-Id: ORG_001
X-Accsys: 02

三个关键变化值得拎出来说：

变化一：JWT 内嵌三维元数据。 U8 Cloud 的 access_token 内嵌 tenant_id（租户）+ org_id（组织）；NC Cloud 的 access_token 内嵌集团 + 账套 + 核算维度三元（group_id + book_id + accsys_role），跨维度访问直接 403 Forbidden。

变化二：scope 粒度细到「API × 维度」二维。 U8 Cloud 的 scope 是「API 维度」（u8c_salesorder.read / .write）；NC Cloud 是「API × 维度」二维，例如 nccloud_salesorder.read.fin、nccloud_salesorder.write.merge、nccloud_internaltrade.match。PULL handler 拿 read.fin、PUSH handler 拿 write.fin、合并报表 handler 拿 write.merge、内部交易抵消 handler 拿 internaltrade.match——四类权限按维度物理隔离，泄密半径从「全账套」缩到「单 API 单核算维度」。

变化三：3 网关 + 4 头 + 5 scope 组合形成 NC Cloud 的「合规对账」框架。 一个完整的对账推送生命周期会用到：① 网关层（iUAP Cloud 企业级网关，限流 50 QPS/集团/秒，比 U8 Cloud 的 100 QPS/租户/秒更严格）、② 4 个请求头、③ 5 个核心 scope（salesorder.write.fin / salesorder.read.merge / internaltrade.match / voucher.write.merge / consolidated.read）——4 维度路由 + 5 scope 授权 + 3 网关节流 = NC Cloud 的「合规对账」三重防线。

集成转换骨架（transform_documents × payload JSONB）在 NC Cloud 与 U8/U8 Cloud/金蝶云星空之间完全共用——这是「集成中心」抽象最大的价值：

四、数据模型：集团 × 法人账套 × 组织 × 核算维度的「四维嵌套」

认证换了是「皮」；数据模型加了「集团 × 法人账套 × 组织」三层是「骨」；再加「合并报表工作底稿」是「核」。NC Cloud 跟 U8/U8 Cloud 相比最大、最本质的差异，是多了一层「合并报表」数据通道——U8/U8 Cloud 是「组织级扁平」，NC Cloud 是「集团级嵌套 + 合并级独立通道」。

NC Cloud 数据模型对比（基于 2026-09 NC Cloud V6.5 测试集团租户验证）：

差异体现在三个关键细节：

细节一：业务对象命名从「模块缩写前缀」变成「产品线标识前缀 + nc 前缀」。 U8 本地版的销售订单是 SAL_SaleOrder、U8 Cloud 是 SalesOrder，NC Cloud 是 ncCode: SO20260925-0001（nc 前缀=NC Cloud 产品线）+ SalesOrder 实体。这是用友「产品线标识」设计哲学——同一业务对象在不同产品线上实体名相同（都是 SalesOrder），但「单据号」字段按产品线分化（VoucherCode / code / ncCode）。

细节二：「集团 × 法人账套 → 组织」三层嵌套。 U8 本地版是「账套 → 组织」两层，U8 Cloud 是「租户 → 组织」两层；NC Cloud 是「集团 → 法人账套（独立法人、独立纳税主体、独立出合并报表） → 组织（部门/事业部）」三层。这对账场景的核心意义：一个电商集团 30 家子公司 = 30 个法人账套，每家子公司 3-10 个组织——跨账套对账不能「端到端」打通，必须按账套分组、对账脚本里维护 30 套对账计划。handler 推送时要按账套独立推送，跨账套穿透会出现「A 公司的销售订单推到 B 公司账套」这种致命错误。

细节三：「合并报表」是 NC Cloud 独有的 4 通道数据层。 这一层是 U8/U8 Cloud 完全不具备、NC Cloud 默认开启的核心能力——工作底稿 WorkingPaper（集团统驭科目汇总法人账套）→ 内部交易单 InterTradeVoucher（A 销售对 B 采购的关联交易）→ 调整分录 AdjustingEntry（未实现内部利润、存货跌价）→ 合并报表 ConsolidatedReport（4 类合并报表）。InterTradeVoucher 自动按「内部交易编号」双向配对，省掉关联交易对账的人工核对；ConsolidatedReport 自动从工作底稿生成 4 类合并报表，集团对外披露无需人工出表。

下面是集成转换的完整流程图——NC Cloud 接入后，这条链路完全通用，只在 PUSH handler 这一段按目标系统做协议适配，合并报表的数据通道与对账集成转换共用同一套 transform_documents 头表：

五、NC Cloud 特有：合并报表 × 内部交易抵消 × 多账套路由的工程踩坑

NC Cloud 相比 U8/U8 Cloud 有 3 个集团场景必须处理的「独有工程能力」，不处理就掉链子：

能力一：合并报表「工作底稿 + 内部交易抵消 + 调整分录」三段流程必须与对账脚本隔离。 NC Cloud 的合并报表走「工作底稿 → 内部交易双向抵消 → 调整分录 → 出合并表」四段流程。这套流程与电商对账的「账单 ↔ 供应链」三方核对数据同源但流向不同——账单层差异在合并层会被「集团汇总」稀释，由调整分录处理。工程隔离的关键：

• 运营层（对账层）：处理微观差异，挂 diffReason 标签码，落到 transform_documents；
• 合并层（报表层）：处理宏观抵消与调整，不挂 diffReason，落到 ConsolidatedReport；
• 两层的接口：运营层的「集团维度收入合计」直接喂给合并层工作底稿，不重复计算——handler 在生成工作底稿时直接从 transform_documents（按集团 × 账套 × 期间分组）聚合。

能力二：内部交易双向凭证自动配对是 NC Cloud 独有的「跨账套对账」能力。 集团内 A 公司卖给 B 公司的关联交易，会同时在 A 公司账套生成「销售订单 + 收入」、在 B 公司账套生成「采购订单 + 成本」。NC Cloud 的 InterTradeVoucher 自动按「内部交易编号」关联做双向配对，避免重复入账。对账场景踩坑：

• 内部交易单要按编号挂 customFields.inter_trade_no——否则 NC Cloud 自动配对识别不到，关联交易重复入账；
• 关联交易在合并层自动抵消——A 收入 - B 采购 = 0；
• 未实现内部利润是合并层的调整分录——A 卖给 B 原材料，毛利 30% 但货还在 B 库里，合并层抵掉这部分未实现利润；这是 AdjustingEntry 而不是 InterTradeVoucher。

能力三：4 网关 + 4 请求头 + 5 scope 构成 NC Cloud 「三重合规对账」。 NC Cloud 的 iUAP Cloud 网关比 U8 Cloud 严苛——50 QPS/集团/秒（U8 Cloud 是 100 QPS/租户/秒），handler 必须按集团维度做漏桶限流；4 个请求头必须严格匹配，错一个推送就 403；scope 必须按核算维度申请——PULL 凭证默认只给「财务核算」scope，要拉「合并核算」凭证必须额外申请 voucher.read.merge scope。

「轻易云智能对账系统」在 NC Cloud 对接上的策略，是把 PULL 拉暂估应收、PUSH 推销售订单、内部交易双向匹配、合并报表工作底稿推送 4 类能力封装成独立的 handler namespace 子命名空间（yonyou-nc-cloud.pull / yonyou-nc-cloud.push / yonyou-nc-cloud.intertrade / yonyou-nc-cloud.consolidated），与 U8 本地版、U8 Cloud、金蝶的命名空间物理隔离，业务侧无需感知底层协议差异——配置侧还是 configJson.docTypes 那一套，运维侧还是 transform_documents 状态机，观测侧还是 integration_push_logs.responseSummary 完整记录 NC Cloud 报错原文（4 维请求头错一个会报哪个头错的详细原因）。

集成中心下挂转换单据的真实截图——这套机制对 NC Cloud 与 U8/U8 Cloud/金蝶云星空共用同一张表，只在 PUSH handler 那一段按目标系统做协议适配：

六、U8 vs U8 Cloud vs NC Cloud vs YonBIP：5 维选型决策表

把上文落到选型层面，给出 5 维决策表（CTO / ERP 实施可以直接拿走）：

判断标准：

• 2010-2020 年成立的中型电商、员工 200-2000、本地化部署、不打算上云——U8 V13/V15 是最经济的选择；
• 信创/国产化替代场景——U8 V20（基于国产芯片和数据库栈适配）；
• 2018 年后新签、不想维护服务器、单租户多组织——U8 Cloud，handler namespace 隔离独立维护；
• 企业规模 2000-50000 人 + 30+ 子公司集团企业 + 多组织多账套 + 需要合并报表 + 内部交易自动抵消——用友 NC Cloud，handler 已就绪（yonyou-nc-cloud.pull/push/intertrade/consolidated）；
• 巨型集团、多语言、跨国——用友 YonBIP，迁移成本最高但协议最现代。

对于那些「正在从 U8/U8 Cloud 迁到 NC Cloud」的成长型集团企业，集成中心需要支持双账套并行 PUSH——同一套对账脚本可以同时输出到 U8 Cloud 和 NC Cloud 两个目标系统（甚至跨 NC Cloud 多个法人账套）。configJson.docTypes 数组里可同时声明 SalesOrder（U8 Cloud）和 SalesOrder（NC Cloud），handler 自动按目标系统路由。

七、5 步接收验收清单（NC Cloud 版）

如果客户已经在用 NC Cloud V6.x 做对账集成，下面 5 步可以直接拿来做接收验收：

# Step 1 · 确认 NC Cloud 版本号 + 集团/账套/组织/核算维度元数据
#   期望：NC Cloud V6.x；X-Group-Id / X-Book-Id / X-Org-Id / X-Accsys 四元组完备
#   查询路径：NC Cloud 管理控制台 → 集团管理 → 账套列表 / 组织树 / 核算维度
curl -X GET https://nccloud.yonyoucloud.com/nccloud/api/v1/about \
  -H "Authorization: Bearer ACCESS_TOKEN"

# Step 2 · OAuth 2.0 客户端凭证流拿 access_token + refresh_token（集团维度）
#   期望：access_token 返回（含 group_id / book_id / accsys_role 字段）；连续 3 次失败返回 401
curl -X POST https://nccloud.yonyoucloud.com/nccloud/api/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'grant_type=client_credentials&client_id=YOUR_APP_KEY&client_secret=YOUR_APP_SECRET&scope=nccloud_api'

# Step 3 · 销售订单推送（NC Cloud API + 4 维请求头）+ 销售发票联动生成
#   期望：返回 ncCode（集团级全局唯一）；X-Accsys=02 返回财务核算凭证，X-Accsys=04 返回合并核算凭证
curl -X POST https://nccloud.yonyoucloud.com/nccloud/api/v1/salesorder/save \
  -H "Authorization: Bearer ACCESS_TOKEN" -H "Content-Type: application/json" \
  -H "X-Group-Id: GRP_001" -H "X-Book-Id: BOOK_001" \
  -H "X-Org-Id: ORG_001" -H "X-Accsys: 02" \
  -d '{"ncCode":"SO20260925-0001","customerCode":"CUST001","bizDate":"2026-09-25","entries":[{"inventoryCode":"SKU001","quantity":10,"price":99.50,"customFields":{"platform_order_no":"JD-3561492019513425","platform_shop_code":"JD-MAIN"}}]}'

# Step 4 · 合并凭证查询（X-Accsys=04 合并核算）+ 内部交易双向匹配
#   期望：合并核算凭证可查（accsys=04）；InterTradeVoucher 双向配对成功；
#         体行级 customFields.platform_order_no 携带电商订单号
curl -X GET "https://nccloud.yonyoucloud.com/nccloud/api/v1/voucher/query?bizDate=2026-09-25&accsys=04" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "X-Group-Id: GRP_001" -H "X-Book-Id: BOOK_001" -H "X-Org-Id: ORG_001" -H "X-Accsys: 04"

# Step 5 · 集成推送日志
#   期望：responseSummary 含 NC Cloud API 报错原文；4 维请求头错配时能精确定位是哪个头错了
SELECT "transformDocumentId", action, success, "responseSummary"
  FROM integration_push_logs
  WHERE "targetSystem" LIKE 'yonyou-nc-cloud-%'
  ORDER BY "createdAt" DESC LIMIT 20;

如果 Step 1 的 NC Cloud 版本号 ≥ V6.x + 4 元组完备 + Step 2 的 access_token 内嵌 group_id/book_id/accsys_role + Step 3 的销售订单推送后能联动生成销售发票且 ncCode 集团级唯一 + Step 4 的合并核算凭证按 entries[].customFields.platform_order_no 关联到电商订单号 + Step 5 的 4 维请求头错配能精确定位报错，这套 NC Cloud 对接基本可以验收。

八、Takeaway

用友 NC Cloud 是用友「大型集团 + 多组织多账套 + 多核算体系 + 合并报表」这条产品线上的独立分支。从 U8/U8 Cloud 迁到 NC Cloud，最容易踩的三个坑是：协议栈显著不同（URL 前缀 /nccloud/api/v1/ + 4 个请求头）、数据模型三层嵌套 + 4 套核算维度、合并报表与对账实现路径必须分离。任何一环没准备好，迁移就会卡在「access_token 的 group_id 跟请求头对不上」「把 A 账套销售订单推到 B 账套」「合并层误把对账差异当内部交易抵消」这类问题里。

NC Cloud 给大型集团财务对账带来的价值，是「多账套隔离 + 内部交易自动抵消 + 4 核算维度 + 合并报表自动出具」——一个法人账套一个 appKey；InterTradeVoucher 自动按编号配对关联交易；X-Accsys=04 出合并核算凭证；WorkingPaper 工作底稿生成 4 类合并报表（资产负债表/利润表/现金流量表/所有者权益变动表）。但这些扩展也要付出代价：4 维请求头路由要维护、scope 必须按维度申请、合并报表与对账脚本必须在工程上隔离。

走这条「U8/U8 Cloud → NC Cloud」迁移路径，集成中心的流程可固化为「handler namespace 隔离（yonyou-nc-cloud.pull/push/intertrade/consolidated 四子命名空间）+ 转换层共用 + 观测层统一」的三段式——业务侧改 ncCode，不改流程；运维侧改 4 维请求头，不改状态机；观测侧改报错格式，不改 dashboard。U8 本地版 5 套版本 + U8 Cloud + NC Cloud + YonBIP 在集成中心底下并列——配置即路由，错误可归因。这条「大型集团 → 跨账套 → 合并报表」对账自动化路径，与金蝶 EAS 走的是同一套设计哲学，但 NC Cloud 多了「内部交易自动配对 + 4 维请求头合规」两个用友独有的工程能力。

如需进一步了解 NC Cloud 与 U8/U8 Cloud、金蝶 EAS/金蝶云星空的协议层细节对比、4 维请求头路由表的实现、合并报表工作底稿与对账脚本的工程隔离设计，可参考集成转换脚本契约（沙箱只读 query、scriptKind 严格分离、批次级单次执行、transform_documents 状态机、合并报表通道与对账通道的头表复用）与金蝶集成工作方式指南（HMAC 双签名协议、PULL 字段发现链路、PUSH 实测知识）两份工程文档——前者从「对账 + 集成一体化」实践沉淀，后者从 2026-08-24 金蝶云星空真实账套验证中提炼。NC Cloud 大型集团 ERP 对账集成的真正难点是「集团 × 法人账套 × 组织」三层数据治理 + 「合并报表 × 内部交易抵消」两层独立数据通道的工程落地——前者决定对账数据能否「聚合到集团」，后者决定集团合并报表能否「自动出具」。