◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 納品書の導入は製品選びより前に、役割・起点データ・記載項目・渡し方・請求や検収とのつなぎ方を要件定義で決める。
- 分納や数量変更のたびに直す場所が二つ以上あるなら、作業を速くするより起点データを見直す段階にある。
- 電子で渡す場合は電子取引としての保存の扱いが関わるため、範囲や要件は国税庁の一問一答と税理士で確認し、控えの残し方を要件の一覧に入れる。
- 現行改善・既存システムへの機能追加・新規導入は、起点データの所在と得意先の受け入れ方で選び分ける。
- 受注番号と明細行を納品書・請求へ引き継ぎ、数社の試行と紙をやめる判断基準を決めてから移行を広げる。
目次

納品書の発行が回らなくなったとき、導入を検討すべき状態の見分け方
出荷のたびに納品書をExcelへ転記して印刷し、箱に同梱する。
得意先ごとに書式が違い、月末には請求との突合で問い合わせが来る。
この状態から納品書の発行システム導入を考えるとき、成否を分けるのは製品選びより前の要件定義です。
納品書の役割、発行の起点データ、記載項目、得意先への渡し方、請求・検収とのつなぎ方を業務の流れに沿って決めます。
そのうえで、現行改善・既存システムへの機能追加・新規導入から選びます。
電子で渡すなら電子帳簿保存法上の電子取引の扱いが関わるため、渡し方を決める段階で確認します。
印刷・同梱・転記で起きている症状
「納品書が回らない」と感じるとき、その中身は大きく二つに分かれます。
一つは、出荷件数に比例して増える作業量の問題です。
印刷し、出荷する箱と突き合わせ、同梱するという手順そのものが追いつかない状態を指します。
もう一つは、同じ情報を別の場所へ打ち直している構造の問題です。
こちらは件数が少なくても、修正漏れや食い違いが起きます。
どちらに当たるかで、取るべき手段が変わります。
たとえば、受注は販売管理システムに入力しているのに、納品書はExcelのひな形で作っている会社を考えてみます。
営業事務の担当者が受注画面を見ながら品番・数量・単価をひな形へ打ち直し、印刷して出荷担当へ渡します。
出荷担当はそれを箱に入れて送ります。
ここで出荷直前に欠品が見つかり、10ケースの注文のうち6ケースだけを先に出すことになったとします。
すると、販売管理の出荷数量とExcelの納品書の両方を直さなければなりません。
片方だけ直して出荷すると、納品書と現物、あるいは納品書と販売管理の記録が食い違います。
この場合に困っている原因は印刷の手間ではありません。
納品書が受注データから切り離されて作られていることです。
作業量の問題であれば、印刷の段取り、ひな形の統一、出荷との突き合わせ手順の見直しで軽くできる余地があります。
一方、数量変更や分納が起きるたびに直す場所が二つ以上ある場合は、手順を速くしても修正箇所の数は減りません。
後者が目立つなら、納品書をどのデータから作るかを含めて、システム化を検討する段階に入っていると考えられます。
得意先別の書式と請求・検収との突合ずれ
得意先から指定の伝票や書式を求められると、ひな形は得意先の数だけ増えていきます。
どの得意先にどの書式で出し、紙で同梱するのか、郵送するのか、PDFで送るのかを、特定の担当者だけが把握している状態になりがちです。
その担当者が休むと発行が止まる、新しい担当者が書式を取り違える、といった形で表面化します。
月末の請求でも症状が出ます。
請求書を作る経理の担当者は、納品書の控えと請求明細を照らし合わせます。
それでも得意先から「請求の数量が受け取った数と合わない」「返品した分が引かれていない」と問い合わせが来ることがあります。
原因をさかのぼると、納品書を発行した後の訂正が請求側に反映されていなかった場合があります。
得意先が検収する単位と納品書の明細の単位が違っていた場合もあります。
どちらも、請求の段階ではなく納品書の段階で生じたずれです。
今の運用がどの段階にあるかは、次の観点で点検できます。
・同じ明細を、受注から請求までに何回入力しているか
・数量変更や分納が起きたとき、直す場所はいくつあるか
・得意先ごとの書式と渡し方を、担当者以外も一覧で確認できるか
・請求時の問い合わせの原因を、納品書の段階までさかのぼって確認できるか
これは効果を測った基準ではなく、どこで手間とずれが生まれているかを見つけるための観点です。
二つ目と四つ目に当てはまる場合は、作業を速くするだけでは解消しにくくなります。
次に説明する要件定義で、納品書をどのデータから作り、どこへつなぐかを決め直すことが必要です。
▼ 図の内容を文字で読む
- 作業量の問題
- 出荷件数に比例して作業が増える
- 印刷し、箱と突き合わせ、同梱する手順が追いつかない
- 印刷の段取りやひな形の統一で軽くできる余地がある
- 構造の問題
- 同じ情報を別の場所へ打ち直している
- 件数が少なくても修正漏れや食い違いが起きる
- 数量変更や分納で直す場所が二つ以上あれば、システム化を検討する段階
納品書の導入前に要件定義で決めておくこと
納品書の役割
要件定義とは、新しい仕組みに何をさせるかを、導入前に業務側の言葉で決めておく工程です。
IPA(情報処理推進機構)の「ユーザのための要件定義ガイド 第2版」は、要件定義のさまざまな局面で発生する問題を取り上げ、解決の勘どころと対にして説明する形で、128の勘どころを収録しています1。
そのうえで、業務部門のユーザーが主体的に関わる進め方への変革が必要だと述べています1。
このガイドは情報システム全般を対象にしたもので、納品書専用ではありません。
それでも、納品書の要件を情報システム担当や販売元に任せきりにせず、出荷・営業事務・経理の担当者が自分の作業の言葉で決めるという考え方は、そのまま当てはめられます。
最初に決めるのは、自社にとって納品書が何のための書類かです。
得意先が荷受けの場で現物と照らし合わせる書類なのか。
得意先の検収や仕入計上の元になる書類なのか。
自社の出荷記録や請求の根拠として控えを残すための書類なのか。
一つに絞れず、得意先によって役割が違うこともあります。
役割が違えば、必要な記載項目も、渡すタイミングも、控えの残し方も変わります。
たとえば、荷受けの担当者が箱を開けて納品書と現物を照合している得意先に対し、納品書をメール送付だけに切り替えたとします。
受け入れの現場では、照合する紙がなくなります。
反対に、受け取った後で検収データと請求書を照らし合わせる得意先であれば、納品書をデータで受け取れれば足りる場合もあります。
どちらに当たるかは自社だけでは分からないため、役割の確認は得意先の一覧を作りながら進めることになります。
発行の起点データと記載項目
次に、納品書の明細をどのデータから作るかを決めます。
これを発行の起点データと呼びます。
候補になるのは、受注データ、出荷指示のデータ、在庫を引き当てた後の出荷確定データなどです。
欠品や分納がある会社では、受注どおりに出荷されるとは限りません。
受注データをそのまま納品書にすると、実際に出荷した数量と合わなくなります。
出荷確定後のデータを起点にするのか、受注データを起点にして出荷時点で数量を確定させるのかを決めておくと、前の節で見た「直す場所が二つある」状態を一つにまとめる設計ができます。
記載項目は、自社が必要とする項目と、得意先が求める項目に分けて洗い出します。
自社側では、納品書番号、受注番号、品番・品名、数量、納品日、単価や金額を載せるかどうかなどが挙がります。
得意先側では、得意先の発注番号、得意先が使う品番、納品先の部署や場所などを求められることがあります。
得意先の発注番号を納品書に載せておくと、得意先は自分の発注と照らし合わせやすくなります。
後の検収や請求での問い合わせを減らす手掛かりにもなります。
注意したいのは、得意先ごとの要望を受けるたびに項目が足し算で増えていくことです。
判断の分かれ目は、その項目をデータとして持てるかどうかです。
得意先の品番を商品マスタに持っていなければ、書式に欄を用意しても、発行のたびに誰かが手で入力することになり、転記は残ります。
共通の項目と得意先別の項目を分け、得意先別の項目はマスタや受注データに持てるものだけを要件に入れると、システム化で減らせる作業がはっきりします。
なお、納品書を請求書と兼ねるなど税務上の記載事項が関わる使い方をする場合は、項目の要否を顧問税理士に確認してから決めます。
得意先への渡し方
渡し方には、紙を荷物に同梱する、郵送する、PDFをメールで送る、得意先の発注サイトやEDIにデータを登録する、といった形があります。
ここは自社だけでは決めきれません。
得意先がどの形で受け取れるかに左右されるからです。
同じ会社の中でも、得意先によって同梱・郵送・メールが混在することがあります。
渡し方が混在していれば、システムにはその数だけの出力と送付の仕組みが必要になります。
そこで要件定義では、得意先ごとに「納品書の役割」「受け取り方」「必要な得意先別項目」を並べた一覧を作ることを勧めます。
取引の多い受け取り方を標準とし、それ以外を例外として扱う整理です。
例外がどれだけあるかが見えると、次に選ぶ手段に何を求めるかが具体的になります。
役割、起点データ、記載項目、渡し方の順に決めるのは、後ろから決めると前が抜けやすいからです。
製品の画面でPDFのメール送付機能を見てから運用を決めると、同梱が欠かせない得意先や、得意先の品番を載せる必要がある得意先が要件から漏れます。
残る請求・検収とのつなぎ方は、番号と明細をどう引き継ぐかという設計の話になるため、手段を比べた後で扱います。
▼ 図の内容を文字で読む
- 納品書の役割
- 荷受けでの照合か、検収や仕入計上の元か、出荷記録や請求の根拠の控えか
- 発行の起点データ
- 受注データか、出荷指示のデータか、出荷確定データか
- 記載項目
- 自社が必要とする項目と得意先が求める項目に分ける
- 得意先別の項目はマスタや受注データに持てるものだけを入れる
- 得意先への渡し方
- 同梱、郵送、PDFのメール、発注サイトやEDIへの登録
納品書を電子で渡す場合に確認する条件:電子取引としての保存の扱いと得意先の受け入れ
電子取引として保存が関わる範囲の確認
渡し方を紙から電子へ変えるときには、もう一つ判断が加わります。
国税庁によると、電子帳簿保存法には電子取引、電子帳簿等保存、スキャナ保存の区分があります2。
電子メールやインターネットなどで授受した取引情報のデータ、つまり取引書類に通常記載される情報を含む電子データには、保存の義務と保存の方法が定められています2。
国税庁は、国税関係書類の保存義務者に対し、とくに電子取引について確認するよう求めています2。
納品書をPDFにしてメールで送れば、送り手である自社にとっても、受け取る得意先にとっても、電子で授受した取引データをどう保存するかという問題が生じる可能性があります。
ただし、納品書がどの範囲で保存の対象になるのか、どのような要件で保存するのか、要件が緩和される条件があるのかといった細目は、ここでは断定できません。
この部分は国税庁の電子帳簿保存法一問一答(電子取引関係)と顧問税理士で確認してから判断します。
要件定義の段階でできるのは、確認の結果を受け止める欄を一覧に用意しておくことです。
送った納品書の控えをどこに、どの形式で、どの単位(納品書番号、得意先、日付など)で残すのかを、保存の扱いを確認したうえで決める項目として入れておきます。
そうしておけば、選定の段階で「送信した納品書の控えを後から取り出せるか」「控えの持ち方を確認結果に合わせられるか」を、製品や既存システムに当てはめて確かめられます。
渡し方の決定と保存の確認を別々に進めると、電子送付に切り替えた後で控えの残し方を作り直すことになりかねません。
得意先の承諾と受信形式の確認
電子化は自社だけの変更ではありません。
得意先にとっては、紙で届いていた書類がデータで届くようになり、受け取ったデータを自社の決まりに沿って保存する作業が増えることがあります。
得意先の承諾が法令上必要かどうかは、ここでは断定せず、保存の扱いと合わせて税理士に確認します。
ただ実務上は、得意先が受け入れられる形を確かめないまま切り替えると、受け取りを断られて紙に戻る、荷受けの現場で照合できなくなる、といったことが起こります。
切り替えを打診するときは、次の点を得意先と確認しておきます。
・受け取り方(メール、得意先の発注サイトへの登録、EDIなど)
・送り先(部署と担当者、共有のメールアドレスか個人宛てか)
・荷物への紙の同梱を続ける必要があるか
・ファイル形式やファイル名の付け方の指定
・切り替えの開始時期と、紙を並行して送る期間
合意した内容は、メールや書面で残しておくと後から確認できます。
同じ記録は社内では、どの得意先がいつから電子で受け取っているかを示す管理表にもなります。
前の節で作った得意先ごとの一覧に、合意の有無と切り替え日を加えておけば、発行する担当者は得意先ごとの渡し方を記憶に頼らずに済みます。

