10 人が閲覧(直近 30 日) ERP

ERPモジュール一覧|個別原価計算を回す基幹システム構成とSAP・国産ERP対応表

ERPモジュール一覧|個別原価計算を回す基幹システム構成とSAP・国産ERP対応表

ERPのモジュールは、会計・販売・購買・在庫・生産・人事といった業務単位に機能を切り出した構成部品です。やっかいなのは、同じ「販売管理」でもSAPではSD、GRANDITでは「販売」、OBIC7では「販売情報システム」と呼び名が変わり、区切り方そのものも製品ごとに違う点にあります。さらに受注生産や受託開発の会社では、製品別ではなく案件や製造指図書ごとに原価を集める個別原価計算を基幹システムのどこで持つかが、モジュール選定の分かれ目となる判断事項です。この記事では主要モジュールを分野別に一覧化し、SAPの略号と国産ERPの呼称を対応表で突き合わせたうえで、個別原価計算を回すためのデータの持ち方、モジュール間をつなぐ伝票の流れ、導入の順序までを整理します。

まとめ

モジュール数の多さは、機能の広さを意味しません。ERPの主要モジュールは会計系(財務会計・管理会計・固定資産)、ロジスティクス系(販売・購買・在庫)、製造系(生産・品質保全)、人事系(人事給与勤怠)、プロジェクト系(案件原価)の5系統10分野に整理できますが、1モジュールが受け持つ範囲は製品ごとに大きく違うのが実情です。

たとえばSAPは会計をFI(財務会計)とCO(管理会計)に分けて提供し、GRANDITは債権と債務を別モジュールとして数え、OBIC7は会計情報システムを軸に売上売掛・債権管理・債務管理・連結会計をその内側のサブシステムとして持ちます。比較すべきは数ではなく、自社の業務プロセスのどこからどこまでを1つのモジュールが担うかという範囲です。

個別原価計算を基幹システムで回す場合の結論は3点です。第一に、原価の集計単位となる製造指図書(案件番号)を受注と会計の両方から参照できる共通キーとして設計すること。第二に、直接費は指図書へ直課し、製造間接費は配賦基準を決めて月次で割り付けること。第三に、案件の進捗に応じて売上を計上する会社は、収益認識基準の進捗度と指図書別の実際原価を同じデータから算出できる構成にすること。標準モジュールでこの3点が賄えない業態では、会計はパッケージに任せ、指図書別原価だけを個別開発で持つ構成が現実的です。

ERPモジュール一覧:主要5系統10分野の担当業務と管理対象・出力の対応

まず全体像を一覧にします。分野名は一般的な日本語呼称に揃え、右列に典型的な管理対象と出力を置きました。

系統 モジュール分野 主な管理対象 主要な出力
会計系 財務会計 仕訳・総勘定元帳・債権債務 貸借対照表・損益計算書
会計系 管理会計 原価・部門別損益・予算 原価計算表・予実対比
会計系 固定資産 資産台帳・減価償却 償却明細・固定資産台帳
ロジスティクス系 販売管理 見積・受注・出荷・請求 受注残・売上明細
ロジスティクス系 購買・調達 購買要求・発注・検収 発注残・仕入明細
ロジスティクス系 在庫・倉庫 入出庫・棚卸・ロット 在庫残高・棚卸差異
製造系 生産管理 生産計画・製造指図・部品表 所要量計画・製造実績
製造系 品質・保全 検査記録・設備保全履歴 検査成績・保全計画
人事系 人事・給与・勤怠 人事マスタ・勤怠・支給控除 給与明細・法定調書
プロジェクト系 案件・工数・原価 案件予算・作業時間・進捗 案件別収支・進捗率

この10分野が、いわゆる「ERPの基本機能」に相当します。個別の基幹システムとして構築する場合は、会計システム・販売管理システム・生産管理システム・購買管理システム・人事給与システムという単位になり、上表の分野とほぼ一対一で対応します。分野ごとの機能をさらに細かく知りたい場合はERPの会計機能と部門別採算の作り方を、ERPという仕組み自体の定義から確認したい場合は統合基幹業務システムとしてのERPの意味を参照してください。以下では、実務で判断が分かれやすい系統を個別に補足します。

会計系モジュールが財務会計と管理会計の2つに分かれて提供される理由

