製造業の棚卸差異承認システム導入｜RFPと受入試験

「棚卸差異を見つけたらExcelで上長に回し、承認メールを保存してからERPの在庫を直す」。タイの製造拠点でこの運用を変えるために、製造業の棚卸差異承認システム導入を検討している担当者へ。本稿は差異の一般的な原因や棚卸時間の短縮ではなく、再カウントから承認、ERP転記、監査証跡までを一つの案件として設計し、RFP、FAT、SATで確かめる方法を示す。原因を調べる前提知識は在庫差異の原因と対策、数え方と頻度の設計は棚卸効率化を参照してほしい。

導入の対象は「承認画面」ではなく差異案件の状態遷移

差異を発見しても、直ちに帳簿在庫を書き換えてよいわけではない。初回カウントが誤っているかもしれず、移動伝票が未反映かもしれず、品目単価の採用時点によって評価額も変わる。差異案件は「発見→再カウント要否判定→独立した再カウント→原因分類→調整申請→権限に応じた承認→ERPへの転記→照合→クローズ」をたどる。原因調査と数量修正を同じボタンにまとめると、数字だけ合って説明責任が残る。

Microsoft Dynamics 365 Supply Chain Managementの公式資料では、在庫仕訳帳のワークフローを設定すると承認済みの仕訳帳だけを転記できる。一方、この機能はInventory Managementモジュールの取引に限られ、Warehouse Managementモジュールから起こる仕訳帳には適用されない。これは特定製品の仕様であり、どのERPでも同じという意味ではない。導入時は、現場端末、WMS、ERPのどこで案件を起票し、どの境界で承認を強制できるかを実機で確認する必要がある。Microsoft Learn: Inventory journal approval workflows

SAPの物理棚卸プロセスも、カウント結果を入力した後に必要なら再カウントし、差異を転記する段階を分けている。差異の転記では在庫数量と帳簿価額を実在庫に合わせる処理となるため、転記を単なる画面上の状態変更と見なしてはいけない。SAP Help: Physical Inventory Process

差異案件IDを最後まで貫通させる

最初に決めるのは画面ではなく識別子だ。案件IDを初回カウント、再カウント、写真、移動履歴、承認履歴、ERP調整伝票、取消伝票にひも付ける。品目コードだけでは、同じ品目の別ロケーションや別ロットで同時に起きた差異を区別できない。最低限、工場、倉庫、ロケーション、品目、ロットまたはシリアル、在庫ステータス、計量単位、カウント基準時点を案件のキーとして保存する。後からロットが訂正されても元の入力を上書きせず、訂正イベントを追加する設計が望ましい。

ローカルの承認アプリがERPに単に「品目Aを3個減らす」と送るだけでは、ERPがタイムアウトした時に再送で二重調整が起きうる。インターフェースには案件IDと転記要求IDを持たせ、同じ要求の再送に対して同じ結果を返す冪等性を要件化する。ERP側の伝票番号を受け取り、案件に返すまでを一つの業務状態にする。承認時点と転記完了時点を別フィールドにすることが重要だ。

棚卸差異承認ワークフローを状態と責任者で定義する

RFPに「承認ワークフローを搭載」と一行書いても、ベンダーごとに解釈が違う。状態、入口条件、出口条件、担当ロール、差戻し先を表にする。以下は製品機能の説明ではなく、導入企業が検討する業務要件のひな型である。

再カウントで差異が消えた場合も案件を削除しない。「初回差異あり、独立再カウントで一致、調整なし」と記録して終える。逆に、再カウントで差異が残るが未記録の移動伝票が発見された場合は、在庫調整ではなく元取引の正規処理で修復する分岐が必要だ。どちらも監査時には、なぜ調整伝票が無いのかを説明できる。

再カウントは同じ値を入力し直す作業ではない

初回担当者が帳簿数量を見ながら同じ場所を数え直すと、独立した確認にならない。再カウント担当を別ロールにし、必要に応じて盲検表示、ロケーションの逆回り、開封確認、計量単位の確認を用いる。何回まで自動再カウントを要求し、何回目で責任者へ上げるかは会社の手順に合わせる。Oracle Inventoryの公式資料には、許容範囲を外れたカウントに対して自動再カウントを要求し、上限に達したら承認待ちにする例が示されている。これは設計の参考例であり、回数をそのまま自社標準にする必要はない。Oracle: Count Adjustments and Approvals

