tres-cost-basis

TRES Finance — 成本基础管理

端到端技能，涵盖 TRES Finance 中的成本基础计算、策略配置、重新评估、财务问题审查及相关操作。

---

MCP 服务

所有调用均使用 user-tres-finance MCP 服务（TRES Finance MCP 连接器）。

所有变量键和嵌套输入字段都必须使用 camelCase（例如，assetClassId，而非 asset_class_id）。

---

步骤 1 — 验证身份并确认组织

不带参数调用 get_viewer。如果组织名称存在任何歧义，请向用户确认。

---

步骤 2 — 确保已定义成本基础策略（计算前置条件）

运行任何成本基础计算前，组织必须先定义策略。此步骤是前置条件检查——每当用户想要计算成本基础（第 D 节），或首次请求成本基础相关帮助时，都要自动执行。

1. 使用第 B 节中的查询获取当前策略。

2. 如果返回了 defaultStrategy（任何有效值，如 FIFO、LIFO 等），说明策略已设置——跳过后续设置，并告知用户：

   “您的成本基础策略已设为 [STRATEGY]。正在继续。”

3. 如果尚未配置策略（查询返回 null 或错误），请向用户展示所有可用方法并询问其选择：

   “在计算成本基础之前，您需要选择一种成本计算方法。 以下是可用策略：

   1. FIFO — 先进先出。最早获取的批次优先处置。这是最常用的方法。
   2. LIFO — 后进先出。最近获取的批次优先处置。
   3. AVG — 所有批次的加权平均成本。
   4. MAX_GAINS — 优先处置成本最低的批次，以最大化已实现收益。
   5. MAX_LOSSES — 优先处置成本最高的批次，以最大化已实现亏损（适用于税损收割）。
   6. FIFO_IMPAIRMENT — 支持减值会计的 FIFO（适用于采用减值冲销的组织）。

   您想使用哪种方法？”

4. 用户选定策略后，使用第 C 节中的变更操作设置策略（如果用户只想设置单一默认策略，则传入空的 strategyPeriods 数组）。

5. 然后继续执行用户请求的操作（通常是第 D 节——触发计算）。

此检查可确保未经明确选择策略，不会运行任何计算。

---

步骤 3 — 运行成本基础计算

确认策略后，检查当前计算状态（第 A 节），并询问用户是否要运行或重新运行计算：

1. 使用第 A 节中的查询获取状态。
2. 如果 status 为 IN_PROGRESS，告知用户计算正在运行，并询问是否等待：

   “成本基础计算当前正在进行（开始时间为 [time]）。您希望我等待计算完成吗？”

3. 如果 status 为 DONE，说明上次运行时间，并询问：

   “成本基础上次计算于 [lastFinishedAt]。您想现在重新计算，还是查看现有结果？”

4. 如果 status 为 ITEM_NOT_FOUND，说明该组织从未运行过计算——直接触发计算。
5. 用户确认后（或首次运行时），使用第 D 节中的变更操作触发计算。
6. 每隔约 10 秒轮询状态，直到 status = "DONE"。
7. 完成后，自动继续显示各项资产的结果（第 E 节）和财务问题（第 F 节）。

此步骤可确保用户始终获得最新结果，并在查看数据前了解计算状态。

---

可用操作

根据用户的请求，遵循下方相应章节。许多用户会提出“帮我处理成本基础”这类笼统问题——这种情况下，请执行步骤 1–3（验证身份、检查策略、运行计算），然后显示结果。

---

A. 检查成本基础计算状态

当用户询问成本基础是否正在计算、是否已完成，或上次计算时间时，使用此项。

query CostBasisGetStatus {
  costBasisGetStatus {
    status
    firstStartedAt
    lastFinishedAt
    updatedAt
  }
}

status 值：DONE、IN_PROGRESS、ITEM_NOT_FOUND（从未计算）。

清晰地报告状态。如果为 IN_PROGRESS，告知用户计算仍在进行中，需要等待。如果为 DONE，报告上次完成的时间。

---

B. 查看当前成本基础策略

获取默认策略和任何按日期设置的策略覆盖项。

query GetCostBasisStrategyByDate {
  getCostBasisStrategyByDate {
    response {
      strategyPeriods {
        startDate
        endDate
        strategy
      }
      defaultStrategy
    }
  }
}