会計系は、外部報告のための財務会計と、社内判断のための管理会計に分かれます。財務会計は仕訳と元帳を起点に決算書を作る領域で、勘定科目体系や会計期間は制度に縛られる部分。対する管理会計は原価計算・部門別採算・予算統制を担い、集計軸を自社の裁量で設計できます。

この2つを別モジュールとして分ける代表がSAPで、財務会計をFI、管理会計をCOとして扱ってきました。ただしS/4HANAではUniversal Journal(ACDOCA)の採用によりFIとCOの仕訳明細が単一テーブルへ統合され、両者を突き合わせる作業自体が不要になっています。モジュールとしての区分と、データ構造上の区分は別物だと理解してください。SAP FIの会社コード・元帳・伝票の設定を実装の解像度で知りたい場合はSAP FIとは:会社コード・元帳・会計年度バリアントの設定と伝票の構造を参照してください。

一方、国産ERPでは会計を1つのシステムとしてまとめ、その内側で管理会計を機能として提供する構成が主流です。導入時は「管理会計が追加ライセンスか標準機能か」で費用が変わるため、見積比較では会計モジュールの内訳まで確認してください。個別原価計算は管理会計側の機能に入るため、この内訳確認がそのまま原価計算の可否確認になります。

プロジェクト単位の工数・原価を扱うモジュールと販売管理との守備範囲

受託開発・建設・コンサルティングのように、案件そのものが原価の集計単位になる業種では、会計と販売の間にプロジェクト管理モジュールが入ります。案件ごとに予算を持ち、作業時間と外注費・材料費を紐づけ、進捗に応じた売上計上や案件別粗利の算出を行う領域です。

SAPではPS(Project System)がこれにあたり、OBIC7では販売情報システム配下の「プロジェクト管理型テンプレート」として提供されます。標準の販売管理モジュールは受注番号単位の採算までしか見ないため、案件別の工数集計を求めるなら専用モジュールの有無を初期の要件に入れてください。案件単位の原価集計の考え方はプロジェクト別原価計算の基本構造と総合原価計算との違いで、業種特化の構成は建設業向けERPの選び方と基幹システムとの違いで扱っています。

全モジュール共通の基盤機能:ワークフロー・マスタ・権限・BIの役割

分野別モジュールとは別に、どのモジュールからも使われる横断的な機能があります。製品資料では「機能一覧」の末尾にまとめて置かれることが多く、モジュール比較の際に見落とされがちな部分です。

  • ワークフロー:申請・承認経路の設定。購買要求の承認、経費精算の決裁、人事異動の承認などモジュールをまたいで使われます
  • マスタ管理:取引先・品目・組織・勘定科目の一元管理。統合の効果はここに集約されます
  • 権限・ロール管理:職務分掌に沿ったアクセス制御と操作ログ。内部統制の実装面を担います
  • BI・帳票出力:モジュール横断の集計と定型帳票。経営ダッシュボードの土台になります

これらは単独では業務を持たないため、モジュール数には数えられません。ただし承認経路の柔軟性と権限設計の粒度は、稼働後の運用負荷を大きく左右します。比較検討では分野別モジュールと同じ重みで確認してください。

個別原価計算を基幹システムで回すモジュール構成と原価データの持ち方

「個別原価計算 基幹システム」で調べる読者の多くは、受注生産・一品生産・受託開発の会社で、Excelで集計してきた案件別原価をシステムへ載せたい段階にいる方です。ここでは計算方法そのものではなく、基幹システムのどのモジュールに何を持たせれば個別原価計算が回るかに絞って整理します。計算手順と仕訳の基礎は個別原価計算とは?受注生産の原価集計・仕訳と総合原価計算との違いで詳しく扱っています。

原価計算基準が定める個別原価計算と製造指図書を集計単位にする理由

1962年に企業会計審議会が公表した原価計算基準は、個別原価計算を「種類を異にする製品を個別的に生産する生産形態に適用する」方法と位置づけ、特定製造指図書について直接費と間接費を個別に集計し、指図書に含まれる製品の生産完了時に製品原価を算定するとしています。システムに置き換えると、製造指図書番号が原価の集計キーであり、材料出庫・作業時間・外注請求のすべての伝票がこのキーを持っていなければ計算が成立しない、ということです。

