転記レジスターの確認

転記レジスターは、個々のプロジェクトの外にあるテナントレベルのコンソールです。経理・財務担当者は、閲覧を許可されたすべてのプロジェクトと接続にまたがる ERP 転記をここで確認します。ERP 転記履歴がすでにアクセスできる 1 つのプロジェクトに限定されているのに対し、転記レジスターは、多数のプロジェクトと接続の転記を 1 か所で確認する必要があるレビュー担当者のための、プロジェクト横断のビューです。

転記レジスターは、まずレビューのために作られています。2 つの一括アクション（シミュレーション転記のクリアと失敗した転記の再試行）、詳細ドロワーでの単一行の再試行、取消、そして会社間実行全体の一括取消により、グリッドと詳細ドロワーから直接操作できます。AIアシストは転記の検索と理解を助け、推移、系統、コントロール合計、クローズ、エクスポートにより、分析、ソースへのさかのぼり、期間の確定、データの取り出しができます。コラボレーションでは、通知に金額を一切含めることなく、チームでコメント、承認、転記のウォッチを行えます。

コンソールは、フローティングウィンドウの集まりではなく、1 つにドッキングされたワークスペースです。左側のナビゲーションレールから、転記、シミュレーション、例外、承認、委任、集計、推移、コントロール合計、系統、エクスポートとアラート、AIアシストの各画面をその場のペインとして開きます。画面を切り替えるとワークスペース中央の内容が入れ替わり、前の画面の上に別のウィンドウが重なることはありません。転記を開くと、作業中の一覧を隠すことなく、その詳細が右からスライドして表示されます。

1 つにドッキングされたワークスペースです。レールから開いた画面は中央にその場で表示され、転記の詳細は一覧を隠さずに右のドロワーで開きます。

開けるユーザー

転記レジスターを開くには、Keycloak レルムの 4 つのスコープ（erp.register.view、.operate、.approve、.admin）のいずれかが必要です。これらは段階的に上がる階層ではなく、独立した権限です。.admin を持っていても、それだけで .operate の権限が付与されるわけではありません。状態を変更する、または外部へ出力するすべてのアクションは、上位の階層から推測するのではなく、それぞれが必要とするスコープを明示的にチェックします。

スコープ	付与される権限
`erp.register.view`	レジスターを開いて転記を確認します。対象は例外キュー、グリッド、集計ビュー、推移、系統、AIアシストです。これらでは、何かを適用したり、エクスポートしたり、通知したりすることはありません。
`erp.register.operate`	状態を変更する、またはコンソールの外へ出るすべての操作の土台となる権限です。一括アクション、取消の開始、取消の承認リクエスト、承認の受信トレイを開いて自分に権限のあるリクエストを判断すること、委任の確認や返却、エクスポートや配信のスケジュール、AIアシストのダイジェストの購読、コメント・承認・ウォッチの投稿が含まれます。`.approve` と `.admin` で制限されたアクションは、`.operate` の代わりではなく、それに加えて検証されます。詳しくは下記を参照してください。
`erp.register.approve`	テナントの職務分掌しきい値以上の取消に対する承認権限です。このスコープを直接保持するか、保持している人からの有効な委任を通じて行使します。また、停止した取消の試行（`released` または `confirmed`）の解決もできます。その権限を他のユーザーに委任するには、自分自身も `.approve` を保持している必要があります。委任の利用、表示、取り消しには不要です。いずれも `.operate` と併せて保持します。
`erp.register.admin`	監査人向けエクスポートと as-of 読み取りプロファイル（マスクされていない金額と作成者の ID）、およびテナントの保持ポリシーの設定です。いずれも `.operate` と併せて保持します。また、他のメンバーのスケジュールの削除や実行もできます。

便宜上、4 つの組み込みセキュリティグループがこれらを累積的にまとめています。Posting Register Viewer（.view）、Operator（.operate を追加）、Approver（.approve を追加）、Admin（4 つすべて）です。ただし、スコープは互いを含意しないため、セキュリティグループのマトリックスでは任意の組み合わせを個別に割り当てられます。.approve と .admin は、それだけでは意味を持ちません。これらで制限されるすべてのアクションには .operate も必要なため、取消の解決やエクスポートのマスク解除を行うグループには、上位の階層から想定するのではなく、.operate を明示的に併せて付与する必要があります。全員に .view だけを付与するのではなく、メンバーが行う作業に合った階層、または組み合わせを割り当ててください。

可視性のルール

erp.register.* スコープを持っていればコンソールは開けますが、それだけで転記が見えるようになるわけではありません。転記がレジスターに表示されるのは、その転記の接続に対する個人の接続権限があり、かつ転記がプロジェクトに属している場合はそのプロジェクトへのアクセス権もある場合に限られます。プロジェクトに紐付いていない転記は、接続権限のみで制御されます。

これは上記のレジスタースコープとは別の権限であり、両方が必要です。

接続権限。 接続の明示的な所有者であるか、個人として指名されているか、接続に指定されたセキュリティグループのメンバーである必要があります。これは、接続のセキュリティモデルが制御するものと同じ権限です。All Workspace Members に設定された接続では、レジスターの可視性は付与されません。 この設定は接続を全員が使用できるようにするものであり、個人、グループ、所有者のいずれの権限でもありません。レジスターは、そのいずれかを具体的に要求します。
プロジェクトアクセス。 プロジェクトに属する転記の場合に必要です。他のプロジェクト作業に必要なアクセスと同じものです。

erp.register.view を持っていても接続権限が 1 つもないメンバーには、正しく空のレジスターが表示され、コンソールは壊れているように見えるのではなく、その旨を伝えます。取り消された接続権限やプロジェクト権限は、次にページを読み込んだ時点で有効になります。古い可視性が残ることはありません。

ロール別の表示

コンソールはロールに適応します。スコープを持たないレールのエントリやアクションボタンは、グレー表示ではなく非表示になるため、ワークスペースには実際に実行できることだけが表示されます。これはサーバーが強制する内容を反映したものであり、その代わりになるものではありません。

保持するスコープ	表示される内容
`erp.register.view`	レビュー画面（例外キュー、グリッド、集計、推移、系統、コントロール合計、AIアシスト）。
`erp.register.operate`	アクションボタンが加わります。再試行、取消、シミュレーション転記のクリアです。
`erp.register.approve`	承認の受信トレイ、承認の判断、委任が加わります。
`erp.register.admin`	保持設定と、マスクされていない監査人向けエクスポートが加わります。

