製造業の生産実績訂正・承認システム導入｜履歴とERP連携の設計

製造業の生産実績訂正・承認システム導入では、入力ミスを直せる画面だけでは足りません。数量、良品・不良品の内訳、作業時間、設備、ロットを訂正したとき、元の報告、訂正理由、承認者、在庫・原価への影響を一続きで説明できることが重要です。タイ工場でMESとERPをつなぐ担当者に向け、訂正履歴、承認ワークフロー、取消・再計上、監査ログ、受入試験の設計を整理します。

本稿の対象は、現場端末から生産実績を登録済みで、例外的な修正がメール、紙、共有表、ERP側の手入力に分散している工場です。実績の自動収集方式そのものは現場の生産実績収集を参照してください。完成品を倉庫へ受け入れる取引は完成品入庫システムで詳しく扱っています。ここでは、その前後で報告値が誤っていたと分かった際に、どの記録をどう訂正し、後続の取引へどう伝えるかに限定します。

生産実績の訂正を「上書き」で済ませてはいけない理由

生産実績には、製造指図、工程、品目、数量、良否、工数、使用設備、作業者、ロット、報告時刻などが結び付きます。現場で良品100個と報告した後に実数が96個と分かれば、表示上の数値だけを96へ変えるのは簡単です。しかし、100を誰がいつ報告し、なぜ4個減らし、差分が在庫へ反映済みか、承認前に別システムが100を読んでいないかは、その操作だけでは分かりません。原因調査や月末照合で必要なのは「現在値」と「そこへ至る経路」の両方です。

Microsoftの生産指図の説明では、完成報告は製品を製造指図から在庫へ移し、良品の部分数量や理由付きエラー数量も報告できます。完成報告後には材料消費、倉庫作業、品質指図などが設定により連動し得ます。このため、訂正が単一の画面内で完結すると仮定できません。Microsoftの生産転記の説明も、材料消費、時間、完成品、仕掛原価、在庫・元帳の関係を区別しています。これらは特定製品の機能説明であり、すべての工場で同じ自動処理が起きるという意味ではありません。ただし、導入前に後続影響を洗い出す根拠になります。

「修正前は消して、最新だけ残す」方式では、監査時に誤入力の発生と是正の順序を再構成できません。逆に、誤った実績を残すだけで有効数量から除外できなければ、生産進捗、在庫、原価が二重計上される恐れがあります。設計すべきは、元イベントを保存し、取消または差分の訂正イベントを追加して、どの版が集計に有効かを明示する仕組みです。

先に定義する三つの時刻

訂正の議論では「昨日の分を今日直した」という一文に複数の時刻が混ざります。発生時刻は実際に作業が行われた時刻、登録時刻は端末から最初の報告が保存された時刻、訂正・承認時刻は修正要求と承認が記録された時刻です。日次生産量を発生時刻で集計するか、会計上の転記日で処理するかは業務ルールに依存します。後から時刻を一つにまとめると、シフト別の能率と月次の在庫・原価が一致しない理由を追えません。

タイ工場では日跨ぎの夜勤、端末のオフライン送信、ERPの締め時刻が重なることがあります。端末、MES、ERPのタイムゾーンと時刻同期を確認し、ユーザーに見せる現地時刻と保存する基準時刻を決めてください。日付をさかのぼる訂正を許す場合も、承認日時と会計への反映日時は実際の時刻として残します。「過去の実績を訂正できる」と「過去の承認行為があったことにできる」は別の要件です。

訂正イベントのデータ設計：元記録を残して有効値を計算する

最小単位は「元の生産実績ID」と「訂正要求ID」です。元の記録を削除せず、訂正要求が元ID、変更前後の値、理由、申請者、申請日時を参照します。承認されたら承認者と承認日時を記録し、有効値の算出ルールに反映します。却下なら元の有効値を保ち、申請内容と却下理由は履歴に残します。承認前の申請を集計値へ混ぜないことが重要です。

例えば良品100個を96個に訂正するなら、「100の元実績」と「100→96の承認済み訂正」を保存します。報告の有効数量を96とするか、100に対して差分マイナス4のイベントを加えるかは、MESの集計モデルで決めます。どちらでもERPへ送る内容と再送時の識別子が一貫していれば運用できます。一方、元行を直接96へ更新して100の存在を失う設計は、後続の100という転記が残ったときに原因を説明しにくくなります。

