2026.07.24 DX

医薬品業界の受発注システムの選び方｜JD-NET・ロット管理・卸/医療機関別の要件と受託開発の判断

医薬品業界の受発注は、一般的な卸売や製造業とは前提が違います。JD-NETをはじめとする業界標準EDI、ロット番号と使用期限の厳密な管理、年に複数回動く薬価への追随、卸ごとに異なる納入先コードの変換——汎用の受発注システムがそのままでは扱いきれない要件が積み重なるためです。この記事では、医薬品メーカー・医薬品卸・医療機関それぞれで求められる受発注の要件を整理し、パッケージで足りる範囲と、スクラッチや受託開発に切り替えるべき分岐を判断基準つきで示します。受発注システムの一般的な定義や種類は受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準で押さえたうえで、本記事は医薬品業界固有の論点に絞って読み進めてください。

まとめ：医薬品業界の受発注システム選定で先に押さえる要点

医薬品の受発注システムは、汎用の販売管理パッケージに「業界EDI連携」と「ロット・使用期限管理」を後付けできるかどうかで選定の筋が変わります。取引の大半がJD-NETやプラネットなどの業界VAN経由なら、これらへの標準対応があるパッケージを軸に据えるのが近道です。

一方で、卸ごとに違う納入先コードの変換、複数倉庫への出庫配分、返品・薬価差の精算といった自社固有の商習慣が絡むと、パッケージの標準機能だけでは運用が回りません。標準EDIは既製品で受け、固有の業務ロジックだけを個別開発で足す——この切り分けが、医薬品業界で過剰投資を避ける現実的な進め方です。判断に迷う領域と、自社開発へ踏み込む条件は本文の後半で具体的に示します。

医薬品業界の受発注システムが一般の販売管理システムと異なる理由

医薬品は生命関連商品であり、取引データの正確性とトレーサビリティに一般の物販とは違う水準が求められます。まず前提として、どこが異なるのかを整理します。

生命関連商品ゆえに求められるロット・使用期限管理とトレーサビリティ

医薬品の受発注では、商品コードや数量だけでなくロット番号と使用期限が取引単位に紐づきます。出荷は先入先出を基本とし、使用期限の逆転（新しいロットを先に出して古いロットが倉庫に残る）を防ぐ制御が要ります。回収が発生した際に、どの医療機関へどのロットが渡ったかを遡れるトレーサビリティも外せない機能です。汎用の受発注パッケージはロット管理を持たない、または簡易な入出庫記録に留まることが多く、この一点だけで選択肢が絞られます。

年に複数回改定される薬価と得意先別・数量別の複数単価への追随

医療用医薬品には薬価基準が定められ、改定のたびに単価の再設定が発生します。加えて医薬品卸の取引では、得意先ごと・数量ごとに異なる仕切価や、後から精算する薬価差（仕切価と実際の販売価格の差）も扱わなければなりません。単一の商品マスタに1つの単価しか持てない仕組みでは、運用は回りません。得意先別・数量別の複数単価を保持し、薬価改定日を境に新旧単価を切り替えられることが、医薬品向け受発注システムの前提条件になります。

業界標準EDI（JD-NET・プラネット・流通BMS）への対応要件

医薬品業界の受発注は、企業ごとの個別接続ではなく業界共通のネットワーク基盤の上で動いています。ここへの対応が、システム選定の分かれ目になります。

JD-NETをはじめとする医薬品業界VANの位置づけと接続の起点

JD-NET（医薬品業界データ交換システム）は、製薬メーカーと医薬品卸との間で発生する受発注データなどをやり取りする業界VANで、NTTデータが運営し1988年（昭和63年）にサービスを開始しています。利用企業数・データ件数ともに国内最大級とされ、メーカーと卸の商取引を支える基盤として機能しています。医療用医薬品を扱う事業者にとって、自社システムがJD-NETと接続できるかは選定の起点です。ほかにプラネットが運営するVANや、医療機関・調剤薬局向けのVANも併存しており、取引相手に応じて複数の業界ネットワークへ対応する必要が生じます。

複数の業界VANの併存と卸ごとに異なる納入先コード変換の負担