コントロールを非表示にするのは表示上の処理にすぎません。拒否されるはずの操作を提示しないための配慮です。権限の判断はあくまでサーバーが行います。状態を変更する、または外部へ出力するすべてのアクションは、実行時に、必要なスコープと自分の接続権限・プロジェクト権限を再チェックします。クライアントがボタンを表示したからといって何かが許可されることはなく、クライアントがボタンを隠したからといって実際にブロックされることもありません。

例外キュー

レジスターを開くと、グリッドではなく例外キューが表示されます。対応が必要な可能性が最も高い転記が、4 つのバケットにグループ化され、優先度順に表示されます。

不確定 — 転記は送信されたものの、その結果を確認できるものがまだありません。
未確認 — 送信済みで、確認されるはずの期限を過ぎています。
保留中 — 非同期の転記で、解決されるはずの期限を過ぎています。
失敗 — ERP に拒否されました。

各バケットは、キューの上にカウントタイルとして表示され、リアルタイムの合計が示されます。そのため、何かを開く前に作業の全体像がわかります。タイルを選択するとキューがそのバケットに絞り込まれますが、他のタイルは引き続きそれぞれの合計を表示します。したがって、失敗に切り替えても、不確定の件数が空に見えることはありません。

「経過」は、独自に決めたしきい値ではなくプラットフォーム自身のタイマーを基準に測定されます。そのため、プラットフォーム自身が期限超過と判断するまさにそのときに、転記がバケットに入ります。各バケット内では、最も古い転記が先頭に表示されます。

シミュレーション転記は、キューにもその件数にも表示されません。キューには除外された件数が示されるため、シミュレーションが理由で件数が少ないのに「確認するものがない」と誤解されることはありません。1 つのバケットに絞り込むと表示される行は減りますが、他のバケットの件数は変わりません。したがって、失敗に切り替えても、不確定が空に見えることはありません。

グリッドと同じ可視性のルールがここにも適用されます。表示されるのは、個人として権限が付与された接続に紐付き、アクセスできるプロジェクトにある転記の例外のみです。

未完了の取消

API 経由の例外一覧 GET /erp/register/exceptions は、5 番目のカテゴリである reversal_outstanding も報告します。これは、取消が送信されたものの確定していない転記済みエントリです。ERP から応答がなかったか、ディスパッチの途中で試行が打ち切られた場合が該当します。他の 4 つとは別に独自の件数があり、不確定とともに先頭に並びます。各行には、取消の試行とその状態が示されます。このようなエントリは、取消で説明するとおり解決されるまで一覧に残り、時間の経過では消えません。

接続の正常性

例外キューと集計ビュー（後述）の上にあるバナーは、どちらも単独では答えられない疑問、つまり接続のいずれかがダウンしていないかに答えます。個人として権限が付与されている接続（それらのみ）について、最後に成功した転記と、その接続が現在エラーを起こしているかどうかが表示されます。まだ転記がない権限付与済みの接続は、一覧から省かれずにその旨が表示されます。また、正常性チェック自体を完了できなかった場合も、問題なしと静かに報告するのではなく、その旨がバナーに表示されます。

金額の書式

レジスターに表示されるすべての金額（グリッド、集計、コントロール合計、詳細ドロワー、例外キュー、承認の受信トレイ、AIアシスト、取消ダイアログ）は、会計形式で表示されます。桁区切り、括弧付きの負数、そして金額の列が小数点で揃うように等幅（固定幅）の数字が使われます。小数点以下の桁数は一律 2 桁ではなく通貨ごとに決まり、JPY は 0 桁、KWD は 3 桁で表示されます。

小計が通貨をまたいで合算されることはありません。 複数の通貨を含むグループやバッチは、集計ビューでもコントロール合計でも、通貨ごとに 1 行に分割され、それぞれに通貨が表示されます。プラットフォームのどこでも為替レートは想定されません。
表示のための丸めが、実際の差異を隠すことはありません。 通貨の通常の小数桁に丸めると 0 でない桁が失われる場合、詳細ドロワーには丸めた値とともに、取得された正確な値が表示されます。コントロール合計の数値は、同じ理由で一切丸められません。許容範囲に対して確認される差異はフルの精度のまま保たれるため、0.004 のような許容範囲外の実際の差異が、「不均衡」という判定の横に 0.00 と表示されることはありません。

レジスターグリッド

例外だけでなくすべての転記を表示するには、グリッドに切り替えます。閲覧できるすべてのプロジェクトと接続にまたがる転記が、1 転記につき 1 行で一覧表示されます。グリッドの上部にスコープバーがあり、ここで表示対象を絞り込みます。

プロジェクト
環境
接続
ERP タイプ
エンティティ
転記日
状態
転記モード

独自の ERP タイプフィルターを作成するには、GET /erp/register/erp-types を使用します。閲覧できる転記上のすべての ERP タイプが、並べ替えられて返されます。

スコープバーはピッカーを使用します。識別子を入力するのではなく、閲覧を許可されている範囲に絞り込まれた一覧から、名前でプロジェクト、接続、エンティティを選びます。状態は複数選択のため、複数の状態を同時にウォッチできます。

転記モードは常に表示される 3 つのボタンのスイッチで、数値に何が含まれているかが一目でわかります。本番は ERP に到達した転記のみ、シミュレーションはシミュレートモードの実行による転記のみ、すべて（デフォルト）は両方を表示します。グリッドの転記モード列には、各行がどちらの種類かが表示されます。照合と集計の画面にも、同じ選択肢を持つ独自の転記モードセレクターがあり、デフォルトは本番です。モードが本番でない場合、金額の合計の横の注記に、ERP に到達しなかったシミュレーション転記が含まれていること、またはシミュレーションの場合はどれも ERP に到達していないことが示されます。設定した内容は作業中も画面に表示され続けるため、グリッドに現在何が表示されているのかを推測する必要はありません。

一括アクション

グリッドで複数の転記を選択し、まとめて操作できます。行にチェックを入れて転記を選択するか、現在のフィルターに一致するものをすべて選択を選びます。後者は、すでに読み込まれているものだけでなく、すべてのページにわたってフィルターに一致するすべての転記を対象にします。

次の 2 つのアクションを利用できます。

シミュレーション転記のクリア — 保持しておく必要のなくなったシミュレーション転記の論理削除です。
失敗した転記の再試行 — ERP に拒否された、または一度も送信されなかった転記を再送します。

