2026.10.27 業務システム

製番管理とは：MRPとの違いと製番を紐付けるデータモデル・引当SQL

Q: 製番とは何の略で、どの単位で振るのですか？

製番は「製造番号」の略です。受注1件に1つ振るのが基本ですが、1つの受注に仕様の異なる製品が複数含まれる場合は、受注明細1行ごとに振ります。分割納入がある装置では、納入単位で枝番を付けるのも運用の一つです。システム上は受注番号と製番を別の列で持ち、製番を在庫・発注・作業指示の外部キーにすると、受注の変更と製番の変更を分けて扱えます。

Q: 製番管理とMRPはどちらが在庫を減らせますか？

部品の共通化率が高い工場ではMRPの方が在庫は減ります。品番単位で全受注の需要を合算し、正味の不足だけを手配するためです。製番管理は受注ごとに部品を囲い込むので、製番間で余りと欠品が並存しやすくなります。ただし一品一様の設計品が中心なら、そもそも共有できる在庫が少ないので差は小さく、受注単位の原価が見える製番管理の利点の方が大きくなります。

Q: 製番管理で過剰在庫が生まれやすいのはなぜですか？

受注キャンセルや設計変更で使われなくなった部品が、製番に属したまま残るためです。フリー在庫に戻す処理（解除）を誰も行わないと、帳簿上は「どこかの製番の部品」として棚に眠り続けます。本稿のデータモデルでは移動理由に release（解除）を用意しており、製番の状態を cancelled にするときに製番在庫をフリー在庫へ戻す処理を同じトランザクションで行うと防げます。

Q: Excelで製番管理を続けるとどこで破綻しますか？

引当と転用です。複数人が同じブックを編集すると、同じ在庫を2つの製番に割り当てる二重引当を防げません。転用を記録する列を作っても、承認者と日時を必須にする仕組みが無いため、原価の振替が漏れます。製番数が月に数十件を超え、担当者が2人以上になった時点で、排他制御と移動履歴を持つデータベースへの移行を検討する目安になります。

Q: 製番別の原価はどのように集計しますか？

材料費は製番在庫から出庫した部品の取得原価、外注費は製番を付けた外注発注の金額、労務費は製番を付けた作業日報の工数に賃率を掛けて集計します。転用した部品は移動履歴を使って転用元から転用先へ原価を振り替える扱いです。すべての伝票に製番を必須項目として持たせることが前提で、製番の無い伝票を1種類でも許すと、その費用は製番別原価から漏れて間接費に紛れます。

製番管理とは、受注ごとに製造番号（製番）を振り、部品の手配・在庫・進捗・原価をその番号で束ねる生産管理方式です。この記事では、製番とロットの違い、MRPとの違いを「在庫を共有するかどうか」という一点から整理したうえで、製番をシステムに載せるときのデータモデルをPostgreSQLのSQLで示します。部品表を展開して製番別の所要量を起こす処理、在庫の二重引当を防ぐロック、製番間で部品を融通する転用処理まで、コピーして動かせる形で載せました。最後に、製番管理を採るべき工場と品目単位のMRPで足りる工場の境界を言い切ります。

まとめ：製番管理は受注と部材を番号で縛る方式で在庫の持ち方がMRPと違う

製番管理は「この部品はどの受注のものか」を常に答えられる代わりに、部品を受注間で共有しない方式です。MRPは同じ品番の在庫を全受注で共有し、品目単位で不足だけを手配します。違いは計算手法よりも在庫の持ち方にあります。

システムに載せるなら、製番在庫とフリー在庫を同じ在庫テーブルに置き、製番の列が空かどうかで区別する設計が扱いやすくなります。引当は在庫行をロックしてから減算し、製番間の部品融通は「転用」として移動履歴に残します。履歴を残さない転用は、原価もトレースも壊す原因です。

採否の目安は、受注ごとに仕様が変わる設計品の比率と、部品の共通化率です。一品一様の装置・治具・金型が中心なら製番管理、共通部品の量産品が中心なら品目単位のMRP、混在するなら品目ごとに両方式を使い分けます。

製番管理とは受注ごとの製造番号で手配から原価までを束ねる生産管理方式

製番は「製造番号」の略で、受注1件（または受注明細1行）に対して1つ発番します。発番した製番は、設計図面、部品表、購買発注、外注指示、作業日報、出荷伝票のすべてに同じ値で記録されます。

