Relqis

Appearance

CLI ワークフロー ​

このページでは、Relqis を CLI から操作するときの主要な流れを整理します。

手入力の下書き仕訳 ​

エージェントが仕訳を直接組み立てるときに使います。

  1. account、subaccount、department、counterparty、tax code など、必要な master data を確認します。
  2. entry create で下書きを作成します。Relqis 1.0 系では entry create は strict JSON 前提なので、--input PATH または --input - を使います。
  3. 生成された下書きを entry show で確認します。
  4. entry post で post します。
  5. posted 後に修正が必要になった場合は、manual/import 起源の normal entry なら通常は entry reverse を使います。entry void は duplicate intake など、domain policy が original posted fact の invalidation を明示的に許すケースに限って使ってください。receivable / payable / fixed asset / closing / carryforward などの workflow-owned entry は、その owning workflow 側の訂正フローを使ってください。

使い分けの目安:

  1. duplicate import / duplicate replay / 同じ source fact を二重に post してしまった場合は entry void
  2. 金額訂正、勘定科目振替、日付修正、見越計上の戻し、単純な再分類は entry reverse

Relqis 1.0 では、manual entry の posting_request_id は caller-managed boundary ID のままです。これは engine-owned UUIDv7 run id ではなく、同じ論理 request を retry するときの相関キーなので、master/policy を直して再実行するときも同じ値を使います。

field 位置の推測ではなく、JSON document をそのまま渡してください。

典型コマンド:

bash
rlq entry create --input entry-create.json --json
rlq entry show ENTRY_ID --json
rlq entry post ENTRY_ID --expected-version VERSION --posting-date DATE --json

段階的な起票要求 ​

上流の import、system、external domain からデータが入り、下書き仕訳を作る前に段階的に起票したいときに使います。

  1. postreq create で要求を stage します。
  2. postreq show または postreq work でエラーや要求行を確認します。
  3. postreq validate で validation します。
  4. 生成された下書き仕訳を entry show で確認します。
  5. asset create や reconcile run などの downstream command で必要なら、entry show、journal show、ledger show、または validation 済み postreq show から entry_line_id を取得します。reconcile run の run id は system-generated で、必要なら caller 側の相関キーだけを client_request_key として渡します。
  6. entry post で下書き仕訳を post します。

manual/import の PostingRequest では、posting_request_id と validate 時に渡す entry_id が caller-managed boundary ID です。これらは retry/replay の anchor として扱われるので、同じ論理 request をやり直すときは同じ値を再利用します。UUIDv7 方針は close / carryforward / reconcile / export のような engine-owned run/batch ID に適用されます。

receivable create / payable create / receipt create / payment create は、この staged posting モデルの external-domain 版です。これらの command は subledger state を先に永続化し、対応する ledger posting は PostingRequest として pending に残します。

つまり:

  1. create 直後でも receivable apply / payable apply など subledger 側の workflow は進められる
  2. ただし ledger side はまだ posted ではない
  3. show / list の ledger state と next action を最初に見る
  4. pending request / rejected request / failed request は、subledger はあるが ledger side が未完了という意味
  5. draft entry ready は postreq validate までは済んでおり、最後に entry post が必要という意味
  6. next action が review_posting_request_work のときは rlq postreq work --origin-type external_domain --json で pending work を確認する
  7. 最終的な ledger reflect は postreq validate と entry post を通して確定する

import を先に確認する推奨フロー:

  1. postreq preview --input PATH --json で batch を preview します。
  2. missing_masters、blocking_issues、policy_suggestions を確認します。
  3. 足りない master を追加するか、policy を調整します。
  4. postreq create --input PATH --json で request を stage します。
  5. postreq validate で validation します。

validation が master 不足や policy 不一致で reject された場合は、master data を直してから、同じ posting_request_id と同じ entry_id で同じ postreq validate を再実行します。手入力の entry create や opening create でも、再試行時は同じ posting_request_id を使います。

典型コマンド:

bash
rlq postreq create --input postreq-create.json --json
rlq postreq preview --input PATH --json
rlq postreq work --json
rlq postreq validate --posting-request-id POSTING_REQUEST_ID --entry-id ENTRY_ID --json

preview 入力例:

json
{
  "requests": [
    {
      "posting_request_id": "pr-import-001",
      "origin_type": "import",
      "origin_id": "row-42",
      "entry_id": "entry-import-001",
      "entry_type": "normal",
      "entry_date": "2026-04-10",
      "posting_date": "2026-04-10",
      "lines": [
        { "line_no": 1, "dc_type": "debit", "account_id": "cash", "amount_minor": 10000 },
        { "line_no": 2, "dc_type": "credit", "account_id": "sales", "amount_minor": 10000 }
      ]
    }
  ]
}

損益レポートと year close ​

profit-loss show は operator が期中損益を読みやすいように、既定では entry_type=closing を除外します。

典型フロー:

  1. 年度の営業成績を見たいときは、そのまま profit-loss show --period ... --json を使う
  2. closing day を含む window でも、既定では pre-close の operating result が返る
  3. closing entry 自体の netting 影響も同じ window で見たいときだけ --include-closing-entries を付ける

