月初二営業日目の朝、情報システム部門から一報が入る。昨夜のバッチが落ちていました、再実行しますか。経理課長は答えられない。再実行してよいのか、してはいけないのか、その場で判断する材料がないからである。 結局その日は情シスと担当者が調べて回り、夕方に「再実行して問題ないと思われる」という結論になる。締めは一日遅れる。翌月も同じ会話をする。この朝に必要なのは技術の答えではない。会計としてどこまで戻してよいかの答えである。そして、それを持っているのは経理しかいない。
「落ちた」の中身は、四つに分かれる
朝の一報を受けたら、最初にやるのは原因分析ではない。状態の切り分けである。 四つに分かれる。
第一に、起動していない。ジョブが Scheduled のまま、あるいは Released で開始条件が満たされていない。前段のイベントが発生しなかった、カレンダーの設定が変わった、リリース権限のないユーザーが登録した。SAPのトラブルシュートの記述では、リリース権限がない場合、ジョブは開始条件を持ったまま Scheduled にとどまる。転記は一件も発生していないので、朝の判断は「今から流してよいか」だけになる。
第二に、起動待ちで滞留している。Ready は開始条件を満たしたうえで空きの作業プロセスを待つ状態で、夜間の他ジョブが作業プロセスを占有していれば順番が来ないまま朝を迎える。技術的には正常だが、締め日程から見れば失敗と同じである。 判断は、日中に流すか、当日の他処理を止めて先に流すかになる。
第三に、途中で異常終了している。Canceled である。ここが最も注意を要する。ジョブが途中で終わったからといって、転記がゼロだとは限らない。 ジョブステップの途中まで正常に転記され、そこから先で落ちている可能性がある。したがって朝にまず確認するのは、原因ではなく どこまで転記されたか である。この確認を飛ばして再実行すると、二重転記になる。
第四に、正常終了しているが結果が誤っている。Finished である。ジョブを構成するすべてのステップが正常に完了しているので、監視画面は正常を返す。ジョブ監視は、金額の妥当性を見ていない。 マスタの設定漏れで一部の対象が拾われなかった、レートが更新されていなかった、前段の処理が空振りしていた。四つのうち、締めを最も大きく壊すのはこれである。 そして、監視の仕組みでは検知できない。検知できるのは、前月比較や残高推移を見る経理だけである。
再実行の可否は、処理の種類ごとに違う
三つの代表的な月次バッチについて、戻し方が三様であることを押さえておく。この違いを知らないまま「再実行しますか」に答えることはできない。
償却転記実行は、比較的戻しやすい。SAPの説明では、繰返し実行（Repeat）は既に実行済みの期間について追加の転記実行を行うためのもので、最初の実行と繰返し実行の差額のみを転記する。再開（Restart）は、何らかの理由で失敗した償却実行をやり直すためのものである。加えて SAP S/4HANA では、最終実行期間より前の期間について償却転記実行を再度実行できるようになっている。SAPの例示では、当期に期005まで実行済みの状態で期003の償却転記実行を繰り返すことが可能とされる。従来はこれが制限されていた。ただし更新実行はバックグラウンドジョブでしか起動できず、朝に画面から即座に回すことはできない。
外貨評価は、性格が違う。SAPの説明によれば、評価実行は 評価エリアごとに特定のキー日付について一度しか実行できない。同じキー日付でやり直すには、評価実行をリセットし、転記を反対仕訳で戻したうえで、同じキー日付に対して評価プログラムを再度実行する必要がある。なお、評価によって転記された為替差損益は、指定した反対転記日付または反対転記期間に、評価実行の後で反対仕訳により自動的に戻される仕組みになっている。翌期首に自動で戻る設計を前提に組んでいる会社では、朝の手戻しと、この自動の反対転記が二重に効かないかを確認する必要がある。 実務では、トランザクション FAGL_FCV（旧 FAGL_FC_VAL）の後続処理として、この反対転記文書が完全でない、あるいは存在しないという事象がSAPのサポート文書で扱われている。評価の失敗は、評価そのものより反対転記の側で顕在化しやすい。
配賦は、実行単位で取り消す。SAPのS/4HANAでは、リバーサル実行は Allocation Results アプリで行い、実行全体を取り消すか、特定の会計年度期間の特定の配賦サイクルだけを取り消すか を選べる。前者は Run ビュー、後者は Cycle ビューである。ここで注意が要るのは、配賦が連鎖している場合と、累計処理を使っている場合である。累計オプションを設定した新総勘定元帳の配賦サイクルは、SAPのサポート文書によれば、期0から指定した期間までを読み取る。単純に当月分だけを差し引く動きにはならない。 前月の配賦を取り消して流し直す判断は、当月以降の配賦にも影響する。
なお、新総勘定元帳の配賦の実行はトランザクション FAGLGA15（実際配賦の実行）、配賦サイクルの作成・変更・照会・削除・概要が FAGLGA11・12・13・14・16、実際賦課の系列が FAGLGA31〜36 である。SAP S/4HANA Cloud Public Edition では、これらのアプリは 2408 の時点で非推奨（deprecated）とされ、Manage Allocations（FINS_ONEALLOC_AC） に集約される方向にある。移行の時期に、朝の手順書が古いトランザクションのまま残っていることは多い。
依存関係には二種類あると、SAPの製品設計が言っている
朝の判断が長引く最大の理由は、後続処理をどうするかが決められないことである。ここについて、SAPの決算タスク管理の設計そのものが答えの形を示している。
SAP Advanced Financial Closing は、タスク間の依存関係を 二種類 に分けている。プロセス関連依存（Process-Related Dependency） と タイム関連依存（Time-Related Dependency） である。SAPの説明によれば、タイム関連依存は 「あるタスクの結果が、後続タスクの開始前に必要とされないこと」 を意味する。順序としては前後するが、前のタスクの出力を後続が使わない関係である。
この違いは、失敗時の挙動に直結する。後続タスクの無効化について、SAPは条件を明示している。タスクが無効化されるのは、Advanced Financial Closing の一般設定で後続タスクの無効化が有効化されており、当該タスクが In Process 又はそれ以降のステータス に達しており、かつ影響を受けたタスクと プロセス関連依存のみ で接続されている場合である。そして、タイム関連依存のみで接続されたタスク列は無効化されない。
朝の判断表に写すべきなのは、この二分法そのものである。 夜間バッチの一本が落ちたとき、後続の処理をすべて止めるのが安全に見える。しかし実際には、結果を使わない後続まで止めているために、リカバリに使える時間を自分で削っていることが多い。前工程の結果を使う後続だけを止め、使わない後続は走らせる。 そのためには、ジョブごとに「後続は自分の結果を使うか」を事前に書いておく必要がある。落ちた朝に調べていては間に合わない。
承認の扱いも同じ設計になっている。承認タイプに Completed Approval Required が選択されている場合、依存タイプがタイム関連依存であっても、後続タスクは前タスクの完了と承認を待つ。依存の種類と承認の要否は別の軸である。 そして Advanced Financial Closing では、タスクに タスクステータスと承認ステータスの二つ が付与される。タスクステータスには Completed with Errors があり、エラーを含んだまま完了とする状態が明示的に用意されている。「終わったか」と「承認されたか」と「正しく終わったか」を、一つの欄で管理しない。
なお、決算タスクを一覧で管理する仕組みとしては Financial Closing cockpit が先にあり、トランザクションは CLOCO（実行）、CLOCOC（テンプレートとタスクリストの管理）、CLOCOT（タスクリストの作成）である。ただし提供の形は動いている。SAPの案内によれば、SAP S/4HANA Cloud Public Edition の 2502 リリース以降、advanced financial closing は SAP Business Technology Platform 上でホストされる SAP Advanced Financial Closing のみでカバーされることとなり、Cloud 側に置かれていた関連アプリは削除されている。
締め日程への影響は、転記期間の開閉で決まる
朝の三つ目の判断が締め日程で、ここで効いてくるのが転記期間の管理である。
リカバリの結果、当該期間への転記が翌日以降にずれ込む場合、転記期間を開けたままにするか、いったん閉じて後で開け直すか を決める必要がある。転記期間のオープン・クローズはトランザクション OB52 で転記期間変動別に設定するが、SAPのサポート文書によれば、レポート RFOB5200 を使うことで転記期間変動・勘定タイプ・勘定・レコードタイプ等を指定して、変更または締めをバックグラウンドで一括設定できる。OB52 の機能はこのプログラムの影響を受けない。
副作用は、期間を開け直す運用が常態化したときに出る。締めた後に転記できる状態が続くと、月次の数字がいつまでも確定しない。開ける判断と、いつ閉じるかの判断を、同じ朝にセットで決める。 開けっぱなしのまま翌月に入る会社は、必ず前月の数字が動く（SAPの会計期間クローズ（期間オープン管理）：締めた後の修正をどう統制するか）。
一枚にまとめるのは、判断表であって手順書ではない
ここまでの内容を、朝に使える形にする。作るのは手順書ではない。判断表である。 列は六つでよい。
第一列、ジョブ名とプログラム／トランザクション。第二列、前工程。このジョブが結果を使う処理。第三列、後続が自分の結果を使うか。使う後続のジョブ名を書く。ここが Advanced Financial Closing でいうプロセス関連依存にあたる。使わない後続は書かない。第四列、失敗時の戻し方。償却なら繰返し実行、外貨評価ならリセットと反対転記、配賦ならリバーサル実行の単位（実行全体か、特定期間の特定サイクルか）。第五列、リカバリの締切時刻。この時刻を過ぎたら当日中のリカバリを諦め、締めを何日ずらすかを宣言する。第六列、判断者。会計としての再実行可否を誰が決めるか。情報システム部門ではない。
この表があると、朝の会話が変わる。「再実行しますか」ではなく「Canceled で三十七件まで転記済み、後続は二本、締切は十一時」という報告が返るようになる。 情報システム部門が判断できないのは判断能力の問題ではなく、会計上の可否を判断する立場にないからである。立場の問題を技術の会話で解こうとしている限り、毎月同じ時間が溶ける。
作成は第三列から始める。後続が結果を使うかどうかは、たいてい担当者の頭の中にしかない。 三十本程度なら半日で埋まる。第四列は製品仕様に依存するので情報システム部門やベンダーと埋め、第五列の締切時刻は締め日程から逆算して経理が決める。
決めるのは三つ
第一に、朝の順序を固定する。原因分析から入らない。 まず状態を切り分ける。Scheduled のまま止まっているのか、Ready で作業プロセスを待っているのか、Canceled で途中まで転記されているのか、Finished だが結果が誤っているのか。Canceled の場合に最初に確認するのは原因ではなく、どこまで転記されたかである。 この確認を飛ばした再実行が、二重転記を生む。そして Finished でも結果が誤っていることはあり、ジョブ監視は金額の妥当性を見ていないので、検知できるのは前月比較や残高推移を見る経理だけである。
第二に、後続が自分の結果を使うかを、事前に書いておく。 SAP Advanced Financial Closing は依存関係をプロセス関連依存とタイム関連依存に分け、タイム関連依存は前タスクの結果が後続タスクの開始前に必要とされないことを意味する。後続タスクの無効化が起きるのは、無効化が有効化されていて、当該タスクが In Process 以降のステータスにあり、かつプロセス関連依存のみで接続されている場合であり、タイム関連依存のみで接続されたタスク列は無効化されない。結果を使わない後続まで止めるのは、リカバリに使える時間を自分で削る行為である。 依存の種類と承認の要否は別の軸で、承認タイプが Completed Approval Required であればタイム関連依存でも承認完了を待つ。
第三に、処理ごとの戻し方を、判断表の列として持つ。 償却転記実行は繰返し実行が最初の実行との差額のみを転記し、再開は失敗した実行のやり直しに使う。SAP S/4HANA では最終実行期間より前の期間の再実行も可能だが、更新実行はバックグラウンドジョブでしか起動できない。外貨評価は評価エリアごと・特定のキー日付につき一度しか実行できず、リセットと反対転記を経て同じキー日付で回し直す。配賦のリバーサル実行は実行全体か特定期間の特定サイクルかを選べるが、累計処理を設定したサイクルは期0から読むため、前月の取消しが当月以降に波及する。「もう一度流す」で済む処理は一つもない。
そのうえで、リカバリの締切時刻と、締めを何日ずらすかの宣言を経理が持つ。転記期間の開閉は OB52 で行い、レポート RFOB5200 でバックグラウンドから一括設定もできるが、開ける判断と閉じる日は同じ朝にセットで決める。 開けっぱなしで翌月に入る運用は、前月の数字が動き続ける状態を常態化させる。そして判断者の列に情報システム部門の名前を書かない。会計としてどこまで戻してよいかを答えられるのは経理だけである。