製造命令書の発行時点で全工程の指示書に同じ製番を振る管理の仕組み

中小企業診断士試験（令和2年度運営管理第8問）では、製番管理方式を「製造命令書を発行するときに、その製品に関するすべての加工と組立の指示書を準備し、同一の製造番号をそれぞれに付けて管理を行う方式」と整理しています。番号を振るのは組立に入る時点ではなく、命令書を出す時点です。

システムでいえば、受注確定のトランザクションで製番を発番し、その製番を外部キーとして部品所要量・発注・作業指示の各行に持たせる構造になります。発番体系は「S＋受注年月4桁＋連番4桁」（例：S2610-0042）のように、年月と連番を組み合わせる形が現場で読みやすく、並び順もそのまま時系列になります。

製番とロット番号・追番管理の違いを管理単位と在庫の持ち方で比較

似た番号体系が3つあり、混同すると設計を誤ります。管理する単位と在庫の扱いで並べると次のとおりです。

方式	番号を振る単位	在庫の扱い	向く生産形態
製番管理	受注1件ごと	製番ごとに囲い込む	個別受注生産
ロット管理	同一条件で作った塊ごと	品番単位で共有	繰返生産・食品・化学
追番管理	製品の累計通し番号	計画の累計数で管理	量産の組立ライン

ロット番号は「同じ材料・同じ日に作った塊」を識別するための番号で、品質の追跡に使います。製番は「誰の注文のために作っているか」を識別する番号で、受注と原価を結び付けるためのものです。1つの製番の中に複数のロットが入ることも、1つのロットが複数の製番に分かれることもあり得ます。そのため両者は別の列で持ち、片方で代用しない設計にします。

製番管理が機械・装置メーカーで選ばれてきた理由と原価の見え方

最大の理由は原価です。製番単位で材料費・外注費・工数が積み上がるので、受注1件ごとの粗利が出荷時点で確定します。見積と実績の差が受注単位で出るため、赤字受注の傾向を次の見積に反映できる仕組みです。原価集計の考え方そのものは原価管理システムとは？機能・原価計算との違いから選び方と受託開発の判断まで解説で扱っています。

次に進捗です。受注ごとに「どの部品が未入荷か」を製番で絞り込めるため、納期回答の根拠が出せます。品質面では、製番から使用部品と作業者まで遡れるので、不具合時の範囲特定は受注単位で済む仕組みです。受注生産そのものの分類は受注生産とは？見込み生産との違い・種類・メリットとシステム化の判断まで解説が詳しく、本稿は製番という管理単位の実装に絞ります。

製番管理とMRPの違いを在庫の共有可否と所要量計算の単位から整理

MRP（資材所要量計画）の計算手順そのものはERPとMRPの違いとは？JIS Z 8141の定義と所要量計算でみる役割分担で総所要量から正味所要量まで解説しています。ここでは製番管理との対比に必要な点だけを扱います。

MRPは品目単位で在庫を共有し製番管理は受注単位で囲い込む違い

MRPは、同じ品番の需要を全受注分合算し、手持ち在庫と発注残を差し引いた正味所要量だけを手配します。在庫は品番に属し、どの受注に使うかは出庫の瞬間まで決まりません。

製番管理は、部品を手配した時点で製番に属します。同じ品番のボルトが棚に100本あっても、製番Aの30本と製番Bの20本とフリーの50本は別物として扱います。計算は単純で、製番ごとに部品表を展開し、その製番に引き当て済みの数を引くだけです。

比較軸	製番管理	MRP
在庫の帰属	製番	品番
不足計算の単位	製番ごと	品番ごとに全需要を合算
受注変更の影響	その製番の中で閉じる	同じ品番の全計画に波及
在庫の偏り	製番間で過不足が並存しやすい	合算されるので偏りが出にくい

表の4行目が実務上いちばん効きます。製番Aに余りが出て製番Bが欠品している、という状態が帳簿上は普通に起きるのが製番管理です。

部品1点の遅延で組立に着手できない製番管理の弱点と転用の運用

同じ試験問題の解説では、部品が製番ごとに管理されるため1点でも遅れると組立に着手できない、という性質を製番管理の特徴として挙げています。在庫が別製番に眠っていても、そのままでは使えません。

