案件ファイル管理

２０１４年頃にここで作っていた弁護士向けのシステムにも関係してくるんですけど、ファイル管理をもっと細かくパスを利用して、フォルダごとや、ファイルごとに管理できないかということで作ってみました。

案件管理っていろんな分野で使われるので知っておくと便利かもしれません。



さっそく作ってみますか！
僕はwinのFileMakerPro16Advancedで作っています。



たぶん、１５でも動くかな

テーブルは
案件管理と関連ファイルの
２つです。

頭にDとか付いているのは
データベースのD
マスタになるテーブルなどには
Mとか付けています。
案件管理は入力や修正などを行うテーブルなのでD、関連ファイルは、事前登録するようなマスタではなく、案件管理と連動してデータが増えていく明細のような働きをするので、これもD、
開発者の癖とかあるので気にしないでください。

テーブルごとにフィールドの設定を行います。
Keyになる案件idなどは
デフォルトのシリアルでも良いのですが、全削除しても１から始まらないので簡単なSQLを使っています。
僕的にはFileMakerでSQLを使うのはこれだけ。
（FMでSQLって好きじゃないんですけど、まぁ、これだけは便利なので・・(笑)）

g_フォルダpathというフィールドはテキストのグローバルフィールドです。

関連ファイル側も同様にフィールを設定します。

ファイルpathのフィールドは、ファイルを格納するファイルBOXというオブジェクトフィールドを指定したいので、計算式でGetAsText()を使用します。

あとは、基本的な設定です。

リレーションはkeyになる案件id同士を結びます。

関連ファイル側の作成許可にチェック。
運用の用途によりますが、削除にチェックすると、案件レコードが削除されると関連ファイル側も削除されてしまうので、ここではあまりお勧めしません。

ごくごく単純なレイアウトです。

基本データとポータル
ポータルは関連ファイルのテーブルです。
アイコンの絵はSVGのファイルを沢山追加していますので
このファイルを移植すれば使えます。










ポータルの中のボタンを設定していきます。

×ボタンは+ボタンと重ねており、インスペクタのオブジェクトを隠す項目にスクリプトを入れて制御しています。







＋ボタン（追加ボタン）は
Get( ウインドウモード ) = 1 or
not IsEmpty( GetRepetition( D_関連ファイル::ファイルBOX ; 1 ) )


×ボタン（削除ボタン）は
Get( ウインドウモード ) = 1 or
IsEmpty( GetRepetition( D_関連ファイル::ファイルBOX ; 1 ) )

です。

追加ボタンのスクリプトです。

今回は外部保存ではなく、パスを利用した管理なので
ファイルの挿入方法を”参照”に設定しています。
参照にすると、オブジェクトをクリックするとファイルが展開して開きます。

※ファイル名付のアイコンを選択してください。画像ファイルの場合は、その画像はオブジェクトに表示されませんが、参照の場合はこれでOKです。

削除ボタンのスクリプト。

僕個人で使うときはボタンを設定しないでオブジェクトに直接右クリックだの削除だの行うのですが、ここはちゃんとボタン操作で設定してみます。

フォルダパスを取得するスクリプト。

そうなんです。
フォルダパスとファイルパスを別々にしてめんどくさいのですが、説明のためにあえて分けてます。ゆくゆく使っていくと運フォルダパスだけで用が足りるかと思うのですのが・・・。
フォルダパスを取得して、指定のフォルダの中身を閲覧させ、その中身をクリックするとファイルが展開する！便利ですよね。
ファイルを一つ一つ選んでパスを取得するなら、こっちの方が楽なんです。


ここではMiddle関数を使用してパスを取得
Middle ( $path ; 2 ; 50 )
Middle ( テキスト ; 先頭文字位置 ; 文字数 )

フォルダパスからの展開先を作成します。

グローバルフィールドと
webビューアーを使って展開させます。

webビューアーにはしっかりとオブジェクト名を指定してください。

フォルダを開く
スクリプト。

ファイルを開く
スクリプト。
















Let([
   #path=GetValue(GetAsText(D_関連ファイル::ファイルBOX);2); 

/*絶対ファイルパスの抽出*/
/*この２ってのはパスが２行取得されちゃうので２。３行取得されるときは３*/


   #pos=Position(#path;"/";Length(#path); -1); 　　　　　　　
/*逆から数えて１つ目の"/"の位置*/
  
   #path=Left(#path;#pos); 

   #path=Substitute(#path;["image:";"file:/"]; ["filewin:";"file:/"];["imagewin:";"file:/"];["filemac:";"file:/"]) 
                 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　  
/*fileスキーム変換   ここんところ、多くて勘弁してほしいよね*/

];
   #path  &　GetContainerAttribute ( D_関連ファイル::ファイルBOX ;"filename"  )
)