数量以外の項目は一律に扱いません。単なる作業メモの誤記ならMES内訂正で足りる場合があります。ロット番号の訂正ならトレーサビリティ、設備の訂正なら設備別指標、作業時間の訂正なら原価や勤怠との境界を確認します。良品・不良品の付け替えは品質記録と完成品在庫の双方を変え得ます。変更対象ごとに影響マトリクスを作ると、承認階層とERP処理を必要な範囲へ絞れます。

訂正の状態を単純にしておく

推奨する基本状態は、下書き、申請中、承認、却下、連携待ち、連携済み、連携エラーです。ここで「承認」と「ERP反映済み」を一つの状態に潰してはいけません。承認済みでも通信障害でERPが未更新という期間があり得ます。その期間を一覧で見られなければ、担当者は何が反映されたか判断できません。取消・再申請についても、既存申請を見えなくするより別イベントとして関係付けます。

状態遷移は対象の数量・理由・承認済みかどうかなどで機械的に制御します。申請中に元実績が別の訂正で変わった場合は、申請者が見た旧版との競合を検知し、承認操作を止めて再確認させます。これをしないと、100→96と100→98の二件が順に承認され、後者が前者の意図を黙って消してしまいます。「承認時点の元版」と「申請時点の元版」を照合するだけでも、この競合を発見できます。

生産実績修正の承認ルールを現場で使える形にする

承認はボタンを増やすことが目的ではありません。後続への影響が大きい修正を適切な責任者が確認し、軽微な誤記は滞留させない設計が必要です。例えば、作業メモの表記訂正、同一シフト内の小さな数量差、在庫確定後の数量変更、ロットの付け替え、締め済み月への訂正では、必要な確認者が異なります。数値の閾値は工場の製品単価、品質要件、業務権限を踏まえて決めるべきで、本稿では普遍的な承認額や数量を示しません。

承認者には「修正後の値」だけでなく、元値、差分、理由、証拠、影響先、ERPの現在状態を一画面で示します。特に同じ人が入力・申請・承認できる設計は、ルール上許す場合でもその例外を明示すべきです。権限管理の一般論は別テーマであり、本稿では訂正イベントの決裁条件と証跡に絞ります。代理承認や夜勤中の不在時は、誰の権限で、いつまで、どの理由で代行したかを残す運用を決めます。

理由コードは「その他」ばかりにならないよう、誤入力、二重登録、設備計測の差、検査結果の後着、ロット識別の修正、ERP連携失敗の再処理など、実際の原因に沿って作ります。ただし原因が未確定なら「調査中」として申請させ、承認前に追記する余地が必要です。申請フォームに長文を必須化しすぎると現場が登録を避けます。理由コードと簡潔な説明、必要時の添付という組み合わせが運用しやすいでしょう。

承認と訂正の順序

原則は、申請→影響確認→承認→MES有効値更新→ERP処理です。ただし現場安全や出荷停止の判断を急ぐケースでは、品質上の隔離や出荷保留を訂正承認より先に実施することがあります。その場合でも、暫定措置と正式な数量訂正を区別して記録します。ERP連携を承認前に自動実行する場合は、承認却下時の逆処理を必ず定義してください。後から設計を付け足すより、承認境界で送信を止める方が説明可能性を確保しやすくなります。

承認済みの訂正を再訂正する場合、最初の訂正履歴を変更せず、新しい要求として連鎖させます。例えば100→96が承認された後に現物照合で95と判明したら、96→95の新規申請を作ります。画面には有効値95とともに、100、96、95の経過を表示します。別部門が中間値96を使っている可能性があるため、二回目の訂正を単なる最新値の上書きとして送ってはいけません。

ERP生産実績の取消・再計上をどう設計するか

ERPが受け取った生産実績を修正する方法は製品、設定、取引の状態によって違います。MES側で元値を変更して同じメッセージを再送するだけでは、ERP側が新規取引として受け取り二重計上する可能性があります。連携契約として、元取引IDを指定して取消できるか、差分調整が可能か、取消後に正値を再計上するかを決めてください。ERP側の標準機能を確認し、在庫・原価・倉庫作業への影響をテストする必要があります。

Microsoftは、生産指図のステータスを戻すと関連工程が前段階へ戻り、Reported as finishedから戻す場合には見積やスケジュールの再実行が必要になり得ると説明します。またStartedからReleasedへ戻すケースでは、完成報告した品目や工程数量、時間などの設定も逆転されます。これは「ERPには取消ボタンがあるから気軽に戻せる」という理解を戒める例です。製造指図全体のステータス巻き戻しと、個別実績一件の訂正は同じ操作ではありません。 適用製品と設定を確認せずに一括巻き戻しを運用へ入れないでください。

