締日別の売上入金消込と入金繰越処理 その２

すみません、説明は後で、先に前回の「売上入金消込繰越処理」を
ダウンロードできるようにします。

Filemaker17 win8
ダウンロード

締日別の売上入金消込と入金繰越処理

前回のお問い合わせの内容の続きです。

ざっくりですが作ってみました。
とりあえず動作確認中なので今回はダウンロードはできません。


まず、締め別の売上請求の一覧。（請求書を作るところは省いてます）

次に入金処理の画面（請求テーブルに入金テーブルを参照しています）
デモデータは少なめにしておきました。締日別、前回、今回、次回などが確認できたり、得意先で検索し、請求・入金・繰越の流れを見られるように作りました。
また、フィールドタイプの集計は使わないということでしたので、
ポータルでsum関数を使用して合計を出しています。
（計算式や非保存を極力使用せず、スクリプトで計算しているので、集計を使用しても
気にされるほど遅くは感じないかと思います）
ボタンが多くなるのが気になりますね(笑)

（パートは締日別、得意先別です）

渡邉と入れて検索ボタンを押してみます。

５月、６月、７月の状況（流れ）を見る事ができます。
入金日によって、繰越更新基準日（名前はなんでもOK)が計算され、次回に回すか、そのまた次に回すかを計算できるようにしています。

入金０円と入金日が薄文字で書かれている箇所は、空の状態ですと繰越計算をしないので、"請求入金ボタン"を使用して今回締日５月２０日だとすれば、＋１日を計上しています。「６月２０日までが入金予定日ですよ」という意味合いで、実際の入金日が６月２１日で、差額があれば、７月２０日の締に繰越分として計上されます。
実際に入金があれば、薄文字カ所に上書きでいいでしょう。薄文字は予定表示と考えればいいかもしれません。

繰越処理はこんな感じで大丈夫ですかね？
繰越が算出されてますから、請求合計も合わせて請求書に載せればいいですよね。
（請求書等は作っていません）

請求テーブルの自己リレーションを作り、上記のように結びます。
繰越更新基準日とは、入金日によって締日を変更し、入金差額を次回に回したり、次の次に回したりします。
一請求先に対して、複数の請求があるので、差額のルックアップは使用せず、入金テーブル（ポータル）差額の合計を、パート集計（得意先）の繰越しに計上しています。
請求ごとに繰越ではなく、請求先別の今回、次回の集計欄（パート）です。


ん～、こんな感じですかね・・・

第２８回弁護士向けソフト まずは、３０分で見積システムを作ってみます。

前回も書きましたが、弁護士さん向けのソフト開発を最初から作っていきますので
よろしくお願いします。



事件管理ソフトの前に、簡単な見積システムなんかを作ってみます。
データベースの構造を知る上で、てっとり早く簡単に理解がしやすいからです。


まずはFileMakerの無料評価版をダウンロードします。
買うのなら、ちょっと高いけどFileMaker Pro Advancedをお勧めします。
理由はスクリプトデバッガとデータビューアがついてるからです。
テーブルインポート、カスタム関数が使えるのもいいですね。

僕は１４のAdvancedで作ります。


データベース（以下DB）は、通常SQLとPHPなど、データベースとアプリを分離して開発しますが、FileMakerは、何も考えずに、これひとつで開発できますので、プロじゃなくても非常に早く簡単に目的にたどり着けます。分離開発は、FileMakerにもExecuteSQL関数がありますので、やってやれないこともないのですが、開発の仕方を間違えると、遅く、使えないシステムになってしまうこともありますので、素直にそのまま使用する事をお勧めします。





----　それでは始めますね　---


新規ソリューションから　ファイル名「Test1」を作り

テーブルを作っていきます。
・見積
・見積明細
・商品マスタ
・得意先


日本語ですよ。
日本人なら日本語がいいに決まってるじゃないですか。

テーブルを作ったら、各テーブル毎にデータを入れるためのフィールドを設定していきます。



見積（テーブル）には

・伝票No（テキスト）
・得意先No（テキスト）
・日付　（日付）

同じく

見積明細（テーブル）