清晰地列出默认策略和任何期间覆盖项。策略： FIFO、LIFO、AVG、MAX_GAINS、MAX_LOSSES、FIFO_IMPAIRMENT。

如果用户询问，请解释各策略的含义：

• FIFO — 先进先出。最早购入的批次最先卖出。
• LIFO — 后进先出。最近购入的批次最先卖出。
• AVG — 所有批次的加权平均成本。
• MAX_GAINS — 优先卖出成本最低的批次，使已实现收益最大化。
• MAX_LOSSES — 优先卖出成本最高的批次，使已实现损失最大化（税损收割）。
• FIFO_IMPAIRMENT — 支持减值会计的 FIFO。

---

C. 更新成本基础策略

当用户希望更改默认策略或设置策略期间时，使用此项。

执行前始终与用户确认 — 更改策略会影响所有未来的成本基础计算，并且需要重新计算。

mutation UpdateCostBasisStrategyByDate(
  $defaultStrategy: CostBasisStrategy!,
  $strategyPeriods: [CBStrategyPeriodInput]!
) {
  updateCostBasisStrategyByDate(
    defaultStrategy: $defaultStrategy,
    strategyPeriods: $strategyPeriods
  ) {
    success
    message
  }
}

变量示例：

{
  "defaultStrategy": "FIFO",
  "strategyPeriods": [
    {
      "startDate": "2024-01-01T00:00:00Z",
      "endDate": "2024-12-31T23:59:59Z",
      "strategy": "LIFO"
    }
  ]
}

CostBasisStrategy 枚举值：FIFO、FIFO_IMPAIRMENT、LIFO、AVG、MAX_GAINS、MAX_LOSSES。

如果要更新为基于期间的配置，请先获取现有期间（第 B 节），以免意外覆盖它们 — 此变更会替换所有期间。

成功更改策略后，询问用户是否要触发成本基础重新计算（第 D 节）。

---

D. 触发成本基础计算

前提条件：触发前，运行 Step 2（策略检查），确保已定义策略。如果尚未设置，用户必须先选择一个策略。

启动（或重新启动）成本基础计算。可以针对特定资产，也可以重新计算全部资产。

mutation TriggerCostBasis($assetClassIds: [Int]) {
  triggerCostBasis(assetClassIds: $assetClassIds) {
    success
  }
}

• 重新计算 全部资产：传入 assetClassIds: null（或省略该参数）。
• 重新计算 特定资产：传入资产类别 ID 数组，例如 [42, 88]。

要查找资产类别 ID，请先查询 assetBalance 或 assetClass：

query AssetClasses($limit: Int) {
  assetClass(limit: $limit) {
    results { id symbol name }
  }
}

触发后 — 轮询直至完成

成功触发（success: true）后，使用第 A 节中的查询轮询状态。小型组织的计算通常需要 10–60 秒，大型组织可能需要几分钟。

1. Trigger → success: true
2. Poll costBasisGetStatus every ~10 seconds
3. When status = "DONE" → proceed to show results (Section E)

状态为 DONE 之前，不要展示结果或提供报告下载。状态为 IN_PROGRESS 时，向用户简要说明需要等待。

---

E. 查看每项资产的成本基础结果

显示每个资产-钱包组合的成本基础明细 — 总成本、已实现收益、销货成本、当前库存等。

重要：使用 assetBalance 查询（不要使用 organizationBalance）。assetBalance 查询会返回每个钱包的资产行，每行都包含一个来自 FifoCostBasisQuery 的嵌套 costBasis 字段。

query AssetBalanceWithCostBasis($limit: Int, $offset: Int) {
  assetBalance(limit: $limit, offset: $offset) {
    totalCount
    results {
      asset {
        symbol
        name
      }
      belongsTo {
        name
      }
      calculatedBalance
      assetFifoCostBasis
      totalProfitLoss
      costBasis {
        costBasis
        totalRealizedGains
        totalShortTermRealizedGains
        totalLongTermRealizedGains
        totalCost
        totalRunningInventoryQuantity
        cogs
        proceeds
        runningBalance
      }
    }
  }
}

变量：{"limit": 50, "offset": 0}

如果 totalCount > 50，请分页查询 — 将 offset 增加 50 并再次获取，直到检索完所有结果。

关键字段说明