SAPの生産確認取消の公式説明では、複数の確認がある工程で取消対象を特定する必要があります。また、確認により有効化されたユーザーステータスやトリガーポイントが起動した後続機能は、確認を取り消しても自動で戻らない場合があると明記されています。ここから得る実務上の教訓は、元確認の識別、取消と再計上の対、後続イベントの個別照合をRFPに書くことです。SAPとMicrosoftの処理をそのまま同一視せず、採用ERPの仕様と設定で受入シナリオを確認します。

連携メッセージに持たせる識別子

MESからERPへ送る要求には、工場・製造指図・工程・元実績ID・訂正ID・処理種別・要求番号を含めます。処理種別は「新規」「取消」「差分」「再計上」など、ERP側で区別できる形にします。再送しても同じ訂正IDを使い、ERPが同一要求として判定できるかを試験します。通信タイムアウトでは、送信元が失敗と見えてもERP側で処理済みの場合があります。タイムアウト時の即時再送だけで解決しようとせず、取引照会で結果を確認してから再送する手順が必要です。

ERPから返る取引番号、処理時刻、在庫伝票番号などをMES側の訂正IDに紐づけます。連携ログに成功のHTTP応答だけを残しても、ERPで期待した数量・品目・ロットが正しく転記されたとは言えません。照合は要求値とERPの確定値で行います。取消と再計上が別トランザクションなら、取消だけ成功して再計上が失敗した途中状態を検出し、担当者へ通知します。両方を盲目的に再実行すると、最初の取消が二重になる可能性があります。

月跨ぎと締め済み期間

締め済み期間の訂正は、現場の発生日時を変えず、会計上の転記日と差異処理を別に決めます。過去月のMES実績を修正して、ERPの過去月取引が自動で書き換わると思い込むのは危険です。経理・在庫管理・生産管理で「どの期間の在庫・原価へ反映するか」を合意し、その判断を訂正要求に保存します。規制や会計の個別判断は会社の規程と専門家の確認に従ってください。システムの役割は、その判断を実行可能な手順と証跡へ変えることです。

MESとERPの照合は「送信成功」より一段深く見る

訂正管理画面に必要なのは、申請の件数だけではありません。申請中、承認済み未送信、送信中、ERP処理済み、ERP照合済み、エラーという段階別の滞留を見せます。承認済みとERP処理済みの差分が増えれば、現場の有効実績と基幹の在庫・原価が乖離します。シフト締めや月末にまとめて発見する前に、日次で例外を確認できるようにします。

照合キーは製造指図だけでは粗すぎます。同じ指図で複数工程・複数日・複数ロットの報告があるため、元実績と訂正イベントの粒度で突き合わせます。一方、ERPが集約数量しか保持しない設計なら、MESの詳細とERPの集約値を橋渡しする対応表が必要です。どの粒度で照合できるかを導入前に確認し、照合できない粒度を「照合済み」と表示しないことが大切です。

特に完成品入庫や出荷引当が進んだ後に生産数量を減らす場合、単純なマイナス4の送信がERP側で拒否されることがあります。システムが自動処理できない状態を「成功」に見せず、在庫担当者が受入・引当・倉庫作業を調整する例外フローへ渡します。逆に現物の増加が確認できた場合も、承認なしでERPへ増産分を流さず、元の報告と差分の根拠を残します。

生産実績の監査ログに何を残すか

監査ログは「誰が画面を開いたか」より、値と意思決定の変化を追えることが中心です。元実績の作成、訂正申請、添付の追加、承認・却下、ERP送信、ERP応答、手動再処理、照合完了を時系列で並べます。各イベントには実行者、実行日時、対象ID、変更前後、理由、関連するERP取引IDを付けます。自動処理の場合は人名の代わりにサービスIDとジョブIDを記録します。

画面上で履歴が見られても、管理者がデータベースの行を直接変更でき、履歴を同時に消せるなら証跡として弱くなります。保存期間、書き出し権限、ログの改変検知、バックアップを要件として検討してください。ただし保存年数を一般論から固定せず、顧客契約、品質規格、会社規程に合わせます。監査用のCSVやPDFを出す場合は、表示時点の有効値と履歴全体、抽出条件、出力日時を含めると再検証しやすくなります。

