請求先

Access 2013 vba

1つの受注された案件で、その売上の請求先が複数になる場合があります。
しかも、その請求先に何を請求するのかは、その場、その場で変わり、決まっていないらしいです。

このような場合に、どのように請求先を1つの受注した工事案件に引き当てれば良いのか、良くわからず、困っています。テーブル構造は恐らく

【受注テーブル】
・受注ID(Main key)
・受注日
・依頼元
・依頼内容
・受注総合計金額

などなど

【請求引当テーブル】
・請求引当ID(Main key)
・受注ID (Ex.Key)
・請求金額
・摘要
・支払期日（依頼元が当社に支払う期日）
・支払方法

しかし、その明細については、受注テーブルの項目の依頼内容の何になるのかは、その時にならなければわからないのです。それに、請求先が1つしかない場合もあるし、複数に成るのが最後にならないと分からない場合もあります。

この場合、請求書をPGでデータベースからデータを選択して作成する場合、何を選択すれば良いのかわかりません。

このような説明の仕方では、ご回答が難しいかとも思いますが、私も説明に苦慮しています。

実際に、このようなケースを扱ったシステムでは、どんな解決策をとっているのか知りたいです。

No.1 回答者： f_a_007 回答日時： 2015/01/07 22:21

ウーン！

まだまだ、Accessを起動してシステム開発の実作業に取り掛かるのは早いのでは？その以前のWordなどで、

(1)テーブルを設計する。
(2)入力フォームを設計する。
(3)データの変換・加工要領を設計する。
(4)各種帳票を設計する。

という設計段階ではないのじゃーないでしょうか？

【全体の考え方】

　営業が受注した案件は、いわば商品在庫。ですから、その入力は、販売管理における仕入伝票入力のゆなもの。売上は、あくまでも在庫商品が納品された時点で発生するもの。よって、その入力は売上伝票処理に相当。その場合、商品在庫テーブルの販売単価と売上伝票の販売単価とは常に一致する訳ではありません。それぞれの単価は、それぞれに管理。もって、その差を把握することもシステムの課題。

＞売上・納品書を発行する場合、売上商品をどのように選択するのか判りません。

　それは、商品在庫＝営業が受注した案件を参照。ただし、販売単価はリンクさせない。あくまでも、商品在庫の販売単価は予定。

【全体の考え方を基に設計を先行】

10 INPUT A, B
20 C = A + B
30 PRINT C

僅かに3行のプログラム。だが、そこには入力データの種類と要領が明示されています。次に、入力したデータの加工（演算）の要領・手順が示されています。そして、最後に結果の出力。目の前の案件も、これがちょっと複雑になっただけ。だが、その複雑さは、入力⇒演算⇒出力の各段階の具体的な設計の必要性を排するもんじゃーないです。むしろ、複雑だからこそ設計が大事。

　とにもかくにも、テーブルを設計し、それに準じた入力フォームもデッサン。それで果たして月次請求書が発行できるのか？そのために必要なデータの変換・加工手順はどのようか？最後に、各種レポートの雛形もWordで設計。Accessを起動してシステム開発の実作業に取り掛かるのは、これらが全て終わってから。

　と、マイクロソフトのマニュアルは言っています。

この回答へのお礼

ご回答ありがとうございました。

仰るとおり、請求の部分が不透明なまま、製造に入ってしまい、その途中で請求先が一受注工事に対して複数になることがあると聞かされ、大変困ってしまっています。
製造前の設計の重要さは認識しておりますが、短い期間での製造を強要され、私としてはどうしようもない事情があります。

その結果、請求先が複数ある場合のテーブル設計のやり直しをするか、請求先が複数の場合には、新規で受注案件レコードを作成し、それまで入力した部材注文明細と工事発注明細のレコードをコピーするか・・・の対策を考えています。