業界VANが複数あり、さらに卸ごとに独自の通信フォーマットや納入先コード体系が残るため、相互の互換性は完全ではありません。メーカー側はデータ受信後に、相手先コードを自社の商品コード・得意先コードへ変換する処理を挟むのが実情です。変換ルールは各社の取引構成によって違い、パッケージの標準機能には収まりにくい領域になります。EDIの受け口は既製品で確保しつつ、コード変換テーブルと例外処理を自社仕様で組む——医薬品業界の受発注システムで開発ボリュームが膨らみやすいのは、多くの場合この変換部分です。

業界EDIと併存するFAX・電話受注を受注データへ集約する設計

業界EDIの整備が進む一方で、小規模な取引先や緊急発注ではFAX・電話が現役で残ります。受発注システムを入れても受注チャネルが一本化されないため、EDI受注とFAX受注を同じ受注データベースに集約し、二重入力を減らす設計が実務では効きます。EDI対応の有無だけでなく、非EDIチャネルをどう取り込むかまで含めて要件化すると、導入後の入力工数の見積もりがぶれません。

受注する卸と発注する医療機関で分かれる受発注システムの要件差

「医薬品の受発注」と一括りにされがちですが、発注する側（医療機関）と受注・供給する側（卸・メーカー）では、システムに求めるものが分かれます。

医薬品卸・メーカー側に求められる受注から在庫引き当て・出荷の統合

卸やメーカー側は、業界EDIからの受注取り込み、ロット単位の在庫引き当て、複数倉庫への出庫配分、返品処理までを一気通貫で回す必要があります。温度帯管理が必要な品目では、保管条件を満たす倉庫・ロケーションを踏まえた引き当ても論点です。ここは製造業の受発注と課題の構造が近く、生産・在庫との連携設計の考え方は製造業向け受発注システムの選び方｜内示・かんばん・生産管理連携の課題と判断基準と共通します。医薬固有の制約（ロット・使用期限・薬価）を、在庫・出荷ロジックへどう織り込むかが設計の勘所になります。

医療機関・調剤薬局側に求められるWeb発注の操作性と発注の一元化

発注する医療機関・調剤薬局側では、システムの重心が変わります。求められるのは、パソコンやタブレット・スマートフォンから在庫や納品予定を見ながら発注できる操作性、発注履歴からの再発注、複数卸への発注の一元化です。実際に医薬品卸が提供するWeb発注サービスには、2万軒を超える医療機関が利用する規模のものもあります。医療機関向けの発注システムを検討する場合は、卸側の基幹システムとの機能配分（在庫の見せ方・締め時間・欠品時の代替提案）を先に決めておくと、後工程の開発範囲がはっきりします。

医薬品向けパッケージで足りる範囲とスクラッチ受託開発への分岐

医薬品向け受発注システムは、すべてを自社開発する必要はありません。過剰投資を避けるには、既製品で受ける部分と個別開発する部分の線引きを最初に引くことです。ここでは判断を言い切ります。

業界EDI標準対応のパッケージ・クラウド型サービスで足りるケース

次の条件がそろうなら、業界EDI標準対応をうたう医薬品向けパッケージやクラウド型サービスで足ります。無理に個別開発へ広げると、保守費と改定追随の負担だけが増えます。

  • 取引先が業界標準EDI（JD-NETなど）に収まり、独自フォーマットの相手が少ない
  • ロット・使用期限管理と薬価改定対応が、パッケージの標準機能でカバーできる
  • 倉庫が単一〜少数で、出庫配分や温度帯別の在庫ロジックが単純
  • 会計・基幹システムとの連携が、標準のCSV連携やAPIで足りる

この場合の判断材料は機能適合よりむしろ費用対効果です。パッケージ費用と個別開発費の見積もりの立て方は受発注システム開発の費用相場は？スクラッチ・クラウドの内訳と外注依頼先の選び方で内訳を確認してください。

固有ロジックが多くスクラッチ・受託開発へ切り替えるべきケース

