見積書・納品書・請求書の連動設計｜3つのデータで転記をなくし全拠点に展開

見積書・納品書・請求書の発行を、拠点ごとのExcel管理簿から1つの仕組みへ移すにあたり、あらかじめ押さえておきたい結論は以下の3点です。

 

1. 見積番号を拠点ごとに個別管理することなく自動採番する仕組みがあるか
2. 見積書→納品書→請求書の順にデータを自動転記できる仕組みがあるか
3. ツールを選定する前に各書類の共通項目、個別項目を整理すること

 

それぞれの具体的な理由は以下の通りです。

 

1.本質：限界が来るのは「管理簿の分散」と「番号の扱い」
Excelマクロは、見積書の内容を納品書や請求書へ写していく作業そのものはこなせます。問題になるのは、拠点ごとに別々のファイルがあるため全社で1つにまとめられないこと、そして見積番号の重複や上書きを人の注意だけで防いでいることです。

 

2. 実現方法：書類ではなく「データ」を3つに分けてつなぐ
取引先へ発行する見積書・納品書・請求書を、それぞれ別のExcelシートで管理するのではなく、見積・納品・請求の3つのデータとして持ちます。後の工程のデータ（納品・請求）は、前の工程のデータから見積番号と明細を自動で引き継ぐため、金額や明細を書き写す作業がなくなります。今回の設計では、ノーコードのクラウドデータベースであるSlopebaseを使い、この3つのデータと依頼用の申請フローを組み立てました。

 

3. 着手順序：工程と項目の書き出しが先
最初にやるべきことは、現在の工程を「入力・採番・出力・連携」に仕分け、書類ごとに固有の項目と引き継ぐ項目を分けることです。この整理が終わっていれば、どのツールを検討する場合でも、比較の前提となる資料として使えます。

 

この進め方には、向いている業務と向いていない業務があります。

 

向いている業務
見積1件に対して納品と請求が1件ずつ続き、明細の形が書類のあいだで共通している業務。拠点ごとに同じ様式の管理簿を持っている業務。

 

向いていない業務
分納や月締めの合算請求で、1件の見積が複数の納品・請求に分かれることが日常的に起きる業務。この場合は、データの分け方そのものから設計し直す必要があります。

 

 

この記事で扱う範囲と、扱わない範囲

 

扱う範囲
取引先へ発行する見積書・納品書・請求書という3つの書類を対象に、工程の分解から3つのデータの設計、項目の型と値域、あえてシステム化しなかった判断までを、要件定義・基本設計の内容から整理します。注文書・受領書・検収書のように、取引先に記入して返送してもらう書類は扱いません。

 

扱わない範囲
次のテーマはそれぞれ独立した記事にまとめているため、本記事では深追いせず該当記事へご案内します。

 

見積帳票のパターン分解

→ 見積管理の脱Excel・システム移行事例｜24帳票の見積もり自動化
請求書の送付と受領確認、電子帳簿保存法
→ 請求書の電子化のやり方｜発行側の手作業をなくす7工程とは
検収の意味と確認項目
→ 検収とは？検品・受入との違いと5つのチェック項目をわかりやすく解説
マクロの属人化
→ エクセルマクロはもう限界？属人化・ブラックボックス化から脱却するクラウド活用術
請求処理ツールの比較
→ 請求処理を自動化する最新ツール事情と導入メリット、選び方を紹介
PoCの進め方
→PoC設計の進め方｜検証項目サンプルと合否基準

設計検討で扱った業務では、見積から請求までの書類を総務部門が発行していました。流れは次の9工程です。

 

1. 営業担当が作った見積依頼書を受け取る
2. Excelマクロの管理簿へ見積依頼書の内容を入力し、見積番号を振る
3. マクロで見積書を出力し、取引先へ渡す
4. 見積書のデータを、マクロで納品書のシートへ写す
5. 納品番号を振り、納品日などを書き足す
6. マクロで納品書を出力し、取引先へ渡す
7. 納品書のデータを、マクロで請求書のシートへ写す
8. 請求番号を振り、請求日などを書き足す
9. マクロで請求書を出力し、取引先へ渡す

 

どの書類も中身はほぼ同じ情報で、その書き写しをマクロが自動で行っています。一見すると効率的な仕組みですが、拠点や担当者が増えると、次のような問題が起きるようになります。

拠点ごとのマクロ管理簿で見積から請求までを運用している組織に共通する3つの状況