//けっこう強引かも(笑)



この辺はちょっと難しいかもしれませんが、いちを掲載しておきます。






オブジェクトにファイルをドラッグすると、参照ではなく挿入になり、パスが入りません。よく「ドラッグさせてほしい」という要望があるのですが、ひとつのディスプレイでドラッグドロップするには、一旦画面を縮小させてファイルが置かれているフォルダを見える場所に配置して行うので、一見便利そうで使われてない事が多いです。
ちゃんと、ボタンからディレクトリを確認してフォルダやファイルを選ぶのがベストかと思います。

パスが２行表示になるのはFileMakerの仕様です。
１行目が相対パスで
２行目が絶対パスです。
読み込まれるのは絶対パスの方になります。



今回はパスがメインですが、次回はフォルダの場所が変わった場合や、インポートを利用した一括取り込みなども追記していきます。

今日のデモファイル（ダウンロード）

ボタン設定のアイコン、２００個くらい入れておきました(笑)

第２０回のダウンロード

すみません、いろいろあってダウンロードできなくなってました。


とりあえず　第２０回目のダウンロードです。

２０１４年のファイル　
（元々のファイル）
（ダウンロード）







事件の大分類、中分類、小分類の設定がちと難しいかもしれませんね～
マスタメニューに設定させていないので、
レイアウトから拾って確認してみてください。

先ほど
少しいじった２０１８年のカレンダースケジュールと連動したファイル
（ダウンロード）




以前作ったものはカレンダーとは連動していなかったのですが、連動させておきました。




製品ではないので、細かいところまでは作り込んでいません。

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

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



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


まずは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キーで次のフィールドに移るように設定します。



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

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









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

第２６回弁護士向けソフト UPしてあったファイルを修正

昨年の１月２日にアップしていたファイルの修正（一年ぶり）

第25回　自分で作ろう！　弁護士向けソフト　請求確認と消込入金、ダイレクト入金

で、少しスクリプトがおかしいのと、カスタマイズするための理屈が分かりずらいので修正しました。

今までダウンロードしてくださった方ありがとうございます。

なんちゃって請求・消込入金画面

↑見積から売上画面　　
　　　
不親切ですがデフォルトのメニューから請求入金に行ってください、、、

↑なんちゃって請求書

公開して沢山の方からリレーションがわかりずらいという声を頂きました（笑）

すみませんです。

普通はこんなにリレーションを張らないと思うのですが、過去のデータを追跡させるために、前々回まで遡れるものを作りましたので、気持ちが悪いのかと思います（詫び）

簡単なものを複雑にする気はないのですが

変数や関数を極力使わず、データをフィールドに保管し、足算、引算、掛算、割算で

請求書や入金処理をしちゃいましょうというものです。

ただ、集計は使っていません。

（関数も最小限、エラー処理もダイアログも作っていませんが・・・）

前回締日とか今回締日とか、リレーションとポータルフィルタで強引に帳尻を合わせたせいで、非常に複雑になっているのだと思います。

カスタマイズするのであれば

例えば、売上や入金日付と締日計算で照合せずに、今回締日開始、今回締日終了という計算式を作って範囲で照合するとポータルフィルタは最小限で済むかと思います。

ポータルフィルタはポータルに表示させるだけの機能で、SUM( )のような計算をすると全て計算されますから、何処かで帳尻合わせが必要になり、より複雑にしてしまいます。

何処に何が隠れているのか、探すのも大変ですから。。。。

前回は請求書までは作らなかったのですが、今回はなんちゃって請求書を作りました。

普通は、ポータル表示で請求書印刷はしません。一得意先で何枚にも渡る可能性があるからリスト形式で作ります。しかし、一得意先の締め単位の売上伝票が少ないのであれば、やっていけないわけではありません。

請求書を発行する前に、締日で検索できるリストがあると便利だと思います。

さらに、今回請求のある得意先にフラグを立てリレーションで照合すれば、もっと楽です。

前回請求+今回売上-今回入金で残があれば未収入金ですから、そういうリストも作れるのかと思います。