現行改善・既存システムへの機能追加・新規導入の選び方
3つの選択肢の比較表
要件の一覧ができたら、手段を選びます。
選択肢は大きく三つです。
・現行改善:Excelのひな形の統一、販売管理から出力した受注データの取り込み、印刷と同梱の手順の見直しなど、今の道具のまま整える
・既存システムへの機能追加:使っている販売管理や受発注のシステムに納品書の発行や送付の機能を加える、または使っていない機能を使い始める
・新規導入:納品書の発行・送付を担うシステムを新たに入れる、または受注から請求までを担うシステムを入れ替える
表の中で判断が分かれるのは、起点データの所在と得意先の受け入れの二つの列です。
保存の扱いはどの選択肢でも確認が必要で、違いは控えの残し方を人の手順で担うか、システムの中に持たせるかにあります。
費用は、今使っているシステムの契約内容や得意先の数で大きく変わります。
相場で比べるより、要件の一覧を渡して見積もりを取り、同じ要件に対する金額で比べるほうが判断を誤りにくくなります。
状況別の選び方
受注データがすでに販売管理システムに入っていて、転記がExcelへの打ち直しで起きている場合は、まず既存システムへの機能追加を検討します。
起点データが手元のシステムにあるので、そこから納品書を出せれば、打ち直しの工程がそのままなくなります。
使っているシステムに納品書の出力機能があるのに、得意先別の書式に合わないという理由で使われていない場合もあります。
その場合は、書式の調整で足りるかを先に確かめます。
受注をFAXや電話で受け、手書きやExcelで管理している場合は事情が違います。
納品書だけをシステムで発行しようとすると、そのシステムに受注を入力する作業が新たに生まれ、転記の場所が移るだけになりかねません。
取引件数が多く、受注から請求までを一つのデータでつなぎたいなら新規導入が候補になります。
件数が限られているなら、まず現行改善でひな形を統一し、入力を一回にまとめる工夫から始めるのが現実的です。
得意先の多くが紙の同梱を求めている場合は、電子送付の機能を基準に選んでも効果が出にくくなります。
このときに効くのは、起点データから正しい納品書を印刷し、出荷する荷物と取り違えずに同梱できる仕組みです。
反対に、電子で受け取れる得意先が多いなら、送付と控えの保存を一つの流れで扱えるかが選定の重みを増します。
既存システムで足りるかどうかは、要件の一覧を既存システムの担当者や販売元に当て、足りない項目がどこに集まるかで判断します。
不足が得意先別の項目や書式だけなら、設定や機能追加で補える見込みがあります。
起点データの持ち方や控えの保存まで不足が及ぶなら、新規導入を比較に入れる段階です。
| 選択肢 | 起点データの所在 | 得意先の受け入れ | 保存の扱い | 移行の負担 |
|---|---|---|---|---|
| 現行改善 | 今のExcelや受注台帳のまま。受注データを取り込めれば転記を減らせる | 紙の同梱や郵送が中心の得意先に合わせやすい | 電子送付を増やすと控えの残し方を人の手順で整える必要がある | 小さいが担当者への依存が残りやすい |
| 既存システムへの機能追加 | 販売管理や受発注に受注データがある場合に向く | 既存システムが出せる形式の範囲で対応する | 送付控えを既存システム内に残せるかを確かめる | 既存のマスタを使える範囲で抑えやすい |
| 新規導入 | 受注から請求までを一つのデータで持ち直す場合に向く | 複数の受け取り方を設計に含められる | 選定時に確認結果に合う控えの持ち方かを確かめる | マスタの移行・操作の習熟・並行運用が必要 |
請求・受注・出荷・検収と納品書をつなぐ設計
番号・明細の引き継ぎ
どの手段を選んでも、転記と突合のずれを減らす鍵は、受注・出荷・納品書・請求の間で同じ番号と明細を引き継げるかどうかです。
ずれは、工程が変わるところで番号が振り直されたり、明細がまとめ直されたりする箇所で生まれやすくなります。
そこで、受注番号と明細の行番号を起点に、出荷、納品書、請求の明細へ同じ番号を持たせる設計を提案します。
最初の節で挙げた、10ケースの注文のうち6ケースを先に出荷する例で考えます。
出荷確定データを起点にすれば、1回目の納品書には6ケース、2回目の納品書には残りの4ケースが載り、どちらにも同じ受注番号と行番号が付きます。
請求の明細を納品書番号ごとに立てておけば、得意先から「4ケースが届いていない」と問い合わせが来ても、受注番号から2枚目の納品書が発行済みかどうかをたどれます。
番号がつながっていなければ、受注台帳、出荷記録、納品書の控えを人が見比べて探すことになります。
得意先の検収とのつなぎ方も決めておきます。
得意先から、受け取った数量に差があった、一部を返品したという連絡を受けたとします。
訂正の起点をどの納品書番号に置き、どこで訂正を入力し、請求へどう反映するのかを決めておかないと、納品書は直したのに請求は元の数量のまま、ということが起こります。
番号を引き継いでも、得意先の検収結果を受け取る仕組みがなければ、検収との照合は人が行う作業として残ります。
何が自動でつながり、どこに確認が残るのかを区別しておくと、導入後に期待と実際がずれにくくなります。
共通EDIとの関係
企業間で受発注のデータをつなぐ枠組みとして、中小企業庁のミラサポplusは中小企業共通EDIを紹介しています3。
EDIとは、企業間で注文などの取引データを決まった形式でやり取りする仕組みです。
その標準である中小企業共通EDI標準は2018年に初版が公開され、仕様書で注文メッセージの項目を定めています3。
紙の帳票類をデータで一元管理することで、手入力による人為的ミスがなくなり、業務の効率化につながると説明されています3。
ただし、これは受発注、とくに注文のデータの標準として紹介されているもので、納品書の標準として示されたものではありません。
納品書との関係は、起点データの側にあります。
得意先からの注文がデータで届けば、受注を打ち込む作業がなくなり、納品書の元になる受注データが最初からデータとして手に入ります。
そのデータから納品書を作る設計になっていてはじめて、納品書の転記も減ります。
受注する側は、この標準に対応したプロバイダーと業務アプリケーションを利用すればよく、大きな費用はかからないとされています3。
ただし、使えるかどうかは得意先が注文をこの形で送れるかに左右されます。
納品書の受け取り方を得意先に確認する機会に、注文の送り方もあわせて聞いておくと、起点データをどこから得るかの選択肢が増えます。
▼ 図の内容を文字で読む
- 受注データ
- 受注番号と明細の行番号を持つ
- 出荷確定
- 分納でも同じ受注番号と行番号を保つ
- 納品書
- 分納時は納品書を分け、納品書番号ごとに発行する
- 得意先の発注番号を載せる
- 得意先の検収
- 数量差や返品は納品書番号を起点に訂正する
- 請求
- 請求の明細を納品書番号ごとに立てる
得意先を絞った試行から移行までの進め方
試行対象の選び方
要件が固まっても、すべての得意先を一度に切り替えるのは避けたほうが安全です。
得意先ごとに納品書の役割や受け取り方が違い、要件の漏れは実際に得意先とやり取りして初めて見つかることがあるからです。
まず数社に絞って試し、見つかった漏れを要件に戻してから範囲を広げます。
試行の対象は、次のような条件で選ぶことを勧めます。
・書式や受け取り方が近く、同じ設定で発行できる
・一定の取引件数があり、分納や訂正も含めて試せる
・担当者と連絡が取りやすく、不具合を早く知らせてもらえる
・電子での受け取りに前向きである
指定伝票が必要な得意先や、取引額が大きく影響の大きい得意先は、試行で手順が固まってから移すほうが無理がありません。
逆に、件数が少なすぎる得意先だけを選ぶと、分納や返品といった例外が試行期間中に起きません。
その結果、問題が見つからないまま範囲を広げることになります。
並行運用と判断基準
試行の間は、新しい方法と従来の紙を並行して出す期間を設けることを検討します。
並行運用は二重の手間になるため、何をもって紙をやめるのかを始める前に決めておきます。
期限だけを決めておくと、問題が残っていても期限が来たから切り替える、あるいは不安だから並行をやめられない、のどちらかに流れやすくなります。
判断の基準には、次のようなものが使えます。
・請求時の突合でずれが見つかった件数
・納品書に関する得意先からの問い合わせ件数
・得意先が新しい受け取り方を受け入れたか
・送った納品書の控えを、決めた方法で残せているか
件数で比べる項目は、試行前の件数を記録しておかなければ比べられません。
試行を始める前の一定期間について、同じ数え方で件数を数えておきます。
決めきれない点は、従来の方法に戻せる範囲で進めます。
たとえば電子送付に切り替えた得意先から紙の同梱を求められたとき、起点データから紙の納品書を出せる経路を残しておけば、切り替えを取り消しても発行は止まりません。
移行が進んだら、得意先の一覧に「切り替え済み」「試行中」「紙を継続」といった状態を持たせ、次の得意先群へ広げます。
試行で見つかった要件を一覧に戻し、次の試行に反映する繰り返しが、移行の進め方そのものになります。
▼ 図の内容を文字で読む
- 試行する得意先を選ぶ
- 新しい方法と紙を並行して出す
- 判断基準で評価する
- 見つかった要件を一覧に戻す
- 切り替え状態を記録し次の得意先群へ
得意先ごとの納品書の役割や受け取り方、起点データがどこにあるかは、社内の担当者だけで棚卸しすると、ふだん扱っている得意先や工程に偏りやすくなります。
受注から請求までの今の流れを並べ、どこで転記と修正が起きているか、現行改善・機能追加・新規導入のどれから検討するかを整理できます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 導入を考える段階 | 数量変更や分納のたびに直す場所が二つ以上ある |
| 要件を決める順 | 役割、起点データ、記載項目、渡し方、請求・検収とのつなぎ方 |
| 得意先別の項目 | マスタや受注データに持てる項目だけを要件に入れる |
| 電子で渡す前 | 保存の扱いを国税庁の一問一答と税理士で確認し、得意先の受け入れ方を合意して記録する |
| 手段の分かれ目 | 起点データの所在と得意先の受け入れ方 |
| 移行 | 数社で試行し、紙をやめる判断基準を始める前に決める |