1つ目は、管理簿が拠点ごとに別のファイルになっていて、全社で1つにまとめられないことです。どの見積がいまどこまで進んでいるかを本社で確かめるには、拠点のファイルを1つずつ開くしかありません。

 

2つ目は、誰か1人がマクロを使っていると、ほかの担当者は終わるまで待つしかないことです。請求書の発行が集中する時期ほど、この順番待ちによって作業が遅れやすくなります。

 

3つ目は、見積番号が重複したときにアラートは出るものの、誤って既存のデータを上書きしてしまう余地が残っていることです。上書きに気づかないまま書類を出せば、取引先の手元にある見積書と社内の管理簿が食い違います。設計検討の場でも、これは業務上のリスクとして挙げられていました。

見積書から請求書までの作業が特定の担当者に頼りきりになる構造

上書きを防ぐために、「このセルは触らない」「この順番でボタンを押す」といった取り扱いの注意点が少しずつ増えていきます。こうした注意点はマニュアルに書かれず、担当者の記憶だけに残りやすいため、結果として管理簿を扱える人が限られていきます。さらに、似た内容のファイルを毎回出力しているため、どのファイルが最新かを確かめる手間も生まれます。

 

ここで押さえておきたいのは、これがExcelの性能の問題ではなく、日々の業務の進め方に原因があるということです。「エクセル 納品書 請求書 連動」で探せば、無料の連動型テンプレートはいくつも見つかります。ただ、1つのファイルの中で書類どうしを連動させることはできても、拠点をまたいだ統合、複数人での同時作業、番号が重複しない仕組みまでは解決できません。テンプレートを替えても同じ問題が残るのであれば、管理簿の作り方と運用の仕方そのものを見直す時期に来ているといえます。

 

移行先のツールを選ぶ前に、いまの業務を分解しておきます。ここでの成果物は、工程の仕分け表と、書類ごとの差分表の2つです。

見積から請求までの流れを入力・採番・出力・連携の4種類に仕分ける

先ほどの9工程を、作業の種類で4つに仕分けます。「入力」は人が値を書き込む作業、「採番」は番号を振る作業、「出力」は書類を作って渡す作業、「連携」は前の書類の内容を次の書類へ写す作業です。

 

仕分けると、採番は見積番号・納品番号・請求番号の3回、連携は見積から納品へ、納品から請求への2回、出力は見積書、納品書、請求書の3回あることが分かります。このことから、番号を振る場面ごとに、見積データ・納品データ・請求データの3つに分けるのが自然だと考えられます。発行する3つの書類は、見積書を見積データから、納品書を納品データから、請求書を請求データから作ります。

 

書類の順番も、この段階で確かめておきます。今回の業務では、見積書、納品書、請求書の順に発行していました。見積から請求までの流れを社内で説明するときも、この順番と3つのデータの対応を1枚の表にまとめておくと、相手に伝わりやすくなります。

現物のテンプレートから差分表を作る手順とチェックリスト

次に、実際に使っている書類のテンプレートを並べ、項目ごとに「次の書類へ引き継ぐ項目」と「その書類だけの固有項目」に分けます。手順は次の4つです。

 

1. 書類ごとに、現在使っているExcelのテンプレートを1つずつ用意する
2. 各テンプレートの項目を、上から順に一覧へ書き出す
3. 同じ意味の項目を横に並べ、引き継ぐ項目と固有項目に印を付ける
4. 固有項目を、3つのデータのどれに持たせるかを決める

 

今回の書類で整理すると、引き継ぐ項目は宛先、ユーザ名、システム名、明細（内容・数量・単価・金額）、合計金額（税抜）、消費税金額、総合計、備考でした。固有項目は、見積書が納品予定日・納入場所・検収予定日・支払予定日・メンテナンス開始予定日・見積有効期限・見積番号、納品書が納品日・支払予定日・納品番号、請求書が請求書番号・支払予定日・振込先です。明細の表と合計欄は、どの書類でも同じ形をしていました。

 

差分表を作るときのチェックリスト
□すべての書類のテンプレートを、拠点ごとの差も含めて集めたか
□同じ意味なのに名前が違う項目（例：見積番号と見積書番号）を1つにそろえたか
□明細の行数の上限を、過去の書類から確かめたか
□数量に「一式」「2ライセンス」のような単位付きの値が入るかを確かめたか
□日付の項目が、予定日なのか実績日なのかを区別したか
□宛先や振込先など、書類によって変わる情報を、どのデータに持たせるかを決めたか