ここで問題になるのがモジュールの分断です。販売管理は受注番号、購買は発注番号、勤怠は社員番号と日付、会計は仕訳番号をそれぞれ主キーにしています。指図書番号を各伝票の明細項目として持たせ、受注から1対1または1対多で指図書を起こす規則を最初に決めておかないと、月末に担当者が伝票を目視で案件へ振り分ける作業が残ります。原価計算表に載せる項目と費目分類は原価計算表の作り方と個別原価計算の集計手順を参照してください。

原価要素 発生元モジュール 指図書への紐づけ方
直接材料費 在庫・購買 出庫伝票に指図書番号を付与
直接労務費 人事・勤怠・工数 作業日報の工数×賃率
直接経費(外注費) 購買 発注明細に指図書番号を付与
製造間接費 会計(部門費) 作業時間などの基準で配賦

製造指図書を軸にした原価テーブルの設計例と間接費配賦を含む集計SQL

パッケージを使う場合でも個別開発する場合でも、データの骨格はどちらの場合も同じ構成です。指図書、原価実績、月次の間接費プールの3テーブルを持ち、直接費は直課、間接費は直接作業時間の比率で配賦する最小構成を示します。PostgreSQLとSQLiteの両方で動く標準的なSQLで書いており、末尾のSELECTを実行すると指図書ごとの原価と、完成品か仕掛品かの区分が返ります。

-- 製造指図書(個別原価計算の集計単位)
CREATE TABLE job_order (
  job_no      VARCHAR(20) PRIMARY KEY,
  sales_order VARCHAR(20) NOT NULL,
  status      VARCHAR(10) NOT NULL  -- OPEN=仕掛中 DONE=完成
);
-- 原価実績(直接費を指図書へ直課する)
CREATE TABLE cost_actual (
  job_no      VARCHAR(20) NOT NULL REFERENCES job_order(job_no),
  period      CHAR(7)     NOT NULL,  -- 会計期間 例 2026-09
  cost_type   VARCHAR(3)  NOT NULL,  -- MAT=材料 LAB=労務 EXP=経費
  amount      NUMERIC(14,0) NOT NULL,
  labor_hours NUMERIC(8,2)  NOT NULL DEFAULT 0
);
-- 製造間接費の月次実績
CREATE TABLE overhead_pool (
  period CHAR(7) PRIMARY KEY,
  amount NUMERIC(14,0) NOT NULL
);

INSERT INTO job_order VALUES ('J-001','SO-1001','DONE'), ('J-002','SO-1002','OPEN');
INSERT INTO cost_actual VALUES
  ('J-001','2026-09','MAT',400000,0),
  ('J-001','2026-09','LAB',300000,60),
  ('J-001','2026-09','EXP', 50000,0),
  ('J-002','2026-09','MAT',150000,0),
  ('J-002','2026-09','LAB',100000,20);
INSERT INTO overhead_pool VALUES ('2026-09',240000);

-- 直接作業時間基準で間接費を配賦し、指図書別原価を集計する
WITH direct AS (
  SELECT job_no,
         SUM(CASE WHEN cost_type = 'MAT' THEN amount ELSE 0 END) AS material,
         SUM(CASE WHEN cost_type = 'LAB' THEN amount ELSE 0 END) AS labor,
         SUM(CASE WHEN cost_type = 'EXP' THEN amount ELSE 0 END) AS expense
  FROM cost_actual
  GROUP BY job_no
),
hours AS (
  SELECT job_no, period, SUM(labor_hours) AS h
  FROM cost_actual
  GROUP BY job_no, period
),
total AS (
  SELECT period, SUM(h) AS total_h
  FROM hours
  GROUP BY period
),
alloc AS (
  SELECT hr.job_no,
         SUM(ROUND(op.amount * 1.0 * hr.h / t.total_h, 0)) AS overhead
  FROM hours hr
  JOIN total t          ON t.period  = hr.period
  JOIN overhead_pool op ON op.period = hr.period
  WHERE t.total_h > 0
  GROUP BY hr.job_no
)
SELECT j.job_no,
       d.material, d.labor, d.expense,
       COALESCE(a.overhead, 0) AS overhead,
       d.material + d.labor + d.expense + COALESCE(a.overhead, 0) AS job_cost,
       CASE WHEN j.status = 'DONE' THEN '製品' ELSE '仕掛品' END AS account
FROM job_order j
JOIN direct d     ON d.job_no = j.job_no
LEFT JOIN alloc a ON a.job_no = j.job_no
ORDER BY j.job_no;