請求先が複数になる場合には、請求テーブル明細などを作るとなると、請求先ごとの請求金額はわかっても、その請求の明細がその場その場の話し合いで結局変わるので、どのように作れば良いのかわかりません。
1受注に対して、請求先が2つになっても、もしかすると、その2つの請求先の工事は一つの工事になるかもしれません。
ようは、支払を2者で分担するというようなやり方です。

ですので、請求先2つだからといって、工事を別々のものとして管理するようなテーブル設計をして良いのかどうかもわかりません。

何か良いアドバイスがあればよろしくお願いします。

お礼日時：2015/01/12 16:00

No.2 回答者： shitaba 回答日時： 2015/01/07 23:55

大変失礼ながら、私も回答No.1さんと同じ感想を持っております。

データモデル設計(テーブル設計)くらいは完了してからプログラム
製造に入ったほうが良いです。
おそらく『データモデル設計が製造中に破たん』という「典型的な
失敗プロジェクトパターン」になりかけていますよ。

そもそも、質問のような引き当て処理は、別に珍しい仕様でも何で
もありません。システム開発ではごくごく普通に見る仕様です。
この程度で設計に困るようでは座学が足りません。いちど在庫管理
や販売管理の設計の知識を入手しておくべきです。

比較的実践的な書籍を紹介します。
　グラス片手にデータベース設計~販売管理システム編
　梅田 弘之 (著)

この回答へのお礼

アドバイスして頂きありがとうございます。

テーブル設計完了して入ったと思いきや、入った後に再度確認したところ、大変重要なイレギュラーを知らされたところです。

典型的な失敗PJにはしたくありませんが、必要な知識を取り入れる事も重要ですね。。。

お話の本、読んでみたいと思います。

お礼日時：2015/01/12 16:04

No.3 回答者： yambejp 回答日時： 2015/01/08 10:23

受注-請求は必ずしも直結しません

受注-製造(?)-出荷-納品完了-売上計上-請求-回収
の流れになると思うので、
売上計上から請求に流れる時点で、売上伝票（もしくは明細）ごとに
請求先を確定するのが筋ですが請求されるまで請求先がわからないとなると
売上計上-請求保留-請求
といった中間処理が必要になるでしょう。

この場合受注先に管理テーブルに請求先が一意で登録されている場合は
自動で流し、請求先が未登録もしくはなんらかの形で複数登録されている場合は
請求保留になるよう調整し、請求保留から請求には手動で属性変更する
ことになるでしょうか。

ただし・・・
監査や税務的に、一受注先の請求先が複数であるということは
架空取引など不正リスクが内在すると判断される可能性は高いと思います。
本来であれば同じ受注先でも請求先が違うのであれば別受注先として管理すべきです

受注＝請求：n対1はあっても1対nはNG。

この回答へのお礼

ご回答有難うございます。

受注＝請求→ n:1　はあっても、1:n　は、NG
というのは、どんな業界でもそうなのでしょうか・・・

依頼してきた会社と請求先が違う場合には、請求先を依頼元として受注データ自体を作り直ししたほうが良いのでしょうか。
ちなみに、私が開発しているのは「建物の工事案件」の管理システムで
受注→工事見積→発注→工事進捗管理→工事完了→精算処理→請求書作成→入金確認処理
となります。
請求先が変わったり、複数になるのは、工事の費用を誰が支払うのかという所で発生します。

お礼日時：2015/01/12 15:47

No.4 ベストアンサー 回答者： shitaba 回答日時： 2015/01/12 18:25

回答No.2です

> 受注＝請求→ n:1　はあっても、1:n　は、NG
> というのは、どんな業界でもそうなのでしょうか・・・

そんなことはありません。『請求は月締めで会社毎にまとめる。
さらに状況によって(分割納品だったりして)請求が一部 月またぎ
することがある』というパターンに遭遇したこともあります。
これですと受注と請求は N:N ですね。
ここらへんは、販売管理システムの "あるある" なので、むしろ
仕様確認時にエンジニアからユーザに確認しておきたい事項です。