締めの一覧表は締日ごとで、月に一度売掛残高一覧表も作れるのかと思います。

ではでは。。。。

ダウンロード

（もう、１２がないので１３か１４で開けてください）

シリアルNOの初期値化と欠番

いろんな局面でシリアルコードが使われていますが
特に入力と明細など親子関係を持つ伝票NOや、病院などの外来で日によって詳細が増えるもの、弁護士さんなら案件Noなどが対象かと思うのですが、コード番号をKeyにしてデータベースを処理される事が多いかと思います。
（顧客マスタや商品マスタなど、日々増えるものでなければデフォルトのオプションで十分）


レコードを増やせば001+１（増分）

はオプションで設定できますが、翌日は001から始めたい
などの場合は自己リレーションと計算式を用いれば可能になります。

これは日付で初期化し、001から始める方法ですが、月によって001にしたり桁を増やして0001にしたりも出来ます。コード番号が整理されて帳票なんかも見やすくなります。

サンプルがダウンロードできますので見ていただければ分かるのですが、

シリアルコードを作るのに、それに関係するフィールドが増えちゃうのが難点でもありますが、覚えて損はないかと思います。デフォルト装備のオプション設定では、001に戻すために都度、管理者権限のデータベースの管理でオプションを変更する、なんて面倒な事したくないですし・・・。

日や月によって001に戻ってくれたり、レコードを全部削除しても、新規レコードで001から始まってくれるのは便利です。

＜欠番＞

しかし、このコード、親子関係にあればKey設定をしますので、レコードを削除した時に欠番をどうするか考えなくてはいけません。

今回は欠番が発生したらそのままにする方法と欠番以降を詰めて連番にさせてしまう方法の2種類をサンプルにしました。

いろんなサイトでシリアルについての注釈が掲載されていますが、僕的には欠番を詰めて連番にさせる方法は好ましくないと考えています。

リレーションで親子関係にあれば、欠番が詰まって連番化されたことで、子の側のデータもズレて（書き換わる）しまうからです。これでは整合性が保てません。ですので、レコードを削除して欠番が発生したときは、そのまま放置をお奨めします。

では、欠番なしとは、どういうケースで使用するか、ですが
伝票などのトランザクション（親子関係）ではなく、呼び出しだけに使用するマスタ等であれば、Noを詰めても良いと考えます。ただし、商品マスタなど後に商品別の分析をするのであれば、危険です。担当者や人事などでも定年や退職などで欠番が出ますが、欠番なしになると欠番以降の関連データが飛んでしまいます。

僕の場合は、欠番なしという手法で開発を手掛けたことはありません。





ダウンロード（FM13以上）

値一覧をポータルにして絞り込む （中分類、小分類）

前回のファイルを利用して
値一覧をポータルで表示させて
絞り込んでいくもの。


値一覧のドロップダウン表示がどうも好きでない方向けです。
ダウンロードできますので中身をみてください。
苦肉ですが、画面はすっきりｗ




中分類を選択すると小分類に

小分類を選択すると商品マスタに

商品マスタを選択すると元の中分類に

前回のファイルに中分類のＴＯ「中分類フロントＰ」を追加してポータルにしました。

１３ならではのオブジェクトを重ねて、スクリプトのフィールド設定で隠してます。




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

第25回 自分で作ろう！ 弁護士向けソフト 請求確認と消込入金、ダイレクト入金

FileMakerで請求・消込入金・ダイレクト入金

あけましておめでとうございます。
引越しやら、出向やらで、手をつけられずにいました。
すみませんでした。

暮れから、年明けにかけて作りこみました。


今回は請求と入金についてですが、入金処理には売上伝票単位で入金処理を行う「消し込み入金」と、普通に入金処理を行う「ダイレクト入金」の２通りがあります。

どちらかひとつという販売管理ソフトも多いのですが、どうせなら一緒にふたつやってしまいましょう！ということです。いいねぇ～

弁護士さん向けというより、通常の販売管理ソフト上の一部として考えて頂ければと思います。
前回同様、デザインは重視していませんので、クラシックなFM１１で作っています。


残念ながら、時間もなかったので請求書発行までは作っていませんが、請求・入金確認画面までは作りました。後は、請求書発行用のテーブルを作り、データを渡して処理するだけなので簡単です。（売上日や入金日を今回の締日に絞って、過去に作った見積もりから売上にデータ移行する要領で飛ばせば良いだけです）