このサンプルでは9月の間接費240,000円を作業時間60時間と20時間の比率で割り付け、J-001が930,000円(完成なので製品へ振替)、J-002が310,000円(月末仕掛品として繰越)になります。実務ではここに予定配賦率と配賦差異、仕損費の処理、複数月にまたがる仕掛品の累計が加わりますが、骨格は変わりません。配賦基準を作業時間にするなら、勤怠ではなく案件別の作業日報から時間を取る点が設計上の要所で、勤怠モジュールしか持たない構成では指図書別の時間が取れず、配賦が成立しません。

SAP・GRANDIT・OBIC7で個別原価計算を受け持つモジュールと設定の差

SAPでは管理会計のCOのうち製品原価管理(CO-PC)が個別原価計算を受け持ち、製造指図ごとに原価を集める指図別原価計算と、受注明細ごとに原価を集める受注別原価計算を選べます。SAP公式トレーニングのS4F25 Cost Object Controlling in SAP S/4HANAが、この原価対象管理の範囲を扱うコースとして案内されています。案件型の業種では、プロジェクトのWBS要素を原価の受け皿にするPSを併用する構成が一般的です。

GRANDITは公式サイトで販売・調達在庫・製造の機能を1ページにまとめ、製造では多階層の部品構成表、受注や販売見込から生成する製造計画、所要量計算(MRP)を掲げています。同ページの機能説明には個別原価計算の記載が見当たらないため、指図書別の実際原価まで求める場合は、経理モジュールの管理会計機能やアドオン、業種テンプレートでどこまで受けられるかを見積時に名指しで確認してください。OBIC7は生産情報システムとプロジェクト管理型テンプレートのどちらで受けるかが、製造業か受託業かで分かれます。

3製品に共通する注意点は、個別原価計算の可否が「生産管理モジュールがあるか」ではなく「指図書や案件に原価を集める受け皿と配賦の仕組みが標準にあるか」で決まることです。生産管理を入れても、原価は品目別の標準原価でしか持てない構成は珍しくありません。

収益認識基準の進捗度による売上計上と指図書別の実際原価をつなぐ設計

受注制作のソフトウェアや工事のように、案件の進捗に応じて売上を計上する会社では、個別原価計算の結果がそのまま売上の計算根拠になります。かつての工事進行基準を定めた企業会計基準第15号「工事契約に関する会計基準」は、企業会計基準委員会が公開する企業会計基準第29号「収益認識に関する会計基準」の第90項で廃止とされ、現在は2021年4月1日以後開始する事業年度から、一定の期間にわたり充足される履行義務について進捗度を見積り、その進捗度に基づいて収益を認識する扱いになっています(第41項、2026年10月時点の公表内容)。

システム設計に落とすと、原価比例法で進捗度を測る場合は「指図書別の発生原価累計 ÷ 見積総原価」が進捗度になり、前段のSQLで出した指図書別原価がそのまま分子になります。見積総原価は案件ごとに改訂履歴を持たせ、決算日ごとの見直しを記録できる構造にしてください。会計モジュールと原価の受け皿が別システムに分かれていると、この比率の算出が月末のExcel作業に戻ってしまいます。

製品別モジュール名称の対応表:SAP・GRANDIT・OBIC7の呼称と区切り方

モジュール一覧で迷いが生じるのは、製品ごとに呼称と区切り方が違うためです。代表的な3製品の公開情報を突き合わせると、次のようになります。

業務分野 SAP(略号) GRANDIT OBIC7
財務会計 FI 経理 会計情報システム
管理会計・原価 CO 経理(内包) 管理会計システム
債権 FI内 債権 債権管理システム
債務 FI内 債務 債務管理システム
固定資産 FI内 資産 固定資産管理システム
経費精算 FI-TV 経費 経費支払・予算管理
販売管理 SD 販売 販売情報システム
購買・在庫 MM 調達・在庫 販売情報システム内
倉庫管理 EWM 調達・在庫内 販売情報システム内
生産管理 PP・PP/DS 製造 生産情報システム
品質管理 QM 製造で対応 生産情報システム内
設備保全 PM 区分掲載なし 区分掲載なし
プロジェクト PS 区分掲載なし プロジェクト管理型テンプレート
人事 HR(HCM) 人事 人事情報システム
給与 HR内 給与 給与情報システム
勤怠 HR内 人事内 就業情報システム