現場はこれを「転用」で回します。製番Bの部品を製番Aへ付け替え、製番B側は再手配する運用です。問題は、転用を口頭や付箋で済ませると、帳簿上は製番Bに部品が残ったまま製番Aで消費されることです。結果として製番Aの原価は過小に、製番Bは過大に出て、在庫も合わなくなります。後述の実装では、転用を承認者付きの移動履歴として必ず記録します。

製番とMRPを品目ごとに混在させる運用とOdoo 18の受注連動補充

実際の工場では、筐体やフレームのような設計品は製番で、ねじ・ベアリング・汎用電子部品のような共通品はMRPで、と品目ごとに方式を分けることが多くあります。品目マスタに「製番品／共通品」の区分を持たせ、手配ロジックを分岐させる設計です。

ERPでの例として、Odoo 18のReplenish on order (MTO)の仕様が参考になります。公式ドキュメントによると、販売オーダーや製造オーダーで品目が必要になるたびに見積依頼または製造オーダーの下書きを作り、生成された文書は元の販売オーダーにスマートボタンで紐付く仕様です。ただし在庫が足りていれば手配文書は作られず、通常どおり在庫から出荷されます。MTOルートは既定でアーカイブされており、使うには複数ステップルートの設定を有効にしたうえで品目ごとに指定します。

つまりOdooのMTOは「受注と手配の紐付け」は持つものの、手持ち在庫を製番ごとに囲い込む厳密な製番管理ではありません。製番在庫の分離まで要るなら、次章のようなデータモデルを自前で持つ必要があります。TPiCSのように製番とMRPの中間を製品として提供する例はTPiCSとは？f-MRP製番管理の仕組み・機能・費用と向く工場の条件で扱っています。

製番紐付けのデータモデルをPostgreSQLのテーブル定義で組み立てる手順

ここからはPostgreSQL 18で動くSQLで、製番管理の最小構成を組み立てます。テーブルは受注・製番・部品表・製番別所要量・在庫・移動履歴の6つです。

受注・製番・所要量・在庫・移動履歴の6テーブルと外部キーの張り方

中心は在庫テーブル stock_lot の seiban_no 列です。値が入っていれば製番在庫、NULLならどの製番にも属さないフリー在庫として扱います。在庫を製番用とフリー用で別テーブルに分けると、引当のたびに2テーブルをまたぐ更新になり、合計数の整合を取るのが難しくなります。

CREATE TABLE sales_order (
  order_no    text PRIMARY KEY,
  customer_cd text NOT NULL,
  due_date    date NOT NULL
);

CREATE TABLE seiban (
  seiban_no   text PRIMARY KEY,             -- 例: S2610-0042
  order_no    text NOT NULL REFERENCES sales_order (order_no),
  item_cd     text NOT NULL,                -- 製品の品目
  qty         numeric(12,3) NOT NULL CHECK (qty > 0),
  status      text NOT NULL DEFAULT 'open'
              CHECK (status IN ('open', 'closed', 'cancelled'))
);

CREATE TABLE bom (
  parent_cd   text NOT NULL,
  child_cd    text NOT NULL,
  qty_per     numeric(12,4) NOT NULL CHECK (qty_per > 0),
  PRIMARY KEY (parent_cd, child_cd)
);

CREATE TABLE seiban_requirement (
  seiban_no   text NOT NULL REFERENCES seiban (seiban_no),
  item_cd     text NOT NULL,                -- 部品の品目
  req_qty     numeric(12,3) NOT NULL CHECK (req_qty > 0),
  PRIMARY KEY (seiban_no, item_cd)
);

CREATE TABLE stock_lot (
  lot_id      bigserial PRIMARY KEY,
  item_cd     text NOT NULL,
  location_cd text NOT NULL,
  seiban_no   text REFERENCES seiban (seiban_no),   -- NULL ＝ フリー在庫
  qty         numeric(12,3) NOT NULL CHECK (qty >= 0),
  CONSTRAINT stock_lot_uq
    UNIQUE NULLS NOT DISTINCT (item_cd, location_cd, seiban_no)
);

CREATE TABLE stock_move (
  move_id     bigserial PRIMARY KEY,
  item_cd     text NOT NULL,
  location_cd text NOT NULL,
  qty         numeric(12,3) NOT NULL CHECK (qty > 0),
  from_seiban text REFERENCES seiban (seiban_no),   -- NULL ＝ フリー在庫から
  to_seiban   text REFERENCES seiban (seiban_no),   -- NULL ＝ フリー在庫へ
  reason      text NOT NULL CHECK (reason IN ('allocate', 'transfer', 'release')),
  approved_by text,
  moved_at    timestamptz NOT NULL DEFAULT now(),
  CHECK (reason <> 'transfer' OR approved_by IS NOT NULL)
);