これが通常と違うのは、請求・入金の確認と追跡をしたい、ということです。
通常、集計を使うと、確認するどころのスピードではなくなりますので、集計を使わないという条件で作り上げました。（なので、リレーション図がクモの巣状態に・・）

リレーション図をみると非常に複雑に見えますが、ごくごく単純に作り上げています。
得意先に設定していた締日をふんだんに利用して、テーブルオカレンスを地獄なくらい作り、
変数も関数もスクリプトも特に使わず、リレーションの照合と足し算と引き算で作りました。
せいぜい、sum関数（笑）


また、なんでもかんでも照合によって自動連鎖させるのではなく、コンテキストなどのデータの流れ、自動連鎖と連鎖を止めるという考え方も必要です。何処で繋げて、何処で断ち切ってるのかを考えながら作るには、とても良い課題でした。

どれが、最初に作ったテーブルで、どれがテーブルオカレンスなのか印を付けていませんので混乱するかもしれませんが、これだけは作りこまないと分からないかもしれません。


請求、入金システムの考え方、作り方は、人によって違いますし、考え方も違います。
単純に売上伝票を日付で絞り込んで請求とする考え方、売上決定後に分割払いの要求や延滞利息などを考え、別に請求書としてインポート・エクスポートさせる考え方

印刷してから確認するのか、処理する前に確認・追跡できるようにするのか、数か月前にさかのぼった売上伝票はどう処理するのか、入金忘れの後処理、ダイレクトな入金処理、伝票単位での消し込み処理、POSレジとの連携で現金売上も頻繁に発生する中での売掛・請求処理、更新作業の考え方など、本当に様々です。

今回は、こうすべきだ、という概念を持たせずに、後々拡張しやすい仕様で作ろう！という考え方で作っています。

これは、消込入金の画面です。
伝票単位で入金処理を行う方法で、業種・業態によっては、ダイレクトな入金処理より、こちらを使用するケースもあります。まとめて請求、まとめて入金ではない場合、営業さんが現地で、この伝票分を現金で集金されたり、レジの売掛と連動された場合などは、伝票単位で消込入金を行います。この場合、売上日は１１月締前で、１１月の締後に訪問したとき、たまたま現金で一部の集金ができたというような、過不足がある場合、通常、残りは、まとめてダイレクト入金で処理をします。
どうしても、過不足分も消し込みで処理をする場合は、売掛の後ろに入金日と未入金分というフィールドを置いて処理をすると良いかもしれません。（入金明細までカスタマイズする必要が出てきます）

ポータルの上に

前回請求
前回入金
前回繰越
今回売上
今回入金
今回請求
とあります。

消し込み入金時と、ダイレクト入金、合算された今回請求分が閲覧できます。

リレーションによって、前々回から締日を分けてポータル表示させたもの
確認、追跡される場合、更新作業に関係なく閲覧でき、過去の売上に対して、いつ入金されたか、今回の入金が予定と違う場合、得意先へ電話での問い合わせなど、非常に便利です。
集計を使っていないので、さくさく動きます。

ダイレクト入金画面
伝票単位を気にせず、得意先誰、入金日、ドカーン！と入金という処理です。
細かいところは、画面に注釈を入れています。

FMを使用しない人が嫌になっちゃうリレーション図
でも、僕的には、IBM標準のER図より、こっちのほうが分かりやすかったりします。

どうして、こんなクモの巣状態なのかと申しますと、前々回締日、前回締日、今回、次回というふうに、売上も消込入金もダイレクト入金も、それぞれを分けているからです。
それぞれ、Sum関数で合計を出し、引き算すれば、各締の合計が取れます。
（表示は、単純な範囲指定のポータルフィルタを使用）
このリレーションを使わず、集計やスクリプトを使用して分けると、処理スピードが遅くなり確認どころではなくなるため、このような一見複雑なものにしました。


いわゆる、現場では請求書を発行する前に、売上と入金状況を確認する作業が発生するのですが、印刷された帳票上ではなく、システム上で確認・追跡できるものを作りたかったわけです。


請求は、締単位なので、前回、今回という表示
売掛は、月単位なので、前月、今月という表示です。（売掛は作っていません）
要領は同じですが、売掛残高一覧表は、得意先の締日に関係せずに月締めですので
それこそ、集計とスクリプトを使用してズドンと印刷でよいのではないかと思うのであります。



今回のダウンロード

FileMakerPro１１以上が必要です。
１２、１３は変換してご利用ください。