表の「区分掲載なし」は、各社が公開するモジュール区分の一覧に該当名称が載っていないという意味で、その機能を提供していないという意味ではありません。個別ソリューションやアドオン、業種別テンプレートで対応する場合があるため、要件に含まれるなら見積時に名指しで確認してください。なお経費精算のSAP列にあるFI-TV(Travel Management)は標準機能ですが、実務ではクラウドのSAP Concurを併用する構成も一般的です。

表から読み取れるのは、粒度の設計思想が3者で違うという事実です。GRANDITは経理・資産・経費・債権・債務・人事・給与・販売・調達・在庫・製造をモジュールとして掲げ、公式サイトでは販売・調達在庫・製造、経理・資産・経費、債権・債務、人事・給与という4つの機能群に分けて紹介しています。オービックのOBIC7は会計情報システム・固定資産管理システム・人事情報システム・給与情報システム・就業情報システム・販売情報システム・生産情報システムという業務システム単位で構成し、会計情報システムの内側に流動資産・管理会計・売上売掛管理・債権管理・債務管理・連結会計といったサブシステムを持ちます。

主要ERPパッケージの区分方式の違い:略号型・スイート型・業務システム型

製品を横断で見ると、モジュールの切り方には型があります。個別の製品比較に入る前に、この型を押さえておくと機能一覧の読み違いを防げます。

製品 区分方式 特徴
SAP S/4HANA 略号型 FI・CO・SD・MMなど機能領域で細分
Oracle NetSuite スイート型 基幹に会計を据えCRM・HRを追加
Microsoft Dynamics 365 業務アプリ分割型 財務とサプライチェーンが別アプリ
GRANDIT モジュール型 必要なモジュールを選んで構成
OBIC7 業務システム型 会計・人事・販売など業務単位で構成

略号型は必要な機能だけを精密に選べる反面、モジュール間の役割分担を理解していないと見積の抜けが出ます。業務システム型は単位が大きく分かりやすい代わりに、使わない機能も抱き合わせになりがちです。製品ごとの詳細比較や選定の進め方はERPパッケージの概要と特徴、タイプ別の分類はERPの種類・分類ごとの特徴で扱っています。

SAPモジュール略号と日本語名称の対応、S4HANA世代での再編と保守期限

SAPの略号は英語の頭字語で、日本語の一般名称と一対一で対応しません。実務で登場頻度の高いものを整理します。

略号 英語名称 日本語での位置づけ
FI Financial Accounting 財務会計
CO Controlling 管理会計・原価管理
SD Sales and Distribution 販売管理
MM Materials Management 在庫購買管理
PP Production Planning 生産管理
PP/DS Detailed Scheduling 詳細生産スケジューリング
QM Quality Management 品質管理
PM Plant Maintenance プラント保全
PS Project System プロジェクト管理
EWM Extended Warehouse Mgmt 拡張倉庫管理
HR(HCM) Human Capital Management 人事管理
CS Customer Service サービス管理

S/4HANAでは構成が動いています。外部製品として提供されていたEWMとPP/DSは本体に取り込まれ、S/4HANA内で動くembedded構成と、別サーバで動かすdecentralized構成の両方が選べます。HRについてはクラウドのSAP SuccessFactorsへ寄せる案内が出ており、CSもS/4HANA世代ではService Managementとして再編されました。

バージョン移行の期限も押さえてください。SAPは2020年2月の発表SAP Extends SAP S/4HANA Maintenance Through 2040で、SAP Business Suite 7のコアアプリケーションの標準保守を2027年末まで提供し、2028年から2030年末までは保守基準料率に2ポイントを上乗せする延長保守を選べること、後継のS/4HANAは2040年末まで保守を維持することを明らかにしています。EHP適用のない6.0およびEHP1〜5は2025年12月31日で標準保守が終了し、RISE with SAPへ移行する場合には2033年まで猶予を得られる別枠のオプションも案内されています。保守条件は改定されるため、契約判断の前にSAPの公式アナウンスで最新の期日と適用条件を確認してください(2026年10月時点の情報)。

基幹システムとERPモジュールの守備範囲の境界とマスタ・伝票の持ち方

