稼働から五年目の月次で、経理課長が同じことを言う。この帳票、前は三分だったのに今は十五分かかる。情報システム部門はメモリの増設見積りを取り、金額は数千万円で返ってくる。稟議の理由欄には性能改善と書かれる。ここで一度止めたほうがよい。遅くなっている原因が処理能力の不足なら増設で解決するが、走査する行が増えたことなら、増設しても翌年また同じ稟議が回ってくる。 五年間で増えたのは能力への需要ではなく、明細の本数である。原因の見分け方、アーカイブが効く条件、保持年数の決め方を順に確かめたい。
重くなっているのは、処理能力ではなく走査する本数である
稼働直後の帳票が速い理由は単純で、対象となる明細が少ないからである。三期目までは体感で気づかない。五期目に効いてくるのは、累積が線形ではないからである。
明細の本数を押し上げているのは、取引量の増加だけではない。伝票分割などで明細が分かれるほど、一つの取引が生む行数が増える。 利益センタ、セグメント、原価センタ、プロジェクト、顧客、製品。こうした単位ごとに明細を分けて記録すれば、そのぶん行が増える。移行の際に「あとから分解できるように」と粒度を細かくした会社ほど、五年後の行数の伸びが大きい。加えて、月次で実行している配賦、再評価、為替換算、期間損益の振替といった処理が、それぞれ行を生む。取引が二倍になっていなくても、行が三倍になっていることは普通に起きる。
明細の行数は、取引件数よりも1件が生む行数で伸びる
ここを取り違えると、投資の方向が狂う。処理能力の不足なら増設が効くが、走査する行数の増加に対しては、増設の効果は限定的である。しかも行数は毎年増える一方で、増設は一度きりの対策になる。 三年で同じ位置に戻る。
判断の材料は簡単に取れる。主要テーブルの年度別の行数を並べる。伸び率が取引件数の伸び率を明らかに上回っていれば、原因は行数の側にある。あわせて、遅いと言われている帳票が実際にどの範囲を走査しているかを見る。期間指定のない照会や、全社を対象とした明細出力が習慣として残っていることは多い。 その場合、最初に手を入れるのはアーカイブではなく照会条件のほうである（SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類）。
増設の見積りを取る前に、行数の伸びと照会条件で原因を見分ける
アーカイブしても、テーブルは自動的には縮まない
ここが実務で最も抜ける。
削除実行がBKPFやBSEGの行を消すのに対し、ACDOCAの行は消えない。残高の計算に使われているため、消すと残高が動いてしまうからである。代わりに伝票ステータスがCに更新され、明細としてではなく合計計算の対象としてのみ残る。 実際に行が減るのは圧縮実行で、SAPの説明によれば、圧縮実行は複数の行を集約して置き換える処理、すなわち古い行の削除と新しい行の挿入によってレコード数を減らす。そして圧縮の対象になるための条件が、関連する伝票が既にアーカイブ済であることである。
この構造から、二つのことが言える。第一に、アーカイブの効果は書き出した瞬間には出ない。 削除まで実行して初めてBKPF・BSEGが減り、圧縮まで実行して初めてACDOCAが減る。三段目に到達していない状態で「アーカイブしたのに速くならない」と結論すると、対策そのものが否定されてしまう。第二に、中途半端な範囲でアーカイブすると、圧縮が効かない。 関連伝票が残っている限り集約できないため、対象範囲の切り方が結果を左右する。年度単位、会社コード単位でまとめて処理する設計にしないと、手間だけかかって行数が動かない。
なお、残高繰越の行は最初からこの扱いになっている。SAPの説明では、ACDOCA上の残高繰越の行は転記期間が000、伝票ステータスがCで保持され、明細照会には現れず合計の表示にのみ使われる。明細として見えないものが、残高としては効いている。 テーブルの行数を数えるときに、この区別を持っていないと数字を読み違える。
アーカイブの効果は、三つ目まで到達して初めて数字になる。
退避したデータが見えなくなるのは、設定の順序を誤ったとき
税務調査で過去の明細を出せなかったという失敗は、データを消したから起きるのではない。索引を作らないまま退避したから起きる。
SAPのドキュメントによれば、アーカイブした会計伝票をアーカイブ情報システムやトランザクションFB03で表示するには、標準のフィールドカタログを基に作成したアーカイブ情報構造が必要で、その情報構造が有効化されている必要がある。 作らずにアーカイブを流すと、ファイルは存在するのに画面から辿れない状態になる。
もう一段深いのが明細照会である。勘定の明細行を表示できるのは、対応する二次索引がシステム内に残っている場合に限られる。アーカイブ済の伝票を勘定明細の照会に出し続けたいのであれば、伝票アーカイブの勘定タイプ別Customizingで二次索引の保持期間を、それに合わせて設定しておく必要がある。 順序が効く。索引の保持期間を短く設定したままアーカイブを流し、後から「明細が見えない」と気づいても、退避済みのデータについては索引がもう存在しない。
そして保存義務の側から見ると、これは単なる利便性の問題ではない。電子帳簿保存法施行規則第2条第2項第2号は、電磁的記録の備付け及び保存をする場所に、当該電磁的記録の電子計算機処理の用に供することができる電子計算機、プログラム、ディスプレイ及びプリンタ並びにこれらの操作説明書を備え付け、整然とした形式で速やかに出力できることを求めている。保存義務は「データを持っていること」ではなく「速やかに出力できること」で判定される。 アーカイブファイルの形で退避しても、読み出す手段が失われていれば、義務を満たしているとは言えない。
索引の設定は、アーカイブを実行する前に決める
残高の側にも制約がある。SAPの解説によれば、残高（transaction figures）をアーカイブする場合、対象とする会計年度に開いている転記期間があるとアーカイブは実行できない。期間オープン管理の運用が緩い会社は、アーカイブの実行日程が組めない。 締めた後に期間を開け直す運用が常態化していると、ここで足を取られる（SAPの会計期間クローズ（OB52）で締め後の修正を統制する運用の作り方）。
何年残すかは、三本の規定で決まる
保持年数を情報システム部門に決めさせている会社が多いが、これは経理と税務の判断である。効いてくる規定は三本ある。
第一に、法人税法施行規則第59条第1項は、青色申告法人は帳簿書類を整理し、起算日から七年間、納税地に保存しなければならないとする。同条第2項の起算日は、帳簿についてはその閉鎖の日の属する事業年度終了の日の翌日から二月を経過した日、書類についてはその作成又は受領の日の属する事業年度終了の日の翌日から二月を経過した日である。決算日からの七年ではない。 二か月ずれる。
第二に、同規則第26条の3は、欠損金額が生じた事業年度については、第59条第1項各号に掲げる帳簿書類を整理し、同条第2項の起算日から十年間保存しなければならないとする。保持年数が事業年度ごとに変わる。 一律七年で設計している会社は、欠損の出た年度で不足する。
第三に、会社法第432条第2項は、株式会社は会計帳簿の閉鎖の時から十年間、その会計帳簿及びその事業に関する重要な資料を保存しなければならないとする。税務の七年とは起算点も年数も違う。
三本を重ねると、実務上の下限はおおむね十年に寄る。そのうえで、十年を超えた分をどうするかが本来の設計論点になる。 ここで問われるのは義務ではなく、経営として過去の明細をどれだけ手元に置くかという判断である。取引先との係争、製品保証、長期契約の遡及精算。業種によって、義務の年数より長く保持すべき理由が実在する。 情報システム部門はこの判断材料を持っていない。
保持年数は3本の規定を重ねて決める。下限はおおむね10年に寄る
Data Agingは、保存の道具ではない
S/4HANAの環境では、データ量の話がData Agingと混ざることがある。分けておく。
Data Agingは、SAP HANAのデータベースに格納されているデータの一部を、メインメモリから能動的に外すための仕組みである。メモリの使用量に効くが、データを保存の観点で整理するものではない。 SAPの案内も、データの保持（data retention）についてはData Agingではなくデータアーカイブを使うべきだとしている。さらに、同じオブジェクトについてData Agingとアーカイブを併用した場合、アーカイブの実行がaged dataも処理することになる、という注意も置かれている。
したがって、税務・会社法・電子帳簿保存法の保存義務に応える手段はアーカイブであり、Data Agingはそれとは別の、メモリ配置の最適化の話である。この二つを一つの稟議に混ぜると、保存義務の議論が性能の議論に飲み込まれる。 分けて書く。
保存義務に応えるのはアーカイブで、Data Agingはメモリの話である
売上高1,180億円の機械部品メーカーで、S/4HANAの稼働から六年目に入っていた。月次の締めは八営業日から十一営業日に伸び、遅延の大半は明細を伴う帳票の出力待ちで発生している。情報システム部門が用意した対策はハードウェアの増設で、見積りは初期費用2,900万円だった。経理担当役員がこれを一度止め、まず年度別の行数を出させている。会計伝票の件数は稼働初年度比で1.4倍だったが、ユニバーサルジャーナルの行数は3.1倍になっていた。取引が増えたのではなく、一件が生む行が増えていた。 移行時に分析軸を六つ持たせて明細を細かく分け、さらに月次の配賦と再評価を稼働後に追加していたためである。次に、遅いと指摘された帳票十四本の実行条件を調べた。うち五本は期間の指定がなく全期間を走査しており、この五本については照会条件の見直しだけで実行時間が半分以下になっている。増設の稟議は、ここで一度取り下げられた。 そのうえでアーカイブの検討に入ったが、実は三年前に一度アーカイブを実施した記録が残っていた。当時の作業ログを確認したところ、書き出しと削除までは実行されており、圧縮は実行されていない。担当していたベンダーの要員は既に離任していた。ACDOCAの行数がほとんど減っていなかったのはこのためである。保持年数の決め直しには、経理と税務担当が入った。一律七年で設計されていたが、過去に欠損金額が生じた事業年度が二期あり、この二期は十年、会社法の会計帳簿としては閉鎖の時から十年、さらに製品保証の期間を踏まえて主要製品ラインの関連伝票は十二年と決めている。年数を決めたのは情報システム部門ではなくなった。 最後に手を入れたのが索引である。アーカイブ情報構造を標準のフィールドカタログから作成して有効化し、勘定明細の照会にアーカイブ済伝票を出し続ける範囲を決めて、二次索引の保持期間をそれに合わせた。この設定を、アーカイブの実行より前に済ませたことが唯一の分かれ目だった、と担当者は言っている。 三年前の実施では、この順序が逆になっていた。翌期の月次締めは九営業日に戻り、増設は見送られている。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
アーカイブの前に決めておく三つのこと
第一に、増設の見積りを取る前に、行数の伸びと照会条件を確認する。 主要テーブルの年度別行数と取引件数の伸び率を並べ、行数の伸びが取引件数の伸びを上回っているなら、原因は処理能力ではなく走査対象の本数にある。あわせて遅い帳票の実行条件を見る。期間指定のない照会や全社を対象とした明細出力が残っていれば、アーカイブより先にそこを直す。行数は毎年増えるが、増設は一度きりの対策である。
第二に、アーカイブは三段目まで到達させる。 書き出しでファイルが生成され、削除でBKPFとBSEGの行が消え、圧縮まで実行して初めてACDOCAの行が集約される。SAPの説明では、削除実行はACDOCAの行を削除せず伝票ステータスをCに更新するにとどまり、実データの削減は圧縮実行で起きる。圧縮の対象になる条件は関連伝票が既にアーカイブ済であることなので、対象範囲を年度・会社コード単位でまとめて切る。 中途半端な範囲では、手間だけかかって行数が動かない。
第三に、索引の設定を、アーカイブの実行より先に決める。 アーカイブ済伝票をFB03等で表示するには標準フィールドカタログを基にしたアーカイブ情報構造を作成して有効化する必要があり、勘定明細の照会に出し続けるには勘定タイプ別Customizingで二次索引の保持期間を合わせておく必要がある。順序を誤ると、退避済みのデータについては索引をあとから作れない。 電子帳簿保存法施行規則第2条第2項第2号が求めているのは、電子計算機・プログラム・ディスプレイ・プリンタと操作説明書を備え付け、整然とした形式で速やかに出力できることであって、データを持っていることではない。
そのうえで、保持年数は経理と税務が決める。法人税法施行規則第59条第1項の七年、同規則第26条の3による欠損金額が生じた事業年度の十年、会社法第432条第2項の会計帳簿の閉鎖の時から十年。起算点も年数も揃っていないので、一律七年の設計では欠損の出た年度で保存期間が不足する。 そしてData Agingは保存の道具ではない。メモリ配置の話であり、保存義務に応えるのはアーカイブのほうである。
