ERPモジュールは実際どう連携するのか

「統合」という言葉が覆い隠す三つの形

ほとんどすべてのERPのパンフレットに「統合」という言葉が使われています。その裏には、月次決算で何か問題が起きたときにまったく異なる振る舞いをする、少なくとも三つの仕組みがあります。一つ目はファイル連携、つまり定期的なバッチ転送で、一方のシステムがエクスポートし、もう一方がインポートします。通常は夜間に行われます。二つ目はAPIやミドルウェアによる同期で、二つの別々のデータベースがメッセージのやり取りによって歩調を合わせます。三つ目は真のデータ共有で、モジュールは別々のシステムではなく、ひとつのテーブル群、ひとつの総勘定元帳、ひとつのマスタレコード群に対する異なるビューにすぎません。

どれかが常に正しいというわけではありません。バッチ転送は安価で理解しやすく、ファイルが待機するだけなので、どちらか一方が停止しても耐えられます。一方で、設計上つねにデータが古く、ジョブが失敗しても、誰かがレポートに疑問を持つまで気づかれないことがあります。API同期はほぼリアルタイムの動作を実現し、残すべき正当な理由のあるシステムを維持できますが、その代わりに分散システムを抱えることになります。再試行、順序、部分的な失敗、そして食い違い得る二つの「正」です。データ共有は、データベースがひとつしかないため、二つのデータベースがずれるという種類の問題そのものをなくします。ただし、モジュールがひとつの勘定科目体系、ひとつの品目定義、ひとつのリリースサイクルで合意しなければならず、これは無償の利点ではなく制約です。

実務上の問いは、どの形が最善かではなく、それぞれのデータの流れにどの形がふさわしいかです。銀行取引明細の夜間転送は問題ありません。稼働中のPOSの背後にある在庫数量の夜間転送は問題です。Skyline Nexusは、自社のモジュールについては三つ目の形をとっています。会計、POSと在庫、CRM、保全、人事、車両管理、資産がひとつの元帳とひとつのマスタ群に書き込み、顧客がすでに残す価値のあるシステムを持っている場合には、外部システムとAPIで連携します。

ずれはマスタデータから始まる

連携の失敗はたいていインターフェースのせいにされますが、最初のひびは通常、内容がわずかに異なる形で二重に存在するマスタレコードです。二つのシステムがそれぞれ独自の顧客リストを持った時点で、リストは数週間のうちにずれ始め、その後のあらゆる数字がそのずれを引き継ぎます。

• 顧客:販売、請求、入金、与信管理を通じてひとつの識別情報。そうでなければ売掛金年齢表と販売レポートが一致しません。
• 仕入先:購買、買掛金、支払で共有。銀行口座情報も含みます。重複した銀行口座情報は不正の標的になります。
• 品目:ひとつのコード、ひとつの単位、ひとつの原価計算方法。品目マスタが二つあれば、在庫評価も二つになります。
• 勘定科目表:単一の体系。モジュールが独自の勘定科目リストを持ち、自社の科目にマッピングするのであれば、そのマッピングは維持し、誤り得るもうひとつの対象になります。
• 税コード:税率、取扱い、適用開始日をひとつの定義で持ち、取引と申告の両方で使用します。
• 支店・拠点:在庫と会計の両方がこの軸で管理されるため、共有します。
• 従業員:給与、勤怠、保全の作業指示、車両の割当ての背後にひとつのレコード。
• 資産:減価償却、保全履歴、除却の背後にひとつの台帳。

補助元帳と統制勘定

総勘定元帳は集約された残高を保持します。明細は補助元帳にあり、各補助元帳は元帳の統制勘定に結びついています。売掛金は顧客の請求書と入金ごとに一行を持ち、その合計が売掛金統制勘定になります。買掛金は仕入先の請求書について同じことを行います。在庫の移動は在庫統制勘定に転記され、商品が出荷されるにつれて売上原価が認識されます。給与は総支給額、事業主負担分、控除、正味の負債を転記します。固定資産は取得、減価償却、除却を取得原価と減価償却累計額に対して転記します。POSは売上、預かった税、支払手段、そして継続記録法を用いる場合は各売上の原価側を転記します。

これを信頼に足るものにするルールは単純です。補助元帳は、通貨の最小単位まで、つねに統制勘定と一致していなければなりません。売掛金年齢表がある数字を示し、売掛金統制勘定が別の数字を示すなら、どちらかが誤っており、調査しなければどちらかは分かりません。統制勘定への直接の仕訳入力が通常禁止されているのはこのためです。売掛金への手動仕訳は、どの顧客も負っていない残高を生み、送付するどの請求明細書にも現れません。

照合は、誰かが管理するスプレッドシートではなく、必要なときに実行できるレポートであるべきです。モジュールがひとつの元帳を共有していれば、照合はほぼ自明になります。共有していなければ、自動化できる最も重要なチェックになります。

