Elanorya

クレジット

返金がクレジット履歴に出てこないことがある理由

一覧は出来事ではなく、残高の動きで絞り込まれています。生成は2行を書き込みますが、残高を動かすのはそのうち1行だけです。返金も、実際に行われたうえで残高をまったく動かさないことがあります。

この一覧が実際には何の一覧なのか

クレジット履歴は、アカウントに起きたことをすべて記録した台帳ではありません。残高を動かした行の一覧です。画面の裏側にある問い合わせは、自分のウォレット上で金額がゼロではない行だけに対象を限定します。そのため、残高への正味の影響がない記録は、台帳の中でどれだけ実在していても、一覧には決して届きません。

この1つの条件が、出品者がこの画面に持ち込む2つの疑問の両方を説明します。返金はどこにあるのか、生成に対する行がなぜ1つしかないのか。答えは同じです。記録は存在していて、それが残高をまったく動かさなかった、ということです。

時点については、ここで導き直すのではなく1文だけ引き継ぎます。画面に見える動きは、実行のためにクレジットが取り置かれた時点で決まります。クレジットが正確にいつ消費されるのかは、別のページが扱う主題です。以下はすべて、そのあとに画面へ届くものについての話です。

書き込まれた行が現れないことがある理由

どれもアカウントの性質ではなく、読み取る側の面の性質です。同じ画面を見るすべてのアカウントに当てはまります。

絞り込みは1つの比較だけです。
履歴の問い合わせは、自分のウォレット上で金額がゼロではない行を選びます。それ以外に除外されるものはなく、条件を満たすものが隠されることもありません。一覧が短いのは動きが少なかったということであって、記録が欠けているということではありません。
生成を清算する行はゼロを持ちます。
クレジットが取り置かれ、そのあとで実行が取り置き分に対して清算されます。清算の行は金額ゼロで書き込まれるため、一覧が描かれる前に絞り込みで取り除かれます。コード自身のコメントが、目に見える結果をそのまま書き留めています。二重の請求は利用者に表示されない、というものです。
負債に吸収された返金には、正味の影響がありません。
返金の全額が未清算の負債の解消に充てられると、残高は始まったところで終わります(packages/db/src/credit-lots.ts:443-454)。返金は行われています。ただし、それが生んだ行は一覧の条件を満たしません。
すでに期限切れになったクレジットの返金にも、正味の影響はありません。
取り置かれていたクレジットが期間の終わりに期限切れになった出所から来ていた場合、それを戻しても使える残高は増えないため、その行は同じ規則で絞り込みから外れます。
通常の、失敗した実行に対する返金は、これらの影響を受けません。
使える残高にクレジットを戻す返金は残高を動かすので、表示されます。ここで見えなくなるのは、負債を抱えているアカウント、あるいは期限切れの期間のクレジットを使ったアカウントに限られます。

何が書き込まれ、何が画面に届くのか

中央の列を台帳、右の列を画面として読んでください。この2つの隔たりが、このページの主題のすべてです。

出来事台帳に書き込まれるもの履歴に表示されるか
生成のためにクレジットが取り置かれる残高を動かす行表示される
その生成が清算される金額がゼロの行表示されない
失敗した実行のあとの返金で、使える残高にクレジットが戻る残高を動かす行表示される
未清算の負債にすべて吸収される返金正味の影響がない行表示されない
期間の終わりに期限切れになった出所から引かれたクレジットの返金正味の影響がない行表示されない

短く見える履歴の読み方

以下の各行は、出品者が実際に持ち込む状況と、画面の作りに合った読み方です。

状況選択理由
実行が失敗し、クレジットは戻っているのに、返金の行がない。残高を信じ、その行を探すのをやめる。未清算の負債に吸収された返金や、すでに期限切れになっていた出所からクレジットを戻す返金は、残高をまったく動かさないため、一覧から外れます。
完了したと分かっている生成に、行が1つだけある。その行は、処理が終わった時点ではなく、クレジットが取り置かれた時点として読む。清算の行は金額ゼロを持ち、画面には決して届かないため、1回の生成が示せる行は常に1つだけです。
生成がいつ終わったのかを知りたい。台帳ではなく、進行中の実行を追う画面を使う。完了は残高を動かすものを何も書き込まないため、履歴には示せる記録がありません。
残高が、アプリが使わせてくれる分より多く見える。小さいほうの数字を本当の値として扱い、あとで確認し直す。残高は保存されたまま読み取られ、読み取りは期限切れの確認を行いません。訂正する処理はサーバー側で、このページが約束できない周期で動きます。
クレジットが届いたのに、残高が付与された分より少なく増えた。残高を答えとして読み、差を説明する行は期待しない。入ってきた付与のうち未清算の負債に充てられた分は、使えるようにはなりません。その分を説明する行も履歴にはありません。
出来のよくない結果を報告するとクレジットが戻るのかを知りたい。このページが答えない別の問いとして扱う。履歴が記録するのは残高の動きです。報告の流れが何をするかは、そのための専用のページに書かれています。

カタログ制作の途中で、これが損になるところ