端末がオフラインになる工場では、再カウント結果の実測時刻とサーバー受信時刻を区別する。最初のカウント以降に入出庫があった場合、二つの数量を単純比較してはならない。差異案件にカットオフ時点を固定し、期間中の移動イベントを別一覧で照合する。端末に残った未送信結果が後から届いたときも、既に承認済みの案件に無言で混ぜず、矛盾として保留させる。

原因コードは「責任追及」ではなく正しい処理への分岐に使う

原因コードが「その他」だけでは、調整承認が連続しても改善に使えない。ただし現場に推測で断定させるのも危険だ。原因候補と「未確定」を分け、根拠となる取引、写真、ロット、作業指示を添付する。代表的な分類は未反映入庫、未反映出庫、ロケーション移動、単位換算、ロット・在庫区分違い、重複カウント、廃棄・不良の未計上、マスター誤り、調査継続である。コードは数値修正の科目だけを決めるためではなく、「元伝票修正」「再カウント」「在庫調整」「品質部門確認」という行き先を選ぶために使う。

SAPの物理棚卸レビュー例では、差異行に理由コードを選んでから差異を転記する手順が示されている。自社の原因コード体系とSAPの標準コードが一致するとは限らないため、RFPにはコードのマッピングと新規コード追加時の運用者を含める。SAP Help: Physical Inventory Document Reviews

原因が未確定でも時間制約で帳簿を締める必要がある会社は、例外ルートを設ける。例外承認では、暫定理由、暫定調整の根拠、後日調査の責任者、期限、結果の記録場所を必須にする。「締めたので原因調査も完了」としない。未確定案件を月次で一覧化し、同じ品目・ロケーション・原因が繰り返されるかを追う。ERPへの調整と再発防止の是正課題は別々の完了条件を持つ。

金額閾値と職務分掌をどう設計するか

在庫調整の承認権限を数量だけで決めると、単価の高い小部品を見逃す。評価額だけで決めると、ロットやシリアルの取り違え、品質保留品の誤出庫など、金額が小さくても重大な案件を見逃す。少なくとも差異数量、評価額、在庫ステータス、品目・ロットの重要度、過去の反復、原因分類を組み合わせる。具体的な金額や許容率は会計方針、内部統制、品目特性に合わせて利用企業が決める。本稿の数値例を業界基準として提示することはしない。

評価額は「差異数量×評価単価」のような単純表示だけで確定しない。標準原価、移動平均、期間末評価など、ERPの評価方法と転記日によって実際の金額は変わる。承認画面には「参考評価額」「採用した単価の根拠と時点」「ERP転記後の実績額」を分けて見せる。参考額で権限ルートを通過した後、転記時の実績額が上位閾値を超えた場合の再承認または保留も決めておく。

職務分掌の基本は、数えた人、原因を確認した人、申請した人、承認した人、ERPへ転記する権限を持つ人の組合せを整理することだ。小規模工場で完全分離ができない場合も、自己承認を防ぐ、代理承認を記録する、管理者による例外解除を別レビューするなどの補完策を要件化できる。NIST SP 800-53のAC-5は、分離すべき職務を定義し、その分離を支えるアクセス権を設定する考え方を示す。これは米国のセキュリティ管理策であり、タイの会計・税務法令を直接示すものではない。NIST SP 800-53 Rev. 5.1, AC-5

権限マトリクスは例外まで書く

これは固定の役職体系ではなく、RFPに添付する検討表である。実際には代理者、夜勤、休日、工場長不在時、外注倉庫、品質保留品を追加する。管理者が本番データの承認者を一時的に変更できるなら、変更理由、開始・終了時刻、変更前後、承認者、対象案件のログを残す。権限の履歴がなければ、当時その人が承認可能だったことを後から証明しづらい。

ERP在庫調整仕訳と監査ログを一対一に結ぶ

承認完了をもって在庫調整完了と扱う設計は避けたい。SAPの公式資料によれば、物理棚卸差異の転記では在庫残高を記録する品目伝票と、必要な勘定活動を記録する会計伝票が生成される。これはSAPの該当プロセスの説明であり、全ERPで同じ伝票構造とは限らない。自社のERPでは、どのAPI・バッチが在庫数量を変え、どの処理が会計に反映し、失敗時に何が残るかを確認する。SAP Help: Posting Inventory Differences

一つの案件から複数のERP伝票が必要になる場合もある。異なるロット、倉庫、在庫区分が混在すれば行単位の処理が分かれる。RFPでは「一案件一伝票」と決め打ちせず、案件ID、案件明細ID、ERP要求ID、ERP伝票番号、会計伝票番号の対応を取得できることを求める。取消・反対仕訳が起きたら元伝票との参照を保存し、画面に最終数量だけを残して履歴を消さない。