「理由が書いてある」だけで適切な承認があったことにはなりません。監査では、訂正時点のルール、申請者と承認者の関係、例外的な代理承認、添付証拠の保全、ERP照合が問題になります。承認ルールを変更した場合は、過去イベントを現在のルールで評価し直さず、当時適用されたルール版を参照できるようにします。この一点が、長期間運用した後の説明可能性を大きく左右します。

導入RFPに入れるべき機能要件と非機能要件

RFPでは「訂正履歴が残る」「承認できる」という抽象表現を避け、具体的なイベントと受入条件で記述します。入力ミスの修正、良否の付け替え、ロット変更、完成報告後の数量減、ERP連携タイムアウト、承認者不在、締め後訂正を最低限の代表シナリオにします。各シナリオで、申請者が見られる範囲、承認者が確認する差分、ERPへ送る取引、照合方法を明示します。

機能要件としては、元イベントと訂正イベントの紐付け、変更前後の表示、理由・添付、承認経路、自己承認制御、版競合検知、取消・再計上の識別、ERP応答照会、失敗時の再処理、監査ログ出力を挙げます。非機能要件では、端末オフライン時の順序保証、時刻同期、通信の再送耐性、権限の棚卸し、ログ保存・バックアップ、障害時の運用手順が重要です。性能の数値は工場の訂正頻度とERP処理能力を測定して設定します。

既存MESに訂正機能を追加するか、別のワークフローを置くかは連携・保守条件で決めます。別システムが申請と承認だけを持ち、MESの有効実績やERP取引と紐づかないと、監査時の照合作業が残ります。発注先には画面デモだけでなく、イベントデータモデル、APIの識別子、失敗時の状態遷移、ログの抽出例を提出してもらうと比較しやすくなります。見積りでは、標準機能と個別開発、ERP側の設定・改修、試験環境・移行作業を分けてください。

段階導入の順序

最初の対象は、発生件数が多く、かつ後続影響を検証しやすい訂正に絞るとよいでしょう。第一段階で数量誤入力の申請・承認・履歴をMES内に整え、第二段階でERPの取消・差分・再計上を接続し、第三段階で品質・倉庫・原価の例外へ広げる方法があります。ただしERPへすでに自動連携している工場では、第一段階でも未送信・送信済みの境界を無視できません。導入順は現行の連携トポロジーを図にして決めます。

移行対象の過去データは、すべての履歴を推測で再構成しないでください。旧システムに修正履歴がないなら、「移行時点の有効値」と「移行前の履歴は不明」を明示する方が正確です。移行後の訂正に新しい監査ルールを適用し、移行時点を境界として識別します。旧システムの伝票番号とERP取引番号の対応は、少なくとも未完了・未照合の案件で確保します。

PoC・FAT・SATで確認する受入試験

画面が動くことと、訂正が正しく閉じることは異なります。PoCではまず一つの製造指図と工程を選び、誤報告→申請→承認→MES有効値変更→ERP取消または差分→再計上→照合まで通します。FATでは製品設定と例外分岐をベンダー環境で確認し、SATでは実際の端末、ネットワーク、ERP接続、シフト運用で再実行します。名称よりも、どの環境で何を証明したかを記録することが大切です。

異常系の試験では、ERPから応答が返らないが実際には転記されたケースを必ず含めます。送信側の「タイムアウト」はERP側の「未処理」を意味しないからです。再送前の取引照会、重複拒否、オペレーターへの表示、担当者へのエスカレーションを確認します。夜勤終了直前の申請や代理承認も試し、実際の役割で操作できるか確かめます。

SATの最後には、製造、品質、倉庫、経理の担当者が同じ訂正案件を見て、各部門の数値が一致することを確認します。画面の数量96、ERP在庫96、元伝票100、差分マイナス4、承認時刻、原因を一つの案件番号から辿れる状態が目標です。照合に手作業を残す場合も、誰がいつ何と何を比較し、差異をどう閉じるかを運用手順に書きます。

本番開始後の運用指標

稼働後は「訂正が何件あったか」だけで良し悪しを判断しません。記録されていなかった修正が正式フローに載れば、導入直後の件数は一時的に増え得ます。申請から承認までの時間、承認からERP照合完了までの時間、二重送信の防止件数、未照合の滞留日数、理由コード別の再発件数を併せて見ます。品質・倉庫・経理が関係する案件は、単純な件数平均よりも、長く残る例外の内訳を確認する方が改善につながります。監視する項目と目標値は、導入前の実態を測ってから決めてください。

