BENJI机构存入仍是PENDING：核订单ID、审批门槛与最终状态
链小知 · 进阶 · 核验 · 依官方文档整理
从本人已有机构存入日志找同一depositId，区分创建、审批、提交与处理结果，并定位鉴权错误和错误订单。
开始前准备
- 准备本人已有机构订单的环境、depositCreate/submit结果、钱包与productId、资金方式、金额和读数时间；分享排错材料时遮去凭据及个人资料。
- 适用官方机构API文档，不是零售App菜单教程。公开示例使用UAT；本教程为documentation，不生成OAuth凭据、不发查询或重新提交订单。
1. 先确认环境、产品与入金钱包
打开官方Status Check及GraphQL Schema文档，对照原日志端点和生成版本。当前公开schema页写api-uat及2026-10-07生成时间；UAT订单不能拿生产记录查询结果替代，也不能拿测试成功证明真钱基金份额。
对原walletId对应的productId、networkId与institutionEntityId一起核对。PRODUCT_NOT_ON_NETWORK指该产品在所选网络不运行；PRODUCT_NOT_ONBOARDED指该实体未开通产品，两个问题与链拥堵不同。
检查结果：订单环境、钱包、产品、网络及实体对应，未用全平台网络表代替逐产品配置。
2. 从创建结果取正确depositId和金额口径
在原depositCreate结果取depositId，连同原value、支付方式及wire/SWIFT reference建立一条订单记录。depositCreate生成的ID才是后续deposit状态读数的关联键；不要用walletId、链上哈希或另一次存入ID代替。
schema的value是货币金额，精度按产品Currency.decimalPrecision，USD/EUR为两位；quantity是份额数量，支持更高精度且与value互斥。它们不是统一18位的链上整数。实际币种与产品不同，不能把样例12345.12当固定入金要求。
检查结果：同一depositId可关联原支付方式及正确金额/份额单位，没有混用value和quantity。
3. 先排除查询失败和缺失数据
按Status Check文档的返回结构，在本人已有有效deposit结果中核data.deposit及depositId；官方查询样例字段为blockchainStatus、approvalsRequired、approvalsCollected、value。记录这些字段时同时记环境及结果时间。缺字段或GraphQL errors不能自行补成PENDING或零审批。
若日志末尾是Cannot Read Properties Of Undefined，先向上找较早的GraphQL error；官方说明样例记录错误后继续走，undefined常是后续症状。鉴权/权限错误可能来自无效Bearer、token交换或客户尚未完成配置；由获授权的账户管理员按官方文档处理，不在排错记录中贴密钥。
检查结果：使用的是有效同订单结果，鉴权失败、缺失字段和真实业务状态分开。
4. 核审批数量和可提交阶段
比较同一记录的approvalsCollected与approvalsRequired。APPROVAL_NEEDED表示还需审批，READY_TO_SUBMIT表示已满足审批并准备提交；两者都不是完成。APPROVAL_THRESHOLD_NOT_MET说明曾在审批不足时尝试提交，先定位该时点数量。
INVALID_TRANSACTION_STATE可能是重复审批已提交订单、提交未准备好的订单或重放已推进的mutation。原日志已进入后续阶段时，不为刷新状态重放创建/approve/submit；后续状态依据同一deposit查询记录核。
检查结果：审批门槛与交易阶段有对应证据，未将ready或审批成功当份额交付。
5. 区分submit返回和最终状态
Status Check明确depositSubmit可能返回PENDING，这说明已提交且仍在处理，不自动说明失败。使用同一depositId的后续状态材料，而不是创建时的blockchainStatus或另一笔订单的成功结果。
按该存入状态页：COMPLETE为成功终态，FAILED为失败终态，TIMED_OUT需后续处理；PENDING不是终态。生命周期页笼统写submit完成流程，不能覆盖具体状态页。文档只写短延迟后再查，没有给固定超时分钟数；未知状态保留原文并找官方说明。
检查结果：已识别同一存入的当前阶段与终态，未给未证等待时长或自动成功结论。
6. 把链上处理与资金、份额结果分别归档
在已有材料中将最终blockchainStatus与实际产品份额接收对应，再保留资金原reference及已提供的cashStatus。静态schema把cashStatus定义为资金匹配状态，与blockchainStatus分开；该页没有展示完整cashStatus枚举，不从文字推某个现金状态键。
完成排错时给出同订单终态、正确份额记录与剩余缺口。COMPLETE支持存入链上操作完成；若没有资金匹配或本人份额结果材料，就明确该项仍待核，不将一张submit回执写成银行收款、基金份额或任意跨链转入全部完成。
检查结果：结论绑定同订单、时间和已证结果；现金匹配、链上操作及份额接收没有合并。
怎样确认完成
- 同一depositId的环境、产品、支付方式、金额、审批与最后有效状态可追溯。
- 能判定未审批、待提交、仍处理或终态；没有结果材料的现金/份额阶段明确待核。
常见错误与边界
- Bearer存在不等于权限正确；不能把401/GraphQL errors解析成零余额。
- 存入状态页的终态列表限定deposit，不能无来源套给提现、转让或银行状态。
- 修改ID、重发创建或重复提交可能生成另一条流程，不是只读刷新。