見積から請求まで情報をつなぐ。金額のズレを避けるための共通管理

個人のお客様から仕事を受けるとき、最初に必要になるのは見積書です。

PDFを作って渡せれば、その時点の目的は達成できます。しかし実際の仕事は、見積の後に案件として進み、作業を終えた後は請求へ続きます。

見積、案件、請求が別々に管理されていると、後工程で同じ情報を探し直し、どの価格を使ったのか確認する作業が増えます。

そこで、自作アプリでは見積と案件を関連付け、案件から見積を参照できるようにしました。価格情報も画面ごとに別々に持たせず、必要な場所から共通して参照します。

見積書を作れば終わりだと思っていた

最初は、商品と数量を入力し、合計を計算して、見積書を出力できれば十分だと考えていました。

見積を作るだけなら、市販の見積ソフトでも対応できます。ところが、自分たちの仕事では、見積後の案件管理や請求でも同じ内容を確認します。

見積を独立した書類として保存するだけでは、後から対象の見積を探し、案件との関係をもう一度確認する必要がありました。

見積と案件を関連付ける

保存した見積を個人案件と関連付け、案件側から参照できるようにしました。

ここでいう関連付けは、見積の顧客情報や明細を案件へ自動コピーすることではありません。見積と案件の関係を残し、必要なときに元の見積を確認できるようにするものです。

自動コピーにすると、見積を修正した場合にどちらが正しいか分かりにくくなるため、現在の仕組みでは参照のつながりを重視しています。

見積の後も同じ情報を使う

見積後には、案件の確認、作業、納品、請求があります。

後工程で見積内容を確認できれば、別々の保存場所から書類を探す負担を減らせます。請求時にも、何を提示していたのかを見直しやすくなります。

ただし、見積から請求までを自動確定するわけではありません。作業内容や数量が変わる場合もあるため、請求前の確認は人が行います。

価格情報を共通して参照する

見積や請求の画面がそれぞれ価格を持つと、変更箇所が増えます。一方だけ直して、もう一方に古い情報が残る可能性もあります。

そこで、価格情報を共通の場所で管理し、必要な画面から参照する形にしました。

一元化したのは、すべての仕事で同じ価格を使うことではありません。仕事の条件や対象時期による違いは残し、その条件に合う情報を参照します。

共通化しても確認はなくならない

価格情報を共通にしても、金額の違いが自動的になくなるわけではありません。

• 選んだ項目が正しいか
• 数量や条件が現場と合っているか
• 対象時期を取り違えていないか
• 見積後の変更が反映されているか

こうした確認は残ります。共通管理の目的は、判断をなくすことではなく、確認する情報の出どころをそろえることです。

市販ソフトやExcelで十分な場合もある

見積書を作成し、保存・印刷することが中心なら、市販の見積・請求ソフトで十分な場合があります。

価格の種類が少なく、更新する人も限られているなら、Excelも変更しやすい道具です。

自分たちは、案件管理、見積、価格情報、請求の流れを同じアプリから確認したかったため、自作する意味がありました。一般的に自作の方が優れているという話ではありません。

Excelから自作アプリへ移した判断は、現場仕事の管理アプリを自作した理由でも紹介しています。

自作によって増えた保守

情報を共通化すると、変更の影響範囲も広がります。

価格情報の持ち方を変えたときは、見積や請求など参照する側も確認しなければなりません。条件の追加、古いデータとの整合、操作する人への説明も必要です。

自作した後も、価格情報と画面の関係を保守し続ける責任があります。このコストより、再入力や確認場所を減らす価値が大きいかを考える必要があります。

まとめ

見積書は、作って渡した時点で終わるものではありませんでした。

そこで、見積と案件を関連付け、案件から見積を参照できるようにしました。価格情報も必要な画面から共通参照します。ただし、自動コピーや自動確定ではなく、条件の違いと人の最終確認は残しています。

自分たちに必要だったのは、高機能な見積ソフトではありません。見積から請求まで、情報を探し直しにくい流れを作ることでした。