転記ルールと監査証跡

元帳のすべての行は、請求書番号、入荷記録、給与計算、減価償却スケジュール、POS取引といった原始証憑までたどれるべきです。原始証憑のない行があれば、誰かがプロセスを迂回しています。証憑の識別子は、別のマッピング表に置くのではなく、元帳の行とともに移動すべきです。

転記済みの仕訳は、黙って編集できてはなりません。訂正は逆仕訳や貸方票で行い、元の仕訳と訂正の両方が、それぞれの日付と担当者とともに見えるようにします。期間の締めは、遡って日付を入れないよう人が覚えていることに頼るのではなく、期間をロックすべきです。試金石は、任意の残高を開き、システムを離れることなく、それを生んだ証憑までたどり着けるかどうかです。

連携が実際に壊れるところ

失敗のパターンはよく知られており、ほとんどいつも同じものです。

• タイミングと期間帰属:期末日の深夜直前に計上された売上が締め後に相手システムへ届き、二つの期間が決して一致しない。
• 誰も監視していない失敗ジョブ:定期転送が止まり、データがないことが「静かな一週間」に見える。
• 部分的な書き込み:請求書のヘッダーは作成されたが明細が失敗し、一方には他方が認識しない証憑が残る。
• キーの重複:再送されたメッセージが同じ請求書の二つ目のコピーを作る、あるいは採番体系が支店間で衝突する。
• 通貨と端数処理のずれ:二つのシステムが異なる段階で端数処理したり、同じ日に異なるレートを使ったりして、小さな差額が積み重なる。
• 税の二重計算:取引システムと会計システムがそれぞれ税を計算し、値引き、税込価格、明細単位か証憑単位かの端数処理について少しずつ異なるルールを使う。その結果、顧客に渡した請求書と申告の数字が食い違う。

べき等性と、双方の一致を証明すること

再試行され得るものは必ず再試行されます。そのため、すべての転記処理には原始証憑から導かれる安定したキーが必要です。同じ請求書を二度送っても、転記は二件ではなく一件にならなければなりません。受信側は処理済みのキーを記録し、新たに作成するのではなく以前の結果を返すべきです。これがなければ、ごく普通のネットワークの挙動が収益の二重計上に変わります。

それと並んで、照合を第一級の機能として備える必要があります。期間ごと・証憑の種類ごとの件数と合計を双方で比較し、差異を要約ではなく一覧で示すものです。直近のジョブが成功したことを示すだけの緑のチェックマークは、一致の証明にはなりません。役に立つレポートとは、一方にだけ存在し他方にない七件の証憑を名指しするものです。

複数拠点と多通貨

複数拠点での運用とは、すべての取引が、後からレポートのロジックで割り当てられるのではなく、作成された瞬間から拠点を軸(ディメンション)として持つことを意味します。在庫、売上、原価、人員はいずれも拠点に属し、拠点間の移動は双方を転記しなければ、二つの拠点の在庫数の合計が会社全体の数字と一致しません。証憑番号は拠点間で一意でありながら、ひとつの拠点の中でも意味を持つものでなければなりません。

多通貨では、取引通貨、使用したレート、基準通貨での金額をすべて明細行に保存する必要があります。換算後の金額だけを保存すると証拠が失われます。そうすれば、未決済残高の評価替えや決済時の実現為替差損益に転記先ができ、為替差額は端数処理の謎ではなくなります。

地域ごとの注記:クリアランスがタイミングを変える

電子インボイス制度が適用される場合、連携のタイミングは設計上の好みではなくなります。いくつかの税務当局は現在、請求書が買い手に届く前または届くと同時に、当局によるクリアランスまたは当局への報告を求めています。サウジアラビアのZATCA制度はその現行の例です。請求書は定められた構造、暗号要素、識別子を備えて生成され、当局は事後に要約を受け取るのではなく、証憑のライフサイクルに関与します。これにより請求書の作成はリアルタイムの連携の問題になります。夜間バッチでは、レジで顧客が待っている証憑を作り出すことはできません。

ほかの地域では状況が異なり、正確に述べておく価値があります。米国には連邦レベルの電子インボイス義務はなく、売上税は州レベルで運用され、ルールと税率は州ごと、さらには地方ごとに異なることも少なくありません。カナダは連邦でGSTとHSTを運用しつつ州ごとの違いがあり、一部の州には州売上税があります。より広いMENA市場は、それぞれ異なる段階にあります。設計上の教訓は、税額の決定と証憑の発行を一か所にまとめておくことです。そうすれば、報告型からクリアランス型へ移行する市場があっても、変わるのはアーキテクチャではなく設定です。Skyline Nexusは、元帳の仕訳を書き込むのと同じ取引からZATCAのクリアランスを処理するため、顧客が受け取る請求書と申告の数字はひとつの計算から生まれます。