要件の一覧ができても、試行する得意先や紙をやめる判断基準は、得意先との関係を踏まえないと決めにくいものです。 試行する得意先の選び方と、並行運用の間に記録する件数や切り替えの基準を、自社の取引に合わせて確かめられます。
よくある質問
納品書を電子で送る場合、得意先の承諾は必要ですか。どう取ればよいですか。
法令上の承諾の要否や、電子取引としての保存の扱いは、国税庁の電子帳簿保存法一問一答(電子取引関係)と顧問税理士で確かめてください。
実務上は、得意先が受け入れられる形を確認せずに切り替えると、受け取りを断られたり、荷受けの現場で照合できなくなったりします。
受け取り方、送り先、紙の同梱の要否、ファイル形式、切り替え時期を確認し、合意内容をメールや書面で残しておくと、社内で得意先ごとの渡し方を管理する一覧にもそのまま使えます。
納品書と請求書を一つにまとめてもよいですか。まとめるとき何を確認しますか。
業務の面では、得意先が納品書を荷受け時の照合に使うのか、請求の照合に使うのかで判断が分かれます。
荷受けで照合する得意先には出荷のたびに渡す書類が必要なので、月ごとにまとめる請求書とは渡すタイミングが合いません。
分納がある場合は、一枚の書類に載る明細と請求の単位がずれないかも確認が必要です。
まとめた書類の税務上の扱い、たとえば記載事項をどう満たすかは、国税庁の資料と顧問税理士で確認してから決めてください。
得意先ごとに書式が違う場合、要件定義ではどこまで個別対応にしますか。
共通の項目と得意先別の項目を分け、得意先別の項目はデータとして持てるものに限るのが一つの目安です。
得意先の品番や発注番号をマスタや受注データに持てるなら、書式に欄を足しても転記は増えません。
持てない項目のために書式だけを合わせると、発行のたびの手入力が残ります。
指定伝票のように書式そのものが決まっている得意先は例外として一覧に記し、試行では後回しにすると、全体の設計を崩さずに済みます。
試行の対象にする得意先はどう選びますか。
書式や受け取り方が近く、分納や訂正も起きる程度の取引件数があり、連絡が取りやすい数社が向いています。
影響の大きい得意先や指定伝票が必要な得意先は、手順が固まってから移します。
既存の販売管理システムで足りるかは何で判断しますか。
要件定義でまとめた一覧を既存システムに当て、足りない項目がどこに集まるかで判断します。
得意先別の項目や書式だけが不足しているなら、設定や機能追加で補える見込みがあります。
出荷確定後の数量から納品書を作れない、送った控えを残せないなど、起点データや保存に関わる部分が足りないなら、新規導入も比較に入れて検討します。
- 1 出典:独立行政法人情報処理推進機構(IPA)社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」(2019年)
- 2 出典:国税庁「電子帳簿保存法関係(特設ページ)」(2026年)
- 3 出典:中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する!」(2018年)
画像の出典元