解決策はご紹介した書籍を見てほしいのですが、質問サイトで伝え
られる程度のヒントだけご紹介します。

受注データの [受注] ＋ [受注明細] という構成になっていると思い
ます。これに対して [請求] は、[受注] と直接の関係を持たせずに、
[請求]対象の [受注明細] をチョイスするという構造にします。
[請求]データの作成時に[受注明細]の内容を選べるようにするわけ
ですね。

これのもっとも単純な構成はこうです。こうすると、受注と請求の
関係を 1:N にすることができます。

　　受注テーブル　　受注明細テーブル　　請求テーブル
　　受注ID　　　←　受注ID
　　　　　　　　　　受注明細ID
　　　　　　　　　　請求ID　　　　　→　請求ID

※[受注明細] テーブルの請求IDは、受注時はNULL。請求時に初めて
　値が入ります
※[受注] テーブルと [受注明細] テーブルは 1:N の関係、
　[受注明細] テーブルと [請求] テーブルは N:1 の関係になります。
　テーブル設計では直接の関係で N:N を作らないのが鉄則です。

もちろん、これは最も単純な形です。
実際には『請求は[受注]を選択して作りたい』などの要件によって、
テーブルに色々な付加情報が付いたり、場合によっては [受注明細]
テーブルと [請求] テーブルの間に[引き当て]テーブルが必要にある
こともあるでしょう。

また、内部データはこのように作っても、UI 的には請求時に明細を
毎回ひとつひとつ選択していたら大変です。『[受注]ごとまとめて
選択』とか『受注明細の検索機能』の充実が必要になるかと思います。

この回答へのお礼

ご回答ありがとうございます。
ご説明を読ませて頂いて、これならば、1受注の工事の請求先を2つの違う請求先に分ける事ができると思いました。
仰るとおり、その振り分け作業を受注明細の全てのレコードに対して1個1個していくと大変な作業になりますが、例えば、ある受注の明細を全て仮テーブルに取込、そこで、チェックボックスなどで選択したものに、請求先IDを引き当てると言う処理をして、そこでチェックされたレコードを請求明細テーブルに格納するというようなやり方はどうかと考えています。
次に、選択済みの受注明細には既に請求先IDがセットされているのですから、2つ目の請求先への引当処理画面では、それらはグレーアウトした表示になって引当自体が出来ないような作りはどうでしょうか。

あと、質問と関係があるので質問させて頂きたいのですが、入金された物の消し込みをスル場合、この請求明細テーブルに対してするのか、それとも、受注明細に対してするのか、このへんはどういう処理の仕方にしたら宜しいでしょうか？

よろしくお願いします。

お礼日時：2015/01/13 09:32

No.5 回答者： shitaba 回答日時： 2015/01/14 00:20

回答No.2です。

> 例えば、ある受注の明細を全て仮テーブルに～(以下略)

具体的な実装は、システムの要件に従って工夫して頂ければ
良いかと思われます。
ただ『データをコピーして他のテーブルに格納』する処理は、
乱用すると後からデータ更新が必要になったときにコピー先も
更新が必要になって、処理が煩雑になりますのでご注意を。
安易なデータコピーもシステム崩壊原因の "あるある" です。

> 入金された物の消し込みをスル場合～(以下略)

この質問が出るということは、失礼ながら質問者さんはまだ
今回作成するシステムの要件の理解が不足しています。もう
いちど業務フローを見直して『なぜ、入金消込処理が必要な
のか、これは何のために実施するのか』を問い直してくださ
い。

これは質問者さんが今作っているシステムの『理解』のため
に、質問者さんご自身の手で解決すべき内容かと思います。

この回答へのお礼

ありがとうございます。

おっしゃるとおりだとは思います。

今、おすすめになられた本を読みながら、研究しています。

よろしくお願いします。

お礼日時：2015/01/15 12:18