- ベストアンサー
工事管理データベースで請求書を出す方法
- 工事管理データベースを使用して、月末に請求書を作成する方法についてまとめました。
- 工事受注から見積作成、進捗管理、請求書、入金、出金の管理を一元化する工事管理データベースの設計についても解説しました。
- 未収金を含めて請求書に集計する場合の処理方法やシステムについても詳しく説明しています。
- superwonderful
- お礼率66% (90/136)
- その他(データベース)
- 回答数3
- ありがとう数10
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (2)
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【補足】請求書の件について。 １、請求書は２種類ある。 (1)売上発生時に渡す請求書。 (2)締め日で締めて渡す請求書。 工事の売上が確定した時点で、売上伝票、納品書控、納品書、請求書等が複写になった伝票を発行します。これは、顧客が個人であれ法人であれです。ただ、個人顧客は、これで終わり。しかし、法人のお客様は、「月末締めの何日払い」ということがあり別途に月次請求書を発行することになります。 ２、繰越管理の一つのアイデア。 [顧客台帳] ID・・・・・・1 お名前・・・・(株)前田興産 読み・・・・・まえだこうさん [顧客別繰越明細] ID・・・・・・・・1 得意先台帳_ID・・・1 年月日・・・・・・・2014/11/01 期首売掛残・・・・・10000 当月売上・・・・・・20000 当月入金・・・・・・50000 1対多の関係で、一人のお客様に年月日の異なる繰越明細が対応します。この明細は、最近の３ヶ月分程度を保存しておけば十分です。 なぜ、繰越明細を記録するのか？それは、一応、月次で締め切るためです。また、なぜ、最近の３ヶ月分程度を保存する必要があるのか？それは、「おい、違っているぞ！遡って修正せよ！」という要求に応えるためです。 また、こういう月次の繰越明細を用意することで月締めとは関係なく売上伝票、入金伝票の発行を継続できます。 ３、売掛残一覧表と月次請求書とは体裁が違う。 さて、[顧客台帳]、[顧客別繰越明細]、[工事台帳]、[工事明細]、[売上伝票]、[入金伝票]のテーブルがあれば、売掛残一覧表と月次請求書とは共に発行できます。もちろん、それぞれ渡す相手と目的が違いますのでレイアウトも内容も異なります。 11月01日御請求残高 11月度新規売上額 11月度入金額 12月度請求額 以下、当該の明細が続く これを、いわゆる現行の月次請求書を思わせる体裁で出力するのが請求書発行アプリケーションです。これに対して、Accessのレポート機能を使って出力するのが売掛残一覧表です。 以上です。
お礼
ご回答ありがとうございます。 上にある『それは、「おい、違っているぞ！遡って修正せよ！」という要求に応えるためです。』と言う事が会った場合、さかのぼって再度、修正するべき見積金額、か、何かはわかりませんが、そこの部分の含まれる月の全ての売上と入金の計算をしなおし、今月文の繰越金額を修正して、繰越台帳に登録するというやり方でよろしいでしょうか。 よろしくお願いします。
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
１、現状のやり方とPCシステムは似て非なるもの。 現状分析⇒PCシステム設計⇒社内の業務改革⇒PCシステム設計の手直し⇒Access等の開発作業に着手 まず、開発手順ですが、[現状分析⇒PCシステム設計]というステップが一番最初かと思います。この場合、現状のやり方とPCシステムは似て非なるものとなります。ですから、請求業務、入金処理業務、その他関連する一切の業務の進め方、関連伝票の多くが刷新されることになります。 が、が、従来の業務に進め方を完全否定する新たなPCシステムってのは現場の歓迎せざるところ。これをやりきるには相当の実権を有している必要があります。が、さりとて、現実には妥協ってのも必要です。こうしてPCシステムは手直しされて最終案となります。 肝心なのは、Access以前の問題ではないでしょうか？PCシステムの最終設計さえ済んでいれば、Accessシステムの開発なんてただの肉体作業。頭を使う作業ではありません。Accessに向かう前に、Wordで全ての入力画面、参照画面、各種レポートを作り、それらを実現するに足るテーブル設計を行い、もって、次期社内帳票の雛型を作成して社内討議にかける。このプロセスが決定的に欠落しているように思います。 ２、売上伝票.単価<>商品マスター.単価。 さて、質問事項の一つの要点は、売上伝票の単価と商品マスターの単価との関連に関する見方・考え方。両者は通常は同じですが、Accessのテーブルでは非連結とし無関係とします。 つまり、テーブル[工事請け台帳]（これを見積書というから、実に、ややこしい）が販売管理で言う[商品マスター ]になりますが、「請け代金＝売上代金」という見方・考え方はシステム上は厳禁です。「参照すれどリンクせず」に徹した設計を行います。 ３、テーブル[工事請け台帳]は、通常の商品マスターとは違う。 当たり前のことですが、[工事請け台帳]は、通常の商品マスターとは違います。それは、実際の工事の見積書を分析すれば判ることですが、主請け代金、副請け代金に２別され、さらに、副請け代金は、カテゴリー１、カテゴリー２・・・と分類できることでしょう。[工事請け台帳]を本件工事一式で記録するのか？それとも、本工事名＋諸カテゴリー名で記録するのか？ここが、一つの検討ポイント。もちろん、見積書発行システムの各種テーブルと[工事請け台帳入力伝票」とは、似て非なるもの。見積書発行システムと販売管理システムとは縁もゆかりもない別物です。 ４、先売り・先入りの原則と棚卸しの両立をいかに工夫するのか？ さて、テーブル[工事請け台帳]は、通常の販売管理の[商品マスター]に相当することは先に述べた通りです。だとすれば、当然に、その月次での在庫棚卸しに相当する処理とレポートを要求されます。しかし、これを実現するには、ちょっとばかりの頑張りを要求されます。 入金伝票で、[顧客ID]欄などに0を入力すると、顧客入力フォームがオープンされて顧客の[読み]等を入力すれば該当する顧客一覧が表示され、それを選択して[顧客ID]欄が確定。となる筈が、顧客入力フォームで顧客を確定すると、更に、そのフォームの下部に[同顧客請負工事未収一覧]ってのが表示されるので、実にややこしい。 この[同顧客請負工事未収一覧]を表示するのが、なぜにややこしいのか？それは、売上伝票、入金伝票をたった一枚入力するだけでリストが変わるからです。月次棚卸しの結果を単に表示すれば良いという訳にはいきません。それを、毎回毎回、ちゃんと最新のそれを表示する。これをクリアしないと、[同顧客請負工事未収一覧]の消込みも彼岸の彼方。 さて、このハードルを跳び越えたら先売り・先入りの原則と棚卸しが両立するステージが見えてきます。 ５、先売り・先入りの原則と棚卸しが両立するステージとは？ １から４までは、実際にシステムを開発した経験からして確か。でも、５の実像は？ちと、不明。でも、次のことだけはハッキリしています。 １、テーブル[入金伝票]に[工事請け台帳.ID]を記録して終わり。 ２、テーブル[工事別入金履歴」を[入金伝票]入力時に作成する。 この２択なんですが・・・。もう、70歳にもなろうかという爺。思考回路がこの辺りでショート。これは、質問者自身が悩みに悩んで結論を出して下さい。
お礼
ご回答ありがとうございました。 とても専門的なご説明で、部分的にまだ私には理解出来ないところがありました。 例えば、以下の部分・・・ 『主請け代金、副請け代金に２別され、さらに、副請け代金は、カテゴリー１、カテゴリー２・・・と分類できることでしょう。[工事請け台帳]を本件工事一式で記録するのか？それとも、本工事名＋諸カテゴリー名で記録するのか？ここが、一つの検討ポイント。』 ここの部分、更に詳しくご説明していただけないでしょうか。 よろしくお願いします。
補足
f_a_007さん いつもご回答をしていただき、大変ありがとうございます。70才にもなるお方とは、ご説明のされ方から結構高齢の方かとは思いましたが、いやはや大変驚いています。 それに比べ私は大変未熟者ですが、アドバイスのほう宜しくお願いします。 現状分析─要件定義なるフェーズは一応、設けいていますが、難点がありすぎまして、大変困っています。詳細は言えませんが、この業界の方々が皆さん要件定義なるものの必要性に理解が疎く、なかなか必要な情報を取得するのが大変です。そのため、なんとか業務フローは出来上り、帳票、そして、データ項目くらいは纏まりそうです。 問題は見積書が1つの工事でいくつも発生し、請求先もイレギュラーに複数化、これらをまとめるのが大変です。どのような請求先があるのかは決まっていますが、数の変動があります。1見積書＝1請求先という関係が成り立てば、案外設計し易いと思いますが。 さて、質問をさせて下さい。 > (1) [工事請け台帳]は、通常の商品マスターとは違います。それは、実際の工事 > の見積書を分析すれば判ることですが、主請け代金、副請け代金に２別され、さ > らに、副請け代金は、カテゴリー１、カテゴリー２・・・と分類できることでし > ょう。[工事請け台帳]を本件工事一式で記録するのか？それとも、本工事名＋諸 > カテゴリー名で記録するのか？ここが、一つの検討ポイント。 質問1：主請け代金、副請け代金とは何ですか？ 質問2：。「[工事請け台帳]を本件工事一式で記録する」というのは、1つの工事に対して1つの見積書で記録するということでしょうか？ 質問3：「[工事請け台帳]を本工事名＋諸カテゴリー名で記録する」とは、本件工事の下に見積対象となる各関係会社や入居者などに応じた見積書を複数記録するという意味でしょうか？ > (2) この[同顧客請負工事未収一覧]を表示するのが、なぜにややこしいのか？そ > れは、売上伝票、入金伝票をたった一枚入力するだけでリストが変わるからです > 。月次棚卸しの結果を単に表示すれば良いという訳にはいきません。それを、毎 > 回毎回、ちゃんと最新のそれを表示する。これをクリアしないと、[同顧客請負工 > 事未収一覧]の消込みも彼岸の彼方。 質問4：以下のような考え方は正しいでしょうか？ 同顧客請負工事未収一覧のもとになるテーブルを作成する。 例えば、見積テーブルで作成したデータから ・工事依頼ID, 見積ID,請求先ID,見積金額 などを未収金一覧テーブルなるものにコピーし、そのレコードに対して請求先ID(顧客ID)でクエリーをかけ、抽出したデータを未収金一覧というリストにするのはどうでしょうか？ ここで、疑問なのは、請求先が、不動産会社や入居者、保険会社などに別れる可能性があり、この前の見積作成の段階で、既にこの3つの請求先別の親・明細テーブルでデータ入力し、見積書を作成する設計をとっています。この場合には、プログラムでこれら3つの親テーブルから同じ工事依頼IDを持つそれぞれの見積の合計金額を取得し、それを未収金一覧テーブルにコピーするという方法しか考えられませんが。 そして、入金があった場合には、入金してくれた顧客のIDを使い未収金一覧テーブルでその顧客の入金金額から該当レコードに入金額、入金日を入力し、消し込みを行う。この部分がプログラムで実行可能かどうかがわかりません。 このようにすれば、未収金一覧テーブルで見積額の支払残が残っているものは全て請求書発行に回せるような気がします。 ここで、必須なのは、必ず、請求先ベースで見積書を作成することだと思います。入居者や物件のオーナー、不動産などそれぞれで見積書をおこす。当たり前の事なのでしょうが。 質問5：そうすると、出金伝票も、同じような作業が必要になるのでしょうか？ 出金伝票の場合は、 未支払一覧テーブルを作成し、そこに ・工事依頼ID ・支払先ID（部材販売元、又は、協力工事会社など） ・見積金額（各工事毎の部材発注金額、または、協力会社の見積金額） ・振込金額 ・支払日 この支払先IDは、 各部材発注テーブル、そして、協力会社見積テーブルから取得します。 そして、出金伝票に支払先IDを入力すると未支払一覧テーブルのリストが出てきて、そこで更に消し込み処理をする。 このような感じの処理を思いつきました。 この考え方があっているのかどうか、また、改善の余地など、具体例などもふくめてアドバイスお願いします！ > １、テーブル[入金伝票]に[工事請け台帳.ID]を記録して終わり。 > ２、テーブル[工事別入金履歴」を[入金伝票]入力時に作成する。 こちらの引用に関する質問が、6, 7になります。 質問6---上の説明1について こうすると、月次で精算書を起こす場合、この入金伝票に入っている工事受け台帳.IDをみて、工事受け台帳の見積額と入金された金額を比較してそれが支払済かどうかをチェックし、住んでいないものを精算書に起こすというやり方ですか？ その場合、過去のどこまで工事受け台帳のレコードを遡れば良いのでしょうか？ 質問7---上の説明2について こちらは、私が最初に質問させて頂いた考えかたに似ているのでしょうか？ アドバイスのほう、宜しくお願いします。 m(__)m
お礼
丁寧に詳しく回答をしていただき、大変ありがとうございました。 回答して頂いた後、自分でテーブル設計・作成としているところです。 また、何かわからないことがありましたら、よろしくお願いします。
補足
ご回答ありがとうございます。 >[顧客台帳]、[顧客別繰越明細]、[工事台帳]、[工事明細]、[売上伝票]、[入金伝票]のテーブル 上の各テーブルの関係性がまだよくわかりません。 各テーブルの主な項目を例えで教えていただけないでしょうか？ よろしくお願いします。