取引はどのように 1 回の精算入金へグループ化されますか？
グループ化は 3 階層あり、そのうち貴社が目にするのは外側の 2 つだけです。
下から読むと、取引はまず決済手段と取引日ごとにまとめられ、そのまとまりが注文通貨ごとに結合され、さらに精算通貨ごとにバッチへ結合されます。
バッチのキーのうち 2 つの軸は見落とされやすく、どちらも同じ日に同じ通貨で複数の精算を受け取り得ることを意味します。
- 契約主体。 貴社の取引が複数の Waffo 契約主体のもとで収単されている場合、それぞれが独自のバッチで精算されます。
- 清算タイプ。 返金Reserve（refund reserve）の取り決めから資金が供給される返金の精算は別の清算ストリームであり、通常の精算とバッチを共有することはありません。また休日カレンダーも無視します。精算サイクルとカレンダーを参照してください。
精算の識別子は何を意味しますか？
識別子の中の日付は生成された日付であり、必ずしも資金が動いた日付ではありません。それにはレコード自身の日付フィールドを使ってください。サポートに伝えるべきなのは
S… の値です。精算とそのファイル、元帳の記録を特定するキーになります。
精算レコードのステータスとタイムラインは何を教えてくれますか？
精算レコードにはステータスがあり、その詳細ページには実行のタイムライン全体が表示されます。精算は複数回試行され得るため、これは重要です。
タイムラインは各イベントを固有のタイムスタンプとともに記録します。生成、失敗した各試行、最終結果です。したがって、実行して失敗し後で成功したレコードは、最後の 1 つだけでなく 3 つすべてを表示します。初期状態のままのレコードは一覧に表示されません。
精算レコードのデフォルトは直近 90 日（UTC+8）です。レコードが今日より前の精算日を示していながら未完了であることは正当に起こり得ます。これを生む再試行の順序は精算サイクルとカレンダーで説明しています。
Settlement Original Amount と Settlement Target Amount とは何ですか？
精算契約が注文通貨をその通貨自身へ精算する場合、両者は同一です。換算が関わる場合は異なります。そして
Settlement Target Amount は換算が完了するまで空です。これはデータの欠落ではなく段階です。照合中に target amount が空白であれば、その精算は準備済みでまだ換算されていません。
Balance History は何を記録しますか？どの business type で絞り込めますか？
Balance History は貴社の精算口座の元帳で、精算先のすべての精算通貨を対象とします。絞り込める business type は 6 つです。
驚かれやすい点が 2 つあります。
- 古い行には、もう生成されないタイプが付いていることがあります。 換算が出金より前に移る前の FX
Conversionの行は、今も独自のラベルで表示されます。フィルターは便宜上のものであり、ある行のタイプが存在しなかったことの証明ではありません。 - Portal の画面は精算口座を表示します。 Reserve口座自体に記帳された動きは、留保と解放用のタブおよび調整用のタブを持つ別の Reserve Account ページにあります。API エンドポイント
/api/v1/account/history/inquiryは 1 回の呼び出しで両方の口座を返します。精算口座の構造を参照してください。貴社のアカウントに返金Reserveがある場合、それにも独自の履歴タブがあります。
Balance History に FX 換算のエントリが表示されなくなったのはなぜですか？
換算が出金時ではなく、資金が精算口座に届く前に行われるようになったためです。以下の帰結はすべて意図的なものです。
過去の記録と比較している場合、古い行に換算の動きがあり新しい行にない理由はこれです。
Balance History にはどんな列がありますか？エクスポートはどうしますか？
Business Id は Portal の他の部分へ戻る結合キーです。精算バッチ ID は Settlement Batch へ、出金注文 ID は Withdrawal History へ持っていってください。
エクスポートは画面上の表と同じ列を持つため、数値の意味が両者の間で変わることはありません。
デフォルトの期間はどうなっていますか？
いずれの期間も UTC+8 です。さらに過去まで照合する場合は、明示的にフィルターを広げてください。
精算カレンダーが通貨ではなく国で構成されているのはなぜですか？
休日は通貨ではなく国の属性だからです。カレンダーの主たる軸は Country/Region で、貴社の有効な契約がカバーする国を ISO 3166-1 alpha-3 コードで列挙し、最初のものが既定で選択されます。ページ上のすべてがその 1 つの選択に従います。- Regions of Holidays は、選択した国/地域の関連国のみを表示し、独立して変更することはできません。
- 取引日と精算日は、繰り延べを含めてその国/地域についてのみ算出されます。
- エクスポートには選択した国/地域のみが含まれます。
行は期間の最初の取引日、次に最後の取引日で並びます。エクスポートは
settlement_calendar_[Region]_[YYYYMM].xlsx を生成し、選択した国/地域がヘッダー行に記載されます。カレンダーには日付ごとのファイルダウンロードはありません。照合用のレポートは精算バッチに属します。
特定の日が精算日でないのはなぜですか？
その日をクリックしてください。カレンダーは理由を Related Holidays として国名：休日名の形で 1 件ずつ列挙します。その日に休業する関連国ごとに 1 行です。これは単なる「Non-settlement Day」のラベルに代わるもので、どの国がなぜ休業したかが正確に分かります。 表示されるのは確定済みの休日のみです。検証中の候補の休日は精算を繰り延べず、表示もされません。 営業日の計算には、その契約国について貴社の収単契約にあるすべての関連国の休日カレンダーを統合・重複排除したものを使用します。いずれかが休業していれば、その日は精算日になりません。どの国の休日が影響しますか？変更できますか？
2 つのルールが支配します。- 一貫性。 1 つの加盟店と 1 つの契約国について、すべての決済手段が同じ関連国の集合を持つ必要があります。 同じ契約国の中で、ある決済手段は休日に繰り延べ、別の決済手段は繰り延べない、という状態にはなりません。これが統合カレンダーを意味あるものにしています。
- 設定可能性。 どの国の休日を考慮するかは加盟店ごとに設定されます。ある市場と関わりのない加盟店が、その市場の休日に繰り延べる理由はありませんし、精算経路が貴社の販売していない市場を必要とすることもあります。繰り延べが貴社のビジネスと合っていない場合は、アカウントマネージャーに相談してください。固定のルールではなく契約の設定です。
バッチを自社の記録と照合して合わない点がありますか？精算バッチ ID を添えてサポートにお問い合わせください。その ID から精算、そのエントリ、ファイル、元帳の記録をたどれます。