・伝票No（テキスト）
・商品No（テキスト）
・商品名（テキスト）
・単価（数字）
・数量（数字）
・金額（計算）　＝単価×金額



商品マスタ（テーブル）

・商品No（テキスト）
・商品名（テキスト）
・単価（数字）


得意先（テーブル）

・得意先No（テキスト）
・得意先名（テキスト）


を作ります。
ファイルを作った時に勝手にできたTest1のテーブルは放置してください。

次はリレーションです。

得意先（テーブル）の得意先Noから
見積（テーブル）の得意先Noをドラッグして線で繋げます。



見積（テーブル）の伝票Noから、見積明細（テーブル）の伝票Noまでドラッグして
線で繋げ、レコードの作成許可と、一緒に削除の２か所にチェックを入れます。



見積明細（テーブル）の商品Noから、商品マスタ（テーブル）の商品NOまで
ドラッグして線で繋げます。



テーブルは文字通り仕事の机と同じで、
田中さんの机と、佐藤さんの机を、あるKeyで結び同時に仕事をする事と似ています。
このとき、田中さんが作ったデータと、佐藤さんが作ったデータは、合わさって見えるのですが、データはしっかりと別々の机で保管されています。この関係をリレーション（関係）と呼び、
これができるデータベースをリレーショナル・データベースと呼びます。