問題が起きる形は、クレジットが失われることではありません。正しい画面から誤った結論を引き出してしまうことです。

  • 複数の作品のまとまりを突き合わせるために、行を数える。

    一覧に入っているのは残高の動きなので、数えるべきものも残高の動きです。返金の行がないことは絞り込みの結果であって、返金が行われなかった証拠ではありません。

  • 行の数から、二重に請求された、あるいはまったく請求されなかったと結論づける。

    生成あたり1行が設計どおりの形です。2つ目の行は金額ゼロで書き込まれ、絞り込みで外れます。行の数は、台帳にある請求の数ではありません。

  • 最後に見た残高をあてにして、長いバッチを始める。

    表示される数値には、もう使えなくなったクレジットが短い間だけ含まれることがあります。その瞬間の残高が正確であることに依存する実行を計画するのではなく、余裕を残してください。

  • 台帳を撮影の時系列として使う。

    実行あたりの時刻は1つ、クレジットが取り置かれた時点だけで、完了の時刻はありません。待ち時間に関することは、それを担う画面で確認してください。

  • 画面がすでに正しく答えている問い合わせを、サポートに引き上げる。

    記録が見当たらないと報告する前に、その記録がそもそも残高を動かしたかどうかを確かめてください。動かさないのであれば、一覧は定義どおりに完全です。

履歴画面が返すもの

戻ってくるものは2つあり、それぞれ別の問いに答えます。

一覧。自分のウォレット上で金額がゼロではない行、それだけです。残高の動きの記録であり、完了の時刻も、品質の結果も、方針も持ちません。

残高。ウォレットの記録から、その時点のまま読み取られた1つの保存された数値です。読み取り自体は期限切れの確認を行いません。ウォレットの記録が存在しない場合の応答は、エラーではなく空の残高です。失敗ではなく、黙って代わりの値を返す動きです。

どちらの答えも、価格やパック、プランと比べられる金額を持ちません。それはこの面の外にあり、このページの外にあります。

このページが扱わないこと

どれも実際にある問いです。ただし、上で説明した面からは答えられません。

  • 実行の途中で、クレジットが正確にいつ消費されるのか。その時点は別のページが担っており、ここでは1文だけを引き継いでいます。
  • 出来のよくない結果を報告するとクレジットが戻るのかどうか。これは専用のページを持つ、製品側の流れです。
  • 負債がどのように生じ、何を妨げるのか。ここで述べているのは目に見える結果だけです。増え方が小さくなり、それを説明する行がない、という点です。
  • 台帳の内部で、クレジットがどの順に選ばれ、分割され、戻されるのか。その手順はコードの別の部分にあり、このページの根拠になった出典では説明されていません。
  • 期限切れの定期処理が本番の配備で有効になっているかどうか、どれくらいの間隔で動くのか、サービスの複製がいくつ動いているのか。いずれもコードからは読み取れない配備側の設定に依存します。
  • アプリの画面が、クレジットや負債の状態をいつ読み直すのか。クライアント側については、この出典が正式に説明しているわけではありません。
  • クレジットの金額、価格、パックやプランの名称、返金の方針、権利内容、法的な表明。いずれもありません。

これらの記述の出どころ

このページの動作は、ドキュメントではなくプラットフォームのソースから読み取りました。確認日は2026-08-18です。

残高の読み取りと履歴の絞り込みは、ウォレットのサービス実装にあります(apps/api/src/wallet/wallet.service.ts)。残高は保存された数値として返され、ウォレットの記録がないときはゼロが返ります。履歴の問い合わせは、金額がゼロではない行に対象を限定します。その問い合わせの脇にあるコメントは、目に見える結果を直接述べています。清算の行が金額ゼロを持つため、二重の請求は利用者に表示されない、というものです。

負債に吸収された返金、あるいは期限切れの出所から引かれた返金の正味の影響がゼロになることは、クレジットのロットを扱うファイルにあります(packages/db/src/credit-lots.ts:443-454)。入ってきた付与のうち負債に充てられた分は使えるようにならない、という記述も同じファイルにあります。

クレジットが取り置かれる時点の消費の処理と、定期的な掃き出し処理との関係は、期限切れの掃き出しを担うファイルにあります(apps/api/src/wallet/credit-expiry-sweeper.ts)。そのコメントは、前者を正式な確認として、後者を表示される残高の正直さのために存在する仕事として名指しています。

よくある質問

生成に対して行が1つしかないのはなぜですか。

2つの行のうち、残高を動かしたのが片方だけだからです。実行のためにクレジットが取り置かれ、その行が現れます。実行を清算する行は金額ゼロで書き込まれ、一覧は金額がゼロではない行だけを表示します。どちらも書き込まれていて、画面に届くのが一方だけです。

返金が履歴にありません。台帳が間違っているのでしょうか。

いいえ。返金は実際に行われたうえで、残高への正味の影響を持たないことがあります。全額が未清算の負債を解消した場合と、取り置かれていたクレジットが期間の終わりに期限切れになった出所から来ていた場合です。通常の、失敗した実行のあとの返金は残高を動かすので、そのまま表示されます。

残高に、アプリが使わせてくれないクレジットが表示されています。いつ訂正されますか。

残高は保存されたまま読み取られ、その読み取り自体は期限切れの確認を行いません。訂正する処理はサーバー側で動きます。次にクレジットが取り置かれる時点と、有効になっている場合は定期処理によってです。ここで時点を約束することはできません。その定期処理がある配備で動いているかどうかは、コードからは読み取れない環境設定だからです。

生成がいつ終わったのかを、履歴から知ることはできますか。

いいえ。完了は残高を動かさないので、残高の動きから組み立てられた一覧には、そのことが何も書き込まれません。実行あたり得られる唯一の時刻は、そのためにクレジットが取り置かれた時点です。