反対に、次のいずれかに当てはまるとパッケージの標準機能では運用が回らず、個別開発の比重が上がります。

  1. 卸ごとに異なる納入先コードの変換や、独自VANとの接続を複数抱えている
  2. 薬価差・返品・センターフィーなど、精算ロジックが自社固有で複雑
  3. 既存の基幹・倉庫管理（WMS）や医療機関向けWeb発注と、リアルタイムに近い在庫連携が要る
  4. 複数倉庫への出庫配分や温度帯別の引き当てに、独自の優先ルールがある

現実的な折衷案は、EDIの受け口とロット管理は既製品で確保し、コード変換・精算・在庫連携という自社固有ロジックだけを受託開発で足す構成です。全面スクラッチは、上記が複数重なり、かつ取引規模が大きくて改修頻度が高い事業者に限られます。判断がつかない領域を切り出して個別開発する進め方は、一創の受発注システム開発でも、既存資産の調査から要件の切り分けまで支援しています。

医薬品の受発注システム導入で起きやすい失敗と回避のための順序

医薬品向け受発注システムの導入でつまずくのは、機能不足よりも要件の順序を誤るパターンです。よくあるのは、EDI連携を後回しにしてパッケージを選び、後から独自フォーマットの卸が扱えず作り直しになるケース。もう1つは、薬価改定や複数単価の運用を軽く見積もり、改定のたびに手作業が発生するケースです。回避の順序は、（1）取引先ごとのEDI・フォーマットを棚卸しし、（2）ロット・使用期限・薬価という譲れない要件を先に固定し、（3）そのうえでパッケージ適合を判定して個別開発の範囲を最後に決める——この順で進めると手戻りが減ります。

よくある質問

医薬品業界の受発注システムについて、検討段階で寄せられることの多い質問に答えます。

医薬品の受発注に一般的な販売管理システムを流用できますか？

ロット番号と使用期限の管理、薬価改定に伴う複数単価の切り替え、業界EDIへの接続がそろわないと、医薬品の受発注では運用が回りにくくなります。汎用の販売管理システムでも、これらを拡張できる製品や、個別開発で補える基盤であれば流用は可能です。まず自社取引でこの3点が必須かを確認し、足りない機能を後付けできる製品かどうかで判断してください。

JD-NETに対応していれば取引先の卸すべてとつながりますか？

JD-NETは医薬品業界の主要な業界VANですが、プラネットのVANや医療機関・調剤薬局向けのVANも併存し、卸ごとに独自フォーマットや納入先コードが残る場合があります。JD-NET対応は起点になりますが、取引先の構成によっては複数のネットワークへの対応やコード変換が別途必要です。取引先ごとの接続方式を先に棚卸ししておくと、対応範囲を見誤りません。

医薬品卸向けと医療機関向けでシステムは分けるべきですか？

受注・在庫・出荷を担う卸・メーカー側と、発注する医療機関・調剤薬局側では、求める機能が異なります。卸側は在庫引き当てや出庫配分の統合、医療機関側は複数卸への発注の一元化とWeb発注の操作性が中心です。両方を1つのシステムで賄うより、役割ごとに機能を配分し、在庫の見せ方や締め時間の取り決めを先に決めるほうが開発範囲が明確になります。

クラウド型とスクラッチ開発はどう選び分ければよいですか？

取引先が業界標準EDIに収まり、ロット・薬価対応が標準機能で足りるならクラウド型やパッケージが向きます。独自VANやコード変換、自社固有の精算・在庫連携を複数抱えるなら、EDIの受け口は既製品で確保し、固有ロジックだけを個別開発する折衷が現実的です。全面スクラッチは、これらが重なり改修頻度が高い大規模事業者に限られます。

既存の基幹システムや倉庫管理と連携できますか？

会計・基幹システムや倉庫管理（WMS）との連携は、標準のCSV連携やAPIで足りる場合と、リアルタイムに近い在庫連動が必要で個別開発になる場合に分かれます。方式を左右するのは、連携頻度と、在庫のずれをどこまで許容できるかです。既存システムの連携仕様を先に把握し、標準連携で届く範囲か個別開発が要るかを見極めてから製品を選べば、後戻りを避けられます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る