year close 実行後に profit-loss show --from ... --to ... がゼロに見えるのは、closing entry を含めた場合だけです。通常の年度損益確認では --include-closing-entries は不要です。

固定資産登録の訂正 ​

取得仕訳を asset create で固定資産登録した後は、その source entry line は fixed-assets workflow-owned です。generic entry reverse は使わず、まず fixed-assets 側で ownership を解除してください。

推奨フロー:

  1. asset show FIXED_ASSET_ID --json で対象 asset の状態を確認する
  2. downstream activity が無いことを確認したうえで asset void-registration --input PATH --json を実行する
  3. 必要なら、その後に source entry へ通常の entry reverse / entry void を適用する
  4. 訂正後の source line を使って asset create をやり直す

asset void-registration は fixed-assets context の lifecycle event です。posted ledger entry 自体は変更しません。取消できるのは、まだ depreciation history が無く、retire もされていない registration だけです。

固定資産の見積変更 ​

固定資産の remaining useful life や salvage value を見直す場合は、generic entry reverse や asset 再登録ではなく asset revise-estimate を使います。

推奨フロー:

  1. asset show FIXED_ASSET_ID --json で current state と registration terms を確認する
  2. 改定対象月の depreciation がまだ未実行で、対象 fiscal period / month が open であることを確認する
  3. asset revise-estimate --input PATH --json を実行する
  4. depreciation preview --fiscal-period-id ... --depreciation-date ... --json で新しい見積が将来分にだけ効いていることを確認する

asset revise-estimate は prospective only です。既に posted 済みの depreciation は書き換えません。effective date は指定 fiscal period の month-end date をそのまま指定してください。

固定資産の取得原価修正 ​

固定資産の useful life や salvage value ではなく acquisition basis 自体を増減させる場合は、generic entry reverse や source entry の直接訂正ではなく asset adjust-basis を使います。

推奨フロー:

  1. asset show FIXED_ASSET_ID --json で current acquisition amount と最新の correction history を確認する
  2. 調整対象月の depreciation がまだ未実行で、対象 fiscal period / month が open であることを確認する
  3. asset adjust-basis --input PATH --json を実行する
  4. depreciation preview --fiscal-period-id ... --depreciation-date ... --json で新しい basis が対象月以降の depreciation にだけ効いていることを確認する
  5. 必要なら asset retire や balance-sheet show で、その後の carrying amount / retirement loss が新 basis を基準に説明できることを確認する

asset adjust-basis は explicit ledger adjustment を伴う fixed-assets lifecycle event です。adjustment posting 自体は指定 adjustment_date に起票され、depreciation schedule への影響はその fiscal month-end から反映されます。既に depreciation がある month-end へは backdate できません。

fixed-assets v1.0 の対象範囲 ​

Relqis v1.0 の fixed-assets は、cost model の実務運用に対象を絞ります。first-class で扱うのは、登録、registration cancellation、prospective estimate revision、basis adjustment、depreciation、full retirement with zero proceeds までです。

つまり:

  1. revaluation は dedicated lifecycle event としては扱いません
  2. impairment も dedicated lifecycle event としては扱いません
  3. partial disposal は扱いません
  4. sale proceeds を伴う disposal も integrated command としては扱いません

運用上の指針:

  1. partial disposal の可能性がある asset は、最初から component ごとに別 fixed asset として登録する
  2. disposal proceeds がある full disposal では、proceeds / gain / loss の仕訳は manual/import posting で別に起票し、asset retire は derecognition side にだけ使う
  3. revaluation や impairment を first-class な policy/event として追跡したい asset は、v1.0 では fixed-assets workflow の対象外として扱う

asset adjust-basis は permanent carrying-amount correction を explicit ledger adjustment と fixed-assets history に残すための汎用 correction ですが、revaluation reserve や impairment reversal のような専用 policy semantics までは表現しません。

create 入力例:

json
{
  "posting_request_id": "pr-import-001",
  "origin_type": "import",
  "origin_id": "row-42",
  "entry_type": "normal",
  "entry_date": "2026-04-10",
  "posting_date": "2026-04-10",
  "lines": [
    { "line_no": 1, "dc_type": "debit", "account_id": "cash", "amount_minor": 10000 },
    { "line_no": 2, "dc_type": "credit", "account_id": "sales", "amount_minor": 10000 }
  ]
}

postreq preview is the same request shape wrapped in { "requests": [ ... ] }.

開始仕訳 ​

開始仕訳だけに限定したいワークフローでは opening コマンド群を使います。

  1. opening create で作成します。Relqis 1.0 系では opening create も strict JSON 前提なので、--input PATH または --input - を使います。
  2. opening show で確認します。
  3. opening post で post します。

opening コマンド群は、entry が存在していても開始仕訳以外の entry id は受け付けません。

opening create と opening update は --input PATH と stdin JSON に対応しています。

締めと再オープン ​

事前確認を先に置くフローを使います。

月次締め:

  1. check close --closing-type month_close
  2. close month
  3. close history or close show

agent / automation から blocker を機械的に扱いたい場合は、check close --json を正規の structured contract として使います。close month 自体の失敗は v1.0 では summary message 中心で、複数 blocker を close-specific payload に展開しません。