最後のCHECK制約で、転用（transfer）だけは承認者の記録を必須にしています。テーブル制約の書き方はPostgreSQL 18のConstraintsの章にあります。seiban_requirement を受注の部品表から複製して持つのは、受注後の設計変更をその製番だけに閉じ込めるためです。品目マスタの部品表を直接参照すると、別の製番の所要量まで変わってしまいます。

フリー在庫と製番在庫を同じ表で分けるUNIQUE NULLS NOT DISTINCT

一意制約は通常、NULLを互いに異なる値として扱います。そのため (item_cd, location_cd, seiban_no) に普通のUNIQUEを付けても、フリー在庫（seiban_no がNULL）の行は同じ品目・場所で何行でも作れてしまう仕様です。PostgreSQLのドキュメントは、NULLS NOT DISTINCT を付けるとNULL同士を等しいとみなして一意性を検査すると説明しています。上のDDLではこれで「品目×場所×製番（またはフリー）」を1行に保ちます。

引当の検索は「この品目のフリー在庫」に集中するので、フリー在庫だけを対象にした部分インデックスを足します。

CREATE INDEX stock_lot_free_idx
  ON stock_lot (item_cd, location_cd)
  WHERE seiban_no IS NULL AND qty > 0;

PostgreSQL 18のPartial Indexesによると、部分インデックスはWHERE句の条件を満たす行だけを索引に含めます。製番在庫が積み上がる工場ほど、フリー在庫の行は全体の一部になるので、索引を小さく保てる仕組みです。ただし検索側のWHERE句が索引の条件を含意しないと使われない点に注意が要ります。

部品表を再帰CTEで展開して製番別の所要量を一括で起こすSQL

受注を確定したら、製品の部品表を多階層で展開し、製番別所要量に書き込みます。階層の深さが品目ごとに違うので、PostgreSQL 18のWITH Queriesにある WITH RECURSIVE で展開します。

INSERT INTO seiban_requirement (seiban_no, item_cd, req_qty)
WITH RECURSIVE explode AS (
  SELECT b.child_cd AS item_cd,
         b.qty_per * s.qty AS req_qty,
         1 AS lvl
    FROM seiban s
    JOIN bom b ON b.parent_cd = s.item_cd
   WHERE s.seiban_no = 'S2610-0042'
  UNION ALL
  SELECT b.child_cd,
         b.qty_per * e.req_qty,
         e.lvl + 1
    FROM explode e
    JOIN bom b ON b.parent_cd = e.item_cd
   WHERE e.lvl < 20                       -- 部品表の循環で止まらなくなるのを防ぐ
)
SELECT 'S2610-0042', item_cd, sum(req_qty)
  FROM explode
 GROUP BY item_cd;

同じ部品が複数の中間組品に使われていても、最後の GROUP BY で製番ごとに1行へ合算されます。このSQLは中間組品も所要量の行として出すため、手配対象を購入品と外注品に絞るなら、品目マスタの手配区分で外側のSELECTを絞り込みます。lvl < 20 は、部品表の登録ミスで親子が循環したときに無限に再帰しないための上限です。

製番引当の排他制御と転用処理をSQLで実装するときの手順と注意点

製番管理のシステムで最も事故が多いのは引当です。2人の担当者が同じフリー在庫を別々の製番に同時に引き当てると、帳簿上の在庫がマイナスになるか、片方の製番が「引当済み」なのに現物が無い状態になります。

SELECT FOR UPDATEで在庫行をロックし二重引当を防ぐ引当クエリ

フリー在庫を減らす前に、対象行を FOR UPDATE でロックします。PostgreSQL 18のSELECTのロック句の説明どおり、FOR UPDATE で取得した行は現在のトランザクションが終わるまでロックされ、同じ行を更新・ロックしようとする他のトランザクションは待たされます。

BEGIN;

-- 1) 対象部品のフリー在庫行をロック（同じ行を狙う別の引当はここで待つ）
SELECT lot_id, qty
  FROM stock_lot
 WHERE item_cd = 'P-1001' AND location_cd = 'WH1'
   AND seiban_no IS NULL AND qty > 0
   FOR UPDATE;