• assetFifoCostBasis — 此资产-钱包组合的总成本基础（顶层快捷字段）。
• totalProfitLoss — 总已实现损益（顶层快捷字段）。
• costBasis — 包含完整明细的嵌套对象（未计算时为 null）：
  • costBasis / totalCost — 当前库存的总成本。
  • totalRealizedGains — 已实现净收益/损失。
  • totalShortTermRealizedGains / totalLongTermRealizedGains — 按持有期限拆分。
  • cogs — 处置资产的销货成本。
  • proceeds — 处置资产的总收益。
  • totalRunningInventoryQuantity — 当前库存数量。
  • runningBalance — 代币余额变动。

呈现结果 — 完整概览

获取所有页面后，将结果分为两组：

第 1 组 — 有成本基础数据的资产（costBasis 不为 null）： 以表格形式呈现，并按已实现盈亏的绝对值降序排序，列包括： 资产、钱包、持仓、成本基础（$）、已实现盈亏（$）。 使用颜色编码：绿色/+ 表示收益，红色/- 表示亏损。

第 2 组 — 没有成本基础的资产（costBasis 为 null 且 calculatedBalance != 0）： 这些资产尚未计算成本基础，通常是因为缺少法币估值、没有交易记录，或属于未经验证/垃圾资产。请在单独的部分中呈现，并使用清晰的标题，例如：

没有成本基础数据的资产： 以下资产有余额，但尚未计算成本基础。这通常意味着缺少法币价格，需要先解决这些问题，才能计算成本基础。

显示：资产、钱包、持仓，以及可能原因的说明（垃圾代币、NFT、缺少法币估值等）。

始终显示这两组，让用户看到完整情况。如果第 2 组中有任何重要资产（非垃圾资产/虚拟资产），还应运行财务问题查询（第 F 节），并筛选 HIGH 严重性，以检查 missing_fiat 问题，同时一并报告。

发现缺少法币估值的问题时，自动使用价格查询（第 G.1 节）查找每项受影响资产在交易时间戳对应的历史价格。向用户展示查到的价格，并提供使用批量法币编辑功能应用这些价格的选项（第 G.2 节）。

建议：生成带样式表格的 HTML 仪表板文件，包含两组资产和财务问题摘要。将文件保存到输出文件夹，并向用户分享链接。

使用标准数字格式：

• 法币金额 >= $1M："$X.XXXM"，>= $1K："$X.XXK"，否则："$X.XX"
• 正收益：添加 "+" 前缀，负收益：添加 "-" 前缀

---

F. 查看财务问题

财务问题是成本基础计算过程中检测到的问题，例如余额为负、缺少法币估值、循环转账等。

query FinancialIssues($limit: Int, $offset: Int, $severity: String) {
  financialIssue(limit: $limit, offset: $offset, severity: $severity) {
    totalCount
    results {
      id
      type
      severity
      message
      balanceImpact
      assetClass {
        id
        symbol
        name
      }
      assetClassId
      internalAccount {
        name
      }
      internalAccountId
      tx {
        identifier
        timestamp
      }
      subTx {
        id
        amount
      }
    }
  }
}

筛选选项

重要：筛选值必须使用小写——API 使用数据库中存储的值。

• severity："high"、"medium"、"low"
• 请勿在查询中直接按 type 筛选，而应获取所有问题后，在呈现时进行筛选/分组。type 筛选器使用的内部数据库值可能与显示名称不匹配。

实际返回的问题类型

type 字段返回小写字符串，例如：

• missing_fiat — 子交易没有法币价格，影响成本基础的准确性。可通过批量法币编辑解决（第 G 节）。
• negative_balance — 库存低于零（卖出的数量多于买入的数量），通常意味着缺少流入交易。
• result_was_rounded — 计算过程中发生了轻微舍入，严重性较低。
• ignored — 子交易已跳过（例如，转账到同一账户的内部转账）。
• no_opposite_tx — 内部转账没有匹配的对应交易。
• circular_internal_sbxs — 内部转账匹配中存在循环依赖。

按严重性对结果分组，并优先呈现 HIGH 严重性问题。最常见的情况是少量 HIGH 严重性的 missing_fiat 问题，加上许多 LOW 严重性的 result_was_rounded 问题——请用数量汇总 LOW 严重性问题，而不是逐条列出。

---

G. 修复缺少的法币估值

这是一个分两步进行的流程：先查找历史价格，然后应用这些价格。

G.1 — 查询历史代币价格

使用 TRES MCP 价格查询，为缺少法币价值的代币获取历史价格。此功能使用平台的定价引擎，该引擎汇总 CoinGecko、CoinMarketCap、交易所及其他来源的数据。