見積書番号・納品番号・請求書番号の付け方と、つなぐ番号を決める

最後に番号の扱いを決めます。今回の設計では、見積番号・納品番号・請求書番号の3つを、それぞれのデータを登録したときに自動で振る方式にしました。人が番号を入力しないので、重複や上書きの心配がありません。

 

もう1つ決めておきたいのが、書類をつなぐ番号です。今回は見積番号をつなぐ番号にしました。納品データは見積番号を、請求データは見積番号と納品番号を引き継いで持ちます。こうしておくと、請求書から見積書までをいつでもさかのぼれます。番号の付け方を決めるときは、桁数や記号より先に「どの番号で書類をつなぐか」を決めておくのがおすすめです。

 

◆検討チェックリスト
□取引先へ渡す書類の種類と順番が、拠点のあいだでそろっているか
□営業担当からの見積依頼を、決まった窓口で受けて履歴を残す必要があるか
□書類の発行前に、上長などの承認が必要か
□見積から請求へ進めるときに、人が内容を確かめる場面を残したいか
□請求書だけを単独で作る例外が、どのくらいの頻度で起きるか
□過去の書類を、番号や取引先から探し出す必要があるか

 

◆システム選定のポイント
□小さな範囲（1拠点・1業務）から始めて、あとで広げられるか
□利用人数や拠点が増えたときの費用を、課金体系からあらかじめ把握できるか
□業務の変更に合わせて、項目の追加や型の変更を自分たちでできるか
□CSVでの一括登録など、既存データを移す手段があるか
□前の工程のデータから次の工程のデータを自動で作る仕組みを、プログラムを書かずに設定できるか

 

---

見積書から請求書までの棚卸しから始めたい方へ

 

本記事では、見積書・納品書・請求書を3つのデータに分けるところから設計を始めました。自社の工程と書類のどこから確かめるかを決めたい方へ、導入の可否を見極めるPoCの進め方をまとめた資料をご用意しています。

 

 

---

 

見積・納品・請求の3つのデータを見積番号でつなぎ、書き写しの作業をなくす

設計した3つのデータは、Slopebaseでは「トラン」（伝票1件ごとのデータを入れる表）として作りました。項目数は、見積データが106項目、納品データが99項目、請求データが96項目です。いずれも明細を20行まで持ち、1行あたり内容・数量・単価・金額の4項目、合わせて80項目を明細に使っています。マスタ（取引先や商品など、繰り返し使う基本情報を入れる表）は使わず、3つのトランだけで構成しました。

 

前の工程のデータから次の工程のデータを作るきっかけになるのは、「納品書データへ連携」「請求書データへ連携」というセレクト項目（決められた選択肢から選ぶ項目）です。初期値は「0：未連携」で、担当者がこれを「1：連携」に切り替えると、データフロー（データを別の表へ自動で受け渡す機能）が動き、次のトランに新しいデータが作られます。

 

見積データから納品データへは、請求先、ユーザ名、システム名、見積内容、合計金額（税抜）、消費税金額、備考、明細20行分、見積番号が自動で入ります。納品データには新しい納品番号が振られ、担当者が書き足すのは納品日や支払条件といった実績の値だけです。納品データから請求データへも同じ形で引き継がれます。

 

納品書・請求書の生成を効率化させるポイントは、見積管理にあります。見積管理については見積管理の脱Excel・システム移行事例をご参照下さい。

 

3つのトランは見積番号でつながっているため、カラムリンク（共通の番号をもとに複数の表を並べて表示する機能）を使えば、1件の見積に対する見積・納品・請求のデータを1つの画面に並べて表示できます。拠点ごとのファイルを1つずつ開かなくても、どの見積がいまどこまで進んでいるかをその場で確認できます。また、各トランにはファイルを添付できる項目も用意し、発行した書類を1件ごとのデータと一緒に保存して、過去の書類としていつでも見返せるようにしています。

 

社内で回す伝票と取引先の署名が要る確認書を、伝票番号の参照でつないで電子化した設計は、伝票番号の参照でつなぐ電子伝票の設計で紹介しています。

 

 

 

カラムリンクで見積・納品・請求を一覧表示

 

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

 

連携セレクトの切り替えで納品データを自動作成

 

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

申請フローとデータフローで入力を減らす4つの入力経路の使い分け

見積データに情報を入れる方法は1つではありません。今回の設計では、入力の方法を4つ用意し、場面に応じて使い分けています。

 