影響のプレビュー

どちらのアクションも実行される前に、PlaidCloud は影響のプレビューを表示します。影響を受ける転記の件数、関係する金額（通貨ごとに内訳が表示され、金額が通貨をまたいで合算されることはなく、未取得の金額は 0.00 ではなく空欄で表示されます）、そして影響を受ける転記が属する接続とエンティティです。選択内容のうち、アクションが対象にできないものは別に示されます。そのため、「選択した 30 件の転記のうち 24 件では何も起こらない」ことが、実行後に気づくのではなく、確定する前にわかります。

入力による確認

しきい値を超える場合、影響を受ける金額を一字一句違わず入力するまで、適用は無効のままです。

再試行は、チェックしたものに対してのみ実行されます

シミュレーション転記のクリアは、チェックした行、またはフィルターに一致するすべてのいずれの選択に対しても実行できます。一括アクションとしての再試行はできません。個別にチェックした転記に対してのみ実行されます。 フィルター全体の選択には、再試行の対象を限定するための固定された転記のリストがないため、再試行では転記を貼り付け直すよう求められ、貼り付けた内容がプレビューに表示されたものと完全に一致しない場合は処理が拒否されます。転記が同じで、重複がなく、件数も同じであることが条件です。この結び付けによって確認の信頼性が保たれ、確認したバッチがそのまま送信されます。

再試行できるもの

再試行できるのは、ERP に拒否された転記、または一度も送信されなかった転記のみです。処理中のもの、不確定のもの、すでに転記済みのものは、ここから再試行できません。

接続の ERP が対応している場合、PlaidCloud は再試行の前に ERP に直接問い合わせます。ERP がすでにそのドキュメントを転記済みとして保持している場合、再試行は拒否され、代わりに取消が提案されます。ERP がこのチェックに応答できない場合は、リスクを取らずに再試行が拒否されます。推測で進めることはありません。このチェックにまったく対応していない接続もあり、その場合の再試行は、転記自体に記録された拒否情報に基づいて行われます。

再試行には、erp.register.operate と、その転記の接続に対する自分自身の個人の権限が必要です。これは、可視性のルールが転記の表示そのものに要求する接続権限と同じものです。

詳細ドロワーからの再試行

転記の詳細ドロワーには、ウォッチのコントロールの隣に独自の再試行ボタンもあります。これは同じ再試行を 1 行ずつ、グリッドを経由せずに実行するものです。ワンクリックでは実行されません。開くと、一括アクションで使われるものと同じ影響のプレビューが表示され、しきい値を超える場合は同じ入力による確認も求められます。再試行の経路は 1 つだけで、2 か所から入れるようになっています。このボタンは、erp.register.operate を持つメンバーにはすべての行に表示されます。ドロワーは、提示する前にその行が再試行可能かどうかを事前に判断しません。そのため、すでに転記済み、処理中、または ERP がすでに保持しているなど、対象外であることが判明した行は、黙って非表示にされるのではなく、サーバー自身の理由とともにプレビューで拒否されます。

シミュレーション転記のクリア

クリアは論理削除です。PlaidCloud は誰がいつクリアしたかを記録し、適用を有効にする前に理由の入力を求めます。これにより、シミュレーションのプレビューストアと、台帳自身のシミュレーション仕訳から転記が削除されます。本番の転記には一切触れず、本番の転記を対象にする方法もありません。

シミュレーション転記ビュー

シミュレーション転記は、レールからペインとして開き、メイングリッドの中からシミュレーションの行を探させるのではなく、シミュレーションストアにあるものを一覧表示します。接続、プロジェクト、環境、またはシミュレーション実行 ID で絞り込めます。

クリア済みを含めるは、デフォルトではオフです。これはサーバー自身のデフォルトに合わせたものです。クリア済みの行は、クリアの監査記録であるため短期間保持されますが、このビューはその履歴ではなく、ストアにまだ有効なものを表示します。
ここからのクリアも、グリッド上の一括アクションと同じ影響のプレビューを経由します。ワンクリックでクリアされることはなく、対象はビューのフィルターが現在一致しているものに限られます。
ビューのサマリー行には、例外キューに表示されるものと同じ simulated_excluded の数値も表示されます。これは、シミュレーションストアとは別のテーブルである転記台帳にあるシミュレーション転記のうち、ERP に到達しておらず例外になり得ないために、キューから除外されている件数です。

AIアシスト

アシストでは、検索ボックス、プロアクティブカードの行、行ごとのアドバイスパネルが開きます。表示されるすべての数値は、あなた自身の有効な権限に基づいて、レジスター自身が計算したものです。モデルが設定されている場合でも、モデルは説明や下書きを行うだけで、数値や述語を作り出すことはありません。

普通の言葉で質問する

「先週の EMEA 接続で不確定の転記」のような文を入力すると、モデルの呼び出しではなく固定のテーブルによって、レジスター独自のフィルターの語彙に解析されます。解析によって絞り込めるのは、グリッドにすでに表示される行だけで、権限のない行に到達することは決してありません。モデルの役割は、解析内容を 1 文で説明することだけです。一致したフィールドの名前と、その結果のフィルターで見つかる行の件数を示します。

プロアクティブカード

確認する価値のある内容を 7 枚のカードにまとめています。各カードには、あなた自身の権限の範囲でのリアルタイムの件数とサンプル行が表示されます。カードは、クローズ未完了、ほぼ重複、会社間ネットゼロの差異、前回のクローズからの変更、ERP で確認済み、経過と担当者、取消済みです。ワークスペースに LLM 接続が設定されている場合は、数値の横に短い説明文が表示されます。設定されていない場合でも、カードは完全に表示され、説明文がない理由が示されます。カードの未取得の金額は常に空欄で、0.00 になることはありません。これは集計ビューと同じルールです。

行ごとのアドバイス

転記を選ぶと、その状態に応じて 2 種類のアドバイスが表示されます。

取消の下書き（あらゆる転記が対象）— 取消を行った場合にどうなるかを示します。接続のドライバーが取消にそもそも対応しているか、一致させる必要のあるコントロール合計、期間チェックです。下書きのみで、ここから何かが取り消されることはありません。
失敗の方向性（拒否された、または不確定の転記が対象）— 失敗した理由、再試行すべきかソースデータを先に修正すべきか、修正すべきフィールド、そして再試行を押した場合の重複のリスクを示します。ERP 自身のエラーメッセージは自由記述のテキストであるため、直接表示されるのではなく、サーバー側で原因に分類されます。これは、レジスターのその他の部分で自由記述のテキストを除外しているのと同じルールです。