查询单个资产在特定时间戳的价格：

query GetStatelessPricing(
  $platform: Platform!,
  $assetIdentifier: String!,
  $currencies: [Currency]!,
  $timestamp: DateTime
) {
  getStatelessPricing(
    platform: $platform,
    assetIdentifier: $assetIdentifier,
    currencies: $currencies,
    timestamp: $timestamp
  ) {
    prices
    assetClassId
    symbol
  }
}

变量示例：

{
  "platform": "ETHEREUM",
  "assetIdentifier": "0x...contractAddress",
  "currencies": ["USD"],
  "timestamp": "2020-11-24T09:01:26Z"
}

一次查询多个资产（按资产类别 ID）：

query GetBatchPricing($requests: [GetBatchPricesByAssetClassRequest]!) {
  getBatchStatelessPricingByAssetClass(requests: $requests) {
    prices
    assetClassId
    symbol
  }
}

变量示例：

{
  "requests": [
    {
      "assetClass": "4272",
      "currencies": ["USD"],
      "timestamp": "2018-06-18T19:13:45Z"
    },
    {
      "assetClass": "4272",
      "currencies": ["USD"],
      "timestamp": "2020-11-24T09:01:26Z"
    },
    {
      "assetClass": "9082",
      "currencies": ["USD"],
      "timestamp": "2020-11-27T20:06:54Z"
    }
  ]
}

prices 字段会返回类似 {"usd": 0.015} 的 JSON 对象。

在缺失法币价值的处理流程中使用此功能：

1. 从财务问题（第 F 节）中，收集每个 missing_fiat 问题的 assetClass.id 和 tx.timestamp。
2. 针对每个问题调用 getBatchStatelessPricingByAssetClass，每个问题提交一个请求。
3. 向用户展示结果：

   “我找到了缺失法币交易的历史价格：

   • 2018-06-18 的 CHSB：每枚代币 $0.015
   • 2020-11-24 的 CHSB：每枚代币 $0.085
   • 2020-11-27 的 vBUSD：每枚代币 $0.021

   是否要应用这些价格？”

4. 如果用户确认，使用第 G.2 节（批量编辑法币价值）应用这些价格。

可尝试的定价来源：如果默认来源返回空结果，请按以下顺序尝试这些 apiSource 值：COINMARKETCAP、CRYPTO_COMPARE、REGULAR_FLOW、COINBASE、BINANCE、KRAKEN。在请求中传入 apiSource 字段：

{
  "requests": [
    { "assetClass": "4272", "currencies": ["USD"], "timestamp": "2020-11-24T09:01:26Z", "apiSource": "COINMARKETCAP" }
  ]
}

重要：没有可用价格数据时，价格查询会返回 prices: {}（空对象）。对于冷门、已下架或 DeFi 封装代币，这种情况很常见。放弃前请尝试多个来源。

如果所有定价来源对某个代币都返回空结果，请告知用户并请他们提供手动价格。如果你了解该代币，可建议一个近似值（例如，锚定 BUSD 的代币 ≈ $1.00）。

G.2 — 批量编辑法币价值

覆盖指定日期范围内某项资产的法币单价。可用于修复 MISSING_FIAT 问题或更正 OTC 价格。

执行前务必与用户确认参数——此操作会为可能大量的子交易写入法币价值。

mutation BulkFiatEdit(
  $assetClassId: Int!,
  $currency: Currency!,
  $startDate: Date!,
  $endDate: Date!,
  $unitPrice: Float!,
  $updateExistingFiat: Boolean
) {
  bulkFiatEdit(
    assetClassId: $assetClassId,
    currency: $currency,
    startDate: $startDate,
    endDate: $endDate,
    unitPrice: $unitPrice,
    updateExistingFiat: $updateExistingFiat
  ) {
    success
    message
  }
}

变量示例：

{
  "assetClassId": 42,
  "currency": "USD",
  "startDate": "2024-01-01",
  "endDate": "2024-01-31",
  "unitPrice": 1.0,
  "updateExistingFiat": false
}

• updateExistingFiat: false（默认值）——仅填入缺失的法币价值。
• updateExistingFiat: true——覆盖范围内的所有法币价值。

要查找 assetClassId，请先按币种符号查询 assetClass。