監査ログは「誰がいつ承認したか」だけでは足りない。少なくとも、何が起きたか、いつ起きたか、どこで起きたか、誰が起こしたか、結果は何かを追えるようにする。NISTのAU-3は監査記録に必要な内容を考える参照点になるが、そのまま製造業の帳簿保存期間を規定するものではない。保存期間や電子帳票の要件は、自社の法務・経理・監査担当と現地の適用要件で決める。NIST SP 800-53 Rev. 5.1, AU-3

案件のイベントログには、旧値と新値、操作者ID、ロール、端末、時刻とタイムゾーン、理由、添付の版、承認ルートの版、ERP応答を記録する。時刻は表示言語に合わせて現地時間に変換しても、保存は一貫した基準で行う。写真ファイルを差し替えられる場合は旧版への参照を残す。CSV出力後に列が欠けると監査資料として使えないため、画面だけでなくエクスポート結果も受入試験に含める。

転記失敗を「承認済み」のまま放置しない

ERPが明確に拒否した時、通信が切れて結果が不明な時、ERP側では転記したが応答だけ失われた時を区別する。結果不明ならERP伝票を案件IDまたは要求IDで照会し、存在を確かめてから再試行する。単純な再送は二重調整の危険がある。画面には失敗理由と次の担当者を表示し、期限超過を通知する。夜間バッチでまとめて転記する運用でも、承認時刻と実際の転記日を混同しない。

棚卸カットオフ後に入出庫が遡及して登録される場合は、案件が計算した差異が変わる。承認前なら差異を再計算して承認ルートを引き直す。承認後なら元案件を静かに書き換えず、保留・取消・再申請のどれを行うかを決める。期間締め後の修正は、経理が定める手順との整合が必要だ。本稿は会計処理や税務判断を代行しない。

RFPに記載する機能要件と回答形式

ベンダーに「標準対応／設定対応／追加開発／外部連携／非対応」の選択と、動く画面、API、制約、費用対象を同時に回答してもらう。単なる「対応可」では、FAT時に範囲が争点になる。特に次の項目は、例外を含む業務シナリオと一緒に提示する。

1. 案件キーとカットオフ：品目・ロット・場所・在庫区分・単位・時刻を保持し、同じ品目の複数差異を区別できるか。
2. 再カウント：初回担当との分離、盲検表示、回数上限、再カウント後の差異消滅、オフライン再同期を扱えるか。
3. 原因コード：選択肢の管理、根拠の添付、未確定時の例外ルート、元伝票修正への分岐があるか。
4. 閾値：数量、参考金額、品質・シリアルなどのリスク条件を組み合わせ、版付きで変更できるか。
5. 承認：自己承認防止、代理、差戻し、承認後変更時の失効、夜勤の代行ルールを表現できるか。
6. ERP連携：調整要求の冪等性、失敗・不明・成功の区別、伝票番号返却、取消参照、再照合ができるか。
7. 監査：変更前後、承認ルートの版、権限変更、添付の版、ERP応答、エクスポートを確認できるか。
8. 運用：滞留一覧、担当者と期限、通知、工場別の閲覧権限、マスター変更時の保守手順があるか。

RFPには非機能要件も必要だ。ピーク時の差異件数、端末台数、オフライン継続時間、復旧目標、認証方式、アクセスログ、データ保持期間、バックアップ、テスト環境と本番環境の差を自社の実測で記載する。「秒単位で動く」など根拠のない目標値を先に固定するより、現状の件数と業務上の待てる時間を示した方が見積もりが比較できる。言語は画面だけでなく原因コード、通知、CSV列名、操作手順まで日本語・タイ語など対象ユーザーの言語で確認する。

デモで示してもらう一連のケース

同じロットの初回差異を端末で登録し、別人が再カウントし、未反映の出庫伝票を見つけ、調整ではなく元取引を修復するケースを指定する。次に再カウント後も差異が残るケースを作り、低額と高額、品質保留品で承認先が変わることを見せてもらう。承認者が差し戻し、申請者が数量を修正し、再承認を要求されるところまでがデモだ。最後にERP通信を切り、再接続後に二重転記しないことを証明してもらう。

RFP回答を比較可能にするサンプルデータ