1つ目は、申請フォームからの自動入力です。営業担当が申請フローの見積依頼フォームに内容を入れて申請し、決裁が終わると、入力した内容がデータフローで見積データへ自動で入ります。このとき見積依頼番号も自動で入るため、どの依頼から作られた見積かを後から確認できます。申請は差し戻しもできます。

 

2つ目は、見積依頼書の添付による申請です。営業担当は申請フォームに詳しい項目を入れず、作成済みの見積依頼書（Excel）を添付して申請し、総務部門の担当者がその内容を見積データへ入力します。依頼の窓口が1つになり、対応漏れを防ぎながら依頼の履歴を残せるのが利点です。

 

3つ目は、前の工程からの自動入力です。先ほど説明した連携の仕組みにより、納品データと請求データの大半の項目はこの方法で自動的に入ります。

 

4つ目は、計算による自動入力です。総合計金額は、合計金額（税抜）と消費税金額を足した値が自動で入ります。

実際の項目例と、決めておくべき型と値域

項目の型は、自動採番・日付・文字列・文字列（複数行）・整数・小数・セレクト・ファイルの8種類を使い分けています。3つのデータに持たせた主な項目を、共通項目と個別項目に分けて表1にまとめました。共通項目は見積データで一度入力すれば、納品データと請求データへ自動転記されます。

 

表1 見積・納品・請求データの共通項目と個別項目

青い行は共通項目（3つのデータで同じ内容を持つ項目。納品データと請求データでは、前の工程のデータから自動転記されます）、オレンジの行は個別項目（その書類だけで使う項目）です。

 

区分	項目	項目タイプ	値域・入り方
見積データトラン（106項目） 共通項目の入力元
共通	見積先（納品・請求データでは請求先）・ユーザ名・システム名	文字列	見積依頼書の内容を入力
共通	見積内容	文字列（複数行）	見積依頼書に書かれた詳細をそのまま貼り付け
共通	明細1〜20（内容・数量・単価・金額）	内容・数量は文字列、単価・金額は整数	数量は「一式」「2ライセンス」も可
共通	合計金額（税抜）・消費税金額	整数	入力
共通	備考	文字列（複数行）	入力
個別	見積番号	自動採番	登録時に重複しない番号を自動で付与
個別	見積日・納品予定日・検収予定日・支払予定日・メンテナンス開始予定日	日付	カレンダーから選択
個別	見積有効期限	セレクト	発行日より1ヶ月〜3ヶ月
個別	見積依頼番号	文字列	申請フローから自動入力
個別	納品書データへ連携	セレクト	0：未連携／1：連携（1で納品データを自動作成）
納品データトラン（99項目） 見積データから自動転記
共通	請求先・ユーザ名・システム名・見積内容	文字列	見積データから自動転記
共通	明細1〜20・合計金額（税抜）・消費税金額・備考	見積データと同じ	見積データから自動転記
共通	見積番号	文字列	見積データから自動転記
個別	納品番号	自動採番	登録時に重複しない番号を自動で付与
個別	納品日・支払条件	日付	実績に応じて人が入力
個別	請求書データへ連携	セレクト	0：未連携／1：連携（1で請求データを自動作成）
請求データトラン（96項目） 納品データから自動転記
共通	請求先・ユーザ名・システム名・見積内容	文字列	納品データから自動転記
共通	明細1〜20・請求金額（税抜）・消費税金額	納品データと同じ	納品データから自動転記
共通	見積番号・納品番号	文字列	納品データから自動転記
個別	請求書番号	自動採番	登録時に重複しない番号を自動で付与
個別	請求日・支払条件	日付	実績に応じて人が入力

 

出典：弊社が携わった要件定義・基本設計の内容をもとに作成

 

なかでも判断が分かれやすいのが数量です。ソフトウェアのライセンスや保守を扱う業務では、数量に「一式」や「2ライセンス」のような単位付きの値が入ります。数値型にすると、こうした書き方ができなくなります。そこで数量はあえて文字列型にし、金額の計算に使う単価と金額は整数型にしました。見積内容は複数行の文字列にして、見積依頼書に書かれた詳細をそのまま貼り付けられるようにしています。見積有効期限は自由入力にせず、「発行日より1ヶ月」から「3ヶ月」までのセレクトにしました。

 

見積データの項目定義

 

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

業務フローの中であえてシステム化しなかった箇所とその理由

すべてを自動にしたわけではありません。今回の設計では、次の3つをあえて人の手に残しています。

 