日次ダイジェスト

ダイジェストでは、上記のカードのうちクローズに関連するもの（クローズ未完了、経過と担当者、ほぼ重複、会社間ネットゼロの差異、ERP で確認済み）を絞り込んだものが、今日あなたに送信された場合にどう表示されるかを、オンデマンドでプレビューできます。トグルで購読と購読解除を切り替えます。購読に保存されるのはメンバー ID だけです。そのため、その後に権限を失った場合、古いビューが漏れるのではなく、該当する行が次のダイジェストから単に除外されます。

取消

転記の取消、つまり ERP に新しい反対仕訳のドキュメントを作成する操作は、詳細ドロワーの取消コントロールから、また自動化のために API から直接行えます。

適格性は、転記自体の状態（ERP ドキュメント ID が確認された転記済みエントリのみ取り消せます）、接続のドライバー（Business Central、Oracle Fusion、Acumatica はプログラムによる取消にまったく対応しておらず、試みるとその旨が表示されます）、そしてすでに未完了の取消の試行があるかどうかによって決まります。ドロワーは、取消を開いたときと、送信する直前の両方で適格性を再チェックします。そのため、その間に古くなった行（たとえば別の取消がすでに未完了になった場合）では、失敗が確定している要求を送信するのではなく、ドライバー自身の拒否理由がそのままの言葉で表示されます。
取消には erp.register.operate が必要で、入力による確認が設定されています。取消のロックが解除される前に、転記自身の ERP ドキュメント ID を再入力します。これはブラウザー内でのみチェックされ、送信されることはありません。一括アクションで使われるのと同じ影響範囲のパターンで、承認ステップではなく安全のためのプロンプトです。
取消では、元の転記とは異なる対象期間に新しいエントリを振り向けることもできます。明示的な転記期間を受け付ける ERP のアダプターでは反映され、対象を指定できないものでは明確なエラーで拒否されます。振り向けた先が、要求した期間とは異なる期間になることがあります。 アダプターによっては、ディスパッチの後で初めて、振り向けが反映されたかどうかがわかるため、ドロワーは、試行が実際に取消として確定した後でのみ着地した期間を表示し、それ以前には表示しません。それ以外の結果については、サーバー自身のメッセージに従います。未完了の取消がある間は、プロセスがディスパッチの途中でクラッシュした場合でも、データベースの厳格なラッチによって 2 回目の取消の試行がディスパッチされることはありません。ERP が拒否した場合は何も作成されていないため、ラッチは自動的に解放されます。
取消は、どこから始めても一度に 1 つだけです。 転記レジスターから送信された取消と、ワークフローやプロジェクトレベルの取消 API から送信された取消は、同じラッチを共有します。それぞれがラッチを保持した後で転記を読み直すため、再実行でも同時の 2 つのリクエストでも、転記が 2 回取り消されることはありません。
不明な応答は、推測せずに保留されます。 ERP がタイムアウトした場合、サーバーエラーを返した場合、または PlaidCloud が認識できない形で応答した場合、取消は拒否されるのではなく in_doubt として記録され、ラッチは保持されたままになります。取消仕訳が取消として扱われるのは、元の仕訳と対応している場合に限られます。つまり、同じエンティティと通貨で、日付が元より前でなく、すべての明細の借方と貸方が入れ替わっている場合です。それ以外はすべて不確定のままとなり、確認が必要です。
pending または in_doubt のままの取消（結果が不明なもの）は、解決されるまでそのままです。Workday と Dynamics 365 Finance & Operations では、その転記に対して次に取消が試みられたときに、PlaidCloud が in_doubt の取消を ERP で調べ、見つかった内容に基づいて解決します。これらの接続の pending の取消や、他のすべての接続で未解決の取消は、ドロワーの解決コントロールでクリアします。.operate に加えて erp.register.approve が必要で、担当者が ERP を直接確認して、見つかった内容を記録します。解放（そこには何も作成されておらず、台帳は変更されず、転記は再び取消可能になります）か、取消済みにする（取消仕訳が存在し、その ID を記録します）のいずれかです。これがそのラッチをクリアする唯一の方法です。取消を confirmed にすると、それは恒久的で、製品から元に戻す方法はありません。

職務分掌

テナントに設定されたしきい値以上の取消は、進める前に承認が必要です。承認は承認者が行うものであり、提出者がリクエストで指定する名前ではありません。

作成者≠承認者。 取消を提出したメンバーが、その承認者になることはできません。また、自分自身のブレークグラスの承認者になることもできません。
金額の大きさで測定されます。 しきい値は、符号に関係なく取消の大きさを比較します。貸方の取消も借方の取消と同じように測定されます。
最近の取消もしきい値に算入されます。 ローリングウィンドウが、同じ接続における提出者自身の取消を合計するため、大きな取消を複数の小さな取消に分割してしきい値を回避することはできません。金額は相殺されるのではなく、大きさで合算されます。負の取消と正の取消が打ち消し合うことはありません。
フェイルクローズ。 ウィンドウ内の以前の取消を検証できない場合（たとえば金額や通貨が未取得の場合）、チェックを省略するのではなく、その取消には承認が必要になります。
承認者は資格を満たしている必要があります。 erp.register.approve（またはそれを保持する人からの有効な委任）と、取り消す接続に対する自分自身の権限が必要です。その両方を持つメンバーが 2 人未満の場合、しきい値以上の取消は通されずに拒否されます。
ブレークグラスは、提出者が上書きを承認した人を直接指名できる唯一の経路です。運用上の指揮系統から独立した承認者によって決定される、真の緊急事態に限られます。承認者は erp.register.admin を保持し、.operate と .approve は保持しておらず、さらに接続に対する自分自身の権限が必要です。すべての上書きは、監査証跡に恒久的に記録されます。
拒否の理由は示されません。 資格を満たす承認者がいない場合、誤った人が判断した場合、リクエストが一度も開かれなかった場合のいずれでも、取消は同じメッセージで拒否されます。これは意図的なもので、拒否を利用して、誰がどのロールや権限を持っているかを探られないようにするためです。実際の理由は、エラーではなく監査証跡に残ります。
実行の取消には、実行全体で 1 つではなく、レグごとに 1 つの承認が必要です。 会社間実行全体を一度に取り消す場合でも、実行レベルの単一の承認は得られません。承認は 1 つの転記、1 つの接続、そしてそこに権限を持つ 1 人の承認者に結び付けられているため、実行全体のレグをまとめて結び付けられる 1 つの名前がないことから、すべてのレグがそれぞれ独自の承認を必要とします。
取消はレジスターを経由します。 職務分掌が有効な間、プロジェクトレベルの ERP 取消 API（プロジェクト、ユーザー定義関数、サービスアカウントが使用する経路）を通じてリクエストされた取消は、ERP に何かが到達する前に拒否され、代わりに転記レジスターから取り消すようメッセージが表示されます。レジスターに取得詳細がないエントリも、そこから取り消すことはできず、ERP で訂正する必要があります。転記には影響せず、Business Central、Oracle Fusion、Acumatica は引き続き、取消に対応していないという独自の理由を返します。

