みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
環境：Win10, FM Pro Advanced 12
・見積No採番ルール：YYYYMMDD & ”E" & Serial No
・テーブル：「見積メイン」
・見積No 設定
フィールド１：「見積日」タイプ：日付、作成日
フィールド２：「見積Serial No」タイプ：数字、シリアル番号
フィールド３：「見積No」タイプ：テキスト、計算値自動入力、既存値の置換、値変更不可、空欄不可
Case ( 見積日 ; Year ( 見積日 ) & Month ( 見積日 ) & Day ( 見積日 ) & "E" & 見積siriarl NO ; 見積日 = "" ; GetAsText ( 見積No ))
１．新規作成時の見積Noは設定通りに表示されます。（例：2020630E001)
２．作成済の見積を修正するとき、同じ番号の「2020630E001」と保存されるようにしたいのですが、
「001」と保存されてしまいます。（”2020630E”がオミットされてしまう）
基本中の基本のことかもしれませんが、なにぶん触り始めたばかりの初心者です。
対処法ご存じの方いらっしゃいましたら、知見をお貸しいただけないでしょうか。
よろしくお願いいたします。
作成済の見積を修正するとき、は、どんな動作をしていますか。元となるレコードを複製しているのですか。
また、上のフィールド定義では、見積日が空白になる事は、あえて消去しない限りは無いので、そこの分岐は無意味なのでは。
もうひとつ、Year ( 見積日 ) & Month ( 見積日 ) & Day ( 見積日 ) では、1月11日と11月1日はおなじテキストを返します。
Offline
作成済の見積を修正するとき、は、どんな動作をしていますか。元となるレコードを複製しているのですか。
また、上のフィールド定義では、見積日が空白になる事は、あえて消去しない限りは無いので、そこの分岐は無意味なのでは。もうひとつ、Year ( 見積日 ) & Month ( 見積日 ) & Day ( 見積日 ) では、1月11日と11月1日はおなじテキストを返します。
１．見積修正するときの動作
検索モードで元となるレコードを呼び出して、そのまま修正できて上書き保存できたらいいなと考えています。
これは、可能なものでしょうか。
２．見積日の空白
検索モードで、見積日：空欄、見積Noのみで検索したときを考えて、分岐させたほうが良いかと考えました。
３．ご指摘の通りでして、Month ( 見積日 )は1～9月までは、頭に”0”を入れたいなと考えています。
レコードを検索して、そのまま上書き修正はできますよ。ですが、その動作で見積もり番号が変更される事はないはずです。
ただ、元のデータは上書きされて残りません。修正する際には、レコードを複製して、複製側を修正する運用が多いです。その際には見積もり番号も更新されるのが普通です。
上の定義ですと、見積日には常に作成日が設定されますので、あえて消去しない限りは空白はないはずです。
Year ( 見積日 ) * 10000 + Month ( 見積日 ) * 100 + Day ( 見積日 ) & "E" でいいでしょう。
Last edited by Shin (2020-06-30 16:04:19)
Offline
レコードを検索して、そのまま上書き修正はできますよ。ですが、その動作で見積もり番号が変更される事はないはずです。
ただ、元のデータは上書きされて残りません。修正する際には、レコードを複製して、複製側を修正する運用が多いです。その際には見積もり番号も更新されるのが普通です。上の定義ですと、見積日には常に作成日が設定されますので、あえて消去しない限りは空白はないはずです。
Year ( 見積日 ) * 10000 + Month ( 見積日 ) * 100 + Day ( 見積日 ) & "E" でいいでしょう。
Shinさん
丁寧なご対応、ありがとうございます。
無事に解決しました。
実は、修正するときの見積Noを継承するか、もしくは更新するかは、ちょっと迷っておりました。
継承する場合は、バージョンNoを付与したほうが修正履歴が追えて管理しやすそうです。
更新する方もシンプルで良いと思ったのですが、不要になったデータが増える（修正前の見積）のがどうなのだろうかと思案していました。
もし宜しければ、見解をお聞かせいただけないでしょうか。
書かれている情報が少ないのでなんとも言えませんが、
（他のファイルとの連動や、「見積」→「受注」の際の動きなど。）
「発行済みフラグ」のようなものがあって、印刷なり、ＰＤＦなりに既にした（先方に提出した）
見積は触れないようになっているような構造なら、トラブルになりにくいとは思いますが、
個人的意見を言わせていただくとShinさんの言うように複製して運用が一般的と思います。
「作成済の見積」というのが、外部に提示したものなのか社内的な部分なのかわかりませんが、
一度外部に提出している見積の内容をコロコロ変更出来るような運用ではないですよね？
２．作成済の見積を修正するとき、同じ番号の「2020630E001」と保存されるようにしたいのですが、
とありますが、これだと既に先方に提出済みなら、同じ見積Noの見積書が２つ渡ることになってしまいますし。
そもそも6月30日に作成したものと7月10日に修正したものも同じ番号にするなら、
番号に日付を入れる必要性自体がない気がします。（通番で充分では？）
あと、上書き更新しながらデータ抑制を考えるよりも、
意図せず内容を変更してしまうデメリットを考えて作成したほうがよいと思います。
私なら、見積りを管理する番号は、何も考えないで全体のシリアルにします。もし、取引先が望むのでしたら、案件番号に枝番をつけます。
また、レコードそのものは、印刷時点か翌日でロックをかけます。それ以降の修正は、複製したものに対してのみ可能にします。
Offline
＞むむむ さん、Shinさん
書き込み、ありがとうございます。
説明が足りず、すみません。
販売管理システムを作ろうとしています。
見積 → 受注処理（注文請書の発行と受注入力） → 売上 → 請求 → 入金確認
↘ 仕入発注 → 入出庫処理 ↗ ↘ 支払 → 出金 まで
一気通貫で案件管理できるようしたいのです。
見積データは、上席者が確認し承認フラグを立てたものだけOutputできる設計で、かつ受注確定した段階でフラグを立てて、ロックする設計を考えています。
管理番号は、単純に連番でも良いとは思ったのですが、
一番大事な入金確認：消込時に、”いつ”売上げた”どの”案件なのかわかりやすい（＝トレースし易い、入金漏れも把握しやすい）管理番号にしようと思い、
日付＋業務ステップ（アルファベット1文字）＋シリアルナンバーを考えました。
ちょっと複雑に考えすぎていますかね。
同じ見積Noの見積書が2通提出された場合ですが、見積日が最新のものが最新版という扱いを考えています。
お二方それぞれのお考えを伺い、大変参考になります。
ありがとうございます。
なにぶん初心者ですので、また壁にぶち当たったらお知恵拝借願うことあるかもしれません。
その際は、どうぞよろしくお願いいたします。
そのような複雑な伝票番号を使うのは、紙運用を行っている時でしょう。
電子運用を主体にするのでしたら、各伝票にはUUIDのような全てのレコードで一意になるようなコードを使うこともあります。伝票にはそれを読み取るバーコード（桁が多いのでQRコードがお勧め）を印刷しておきます。システム側ではそれを読み取れば、その一連の伝票を呼び出すことは容易です。
その中間的な運用としては、1販売ごとにコードを与え、その中で全ての伝票に作成順で通し番号を与える、という方法でもいいと思います。ただ、複数伝票が発生するのは見積もりの段階だけでしょうから、そこだけを考えてもいいのでは。
Offline
「解決」なので最後に。
まぁこの辺りは制作者の好みで変わってきますしね。
Shinさんの提案のようなQRコード等で呼び出しての入力なら長い管理番号でもいいと思いますが、
手入力者がいるなら、あまり長い番号だと受注以降の入力（仕入・売上等）や検索の際に面倒がられますよ 笑
あと業務ステップのアルファベットも別で管理したほうがいい気がします。
たとえばこの先８０年、そのシステムを使う予定でないなら、最初の西暦の部分は下二桁でいいような。
見積作成ペースがわからないですが、月に１万件いかないなら、
「西暦下二桁＋月＋シリアル四桁」の八桁番号くらいの方が入力作業者的には楽なのではと思いますがお好みで。
＞Shin さん、むむむ さん
お二方共「解決済」ではありましたが、ありがとうございます。
「知らないこと」に気づけましたし、良い刺激をくださり勉強になります。
1.電子運用を主体にするのでしたら、各伝票にはUUIDのような全てのレコードで一意になるようなコードを使うこともあります。～
2.複数伝票が発生するのは見積もりの段階だけでしょうから、そこだけを考えてもいいのでは。
1. なるほど、そういう方法もあるんですね！ 調べてみます。
2. 失礼ながら具体例が思い浮かばないのですが、レアケースもあるでしょうし、考えてみようと思います。
業務ステップのアルファベットも別で管理
ご指摘の「入力が面倒」なのは、確かにその通りですよね。桁数も考えてみようと思います。
引用の「別で管理」する部分が、どのような考え方なのか気になりました。自分なりに考えてみたいと思います。
業務ステップのアルファベット1文字は
売上が終ったら →Ｕ
請求が終ったら →Ｓ
入金確認が終ったら →Ｎ
と変化していくものと勝手に解釈したんですが･･･。
変化しないならここまで読んでスルーしてくださって結構です。
変化する定義での話なら、
管理番号はどの部署からしても同じ番号の方がいいのでは？
「業務ステップ」というフィールドを
売上が終ったら →Ｕにフィールド設定
請求処理するときは「業務ステップ」がＵのものを検索
請求したら →Ｓにフィールド設定・・・
「管理番号の内」でどのステップまで進んでるかを把握しなくても、
「管理番号」＆「業務ステップ」で管理したほうがいいと思います。
どの段階まで進んでいるのかパッと見で簡単に把握したいのなら、
条件付き書式で「業務ステップ」を基礎に
色分けでもしてあげてもいいですし、
レイアウト上に「管理番号」＆「業務ステップ」の
表示用フィールドを作ってあげてもいいですし、
関数を使って"U”なら"売上済", "S”なら"請求済",・・・
と表示をしてあげてもいいですし。
管理番号内に変化する部分があるのなら、
あまり一気通貫の「管理番号」としての意味をなさない気がします。
（後工程の人が前工程の人に確認を求めたときに、
後工程の人と前工程の人では番号が違いますよね？
まぁアルファベット一文字なんで大した問題でもないかもですが、
それならそもそも要らない。）
あと、他のファイルとのリレーションはどうするか。
「仕入ファイル」「発注ファイル」を分けるなら、
その案件との連動は、変わってしまう管理番号でするんですか？
それ用にフィールドを作るなら、最初から数字だけの「管理番号」
フィールドで結んだ方が早いです。
あくまで個人的意見ですので、
ご参考程度にでもなれば幸いです。
Pages: 1
[ Generated in 0.010 seconds, 7 queries executed - Memory usage: 557.07 KiB (Peak: 577.62 KiB) ]