primary key　(主キー）や外部キーについては、今回は省きます。

見積明細（テーブル）の商品名フィールドと単価フィールドを商品マスタ（テーブル）の同じ名称のフィールドからルックアップさせてデータを保管させます。


データの正規化と冗長性については後程説明します。

見積（テーブル）の伝票Noをオプションでシリアル番号を設定します。
１+１でも、0001+１でも、自由でいいです。


同じように、日付フィールドを作成日にチェックします。

得意先（テーブル）の得意先Noもシリアル設定をします。

商品マスタ（テーブル）の商品Noもシリアル設定します。


※　見積（テーブル）と見積明細（テーブル）は伝票Noで照合されていますが、
見積明細（テーブル）側の伝票Noはシリアル設定をしてはいけません。
見積明細（テーブル）の伝票No以外のデータが入力され確定された時点で
自動的に見積（テーブル）側の伝票Noが生成されます。

見積（テーブル）のレイアウト画面を開き、見積明細（テーブル）のポータルを作ります。

田中さんの机の上で、佐藤さんの机が見えるような状態（不思議ですね～）

ポータルにフィールドを追加します。
このとき、明細の伝票Noは省いて結構です。

こんな感じになりますが、全部同じ幅だと変ですので、フィールドの幅と書式を設定します。

数字フィールドは右寄せ、小数点以下、３桁区切りなどを設定します。

見積（テーブル）に得意先（テーブル）の得意先名フィールドを置きます。

あれ？と思うでしょう。
見積（テーブル）側に得意先名フィールドを作って、さっきと同じようにルックアップさせて
データを保管させなくてもよいのかと・・・・。

それでもOKなんです。

でも、あえて、見積（テーブル）とキーで結んだ得意先（テーブル）から得意先名を参照させることにしました。


実は、なぜ見積システムを作るのかは、これを説明したかったからなんです。


先程の見積明細(テーブル）の商品名や単価もルックアップさせずに、キーによって参照させることによってデータを表示させることが可能です。（これが正規化です）

なぜ、そうしなかったのか・・・


一つには、参照させて表示させる事は、この見積（テーブル）画面で、マスタ側のデータも変更できてしまう！ということです。
そこに不具合が生じるか否かを、使用者側の用途によって決定させなくてはいけません。
例えば、見積もりの場合、明細（テーブル）ポータル上で商品マスタにある名称や単価が操作（参照して表示）できれば、まるで学習機能かのようで便利ではありますが、過去の取引データの変化が取得できません。


８月１５日　りんご　１００円
９月１１日　りんご　１０１円

という単価の変化を明細で取得したいのに、正規化したいがために、商品マスタを参照させ過去のデータまで


８月１５日　りんご　１０１円
９月１１日　りんご　１０１円

に上書きされてしまったら、取引の変化が分かりません。




見積もりや売上請求、仕入・買掛など、相手と取引する業務では、「過去と現在に変化があって当然」と決定されれば、ルックアップさせて、データを保管させ、あえて冗長させる手段をとります。


いやいや、過去データよりも、どんどんマスタ・データを参照させて上書き（正規化）させれば、データも更新され「楽なんだ」と考える場合は、過去の明細単価まで一斉に変わってしまいます。

もう、これは開発者より、使用者が決めなくてはいけません。


見積書という概念で考えると、得意先名が伝票入力時に変更される事は考えられないので正規化でいいのだと考えます。一方、明細内の商品単価は、原料の値上げや、諸事情などで今回の取引上の単価が変わるなど日常起こりうることです。
マスタ側のデータはそのままで、明細上で単価変更が出来き、過去の取引金額の変化が分かった方が良いでしょう。
見積ならまだしも売上請求で過去の明細データが変わってしまったら、ソフトウエアとは言えないものになってしまいます。



リレーションといっても、なんでもかんでも正規化すると、実際の業務に支障をきたす場合がありますので、現場実務を考慮して判断しなくてはいけません。
また、メンテナンスなど、ファイルが壊れ、NOと名称を合わせるのが大変な場合、ルックアップされてデータが保管されていれば、「０００３番はリンゴ」というデータが確認できますが、正規化された場合は、NOがなんの商品なのか分からなくなる可能性もあります。

（だからといって、なんでもルックアップも止めましょう）

さてさて、見積（テーブル）の合計フィールドをSum関数を使って、
見積明細（テーブル）の金額を指定します。

まぁ、見栄えの問題でもありますが、ポータルをクリックし、代替の行状態にチェックを入れます。

インスペクタで、各フィールドの入力しなくてよいものを選び、ブラウズモードを外します。

入力するフィールドに色を付けてみます。

レイアウトモードにして、レイアウトメニューからタブ順の設定を行います。

キーボード操作で次のフィールドに移れるのは便利ですね。２分でできます。


（最近クラウドを使ったWebでの業務アプリが増えてきましたが、FileMakerでは、このタブ順でキーボード操作を設定するのは便利ですよね、Webソフトでは下手するとEnterキーを押すたびに送信したりして使い物にならなくないですか？最近ではjqueryのイベントなど使ってコードを書けるようにはなりましたが、何日もかかりますし、開発が嫌になります。実際、現場実務でのWebソフトは、まだちょっと処理も遅く駄目っすね～）



必要のない箇所の番号は削除します。

TabキーとEnterキーで次のフィールドに移るように設定します。



これで、非常に簡単で簡易的な見積システムが完成です。
得意先（テーブル）と商品マスタ（テーブル）にデータを入れて
実際に操作してみましょう。

消費税の設定やデータのコミット（確定）は後日、説明します。
今回はスクリプトを一切使っておりません。









ダウンロード
（今回の分）

ＦｉｌｅＭａｋｅｒで分類 絞り込み（中分類、小分類）

ひさびさにＦｉｌｅＭａｋｅｒ

あれから時は過ぎ、なんと１４なんかも出ちゃったりしました。ユーザーが増えました！ということでしょうね。ユーザーが増えるという事はいいことで、バージョンが上がったり、メーカー側の対応もよくなったりします。


随分と前に弁護士向けのソフトで大分類、中分類、小分類について書きましたが
そんなに分類分けが必要でなければ中分類、小分類だけでやってみようということです。

今回はバージョン１３で作ってみました。
ダウンロードもできますので試してみてください。

動的値一覧と何が違うのかというと、ちゃんとid,と名称フィールドを作り、しっかりマスタ管理して動かそうということです。
よくあるのは、名称を値一覧にすることですが、当然索引設定されますので非常に検索呼出しが早くなるのですが、名称変更があり得るのなら、しっかりidなどの番号をＫｅｙにして管理されたほうがいいと思います。


＜２つの用途をみたします＞

　事前登録時の分類絞り込み（マスタ側）

　事前登録されたデータを分類によって絞り込み、ガイドに表示（入力画面など）


というわけなので、事前登録時の考え方、
それを呼び出す絞り込みの考え方、そしてそのリレーションの組み方は当然違います。

事前登録の画面（商品マスタ）

先に中分類マスタ、小分類マスタを設定し商品マスタ設定時には、分類を絞り込り込める設定です。（中分類マスタで小分類を設定する）

一方で、入力画面で商品を分類の絞り込みによってガイド表示させる場合は、中分類をＫｅｙにした商品マスタのテーブルオカレンスから値一覧設定で絞り込む様にします。

中分類側の値一覧設定、中分類マスタではなく、中分類をＫｅｙにした商品マスタから閲覧するように設定します。

小分類は、中分類をＫｅｙにした商品マスタからidを絞り込ませます。
名称は小分類マスタのテーブルオカレンス側から拾いましょう。

メインテーブルを関連レコード表示させると、小分類をＫｅｙにした商品マスタのポータルにデータが表示されるという仕組みです。

いろいろ使えますので改造してみてください。


ダウンロード（ＦＭ13以上）

第２4回 自分で作ろう！ 弁護士向けソフト 見積書と売上と消費税 その3

前回の続き～


見積書のレイアウト

今までの様なNavレイアウトじゃない理由は、そこまで、マジでやったら製品になっちゃうから、あえてFileMakerPro11のクラシックなレイアウトを使用して作っています。
まぁ、お時間があれば、Nav（事件管理）と合体させてください。


関係者を選択したら、タブのオブジェクト名を設定しておいて移動するスクリプトを組んで自動的に商品マスタのガイド開けるようにすると親切ですね。（関係者は一人なので、それが可能）

レイアウトは好きなように作り替えてください。

自社マスタとか作って、右上に会社名や住所を表示させた

ほうがいいかもしれません。

見積もりなのでパートで小計とかしていません。

前回作った見積書に印刷のレイアウトと一覧を付けました。
それと、今回は、見積書データを売上伝票に移行処理。
ダイレクトに売上入力もできますし、見積もりから移行処理かけてもOKです。

商品マスタと税率マスタを照合させて、明細別に消費税（課税、非課税）ってのもカスタマイズできます。とにかく、今回は基本形ですので、やってません。

売上は、一覧表関係、沢山作れますよ。

商品順位表、分類別集計表とか、順位表とかいっぱい！

弁護士さんは数量とか表示しないんでしたっけ？
後日、やり方だけ載せてみます。

　　予のう金、着手金、報酬、手数料、諸経費、時間別、日当とか・・・
　　たぶんですが、計算式が沢山あるんですよね、
　　印紙とか諸経費の非課税があれば、明細での税率設定が必要。
　　（ここでいう商品マスタと税率マスタを照合）


　　細かい明細の他に、大まかな分類名を着手金とか報酬にして
　　その明細（細かい明細の合計値）を作ればいいんだと思います。
　　上の明細の分類合計明細です
　　提示するのは、数量も無く、単価も無い

　　●　着手金　　２００，０００円
　　●　手数料　　　２０，０００円　備考とか・・・

　　明細に戻れば、６行くらいの細かな計算がされているとか・・・
　　細かい明細は、計算の根拠として残しておけば良いのかと思います。
　　どうしてもくれ！と言われれば出せるものが良いでしょう。
　　


売上の消費税は、前回と同じ設定で、TO(テーブルオカレンス）を使用しています。


商店の場合、
売上伝票の連続打ち（溜め打ち）は、ボタンを設置して　前の関係者を呼び出すスクリプトでいいです。トリガ仕掛けると、見積からデータが貼り付けられた後に反応してしまいます。
最終タブ順位の空フィールドにトリガ仕掛けるって手もありますが・・・


請求書は
相手側の締日。それと請求書締日＝請求書到着期限（発送して到着させる期限）、すなわち、遅くとも3日前には、締て、請求書を発送する。そして支払日（入金予定日）
この３つの情報が必要ですね。


それと、未収入金、月末に集計される売掛残高、繰越請求。

今のままですと、売上伝票分は全て売掛になってしまいます。
さかのぼって、閲覧できて回収できるような仕組みじゃないと、駄目ですね。


入金は、明細の消し込み式じゃなくてもいいのかな・・
基本のやつでやってみます。





今回の
ダウンロード