「基幹システムの一覧」と「ERPのモジュール一覧」は近い言葉ですが、指しているものが違います。基幹システムは会計システム・販売管理システムのように業務ごとに独立して構築された個別システムを指すことが多く、ERPモジュールは1つのデータベースを共有する統合システムの構成部品を指します。

実務上の差は、マスタと伝票の持ち方です。個別の基幹システムでは取引先マスタや品目マスタがシステムごとに存在し、更新はCSV連携やAPI連携での同期が前提。ERPモジュールでは同じマスタを共有するため、販売で登録した取引先がそのまま債権管理の相手先です。この統合の度合いが、月次締めのリードタイムと突合作業の量に直結します。個別原価計算でいえば、指図書番号を共有マスタとして全モジュールが参照できるかどうかが、この差の典型例です。個別システム間をつなぐ場合の考え方はERPの連携機能と業務効率化の関係で詳しく整理しています。

ERPモジュールで賄わない方がよい領域:WMS・CRM・MESを切り出す判断

モジュールが揃っているからといって、すべてを1製品に寄せるべきではありません。最も判断を誤りやすいのが倉庫運用(WMS)です。庫内オペレーションはハンディターミナルでの逐次更新、ロケーション単位のロット・シリアル追跡、作業指示の動的な組み替えといった要求が中心で、月次の在庫残高を正しく持つことを目的とするERPの在庫モジュールとは設計思想が異なります。専用WMSを採用し、ERPとは在庫残高と入出庫実績のサマリで連携する構成が現実的です。

根拠はベンダー自身の製品構成にも表れています。SAPは倉庫運用をEWMという独立した機能領域として維持し、embeddedとdecentralizedの2形態を用意したうえで、人事はSuccessFactorsという別クラウドへ移す構成を採っています。広義のERPを提供するベンダーですら、要求特性の異なる領域は分離しているということです。

顧客管理(CRM)と製造実行(MES)も同様の判断が要ります。CRMは商談履歴の更新頻度が高く画面要件が営業寄りになるため、受注以降だけをERPへ渡す切り分けが有効です。MESは設備からの実績収集が秒単位になるケースがあり、ERP側は製造指図と完了実績の単位で受ければ足ります。判定の基準は取引件数の多寡ではなく、リアルタイム更新が業務要件に含まれるかどうかです。

原価管理も切り出しを検討する候補の一つです。標準原価と差異分析を軸にする量産型の会社はERPの管理会計で足りる一方、指図書別の実際原価と見積原価の対比を日次で追う受注生産型の会社では、専用の原価管理システムを置いてERPには月次の確定原価だけを渡す構成が選ばれます。専用システムの機能範囲と選び方は原価管理システムとは?機能・原価計算との違いから選び方までで整理しています。

ERPの階層構成とモジュール間データ連携:受注から入金、発注から支払まで

「モジュールが連携する」という説明は抽象的になりがちですが、実体は共有データベースの上に伝票が積み上がる構造です。まず構成を階層で示します。

階層 構成要素 役割
外部連携層 WMS・MES・CRM・銀行 専用領域との実績交換
モジュール層 会計・販売・購買・在庫・生産・人事 業務ごとの伝票処理
基盤層 ワークフロー・BI・権限管理 モジュール横断の共通機能
データ層 統合データベース・各種マスタ 単一の正データの保持

ベンダー各社が公開する構成図も、名称は違えどこの4階層に整理できます。図を見る際は、描かれた箱が標準ライセンスに含まれるのかオプションなのかを見積書と突き合わせ、外部連携層に置かれた製品が別ライセンスかどうかも併せて確認してください。次に、モジュール層で伝票がどう流れるかを2つの業務で追います。

受注から入金までの販売プロセスの流れと各ステップで起票される伝票

販売管理モジュールで受注を登録すると、在庫モジュールで引当が立ちます。出荷を計上した時点で在庫が減り、同時に売上原価の仕訳が会計モジュールへ渡る仕組み。請求処理で売上と債権が計上され、入金消込によって債権が落ちます。

業務ステップ 起票モジュール SAPでの伝票 生成されるデータ
受注登録 販売管理(SD) 受注伝票 受注残・引当
出荷計上 在庫(MM) 出荷伝票 在庫減・売上原価
請求発行 販売管理(SD) 請求伝票 売上・売掛金
入金消込 財務会計(FI) 入金伝票 債権消込