-- 2) フリー在庫から12個減らす（足りなければ0行更新になる）
UPDATE stock_lot
   SET qty = qty - 12
 WHERE item_cd = 'P-1001' AND location_cd = 'WH1'
   AND seiban_no IS NULL AND qty >= 12;

-- 3) 製番在庫へ積む（同じ品目・場所・製番の行があれば加算）
INSERT INTO stock_lot (item_cd, location_cd, seiban_no, qty)
VALUES ('P-1001', 'WH1', 'S2610-0042', 12)
ON CONFLICT ON CONSTRAINT stock_lot_uq
DO UPDATE SET qty = stock_lot.qty + EXCLUDED.qty;

-- 4) 移動履歴を残す
INSERT INTO stock_move (item_cd, location_cd, qty, from_seiban, to_seiban, reason)
VALUES ('P-1001', 'WH1', 12, NULL, 'S2610-0042', 'allocate');

COMMIT;

手順2の更新件数が0なら、在庫不足なのでアプリケーション側でROLLBACKします。画面の一括引当のように待たせたくない処理では、ロック句に SKIP LOCKED（ロックできない行を飛ばす）や NOWAIT（待たずにエラーにする）を付ける方法も選択肢の一つです。ただし同じドキュメントは、SKIP LOCKEDで飛ばすとデータの見え方が一貫しなくなるため汎用の処理には向かず、キューのような表で競合を避ける用途向けだと書いています。在庫が見えないまま「不足」と判定する危険があるので、引当では待つ方を既定にします。

製番間の部品転用を移動履歴として残し原価とトレースを守る実装

転用は「製番Bの製番在庫を減らし、製番Aの製番在庫に積む」2行の更新です。デッドロックを避けるため、2つの製番の行は必ず同じ順序（ここでは製番の昇順）でロックします。

BEGIN;

SELECT lot_id, seiban_no, qty
  FROM stock_lot
 WHERE item_cd = 'P-1001' AND location_cd = 'WH1'
   AND seiban_no IN ('S2610-0042', 'S2610-0057')
 ORDER BY seiban_no
   FOR UPDATE;

UPDATE stock_lot
   SET qty = qty - 4
 WHERE item_cd = 'P-1001' AND location_cd = 'WH1'
   AND seiban_no = 'S2610-0057' AND qty >= 4;

INSERT INTO stock_lot (item_cd, location_cd, seiban_no, qty)
VALUES ('P-1001', 'WH1', 'S2610-0042', 4)
ON CONFLICT ON CONSTRAINT stock_lot_uq
DO UPDATE SET qty = stock_lot.qty + EXCLUDED.qty;

INSERT INTO stock_move
  (item_cd, location_cd, qty, from_seiban, to_seiban, reason, approved_by)
VALUES ('P-1001', 'WH1', 4, 'S2610-0057', 'S2610-0042', 'transfer', 'E1203');

COMMIT;

転用元の製番B（S2610-0057）の所要量は変えません。所要量はそのまま、製番在庫だけが4個減るので、次の不足計算で製番Bに4個の不足が出て、再手配の対象になります。原価は stock_move の転用行を使って、部品の取得原価を製番Bから製番Aへ振り替えます。不具合が出たときに「製番Aに入った部品は元々どの手配か」を遡れるのも、この履歴があるからです。製品の追跡の考え方はトレーサビリティとは？追跡可能性の意味と2種類・法制度・システム化の判断にまとめています。

製番ごとの不足は、所要量から製番在庫を引くだけで出ます。

SELECT r.item_cd,
       r.req_qty,
       COALESCE(sum(l.qty), 0)             AS allocated,
       r.req_qty - COALESCE(sum(l.qty), 0) AS shortage
  FROM seiban_requirement r
  LEFT JOIN stock_lot l
         ON l.seiban_no = r.seiban_no AND l.item_cd = r.item_cd
 WHERE r.seiban_no = 'S2610-0057'
 GROUP BY r.item_cd, r.req_qty
HAVING r.req_qty > COALESCE(sum(l.qty), 0);

この最小構成では出庫済みの数を在庫から消すため、出庫後は所要量と比べると不足に見えます。本番では出庫も stock_move に記録し、「引当済み＋出庫済み」で所要量と突き合わせます。

製番管理をシステム化するか判断する工場の受注形態と在庫共有の条件

ここまでの実装は、製番管理を採ると決めた後の話です。採るかどうかは、受注の性質と部品の共通化率で決まります。