1つ目は、次の工程へ進める判断です。見積データから納品データへ、納品データから請求データへの連携は、登録しただけでは動かさず、担当者が内容を確かめてから「1：連携」に切り替えたときだけ動く設計にしました。金額や明細に誤りがあるまま請求まで流れてしまうことを防ぎ、確認した人の操作として履歴を残すためです。

 

2つ目は、添付による依頼の受け付けです。すべての営業担当に申請フォームの全項目を入力してもらうのが理想ですが、使い慣れた見積依頼書の形のまま依頼したい場面もあります。依頼の窓口と履歴を1つにすることを優先し、添付された見積依頼書の内容を総務部門が入力する経路を残しました。

 

3つ目は、実績の日付です。納品日、請求日、支払条件は、実際の納品や取引先とのやり取りが決まってから人が入れます。予定日から自動で決めてしまうと、実績と食い違ったときに直す手間が増えるためです。

 

あわせて、各トランの使い方はSlopebaseのストーリー機能にマニュアルとして登録しました。注意点が担当者の頭の中に残らず、最新のマニュアルを探す手間もなくなります。入力の形式をそろえたことと合わせて、管理簿を扱える人が限られてしまう状態を解消することにつながります。

 

新しい仕組みを社内へ導入・提案する際、決裁者からは「いまのやり方（Excelのマクロ）を直せば済むのではないか？」「市販の請求書作成ソフトではいけないのか？」といった明確な理由が求められます。

 

ここでは、自社に合った手段を選ぶための判断軸として、検討の過程で比較に挙がりやすい選択肢と、それを見送るに至った理由、そして既製品で十分な場合について整理します。

現行のExcelマクロ管理簿を改修して使い続ける案を見送った理由

最も手軽なのは、いまのマクロを直しながら使い続ける案です。費用・期間・機能範囲の3つの軸で見ると、次のようになります。

 

費用の面では、新しいツールの利用料はかかりません。ただし、拠点ごとに管理簿があるため、マクロを直すたびに同じ作業が拠点の数だけ発生し、その手間は続きます。

 

期間の面では、目の前の不具合はすぐに直せます。一方で、拠点ごとの管理簿を1つに統合するには、ファイルの作り方そのものから見直す必要があり、部分的な修正では対応できません。

 

機能範囲の面が、見送った決め手でした。課題として挙がっていたのは、拠点をまたいだ統合、複数人での同時作業、番号が重複しない仕組みの3つです。いずれもファイルを1人ずつ開いて使うExcelの仕組みに関わるため、マクロの改修では解決できません。

既製の見積書・請求書作成ソフトで足りるのはどんな場合か

公平のために、既製品で十分な場合も挙げておきます。書類の様式が一般的で、見積から請求までを1人または少人数で完結でき、発行前の承認や依頼の申請が要らない場合は、市販の見積書・請求書作成ソフトで十分に対応できます。

 

反対に、メンテナンス開始予定日や単位付きの数量のような業界固有の項目がある、営業から総務への依頼を申請として残したい、拠点ごとの管理簿を1つにまとめたい、といった条件が重なるほど、業務に合わせて作る方が運用しやすくなります。製品ごとの比較は、請求処理を自動化する最新ツール事情と導入メリット、選び方を紹介で詳しく紹介しています。

検討の場で挙がった疑問にどう答えたか

設計の確認の場では、次の2つの質問が出ました。

 

1つは「見積を通さず、請求書だけを作りたいときはどうするのか」という質問です。この場合は、請求データのトランに直接入力すれば作れます。見積から始まる流れを基本にしながら、請求書だけを作る例外的な使い方にも対応できるようにしています。

 

もう1つは「100件から200件の請求データをまとめて登録できるか」という質問です。元になるデータをCSVでダウンロードし、変えたい箇所を直してアップロードすれば、新しいデータとしてまとめて登録できます。このとき一意のキーを消しておけば、既存のデータを上書きせずに新しく登録されます。

ここで紹介するのは、金融機関向けのソフトウェアを販売・保守する企業の業務です。業種は違っても、見積から請求までの書類を管理簿で発行し、営業から依頼を受けて総務部門が書類を作るという業務の進め方は、多くの企業と共通しています。

 

移行を検討し始めた当初、担当者には迷いもありました。

 

「マクロで見積から請求まで一応つながっていたので、作り直す手間に見合うのかは正直わかりませんでした。」

 