この連鎖があるため、販売管理モジュールだけを単独導入しても会計側の効果は限定的です。会計と販売を同時に入れれば、請求伝票から売上仕訳が自動生成されるので、販売システムの数字を会計システムへ転記する工程そのものが消えます。受注生産の会社では、受注登録の時点で製造指図書を起こし、出荷時の売上原価に指図書別の実際原価を引き当てる流れになります。導入範囲を決めるときは、この伝票の連鎖がどこで切れるかを先に確認してください。

発注から支払までの購買プロセスの流れと三点照合を自動化する仕組み

購買側は、購買要求から始まり、発注・入荷検収・請求書照合・支払という順で伝票が流れます。検収の時点で在庫が増え、請求書照合で債務が確定し、支払処理で債務が落ちる構造です。

ここで効くのが三点照合、すなわち発注・入荷・請求書の3つの数量と金額を突き合わせる仕組みです。個別システムのままでは目視や表計算での照合になりますが、購買モジュールと会計モジュールが同一データベースを共有していれば、差異のある請求書だけを自動で保留にできます。SAPでの許容範囲キーと支払ブロックの設定例はSAP MMとは:購買発注・入庫・請求書照合の伝票フローと組織・勘定決定の設定で取り上げています。実装面では、数量差異と金額差異それぞれに許容範囲を伝票種別ごとに設定し、範囲内は自動で通し、範囲外だけを担当者へ回す形が一般的。外注費を指図書へ直課する会社では、発注明細に指図書番号を必須項目として持たせておくと、検収と同時に案件原価へ計上されます。仕入計上の精度と検収漏れの検知は、購買モジュールを入れる金額的な根拠になりやすい部分です。

導入するモジュールの選定と段階導入の順序、個別原価計算の載せ方の判断

全モジュールを一度に稼働させる必要はありません。必要な機能だけを選んで組み合わせる構成は一般にコンポーネント型と呼ばれ、統合型・業界特化型との違いはERPの種類・分類ごとの特徴で整理しています。

順序の考え方は明快です。全社の伝票が最後に集まる会計モジュールを先に据え、その上流にあたる販売・購買を接続し、業種固有の生産やプロジェクトを最後に載せます。会計を後回しにすると、先行導入したモジュールから出る仕訳を既存の会計システムへ流すための一時的な連携を作ることになり、その開発は本稼働時にすべて捨てられます。

もう1つの典型的な失敗が、販売管理だけを先行させて会計を旧システムに残したまま長期運用に入るケースです。売上計上のタイミングが両システムでずれ、月次で差異調整の作業が新たに生まれます。暫定期間は長くても数か月に区切り、会計移行の期日を先に決めてから販売の稼働日を置いてください。

選定時に確認すべき点を挙げます。まず1と3を見積書で確定させ、2・4・5・6は要件定義で詰める順序が効率的です。

  • 会計モジュールに管理会計・固定資産・債権債務がどこまで含まれるか(追加ライセンスの有無)
  • 勤怠が人事モジュールに内包されるか、就業として別売りか
  • プロジェクト別・指図書別の工数・原価集計が標準機能かオプションか
  • 倉庫運用や製造実行を外部パッケージへ切り出す場合の連携インターフェース
  • 電子帳簿保存法・インボイス制度への対応が標準提供か個別対応か
  • 進捗度による収益認識で、見積総原価の改訂履歴を保持できるか

提供形態によって初期費用と運用体制も変わります。クラウドとオンプレミスの比較はクラウド型ERPの導入ポイントとメリット・デメリットを確認してください。

個別原価計算をパッケージで受けるか、基幹システムを開発するかの判断基準

判断は、原価の集計単位がパッケージの想定と一致するかで決まります。パッケージで受けてよいのは、指図書の起こし方が「1受注1指図書」に近く、配賦基準が部門ごとに1つで足り、案件の見積原価の改訂が月1回程度に収まる会社です。この条件ならSAPのCO-PCやPS、国産ERPのプロジェクト管理テンプレートの標準設定で回り、アドオン費用を抑えられます。

個別開発を検討すべきなのは、1つの受注が設計・製造・据付のように複数の指図書へ分かれ、工程ごとに配賦基準が違う会社や、受託開発のように工数が原価の大半を占め、作業日報と案件原価を日次で突き合わせたい会社です。こうした業態でパッケージへ寄せると、アドオンが増えて保守期限のたびに改修費がかさみます。会計・債権債務はパッケージに任せ、指図書別原価と工数管理だけを自社の業務に合わせた基幹システムとして開発し、月次の確定原価を仕訳で会計へ渡す構成が、改修範囲を最も小さくできる構成です。一創の基幹システム開発では、既存の会計パッケージを残したまま原価管理や販売管理を業務に合わせて構築する進め方に対応しています。