職務分掌の有効化とそのしきい値の設定は、PlaidCloud がテナントに対して行います。コンソールには、まだそのためのトグルはありません。

承認の受信トレイ

しきい値によって必要とされる場合、詳細ドロワーで取消と並んで表示される承認をリクエストが、その接続に対して有効な個人の権限を持つすべての承認者に取消を回します。宛先を指定する必要はなく、接続権限そのものがルーティングです。承認者は、レールの承認からキューを処理します。自分の判断を待っているリクエストの受信トレイと、自分が提出したリクエストを表示する 2 つ目のキューがあります。各行には、転記の金額、エンティティ、期間、待機している時間が表示されるため、判断のために何かを調べにキューを離れる必要はありません。承認または却下には 1 つの理由を指定し、判断とともに記録されます。

承認は、付与された内容、つまり転記、その接続、記載された理由、対象期間にそのまま結び付けられ、別の取消、別の理由、変更された対象期間には再利用できません。リクエストが変更された場合は、新たな承認が必要です。1 つの転記に対して同時に開けるリクエストは 1 つだけで、承認は使用された時点で消費されます。承認のたびに短い保留期間があり、その間は承認者または提出者のどちらでも取り消せます。保留期間が過ぎると、取消はすでに ERP のドキュメントになっている可能性があり、それを元に戻す方法はありません。取消が実際に適用される時点で、すべてが再度チェックされます。承認者のロール、双方の接続へのアクセス、テナントの 2 人承認の最小要件です。したがって、先に付与された承認が、その間に承認者がアクセスを失った場合にまで有効であり続けることはありません。

委任

承認者は、レールの委任ペインから、期間を限って他のメンバーに承認権限を委任できます。承認者が不在になっても取消の判断が必要な場合に便利です。委任を付与するには erp.register.approve が必要です。委任の利用、自分宛ての確認、返却には .operate だけで済みます。一般的な委任先は承認者のロールをまったく持っておらず、それが委任の目的だからです。

自己委任は拒否されます。また、相互のペア（すでに自分に委任している相手に委任すること）や、それより長い連鎖も同様に拒否され、いずれも認められません。これにより、2 人のメンバーが、直接または中間の人物を通じて、互いの判断を双方をカバーするものとして密かに有効にすることはできません。委任を通じても、作成者≠承認者は引き続き適用されます。委任された人は、自分に委任した人からのリクエストを承認できず、どちらの場合も自分自身のリクエストを承認できません。委任された人が行うすべての判断は、そのロールを直接保持しているかのようにではなく、委任元の承認者の権限の下で行われたものとして、監査証跡に記録されます。

エスカレーション

判断されないまま長時間放置された承認はアラートを発し、誰も見ていないキューの中で静かに経過することがないようにします。各受信者に通知されるのは、自分自身が実際に判断できるリクエストのみです。同僚へのエスカレーションメールに、他の人の権限にルーティングされたリクエストが記載されることはありません。また、アラートには金額も自由記述のテキストも含まれません。これは、レジスターの他の通知にも適用される最小化と同じです。

会社間実行

会社間実行とは、1 回のクローズのためにまとめて行われた転記のグループで、各転記がそのレグです。その時点で転記に付けられたクローズ日とシーケンスによって識別され、転記を生成したワークフロー実行によって識別されることはありません（そのワークフロー実行 ID は台帳自身の履歴に別個に残り、転記のクローズスタンプより長く残ることがあるため、実行の識別には安全ではありません）。実行を一覧表示し、1 つを開いてそのレグの突合と照合を確認し、実行全体を 1 つの統制されたアクションとして取り消せます。

現時点では API 経由でのみ利用できます。GET /erp/register/runs、GET /erp/register/runs/{run_day}/{sequence}、POST /erp/register/runs/{run_day}/{sequence}/reverse です。コンソール画面はまだありません。

ネットゼロと照合

実行を開くと、そのレグが 2 つの方法で突合されます。どちらも、個人として権限が付与されている接続に限定されます。これはレジスターの他の場所と同じ可視性のルールであり、部分的にしか見えない接続にまたがる実行は、不均衡ではなく、部分的に表示されているものとして報告されます。

ネットゼロ（通貨ごと）— 均衡、不均衡、判定不能のいずれかの判定が、それぞれのネットの元になったエンティティの内訳とともに示されます。通貨内のすべてのレグが取得されていない限り、その通貨は突合されません。未取得のレグが 1 つでもあれば、通貨全体が判定不能になり、たまたま測定できたものだけでネットが計算されることはありません。
照合— 各買掛金のレグを、対応する売掛金のレグと、どちらかが送信される前に転記ワークフローが両方に付与した照合キーで一致させます。一致したペアは、1 つの通貨でネットゼロになります。それ以外はすべて、理由が示されます。自分に見える相手側のレグがない、金額が未取得である、ネットが実際にゼロでない、またはクロスカレンシーです。クロスカレンシーはプラットフォームのどこにも為替レートがないため、報告されるだけで突合されることはありません。

200 レグを超える実行は大きすぎて、1 回のレスポンスで突合や照合ができません。どちらも、実行の一部を切り詰めて計算するのではなく判定不能で返されます。そのため、大きな実行が、そのサイズだけが原因で誤った均衡や誤った相手側レグの欠落を報告することはありません。

実行の取消

POST /erp/register/runs/{run_day}/{sequence}/reverse から、実行のすべてのレグを 1 回のアクションで取り消します。