应用 G.1 中的价格时，请使用查询到的单价，并将日期范围精确设为交易日期（startDate 和 endDate 设为同一天），以免覆盖其他交易的价格。

批量编辑法币价值后，建议用户触发成本基础重新计算（第 D 节）。

---

H. 重估和减值

重估会调整库存批次在特定时间点的公允市场价值（FMV）。减值是公允市场价值低于成本的一种特殊情况。

H.1 — 列出重估

query GetReevaluations($limit: Int, $offset: Int, $assetClassId_In: [ID]) {
  reevaluation(
    limit: $limit,
    offset: $offset,
    assetClassId_In: $assetClassId_In,
    ordering: "-timestamp"
  ) {
    totalCount
    results {
      id
      timestamp
      unitPrice
      currency
      isImpairment
      assetClass {
        id
        symbol
      }
      appliedCostBasis {
        id
        totalCost
        revaluedCostAdjustment
        internalAccount {
          id
          name
        }
      }
    }
  }
}

H.2 — 创建重估

执行前务必与用户确认。

mutation CreateReevaluation($reevaluations: [ReevaluationObjectType]!) {
  createReevaluation(reevaluations: $reevaluations) {
    reevaluationIds
  }
}

变量示例：

{
  "reevaluations": [
    {
      "unitPrice": "45000.00",
      "timestamp": "2024-12-31T23:59:59Z",
      "assetClassId": 1,
      "currency": "USD",
      "isImpairment": false
    }
  ]
}

• isImpairment: false — 标准重估（按市值计价）。
• isImpairment: true — 减值冲销。

创建重估也会创建一笔手动交易，以在账本中体现此调整。请告知用户这一副作用。

创建后，建议触发成本基础重新计算（第 D 节）。

H.3 — 更新重估

mutation UpdateReevaluation(
  $reevaluationId: Int!,
  $unitPrice: Decimal!,
  $timestamp: DateTime!,
  $assetClassId: Int!,
  $currency: Currency!
) {
  updateReevaluation(
    reevaluationId: $reevaluationId,
    unitPrice: $unitPrice,
    timestamp: $timestamp,
    assetClassId: $assetClassId,
    currency: $currency
  ) {
    status
  }
}

H.4 — 删除重估

mutation DeleteReevaluation($reevaluationId: Int!) {
  deleteReevaluation(reevaluationId: $reevaluationId) {
    status
  }
}

删除操作也会从账本中移除关联的手动交易。

---

I. 指定批次（Spec-ID）规则

指定批次规则允许用户在处置资产时，明确指定要使用的购入批次，从而针对特定交易覆盖默认策略（例如 FIFO）。

I.1 — 查看指定批次规则

query CostBasisSpecIdRules(
  $limit: Int,
  $offset: Int,
  $outflowSubTransaction_In: [String]
) {
  costBasisSpecIdRule(
    limit: $limit,
    offset: $offset,
    outflowSubTransaction_In: $outflowSubTransaction_In
  ) {
    totalCount
    results {
      id
      outflowSubTransaction {
        id
        amount
        timestamp
        asset { symbol }
        belongsTo { name }
      }
      disposedLotSubTransaction {
        id
        amount
        timestamp
      }
      amountToDispose
      priority
    }
  }
}

I.2 — 设置指定 ID 规则

执行前务必先征得用户确认。 这会替换给定流出子交易的所有现有规则。

mutation SetSpecIdRules(
  $subTransactionId: ID!,
  $specIdRules: [SpecIdRuleInput]!
) {
  setSpecIdRules(
    subTransactionId: $subTransactionId,
    specIdRules: $specIdRules
  ) {
    success
  }
}

变量示例：

{
  "subTransactionId": "12345",
  "specIdRules": [
    {
      "disposedLotSubTransactionId": "67890",
      "amount": 1.5,
      "priority": 1
    },
    {
      "disposedLotSubTransactionId": "67891",
      "amount": 0.5,
      "priority": 2
    }
  ]
}

• subTransactionId — 流出（处置）子交易
• disposedLotSubTransactionId — 用作成本批次的流入（取得）子交易
• amount — 要处置的该批次数量
• priority — 处理顺序（1 = 最先）

设置规则后，建议触发成本基础重新计算（第 D 节）。

I.3 — 删除指定 ID 规则

mutation DeleteSpecIdRules($subTransactionId: ID!) {
  deleteSpecIdRules(subTransactionId: $subTransactionId) {
    success
  }
}

---