見送りの判断も明確にしておきます。年間の案件数が少なく、Excelの原価計算表で月次締めが3営業日以内に終わっている会社は、システム化の前に指図書番号の採番規則と作業日報の様式を揃えるだけで効果の大半が得られます。システム投資はその運用が定着し、件数の増加で締めが遅れ始めた段階で判断しても遅くありません。

よくある質問

ERPのモジュールは全部で何個ありますか?

製品によって異なり、共通の正解はありません。GRANDITは経理・資産・経費・債権・債務・人事・給与・販売・調達在庫・製造をモジュールとして掲げ、オービックのOBIC7は会計情報・固定資産管理・人事情報・給与情報・就業情報・販売情報・生産情報といった業務システム単位で構成しています。SAPはFI・CO・SD・MM・PPなど10を超える略号で区分します。数の多さは機能の広さを意味しないため、モジュール数ではなく1モジュールが担う業務範囲で比較してください。

個別原価計算は基幹システムのどのモジュールで行いますか?

計算そのものは管理会計(SAPではCOの製品原価管理)またはプロジェクト管理モジュールで行い、材料・外注・工数の実績は在庫・購買・工数管理の各モジュールから製造指図書番号付きで集めます。どのモジュールで計算するかより、すべての原価伝票に指図書番号を持たせられるかが成否を分ける判断軸です。標準機能で受け皿が持てない場合は、原価管理だけを専用システムとして構築し、会計へは月次の確定原価を仕訳で渡す構成を選びます。

基幹システムをERPへ寄せるとき、最初に統合すべきマスタは何ですか?

取引先マスタと品目マスタです。この2つは販売・購買・在庫・会計のすべてが参照するため、コード体系が揃っていないと伝票の自動連携が成立しません。移行作業では、旧システムごとに重複登録された取引先の名寄せと、廃番品目の整理に最も時間がかかります。受注生産の会社では、これに加えて製造指図書や案件番号の採番規則を統合初期に決めておくと、個別原価計算の移行がスムーズに進みます。

最小構成でERPを始める場合、どのモジュールから入れるべきですか?

会計モジュールに債権管理と債務管理を加えた3点が基本の最小構成です。全社の伝票が最終的に集まる先を先に固めると、後から販売・購買を接続する際に一時的な連携開発が不要になります。逆に販売管理だけを先行させると、売上計上が二重管理になり月次で差異調整が発生します。

工事進行基準での売上計上はERP標準でどこまで賄えますか?

工事進行基準を定めた企業会計基準第15号は収益認識会計基準の適用に伴って廃止され、2021年4月1日以後開始する事業年度からは、一定の期間にわたり充足される履行義務について進捗度に基づき収益を認識する扱いです。プロジェクト管理モジュールを導入すれば、案件の見積総原価と実際原価から進捗度を算出し、その比率で売上を計上する処理まで標準で行える製品が多くあります。SAPではPS、OBIC7では販売情報システム配下のプロジェクト管理型テンプレートが該当します。進捗度を原価比例法で測るかアウトプット法で測るかで設定が変わるため、会計方針を確定させてから設定要件を詰めてください。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

ほか 5 件の記事からもリンクされています。

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2025.02.27 コラム トラッキングビーコン(Webビーコン)とは?仕組み・用途・確認と対策を徹底解説
  2. 2026.10.27 テックブログ Brotli 脆弱性:CVE-2026-111497の影響確認とNode.js・Python・.NETの更新手順
  3. 2026.10.27 テックブログ Joshin(ジョーシン)不正アクセス:最大600万件の対象とサブスク初期パスワードの対処
  4. 2026.07.09 テックブログ Muse Imageとは?Metaの画像生成AIの使い方・API料金(1枚0.01ドル)と日本での提供状況【2026年10月】
  5. 2026.10.23 テックブログ Renta!はいつ再開?不正アクセスでメールアドレス等が流出したおそれ・再開時のパスワード再設定と運営側の対応

RELATED POSTS 関連記事

目次