month_close の preflight では、月末時点の receivable / payable open item、未照合の bank statement、未実行の減価償却、未確認の tax summary は warning です。未消込の receipt / payment は引き続き blocking error として扱います。cash-side subledger を締めたい月次、という位置付けです。

未消込の receipt / payment がある場合は、先に receivable apply、payable apply、receivable apply-credit-note、payable apply-debit-note、または必要な訂正フローを完了してから再実行してください。

ただし、subledger が settled / fully_applied でも、linked external-domain PostingRequest に ledger entry が無いままなら month close は止まります。receivable create / receipt create / payable create / payment create の結果をそのまま subledger だけで進めた場合は、先に postreq validate と entry post まで完了してください。

銀行照合、減価償却、税サマリ確認は月次では advisory 扱いです。provisional close を先に進め、final review で追い付く運用を取れます。 reconcile reverse で statement line を reopen した場合は、該当月や year close の check close で BANK_STATEMENT_UNRECONCILED_REMAINS warning が再表示されます。

年次締め:

  1. check close --closing-type year_close
  2. close year preview
  3. close year run
  4. close history or close show

close year preview / close year run でも同じ方針です。blocking detail を agent が読む必要があるときは、先に check close --closing-type year_close --json を実行します。

year_close の preflight では、receivable / payable open item、未消込の receipt / payment、未照合の bank statement、未確認の tax summary は warning です。pending fixed-asset depreciation は引き続き blocking です。さらに、source fiscal period 内に external-domain PostingRequest が残っていて ledger entry が無い場合も blocking です。blocking になるのは、月次未締めや period state、pending depreciation、ledger 未反映の external-domain posting、profit/loss 以外の整合性エラーです。

whole-period の tax summary を sign-off したい場合は、tax-summary confirm で target_month を省略して確認してください。year close 自体は tax summary 未確認でも進められます。 tax-summary confirm は、対象 scope に tax-coded posted line が 1 件も無い場合は拒否されます。先に tax-summary show で同じ scope が非空であることを確認してください。

再オープン:

  1. close reopen-month or close reopen-year
  2. Inspect the recorded operation with close history or close show

close reopen-month は year close 済みの fiscal period には直接使えません。先に close reopen-year が必要です。

close reopen-year は、carryforward 済みの fiscal period に対しては linked carryforward entry を rollback してから year reopen を行います。zero-balance carryforward の場合は rollback すべき entry が無いので、carryforward completion state だけを解除します。

この rollback は target period の開始日で reversal を起こすため、target period の opening month がまだ open である必要があります。target opening month がすでに closed の場合は、先に target 側の reopen 方針を決めてから対応してください。

繰越 ​

繰越は年次締めとは別操作です。

推奨フロー:

  1. check close --closing-type carryforward
  2. carryforward preview
  3. carryforward run
  4. Inspect the recorded run with close history

carryforward preview / carryforward run の失敗も summary message 中心です。machine-readable な blocker 一覧が必要なら check close --closing-type carryforward --json を使います。

carryforward の preflight では、subledger settlement、bank reconciliation、pending depreciation、tax summary confirmation などの operational readiness item は表示しません。ただし、source fiscal period 内の external-domain PostingRequest に ledger entry が無い状態は blocking のままです。blocking になるのは、source period が year close 済みでないこと、profit/loss が未クローズであること、carryforward balance の整合性エラー、ledger 未反映の external-domain posting、または target fiscal period policy の違反です。 reconcile reverse で bank statement line を reopen しても、carryforward preflight は bank reconciliation item を表示しません。必要なら month_close / year_close の check close で再点検してください。

target fiscal period policy:

  1. target は source と同じ period ではなく、source end date の翌日から始まる直後 fiscal period であること
  2. target period の opening month が open であること

source year が zero-balance で繰越対象 line を持たない場合でも、carryforward preview / carryforward run は成功します。この場合は no-op carryforward として扱い、closing run と audit は記録しますが、posting request や entry_type=carryforward の entry は生成しません。

レポート確認 ​

帳票確認や点検では read-side command を使います。

  • journal show for journal order grouped by entry
  • ledger show ACCOUNT_ID for an account ledger with running balance
  • trial-balance show for account totals over a period or date range
  • entry list and entry show for aggregate-level inspection

これらのコマンドは、origin_type に関係なく posted 済み entry を既定対象とし、--include-voided などの flag を明示したときだけ対象を広げます。

エクスポート ​

推奨フロー:

  1. Confirm the export profile with export-profile show
  2. Validate the selection with export validate
  3. Run the export with export run
  4. Inspect the persisted export run with export show

export run の export_run_id は system-generated です。外部 caller 側で相関したい場合だけ --client-request-key を渡します。

典型コマンド:

bash
rlq export-profile show EXPORT_PROFILE_ID --json
rlq export validate --export-profile-id EXPORT_PROFILE_ID --period FISCAL_PERIOD_ID --json
rlq export run --export-profile-id EXPORT_PROFILE_ID --client-request-key EXPORT_CLIENT_KEY --output-path PATH --json