同じ設備・同じシフトで誤報告が続くなら、訂正画面を増やすだけでは解決しません。端末の入力単位、スキャナの読取、計量器やカウンタの連携、作業指示の表記、良否判定の遅延を調べます。訂正履歴は現場を責めるためではなく、最初の報告が正しくなるよう工程を改善する材料です。逆に、承認滞留が多いなら承認者の配置と代理ルールを見直します。ERPエラーが集中するなら、品目・単位・ロットのマスタやインターフェース条件に原因がないかを調べます。

月次レビューでは、未照合案件の一覧を製造・倉庫・経理で共有し、誰が閉じるかを決めます。「MES上は承認済みだから終わり」と「ERPへ送ったから終わり」を避け、ERP取引の確定と必要な在庫・原価調整まで完了条件に含めます。差異の解消方法を記録すれば、次回の同じ例外に対する標準手順が作れます。

承認待ちの案件を一覧に出す際には、申請からの経過時間だけでなく、出荷予定や棚卸し予定との関係を表示すると優先順位を判断しやすくなります。例えば翌朝に出荷するロットの数量訂正が保留中なら、通常の入力誤記より早く関係者へ伝える必要があります。一方、急ぎであっても確認証拠を省略してよいとは限りません。緊急度と承認要件を別の属性として扱い、期限超過時の通知先を決めておくと、夜勤や休日にも判断を先送りしにくくなります。訂正後には、現場の表示だけでなく生産日報、仕掛一覧、完成品入庫、原価計算に使う集計が同じ有効値を参照しているか確認してください。画面ごとに旧値と新値が混在する状態は、履歴を保存していても現場判断を誤らせます。

よくある質問

生産実績の訂正履歴は元レコードの更新履歴だけで十分ですか？

変更前後の値を保存できても、申請、承認、ERP取消・再計上、照合の各状態が元レコードと結び付かなければ十分とは言えません。訂正要求IDを中心に、元実績IDとERP取引IDをつないでください。レコードの更新履歴はその一部です。

MESの実績修正は必ず上長承認にすべきですか？

すべてを同じ承認経路にすると軽微な誤記が滞留します。変更項目、金額・在庫・品質への影響、締め状態に応じて経路を分けます。承認不要の訂正を設ける場合も、対象範囲と理由・実行者の履歴を残します。

ERP生産実績は元の値を直接書き換えられますか？

製品・設定・取引状態によります。SAPの生産確認取消やMicrosoftの生産指図ステータス巻き戻しも操作の粒度と後続影響が異なります。採用ERPで個別実績の取消、差分調整、再計上を確認し、在庫・原価・倉庫への波及を受入試験で検証してください。

監査ログがあればERPとの照合は不要ですか？

不要にはなりません。ログはMESで何を申請・承認・送信したかの証拠です。ERPが実際に受け付けた数量・ロット・転記日・取引番号を確認する照合は別に必要です。特にタイムアウトや途中失敗は送信履歴だけでは判定できません。

まとめ

生産実績の訂正・承認システムは、誤入力を直す画面ではなく、元実績から訂正要求、決裁、ERP処理、照合までを一つの案件として追う仕組みです。元値を残し、変更前後と理由を記録し、影響に応じた承認を通し、取消・再計上を識別して、ERPの確定値と照らし合わせます。導入時は正常系だけでなく、二重送信、途中失敗、締め後訂正、承認競合を試験してください。

タイ工場のMESとERPで、生産実績の修正が現在どの画面・帳票・担当者を経由しているかを整理する段階からでも、TOMAS TECHへご相談いただけます。元実績、承認、在庫・原価への影響を一枚の業務フローにしてから、必要な機能と導入範囲を検討できます。

参考情報

• Microsoft Learn: Report production orders as finished — 完成報告と在庫、部分数量、エラー数量、関連工程。
• Microsoft Learn: Reverse the production order status — 指図ステータス巻き戻しと後続影響。
• Microsoft Learn: Production posting — 材料・時間・完成品の転記と仕掛・在庫の関係。
• Microsoft Learn: Production feedback — 工程の時間・数量・不良の実績入力とジャーナル。
• Microsoft Learn: Configure the production floor execution interface — 現場端末からの報告と生産進捗・原価の追跡。
• SAP Help Portal: Canceling Confirmations — 生産確認の取消と例外的な後続機能の扱い。