適格性は、すべてのレグについて事前にチェックされます。 状態、アダプターの対応、未完了の試行、自分の接続権限など、事前にわかることがあれば、ERP に 1 件もリクエストが届く前に実行全体が拒否されます。
事前にわからないことは、レグごとに後から報告されます。 稼働中の ERP や認可の状態は実行中に変わることがあるため、事前チェックの時点では問題がなさそうでも、実行が部分的に取り消された状態で終了することがあります。自動的な補正は行われません。部分的な失敗を元に戻すために追加のドキュメントを転記するのは、失敗した書き込みよりもリスクの高い書き込みだからです。部分的な実行は、単一の取消と同じように、レグごとに対処します。
実行の取消を再実行することで、部分的なものを完了させます。 前回の試行ですでに取り消されたレグは、拒否されるのではなく除外されるため、再試行では実際にまだ残っているものだけが取り消されます。
職務分掌は、実行の合計ではなくレグごとに適用されます。 テナントの SoD ポリシーが適用されている場合、実行が何かをディスパッチする前に、すべてのレグがそれぞれ独自の承認を必要とします。しきい値を超える場合だけでなく、どの金額でも同様です。これは意図的に保守的にしています。レグ自身の要件は、ディスパッチされる瞬間にしか決まりません。実行自身のレグが取り消されるのに合わせて数える、ローリングの分割回避ウィンドウと、失敗し得る稼働中の ERP からの読み戻しがあるためです。すべての承認を事前に求めることで、残りのレグにも承認が必要だと途中で判明する前に、実行がレグの半分を取り消してしまうことを防ぎます。
一括アクションは、1 回の呼び出しで実行全体を対象にします。 POST /erp/register/runs/{run_day}/{sequence}/approval-requests は、提出者が操作できるすべてのレグに対して承認リクエストを開き、POST .../approval-decisions は、承認者が資格を持つすべてのレグを判断します。レグごとにリクエストと判断を行う代わりに、それぞれ 1 回の呼び出しで済みます（通常の 10 レグの実行なら 20 回の呼び出しです）。基盤となるセキュリティモデルは変わりません。各レグには引き続き、その転記、接続、理由、対象期間に結び付けられた独自の承認が付き、承認者には各レグの接続への自分自身のアクセス権が引き続き必要です。承認者が承認できないレグは、巻き込まれることなく、承認できる人を待って保留のままになります。承認権限をまったく持たない呼び出し元は、どのレグにリクエストが開かれているかを知らされることなく、即座に拒否されます。結果はレグごとに返されるため、一部しか承認できない実行でも、どのレグが判断されどのレグが保留のままか、またその理由が正確に報告されます。
実行の取消では、ブレークグラスは使用できません。 これは 1 つの転記に対する 2 人体制の上書きであり、1 人の立会人の承認を実行全体に適用すると、実行のレグ数だけ倍になってしまうためです。ブレークグラスは、代わりに POST /entries/{ledger_id}/reverse からレグごとに行ってください。
200 レグを超える実行は、1 回のアクションでは取り消せません。 代わりにエントリ一覧から、分割して取り消してください。

推移

推移には、接続または ERP タイプ別にグループ化された失敗率とレイテンシー、および取消理由コードの分布が表示されます。すべての数値は、分母を含めて、あなた自身の有効な権限に基づいて計算されます。期間内に最終状態のものがない接続の失敗率は、0% ではなくエムダッシュで表示されます。完全なゼロと表示すると、誰も使っていない接続が正常性リストの最上位に来てしまうためです。レイテンシーは、直近の最終状態の転記に対する限定的なサンプルであり、期間全体をカバーしているかのように表示されるのではなく、サンプルとして明示されます。取消理由は構造化されたコードとしてのみ表示され、人が入力した自由記述の理由がここでバケット分けされたり表示されたりすることはありません。

系統

系統では、1 つの転記から、それを生成したワークフロー実行、さらに ERP 内のドキュメントそのものまでさかのぼれます。実行 ID または転記の台帳 ID で検索できます。台帳 ID で検索すると、まずあなた自身の権限を通して実行が解決されるため、見えない接続上の転記は、どの実行から来たかを明かすことなく、何も解決されません。PlaidCloud がそのアダプターについて ERP のドキュメント URL の形式を検証できる場合、系統にはドキュメントへの直接のディープリンクが含まれます。検証できない場合や、転記が一度も確認されなかった場合は、リンクを推測するのではなく、そのどちらが理由かが示されます。ERP のビジネスキーは、ここにも一切表示されません。系統のキーはワークフローの run_id で、ERP へのポインターはレジスターの他の場所と同じく confirmation_id です。

クローズ

クローズをリクエストすると、期間を、1 つ以上の接続とエンティティについて、変更不可の特定時点のスナップショットに確定します。その時点でレジスターが把握していた、それらの転記に関するすべての情報であり、ライブの行があとで再試行、取消、クリアされても保持されます。ロックされた会計期間において、今日のライブグリッドの表示ではなく、根拠があって変わらない記録が必要な場合を想定しています。クローズのリクエストと読み取りは現時点では API 経由でのみ可能で、リクエストや閲覧のためのコンソール画面はまだありません。

クローズのリクエスト（erp.register.operate）は、個人的なものではなくテナント全体の管理アクションです。指定した接続とエンティティが、あなた自身の接続権限に関係なく、そのまま確定されます。すでにクローズされた期間を再度クローズしても破壊的ではなく、前の結果を上書きせずに、常に新しい別番号のリビジョンが作成されます。

クローズは自動的に具体化されます。 クローズをリクエストしても、すぐには確定されません。バックグラウンドジョブが毎日のスケジュールで保留中のすべてのクローズを自動的に処理し、それ以上の操作なしに Iceberg スナップショットを書き込みます。特定のクローズについて処理を完了できなかった場合（たとえばウェアハウスの障害）、そのクローズは停止したままになるのではなく失敗とマークされ、翌日の処理で自動的に取り上げられて再試行されます。黙ってスキップされることはありません。例外は、非常に大きなクローズ（約 50 万件を超える転記にまたがるもの）で、この方法では自然に解決しません。処理は 1 回の実行での確定を拒否し、より小さなバッチでクローズするには PlaidCloud の支援が必要です。ほとんどの報告期間では、まれなエッジケースです。