全社の実データを渡す必要はないが、候補ベンダー全社に同じ匿名サンプルを渡すと回答の差が分かる。たとえば、部品Aは個数管理で複数ロケーション、部品Bは箱から個への換算が必要、部品Cはロット管理と品質保留あり、部品Dは評価額が高いが数量差は小さい、という組合せを用意する。それぞれに初回数、再カウント数、基準時刻の帳簿数、前後の入出庫、参考単価、想定する原因を付ける。ベンダーにはこのデータを取り込み、どの案件が再カウントに進み、どの案件が元取引修正に進み、誰が承認し、ERPへ何行が転記されるかを示してもらう。

価格比較では、導入費だけでなく原因コード追加、承認ルート変更、ERPのAPI変更、拠点増設、帳票の多言語化、保存容量、運用保守の費用を分ける。標準機能と呼んでいても、顧客固有のERPへ接続するための開発は別見積もりになることがある。提案書の見積対象とRFPの要件番号を対応させ、未見積もりを空白のままにしない。これにより契約後に「画面は標準だがERP転記は別」という齟齬を減らせる。

承認ルート変更の試験も要件化する

通常運用では組織変更や担当者異動が起きる。RFPには閾値表と承認者一覧の版管理、発効日時、変更承認、過去案件への適用方針を書く。発効前に申請した案件は旧ルートのままか、新ルートに移すかを決めておく。異動で承認者のアカウントが無効になった場合、案件を次の上長へ引き継ぐのか、管理者が再割当てするのか、再割当て自体の承認者は誰か。こうした点は、通常のデモでは見えないが、運用開始後の滞留原因になりやすい。

同様に、参考単価が未登録、単位換算が未定義、ロットがERPに存在しない、対象期間が締められているといった異常入力を試す。承認画面だけで完了できても、ERPが受け入れられないデータなら案件は進まない。どの時点で何を検証し、申請者にどのエラーを返すかが、現場の手戻りを左右する。入力時、申請時、転記直前の三点で検証項目を整理しておく。

FATとSATで確認する受入試験

FATは設定と連携を試験環境で確認し、SATは実際の工場、端末、ネットワーク、権限、ERP接続を使って確認する。両者の違いを「同じ画面をもう一度見ること」にしない。試験項目には入力、期待結果、証跡、合否判定者、失敗時の再試験条件を記載する。以下はそのまま試験票の骨格として使える。

受入判定は「画面に成功と出た」だけでは弱い。F09ならERPの在庫残高、調整伝票の件数、連携ログ、案件の履歴を同じ案件IDで揃える。F05なら境界条件を一単位ずつ変えて、閾値の丸めや通貨換算による想定外の分岐を確かめる。S01なら無線が弱い通路で実際の端末を使い、未送信表示を現場担当者が理解できるかを確認する。試験に使ったテスト品目と元残高は後から再現できるよう保存する。

不合格時の扱いを契約前に決める

重大度を「在庫・会計の二重転記」「承認回避」「証跡欠落」「操作性」のように分ける。二重転記や自己承認が残ったまま本番移行しない。軽微な表示修正は、期限と暫定手順、再試験日を明記して条件付きで進める余地がある。現場教育不足とソフト不具合を混同しないよう、操作手順の版と試験時の権限設定も保存する。

境界値の試験票を一枚だけでも具体化する

たとえばF05で「参考額が会社の第一承認閾値に等しい案件」を作る。試験票には、投入する品目、差異数量、参照する原価の版、算出結果、期待する承認者を記入する。次に同じ条件で差異数量だけを一単位減らし、最後に一単位増やす。小数単位の原材料なら、最小入力単位と丸め位置も指定する。画面表示だけではなく、承認エンジンが受け取った金額、保存された承認ルートの版、承認後にERPが返した実績額を照合する。実績額が上位閾値へ移った際に保留する方針なら、FATで保留表示と通知、SATで担当者がその表示を理解できることまで確認する。

F08では、ERPが伝票を作った直後に応答を遮断する試験用の仕掛けを準備する。画面が単に「通信エラー」と出るだけでは合格にしない。案件IDから既存のERP伝票を照会し、その伝票の品目・ロット・数量・評価日が要求と一致することを確認し、二回目の送信では追加伝票を作らないことを証拠として残す。ERP側が要求IDで検索できないなら、代替の照合キーと人手による保留手順を契約前に明記する。再送ボタンの操作権限も通常の申請者とは分ける。