印象が変わったのは、3つのデータが1つの画面に並んだときだったといいます。

 

「見積番号で3つのデータが横に並んだ画面を見て、どの見積がどこまで進んでいるかを1画面で追えると分かったときです。」

 

作業時間のほかにも、変化がありました。

 

「誰かがファイルを開いているあいだ待つ、ということがなくなりました。番号を上書きしてしまわないかと気にする必要もなくなりました。」

 

運用面では、次の工程へ進める操作について、チームでルールを決めています。

 

「次の書類へ進めるのは、中身を確認した人が連携を『1』に切り替えたときだけ、と決めています。」

 

これから同じような見直しを考える企業へは、次のように話しています。

 

「まず、いまの管理簿がどのシートからどのシートへ、何を写しているかを書き出すことをおすすめします。」

 

---

自社の見積書・納品書・請求書で同じ形が成立するかを確かめる

 

本記事の設計は、製品を選ぶ前に見積から請求までの工程と書類を棚卸しするところから始まっています。同じ手順を自社に当てはめ、3つのデータに収まるかどうかを一緒に確認するところからご相談いただけます。ご用意いただくのは、現在お使いのExcelと書類のサンプルだけで構いません。

 

 

---

 

Q.見積書・納品書・請求書はどの順番で発行するのですか？

A.売り手が取引先へ発行する書類は、一般的に見積書、納品書、請求書の順です。注文書（発注書）は買い手が発行する書類で、売り手は受け取る側になります。設計検討で扱った業務でも、見積書、納品書、請求書の順に発行していました。

Q.納品書と一緒に受領書を送る必要はありますか？

A.受領書は、取引先が「この内容で受け取りました」と示すための書類です。郵送でやり取りする場合は、納品書が確かに届いたかを確かめるために、返信用の受領書を納品書に同封して送ることがあります。一方、Web上で書類を受け渡す電子取引では、取引先が書類をダウンロードしたかを確認できる機能を持つ仕組みが多く、受領書を返送してもらう必要はありません。受領書には発行する義務がなく、受け取った場合は取引関係の書類として保存が必要になる点にも注意が必要です（参考：国税庁 電子帳簿保存法関係）。メールで送るだけでは開封されたかが分からないため、ダウンロードの確認ができる仕組みは実務で役立ちます。

Q.見積書番号や請求書番号はどう付ければよいですか？

A.番号の付け方に法令上の決まった形式はありません。インボイス制度の適格請求書でも、請求書番号は記載事項に含まれていません（参考：国税庁 インボイス制度の概要 ）。実務では、人が番号を入力せずに自動で振ること、そして後の工程の書類が前の工程の番号を引き継いで持つことの2点を押さえておくと、重複や追跡の漏れを防げます。

Q.請求書だけを作りたい場合や、100件以上の請求をまとめて作る場合はどうしますか？

A.請求書だけを作る場合は、請求データに直接入力します。まとめて作る場合は、元になるデータをCSVでダウンロードして直し、アップロードして一括で登録します。一意のキーを消しておけば、既存のデータは上書きされません。

Q.Excelで納品書と請求書を連動させるのではだめですか？

A.1つの拠点で、決まった担当者だけが使うのであれば、Excelでの連動でも十分に運用できます。拠点ごとの管理簿を1つにまとめたい、複数人が同時に作業したい、番号の重複を仕組みで防ぎたい、という条件が出てきたときが、移行を考えるタイミングです。

見積書・納品書・請求書をExcelマクロの管理簿で連動させる運用が限界を迎える原因は、書類の作成ではなく、拠点ごとに分かれた管理簿と番号の扱いにあります。解決するためのポイントは、見積書・納品書・請求書を見積・納品・請求の3つのデータに分け、見積番号で引き継ぐことです。着手するときは、ツールを選ぶ前に、工程を入力・採番・出力・連携に仕分け、書類ごとの差分表を作るところから始めましょう。次の工程へ進める判断や実績の日付のように、あえて人の手に残す箇所を決めておくことも欠かせません。

 

---

見積書から請求書までの業務構築について、資料と個別相談をご用意しています

 

本記事で紹介した業務概要・業務フロー・業務ポイント・データ設計は、弊社が複数のPoCで行った要件定義と基本設計の経験をもとに、一般化して再構成したものです。同じ形式で自社の見積書・納品書・請求書の業務を設計するとどうなるのか、資料でご確認いただくか、個別にご相談いただけます。

 

 

 

---