クローズが具体化されたら、読み戻す際にレジスターの通常のルールが適用されます。これらは確定時にスナップショットに組み込まれるのではなく、読み取りのたびにリアルタイムで再解決されます。表示されるのは、現在権限が付与されている接続とプロジェクトの行のみです。行が見える閲覧者なら誰にでも金額と作成者の ID が表示されるライブグリッドとは異なり、クローズの数値は erp.register.admin を保持していない限りマスクされます。これはエクスポートに適用されるルールと同じです。また、クローズ自身の後着件数も報告されます。これは、クローズの高水位マークの後に送信または変更されたため、確定に含まれなかった転記の件数です。古いクローズを再オープンするものはないため、同じ期間に対して新たにクローズをリクエストしない限り確認できません。

エクスポート

エクスポートとアラートは、レジスターがファイルまたは通知としてコンソールの外へ出る場所であり、バイトがコンソールを離れた瞬間に PlaidCloud の制御が及ばなくなる唯一の画面です。エクスポートの作成や配信のスケジュールには erp.register.operate が必要です。レジスターを開いて見るだけであれば不要です。

今すぐダウンロード

現在表示しているレジスターを、Excel 向けの CSV または JSON としてエクスポートします。あなた自身の有効な権限に基づいて、その都度新たに作成されます。ロールに応じて、2 つのマスキングプロファイルが適用されます。

erp.register.operate には、標準のマスクされたプロファイルが適用されます。金額と作成者の ID は含まれません。
erp.register.admin には、監査人向けプロファイルが適用されます。金額と作成者の ID をマスクせずに含む唯一のプロファイルです。

すべてのエクスポートは、レジスターの他の部分と同じルールに従います。natural_key は表示されず、自由記述のフィールド（コメント、ディメンション値、ワークタグ値）は単にスクラブされるのではなく完全に除外され、未取得の金額は空欄になります。マスクされた金額とは区別されるため、空欄が実際には「あなたのロールではこれが見えない」を意味しているのに、「何も転記されなかった」と読まれることはありません。

配信のスケジュール

スケジュールを作成します。フィルター、頻度、形式、メンバーまたは行の内容を一切含まない通知のための Slack 接続による受信者のリストで構成されます。2 つの種類があります。

エクスポート — フィルターされたレジスターの定期的な CSV または JSON の配信。
アラート — 3 つの条件のいずれかによってトリガーされる通知です。失敗した本番の転記、経過した承認、転記の取消です。購読する前に、トリガーが現在あなたに対して何に一致するかをプレビューできます。

各受信者のファイルは、スケジュールの所有者ではなくその受信者自身の有効な権限に基づいて、送信の時点で作成されます。同じスケジュールの 2 人の受信者が、異なる 2 つのファイルを受け取ることもあります。エクスポートのロールを失った、すべての接続権限を失った、無効化された、またはアドレスが登録されていない受信者は、黙って除外されるのではなく、理由が示されたうえで個別にスキップされます。他の人のスケジュールを削除または実行できるのは、スケジュールの所有者か erp.register.admin のみです。

保持

レジスターが 3 種類の履歴をどれだけの期間保持するかを設定します。取得されたペイロードの詳細、シミュレーション転記、監査証跡です。それぞれ日数で指定し、テナント全体に適用され、erp.register.admin が必要です。すべてのフィールドは呼び出しのたびに書き込まれます。省略したフィールドは、変更されずに残るのではなく、その期限がクリアされます。未設定のテナントはすべてを保持します（すべての期限は、隠れたデフォルトではなく null と読み取られます）。

このポリシーに基づいて動作する保持の処理は、現在、1 日に 1 回、テナント全体で自動的に実行されます。これは、スケジュール済みのエクスポートとアラートを動かし、期限超過の転記を例外キューに移し、古いシミュレーション転記を期限切れにするのと同じ定期ジョブの仕組みです。

集計ビュー

集計は、レールからペインとして開きます。レジスターを実行、期間、または接続でグループ化すると、個々の行ではなく、小計とステータスの集計が表示されます。グループ化はペインの上部にあるセグメントコントロールで行うため、何かを開き直すことなく、実行別、期間別、接続別をその場で切り替えられます。

空欄の金額は空欄のままです。 取得された金額のない転記（すべての SAP 転記、生まれつき最終状態の転記、またはこの機能が存在する前に書き込まれた転記）は、小計に何も加算されず、0.00 として表示されることもありません。各グループには、その中のすべての転記が取得されたか、一部が取得されなかったか、まったく取得されなかったかが、言葉で示されます。
通貨が 1 つの合計に混ぜられることはありません。 PlaidCloud は外国為替の換算を行わないため、複数の通貨にまたがるグループは、1 つに混合された数値ではなく、通貨ごとに 1 行になります。金額の書式を参照してください。
上限のあるグループ一覧でも、合計は正しく計算されます。 グループ化の結果がビューの表示数を超えるグループを生成した場合でも、合計行は表示されているグループだけでなくすべてのグループを対象にし、その旨が示されます。

接続の正常性バナーは、このビューにも表示されます。

コントロール合計

コントロール合計は、レールからペインとして開きます。対象は、可視性のルールですでにあなたに限定されている接続とエンティティです。転記をバッチにグループ化し、それぞれについて 3 値の判定、つまり均衡、不均衡、判定不能を、単なる一語ではなくサーバー自身が示す理由とともに表示します。

判定不能は本物の答えであり、ソフトな合格ではありません。 バッチが均衡と判定されるのは、その中のすべての行が測定され、グループが一致する場合に限られます。空のウィンドウ、未取得の金額、送りっぱなしのアダプター、バッチ全体が読み込まれる前に打ち切られたスキャンはすべて、理由が明記されたうえで判定不能として返されます。デフォルトで緑になることは決してありません。
金額は、ゼロではなく空欄です。 グループのソースと転記の合計、およびその差異は、金額が取得または確認されていないときは空欄になります。これは集計ビューと同じルールです。捏造された 0.00 は、測定されていないバッチを過小評価しながら、信頼できる数値であるかのように見えてしまうためです。
グループは通貨とエンティティごとで、合算されることはありません。 PlaidCloud は外国為替の換算を行わないため、複数の通貨またはエンティティにまたがるバッチは、それらを混合せずに、各グループ自身の合計を並べて表示します。これらの数値の表示方法については、金額の書式を参照してください。
取得より前の行は、独自の (no batch id) バケットになります。 バッチの取得が存在する前に書き込まれた転記は、そのバッチに含まれていなかったものに再グループ化することはできないため、統合されたり除外されたりせず、独立した行として表示されます。

