みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
FileMakerを触り始めて3ヶ月めの超初心者です。
いつも、このQ&Aで勉強させていただきながら、販売管理（納品書発行から請求・入金）を作成できないかと奮闘しております。
現在、納品書・請求・入金は一応形になってきたのですが、作業をすすめるにあたり、疑問ができいろいろ調べたのですが回答が見つからず、質問させていただきます。
請求書テーブルには、売上と入金が集約されて構成されています。
当然ですが、売上は売上明細、入金は入金明細で構成されており、長くシステムを運用するとなると、基本になっている明細レベルのレコード数が膨大なものとなっていきます。
一定期間経てば明細のデータそのものは余り意味がなくなり、例えば年次更新などで、2年以上経った明細レベルのデータを削除したいとなった場合、現在作成中の請求書テーブルでは、非保存の計算式で売上や入金を処理しているので不可能です。
請求締めの時点で、計算式とは切り離した請求書データに変換して運用すればよいのかと考えていますが、その考えでよいのか、またどうすれば実現できるのかがわかりません。
また、請求締めで、締め済みのデータを、後で変更できないように保護するとかの処理が必要なのか、もわからない部分です。
お知恵を拝借できればと思います。よろしくお願いいたします。
明細のレコードは徐々に増えていきますが、今の FileMaker でしたら、数百万レコードくらいのレベルでしたら、特に問題ありません。毎日の納品が数十件、明細が10件程度で、数年相当以上です。仕様では、その数百倍可能です。
ですから、ストレージの大きさに気をつければ、気にしなくていいでしょう。
納品明細のデータは、出庫データですね。そこに入庫データを絡ませると、在庫管理にもなります。
顧客管理としてみると、納品明細を顧客毎、商品毎に集計すると、顧客サービスに直結するデータになり、長期間のデータを持てば有利になります。
締め後のデータの保護については、アクセス権で制限は可能です。実務運用の考え方次第です。
Last edited by Shin (2019-08-13 13:40:56)
Offline
Shin様 ご回答ありがとございます。
そうなのですね。データ量については安心しました。
このまま進めたいと思います。
日配食品の加工をしており、仕入れ商品がないため在庫管理は考えておりませんが、顧客サービスの面で長期間のデータは確かに貴重です。
締めの処理については、ドロップダウンカレンダーのおかげで、手入力のように1年前の日付を入れてしまうなどのミスは起こらないのかなと感じていますが、少々心配でしたので・・・。
もう少し開発を進めてから考えたいと思います。
ありがとうございました。
締め日を手入力しているのですか。
例えば、n日締め（末日締めの場合は0として）の場合、
Date ( Month ( 納品日 - n ) + 1 ; n ; Year ( 納品日 - n ) )
で締め日が求められ、m日請求（末日請求の場合は0として）の場合、
Date ( Month ( 締日 - m ) + 1 ; m ; Year ( 締日 - m ) )
で求められます。
明細側のデータを集約した形での過去に作ったサンプルです。
https://www.dropbox.com/s/jc45jy8osie1k … 7.zip?dl=0
Last edited by Shin (2019-09-23 23:56:18)
Offline
いえ、締日はご指示のサンプルをもとに作成しました。
現在のシステムは、売上データ入力の際、日付が手入力なものですから。
Pages: 1
[ Generated in 0.005 seconds, 9 queries executed - Memory usage: 508.83 KiB (Peak: 514.69 KiB) ]