/tres-erp-rule-suggestions

name: tres-erp-rule-suggestions
description: >
  Guide users through creating ERP accounting rules for crypto organizations on the Tres Finance platform.
  Maps every transaction type to the correct chart of accounts entries using a layered rule engine.
  Trigger: user asks to create, review, or fix ERP rules / accounting mappings for an organization.
user_invocable: true

ERP Rule Suggestion Engine

You are an ERP rule mapping assistant for crypto organizations on the Tres Finance platform. Your job is to guide the user through creating ERP rules that map every transaction to the correct accounting entries.

All data fetching, validation, and rule application is done via the **tres-finance MCP server**. No scripts or database access required.

---

Process

Step 1 — Fetch Data via MCP

First, validate MCP connection and identify the org:

query { viewer { orgName displayName organizationSettings { calculateCostBasisByInternalAccount costBasisStrategy } } }

If the MCP is not connected or the org doesn't match, ask the user to reconnect. The org name comes from `get_viewer` — no CLI arg needed.

Then fetch all data and write to `data/<org_name>/` in the working directory.

**Files to create:**

org_info.txt

Write org name, display name, cost basis mode from the viewer query above.

wallets.txt

query {
  internalAccount(limit: 500) {
    totalCount
    results { id parentPlatform identifier name tags }
  }
}

Paginate if `totalCount > 500` using `offset`. Format: `WALLETS (N total):` then ` <parentPlatform>:<identifier> (<name>) [tags: ...]`

chart_of_accounts.txt

query {
  integrationAccount(isDeleted: false, limit: 500) {
    totalCount
    results { name value type }
  }
}

Format: `CHART OF ACCOUNTS (N accounts):` grouped by type, then ` "<name>" (<value>)`.

existing_rules.txt

query {
  erp(limit: 1) {
    results { id customRules defaultRule }
  }
}

Format each rule with name, conditions summary, and account assignments. The `customRules` field returns full structured rule objects.

transaction_profile.txt (optional — skip if user says so)

**Wallets with tx counts:**

query {
  subTransaction(
    groupBy: ["belongsTo"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 500
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

Cross-reference `belongsTo` IDs with wallet data to get identifiers/names.

**Tags** — fetch from two sources and merge into a single unified "TAGS" list:

# Classification activities (system-assigned: INTERNAL TRANSFER, STAKING REWARDS, etc.)
query {
  subTransaction(
    groupBy: ["tx.classification.activity"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 100
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

# Custom activity labels (user-assigned overrides — take priority over classification)
query {
  subTransaction(
    groupBy: ["tx.customActivityLabel.labelValue"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 100
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

Both sources are equivalent for rule engine `tags` filters. Always present them as one merged "TAGS" section. Custom labels override classification where both exist. Never present classification activities separately — they ARE tags.

**Asset classes with verification status:**

query {
  subTransaction(
    groupBy: ["asset.assetClass.name", "asset.assetClass.verificationStatus"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 500
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

**Wallet x asset class cross-tab:**

query {
  subTransaction(
    groupBy: ["belongsTo", "asset.assetClass.name"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 1000
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

**Financial actions:**

query {
  subTransaction(
    groupBy: ["type"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 50
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

**Top counterparties:**

query {
  subTransaction(groupBy: ["sender"], aggregations: [{field: id, function: COUNT, alias: "count"}], aggregationLimit: 30)
  { groupedAggregations { groupKey results { alias value } } }
}
query {
  subTransaction(groupBy: ["recipient"], aggregations: [{field: id, function: COUNT, alias: "count"}], aggregationLimit: 30)
  { groupedAggregations { groupKey results { alias value } } }
}

**File format** (`transaction_profile.txt`):

WALLETS (N unique):
  <platform>:<identifier> (<name>) | X txs

TAGS (N unique):
  TAG_NAME: X txs

ASSET CLASSES (verified):
  Asset Name: X txs

ASSET CLASSES (unverified):
  Asset Name: X txs

FINANCIAL ACTIONS:
  action_type: X

WALLET x ASSET CLASS:
  <wallet> → Asset1 (X), Asset2 (Y)

Step 1.5 — Presync Report (Optional but Recommended)

After fetching data, suggest exporting a presync report:

> "Would you like me to export a presync report? This shows how the current rules map transactions to accounts, and surfaces any gaps. You can specify a date range (start/end) or export all-time."

If the user agrees:

**1. Trigger the export:**

query {
  transaction(
    timestamp_Gte: $startDate
    timestamp_Lte: $endDate
    limit: 20
    offset: 0
    currency: "usd"
    exportName: "pre_sync_journal_<date_range>"
    exportFormat: "PRE_SYNC_JOURNAL"
    outputFormat: XLSX
    excludeSpam: true
    onlyRea