J. 完整库存配置

默认情况下，TRES 会修剪旧库存批次以减少存储空间。对于需要查看完整库存队列的特定交易，可切换为保存完整库存。

mutation SetFullCostBasisInventoryConfiguration(
  $subTransactionId: ID,
  $enableFullInventory: Boolean
) {
  setFullCostBasisInventoryConfiguration(
    subTransactionId: $subTransactionId,
    enableFullInventory: $enableFullInventory
  ) {
    success
  }
}

这会删除受影响资产的现有成本基础记录，并自动触发重新计算。

---

K. 导出成本基础报告

TRES 提供多种成本基础报告类型。使用 availableReportTypes 查询查找可用的导出类型，然后通过 organizationBalance 触发导出：

query AvailableReports {
  availableReportTypes {
    name
    exportType
    entitiesType
    llmDescription
  }
}

与成本基础相关的报告类型包括：

• COST_BASIS_STACK_PER_ACCOUNT — 按钱包分组的库存批次
• COST_BASIS_STACK_PER_ASSET — 按资产分组的库存批次
• COST_BASIS_INVENTORY — 完整库存明细
• COST_BASIS_ROLL_FORWARD — 期间结转明细
• REEVALUATION — 重新估值记录

导出时，使用带导出参数的 organizationBalance：

query ExportCostBasisReport(
  $exportName: String,
  $exportFormat: String,
  $currency: String,
  $outputFormat: ReportOutputFormat
) {
  organizationBalance(
    exportName: $exportName,
    exportFormat: $exportFormat,
    currency: $currency,
    outputFormat: $outputFormat
  ) {
    totalCount
  }
}

变量示例：

{
  "exportName": "Cost Basis Stack Per Asset - April 2024",
  "exportFormat": "COST_BASIS_STACK_PER_ASSET",
  "currency": "usd",
  "outputFormat": "XLSX"
}

然后轮询 report 查询，直到 status = "DONE"，并提供下载链接：

query Reports($limit: Int, $offset: Int) {
  report(limit: $limit, offset: $offset, ordering: "-created_at") {
    totalCount
    results {
      id
      name
      status
      downloadUrl
      createdAt
    }
  }
}

重要：当状态为 IN_PROGRESS 时，切勿提供下载链接——文件尚未写入 S3，链接会返回 NoSuchKey 错误。每隔约 10 秒轮询一次，直到状态为 "DONE"，然后向用户提供 downloadUrl。

---

防护规则

• 写入前确认：执行任何变更（策略更改、重新估值、指定 ID 规则、批量法币编辑、触发计算）前，务必先征得用户确认。
• 重新计算提醒：进行任何配置更改（策略、重新估值、指定 ID、法币编辑）后，提醒用户需要重新计算成本基础，才能使更改生效。
• 锁定期间：如果变更因“locked period”错误而失败，请告知用户时间戳落在已锁定的会计期间内，可能需要先将其解锁。
• 触发前检查状态：触发重新计算前，检查当前状态——如果已是 IN_PROGRESS，请告知用户任务仍在运行。

---

限制 — MCP 无法提供

后端支持以下成本基础功能，但不会通过 MCP GraphQL API 公开，因此此技能无法执行这些操作：

1. 按钱包重新分配流程 — 两阶段重新分配流程（统一库存 -> 按钱包拆分）是由组织设置触发的后端内部操作，无法通过 API 直接调用。

2. 查看原始库存队列详情 — assetRunningQueueFifo 字段可通过 FifoCostBasisQuery 获取，但会返回大型 JSON 数据块。最好通过 TRES 控制面板或导出的报告（COST_BASIS_STACK_PER_ACCOUNT / COST_BASIS_STACK_PER_ASSET）查看队列数据。

3. 空头头寸 / 贷款队列管理 — 空头头寸跟踪（贷款队列）在组织设置级别配置，并自动计算。没有可直接查看或操作贷款队列的 API。

4. 成本基础计算内部机制 — 实际计算引擎（CostBasisCalculator、CostBasisManager）在服务端运行。我们可以触发计算并读取结果，但无法控制内部计算流程、缓存或 S3 队列持久化。

5. 内部转账成本基础映射 — 内部转账时成本基础如何在钱包之间结转是自动完成的，无法通过 API 按交易进行配置。

对于上述任何操作，请引导用户使用 TRES Finance 控制面板，或建议导出相关成本基础报告进行离线分析。