同じ読み取りでは、関連する 2 つの質問にも答えます。1 つは、エンティティと期間ごとの期間締めの準備状況です。カットオーバーのクローズ時の取得前の行のように、プラットフォームにまだ数値がないバケットについては、誤ったブロックではなく判定不能に下げられます。もう 1 つは確認ドリフトで、グループごとではなくドキュメントごとに報告されます。同じ通貨とエンティティのグループ内で、2 つのドキュメントが逆方向にずれていると、合計では一致してしまい、両方が隠れる可能性があるためです。

詳細ドロワー

詳細ドロワーはワークスペースの右にドッキングされるため、1 つの転記を読んでいる間も一覧が見えたままになります。行の虫めがねアイコンから開くか、選択した行で Enter を押すか、行をダブルクリックします。次のタブで構成されています。

タブ	表示内容
仕訳	転記の借方と貸方の明細を、会計担当者の見方で表示します。仕訳タブを参照してください。
リクエスト/レスポンス	送信したリクエストと ERP のレスポンスを、データ最小化のためにフィルターしたもの（下記を参照）。
エラー	ERP または転記ステップが返したエラー。
タイムライン	送信から現在の状態までの、転記の状態を順番に表示します。
関連	元の転記とその取消が存在する場合に、相互にリンクして表示します。
監査	この転記に対するアクティビティの読み取り専用の記録です。現時点では内容が少なめです。下記の監査タブを参照してください。
コメント	この転記に対するスレッド形式のコメントで、メンバー ID による @メンションができます。コラボレーションを参照してください。
承認	転記の現在のレビューステータス（レビュー済み、クリア済み、フォローアップが必要）と、その全履歴です。コラボレーションを参照してください。

仕訳タブ

仕訳タブでは、生のリクエストペイロードではなく、勘定科目ごとの借方と貸方の明細として、会計担当者の見方で 1 つの転記を読めます。

各 ERP が実際に取得する列のみ表示されます。 タブには、特定のシステムが送信するフィールドだけが表示され、それ以外は表示されません。Acumatica の転記ではサブ勘定が表示されますが、サブ勘定を一切送信しないシステムでは、空のサブ勘定列は表示されません。何も入ることのない列を読み飛ばす必要はありません。
ディメンションとワークタグは、各明細の下に表示されます。 明細の分析詳細（ディメンション、または Workday のワークタグ）は、上部に追加の列として詰め込まれるのではなく、それが属する明細の下に表示されます。
通貨ごとの集計と、正確な貸借チェック。 各通貨は個別に集計されます。このチェックは通貨を混合せず、貸借の合わない転記をゼロに丸めることもないため、実際の不均衡は 0.00 に消えることなく、そのままの数値として表示されます。
明細の詳細を取得しないアダプターは、その旨を表示します。 オンプレミスの SAP のように、明細ごとの内訳を記録しないドライバーの場合、「明細なし」と読み違えかねない空のグリッドを表示するのではなく、タブにその旨が明記されます。

キーボードトリアージ

例外キューでは、上下の矢印キーで転記から転記へ移動し、詳細ドロワーが選択に追従します。マウスに手を伸ばすことなく、各転記の詳細を順に読みながら、トリアージの全工程をキーボードで進められます。

メイングリッドでは、意図的にマウスによる選択、Enter、ダブルクリックが維持されています。複数行の選択が、再試行やシミュレーション転記のクリアなどの一括アクションを動かすため、ここでの矢印キーは、ドロワーをすべての行にわたって動かすのではなく、選択を移動させます。

コラボレーション

レジスターを離れることなく、チームで転記に取り組めます。@メンション付きで転記にコメントする、承認を記録する、または今後のアクティビティについて接続や実行をウォッチします。

コメントは、1 つの転記に対するスレッド形式のプレーンテキストのメモで、そのコメントタブから投稿します。メンバー ID で同僚を @メンションすると、その人が現在その転記を見られる場合に通知されます。この確認は送信時にやり直され、メンションされた人から想定されることはありません。
承認は、レビュー済み、クリア済み、フォローアップが必要の 3 つの状態のいずれかを、任意のメモとともに記録し、誰がいつ何を設定したかの全履歴を保持します。これは記録であり、ゲートではありません。現在、承認の状態を理由に転記や取消がブロックされることはありません。
接続または実行をウォッチ（2 つの別々のトグル）すると、今後それぞれで発生するアクティビティが通知されます。

コメント、承認、ウォッチの投稿には erp.register.view と .operate が必要です。それらの読み取りには .view だけで足ります。

データ最小化

レジスターは、転記が行われたことをレビュー担当者が確認するために必要なものを表示しつつ、転記ステップが処理した機密データを表に出さないように作られています。

リクエストとレスポンスのペイロードは、アダプターごとに許可リスト方式です。 フィールドが表示されるのは、保持しても安全であると明示的に分類されている場合に限られます。銀行口座番号、ルーティング番号、IBAN、納税者番号、その他の個人識別子は、ペイロードが表示される前に削除されます。
ERP のビジネスキーは完全に伏せられます。 仕入先名やその他の参照トークンが含まれている可能性があるため、AIアシストを含め、レジスターには一切届きません。表示内容を決定するのと同じ許可リストが、モデルのプロンプトに見せてよいものも決定し、そのペイロード内のどこかにある自然キーの値は、送信されずに完全に拒否されます。行は台帳 ID で識別し、ERP 自身のドキュメントへのポインターとして confirmation_id を使用してください。これは ERP 転記履歴が confirmation_id と呼ぶものと同じフィールドです。
自由記述のフィールドは、読み取り時にパターンスクラブされ、ダイジェスト、AI モデルのプロンプト、エクスポートからは、単にスクラブされるのではなく完全に除外されます。パターンスクラブは IBAN や納税者番号のような形式を捕捉できますが、メモに入力された仕入先名は捕捉できません。そのため、ファイルとしてコンソールを離れるものは、スクラブだけに頼らず、それらのフィールドを完全に削除します。

監査タブ

監査タブは表示専用です。基盤となる監査用語がまだ分類されていないため、このリリースでは詳細は意図的に最小限になっています。ドロワーの他の部分の読み方が変わるのではなく、その作業が完了するにつれて充実していくことが見込まれます。

このページの他のすべて（例外キュー、接続の正常性、集計ビュー、一括アクション、単一行の再試行、取消、コントロール合計、AIアシスト、推移、系統、クローズ、コラボレーション、エクスポート）は、現在動作しています。