製番管理を採用すべき工場と品目単位のMRPで足りる工場の境界線

製番管理を採るべきなのは、次の条件が2つ以上当てはまる工場です。

受注の過半が顧客仕様の設計品で、部品表が受注ごとに変わる
1受注の金額が大きく、受注単位の粗利を経営が毎月見ている
リードタイムが数か月あり、受注後の仕様変更が日常的に起きる
顧客から製造記録の提出を製品単位で求められる

逆に、部品の大半が共通品で、受注ごとの違いが色や外装程度なら、製番管理は過剰です。共通品まで製番で囲い込むと、製番間の余りと欠品が並存し、転用の承認作業が毎日発生します。この場合は品目単位のMRPで手配し、受注番号は出荷と売上の紐付けにだけ使う方が在庫を減らせる方式です。計画の階層ごとの手法の選び方は工程管理の手法を計画の階層で選ぶ｜山積み山崩しとシステム要件への翻訳で整理しています。

パッケージの製番機能で足りる条件と個別開発に進む場面の判断基準

生産管理パッケージの多くは製番管理の機能を持っています。製番の発番、製番別の所要量、製番別原価までが標準機能で揃い、自社の製番体系と承認フローがパッケージの型に合うなら、パッケージで足ります。

個別開発に進むのは、品目ごとの製番／MRPの混在、転用の承認ルール、設計変更の製番への反映タイミングといった、工場固有の運用がパッケージの設定範囲を超える場面です。特に「部品表を製番に複製した後の設計変更を、どの工程まで進んだ製番に反映するか」は工場ごとに答えが違い、パッケージの追加開発費が膨らみやすい箇所です。この部分を自社の業務に合わせて作る場合は、一創の生産管理システム開発でデータモデルの設計から相談できます。生産管理システム全体の機能の切り分けは生産管理システムとは？機能・ERP／MESとの違いから種類・選び方と内製化の判断まで解説を参照してください。

製番管理の仕組みと実装を検討する工場の担当者から多いよくある質問

製番管理の導入やシステム化を検討するときに出やすい質問をまとめました。

製番とは何の略で、どの単位で振るのですか？

製番は「製造番号」の略です。受注1件に1つ振るのが基本ですが、1つの受注に仕様の異なる製品が複数含まれる場合は、受注明細1行ごとに振ります。分割納入がある装置では、納入単位で枝番を付けるのも運用の一つです。システム上は受注番号と製番を別の列で持ち、製番を在庫・発注・作業指示の外部キーにすると、受注の変更と製番の変更を分けて扱えます。

製番管理とMRPはどちらが在庫を減らせますか？

部品の共通化率が高い工場ではMRPの方が在庫は減ります。品番単位で全受注の需要を合算し、正味の不足だけを手配するためです。製番管理は受注ごとに部品を囲い込むので、製番間で余りと欠品が並存しやすくなります。ただし一品一様の設計品が中心なら、そもそも共有できる在庫が少ないので差は小さく、受注単位の原価が見える製番管理の利点の方が大きくなります。

製番管理で過剰在庫が生まれやすいのはなぜですか？

受注キャンセルや設計変更で使われなくなった部品が、製番に属したまま残るためです。フリー在庫に戻す処理（解除）を誰も行わないと、帳簿上は「どこかの製番の部品」として棚に眠り続けます。本稿のデータモデルでは移動理由に release（解除）を用意しており、製番の状態を cancelled にするときに製番在庫をフリー在庫へ戻す処理を同じトランザクションで行うと防げます。

Excelで製番管理を続けるとどこで破綻しますか？

引当と転用です。複数人が同じブックを編集すると、同じ在庫を2つの製番に割り当てる二重引当を防げません。転用を記録する列を作っても、承認者と日時を必須にする仕組みが無いため、原価の振替が漏れます。製番数が月に数十件を超え、担当者が2人以上になった時点で、排他制御と移動履歴を持つデータベースへの移行を検討する目安になります。

製番別の原価はどのように集計しますか？

材料費は製番在庫から出庫した部品の取得原価、外注費は製番を付けた外注発注の金額、労務費は製番を付けた作業日報の工数に賃率を掛けて集計します。転用した部品は移動履歴を使って転用元から転用先へ原価を振り替える扱いです。すべての伝票に製番を必須項目として持たせることが前提で、製番の無い伝票を1種類でも許すと、その費用は製番別原価から漏れて間接費に紛れます。