F12の監査出力では、承認者が交代した案件と管理者が権限表を変更した案件を含める。単一案件の「現在の承認者」だけでは、当時の権限が説明できない。画面の履歴、CSV、ERP伝票の三つを照合し、時刻はタイの現地表示と保存基準の変換を確かめる。証跡を一括出力する際、写真や添付を参照できる期間と、退職者アカウントの表示方法も確認しておく。これらは実装後に追加するとデータモデルを変えることがあるため、RFPの段階で問いにしておく。

導入順序と運用開始後の指標

最初から全工場・全品目へ展開するより、差異が多い一倉庫と、単位・ロット・品質区分の異なる品目群で試すと例外が見えやすい。現行のExcelとメールから、どの情報を移行し、どの案件を旧運用で閉じるかを決める。移行日に承認中の案件を二重登録しないよう、切替時刻、案件番号の対応、責任者を記録する。ERP転記権限は本番稼働前に最小権限に戻し、試験用ユーザーを無効化する。

開始後は、差異件数だけでなく、再カウント待ち時間、原因未確定比率、承認待ち時間、ERP転記失敗件数、二重転記防止件数、同一原因の再発、調整なしで元取引を修復した件数を追う。これらは管理のための指標案であり、改善効果の保証値ではない。「差異がゼロになったか」だけで評価すると、現場が差異を記録しない誘因になりかねない。差異が見えるようになった初期に件数が増えることもあり、稼働前の定義と比較条件を固定する。

問い合わせ前に用意したい資料

現行の棚卸票、差異一覧、承認メールの例、ERP調整伝票、役割一覧、品目・ロット・ロケーションのマスター、夜勤やオフラインの運用例を集める。機密情報は伏せたサンプルでよい。分からない点は「未決」と明示し、ベンダーに勝手に埋めさせない。とくに金額閾値、会計処理、保存期間は顧客側の経理・監査部門が決める事項として区切る。

FAQ：棚卸差異の承認システム導入でよくある質問

棚卸差異の承認ワークフローはERP標準だけで足りるか？

製品と対象モジュール、端末・WMSとの接続によって異なる。たとえばMicrosoftの在庫仕訳帳ワークフローは対象範囲に制限がある。標準機能に再カウント、原因調査、端末のオフライン、ERP転記結果の照合が含まれるかをシナリオで確認し、不足部分だけを連携または追加開発する。画面名だけで「標準で足りる」と判定しない。

在庫調整の申請・承認で金額閾値をいくらにすべきか？

共通の正解はない。品目評価額、ロット・品質・シリアルのリスク、工場規模、社内の権限規程をもとに経理・監査・倉庫が決める。承認時の参考額とERP転記後の実績額が異なる場合の扱いまで定義する。まず過去の差異案件を仮ルールに当て、どの役職に何件流れるか試算すると運用負荷が見える。

循環棚卸の差異が再カウントで解消した場合も記録が必要か？

必要と考える。初回値、再カウント値、担当者、時刻、結果を残せば「なぜ調整伝票が無いか」を説明できる。初回担当と同じ人が帳簿値を見て再入力した結果だけでは、独立した確認の証拠として弱い。再カウントが何度も発生する場所や品目は、作業方法やマスターの見直し候補にもなる。

ERP在庫調整の監査ログは承認メールを保存すれば十分か？

メールだけでは、承認した数量とERPに実際に転記された数量、元伝票、取消、権限設定の版を結び付けにくい。案件IDを軸に、カウント、根拠、承認、転記要求、ERP応答、伝票番号、照合を追えるようにする。保存期間や法定要件は適用される制度と会社方針を専門担当者が確認する。

まとめ

製造業の棚卸差異承認システム導入では、差異を見つける機能より、発見後の状態遷移と転記後の照合が成否を決める。再カウント、原因コード、金額とリスクに応じた権限、自己承認防止、ERPの一回限りの調整、監査証跡を一つの案件IDで通す。RFPに例外と境界条件を書き、FATで機能・連携を、SATで現場条件を確認すれば、単なる承認画面の導入で終わらない。

タイの製造拠点で差異承認の業務整理、RFP作成、既存ERPとの接続、FAT・SATの試験項目を検討している段階なら、TOMAS TECHへ相談できる。現行の棚卸票と調整伝票を使い、どこから設計すべきか一緒に整理する。

参照した一次資料

1. Microsoft Learn, Inventory journal approval workflows
2. Microsoft Learn, Inventory journals
3. SAP Help, Physical Inventory Process
4. SAP Help, Posting Inventory Differences
5. SAP Help, Physical Inventory Document Reviews
6. Oracle Inventory, Count Adjustments and Approvals
7. NIST SP 800-53 Rev. 5.1, AC-5 and AU-3