みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
受注書-受注明細行 という1対多のリレーションを持った通常の会社で使われるような受注書を作っているのですが
Filemakerで作る受注書で、受注そのものがキャンセルになった場合の
一般的な処理方法というのはあるでしょうか？
受注書に「キャンセル」のフラグを立てて
受注明細行の「商品個数」の値をマイナスにする
ということまではイメージできるのですが・・・
レコードそのものを削除しないのなら、明細テーブルに関連レコード(のみ)移動して
個数フィールドを-個数で全置換したらいいのでは。
Offline
どのような受注形態かわからないので一概にいえませんが、
マイナスにしたものだけ残していたら集計を行う際に影響が出ませんか？
Offline
あああ説明が不足していました。
これではMozさんの言われるようにおかしくなります。
ただしくは、元の受注書を明細行ごと複製して数量をすべてマイナスにする という処理をします。
やりかたは旅人さんの書かれたようにする予定ですが、個人的に全置換に恐怖心があるのでloop処理の予定ですが・・・
レコード自体は削除しないため、会計処理と同じような赤伝という扱いでいいのかな・・？と思いまして。
>個人的に全置換に恐怖心がある
どんな恐怖なのでしょう。Loopよりずっと簡単ですけど。
Offline
元伝票にキャンセルフラグを立てると、その伝票の数字を書き換える事になるので、在庫管理の問題が出る可能性が出るかも。（キャンセルが月またぎになったりすると、月末在庫が変わってしまいます）
普通に言う赤伝を作る様な運用が良いのでは。
元の伝票をコピーして、元の明細へ関連レコードへ移動して、レコードを複製し、リレーションキーを変更、数量をマイナスにする、という事でしょうが。レコードを複製する時に１レコードずつしていく事が多いので、その時に設定し直せば良いと思います。
Offline
あまり思い出したくはないのですが
レコードの絞り込みが意図したように動作せず
全レコードの全置換がおこなわれてしまったということがありました。
また、誰かが編集中で全置換がおこなわれなかったレコードも発生します。
loopでしたらエラーの捕捉や条件式での中止がやりやすいのですが。
Shinさんのおっしゃるような方法がベストでしょうか・・・
赤伝方式で作りこんで見ようと思います。
在庫管理のことに触れておられるのでちょっとだけお聞きしたいのですが
在庫管理は増減1回を1レコードとして作成するのが一般的でしょうか？
その場合、たとえば仕入れ伝票1明細行、受注伝票1明細行ごとに在庫増減テーブルを新たに1レコード作るのか、
商品マスタ側からリレーション先の各伝票を見て計算式で今の在庫を求めるのか・・・
全置換やインポート等は、可能な限りスクリプト内では使わない方が良いと思いますよ。他のファイルを参照する時にも、インポートは使わないに超したことはありません。
在庫管理ですが、紙伝票（電子フォームの形でも）が全く不要でしたら、別の形も有るでしょうが、それは運用上必要でしょうね。その中の運用のみを電子化させる様にしましょう。
1イベント毎に１レコード、という運用が良いと思います。また、伝票内の明細1行毎に１レコードの作成が普通でしょうね。
Offline
全置換やインポート等は、可能な限りスクリプト内では使わない方が良いと思いますよ。
使わないほうがいい理由はどんなものがあるでしょうか？
きっちりと例外処理をしてあれば、むしろユーザーの好きにさせない意味でもスクリプトで固定してしまったほうが安全な気はしますが・・・
在庫管理ですが、紙伝票（電子フォームの形でも）が全く不要でしたら、別の形も有るでしょうが、それは運用上必要でしょうね。その中の運用のみを電子化させる様にしましょう。
1イベント毎に１レコード、という運用が良いと思います。また、伝票内の明細1行毎に１レコードの作成が普通でしょうね。
すみません、ちょっと理解が出来なかったので確認したいのですが・・・
「紙媒体で在庫の入出庫の一覧を出す必要がなければ他のやり方があるが、それはレアケースなので他のやり方は通常は考えなくていい」
「在庫が減る処理・在庫が増える処理・棚卸し等の処理など明細行1件につき在庫管理用のレコードを1つ作成する」
ということでいいのでしょうか？
そうであれば、在庫管理用のレコードとして下記のようなフィールドを考えています。
過不足あるでしょうか？
・在庫管理レコードのID
・商品のID
・増減数 （リレーションしてSumしたいので+でも-でも同一のフィールドのほうが良さそうなきがします）
・増減の理由（ex.仕入/受注/棚卸し/返品）
・担当者
・日付
業務で共有して使っている事を前提にしますが。
全置換は、その対象レコードが別のクライアントが開いていると、エラーになります。そのエラーになった事は解るのですが、どれでエラーになっているのかがわかりません。ですから、これを回避する為には、エラーが出なくなるまで繰り返す必要があります。（そのクライアントがレコードをアクティブにしたままで離籍したら...）
また、同じ動作を他のユーザーが行なっていた場合に、動作上の不具合が起こる事もあり得ます。
全置換がどうしても必要な操作，例えば、あるレコードをまとめて、別のテーブルと関連づける為に、キーを設定、という動作は、しないと仕方無いでしょう。
インポートについては、例えば、他のシステムからのデータを読み込む、という動作は必要な動作でしょうね。
FM内の動作、例えば、納品テーブルの明細から請求テーブルの明細へインポートでデータを送る、という作り方をよく見ますが、同じ内容のレコードを増やして行く必要があるのか、を考えるといかがな物でしょうね。
紙伝票の件は、現在よく使われている紙伝票の様なフォームを使わないで、品物の管理側から考えられているシステム、通販業界で使われ始めている様ですが、でしたら、その様なフォームは不要になります。ですが、一般的には、取引先のタイトル、その下に明細、という伝票の形が無いと、業務上動けないと思います、という意味です。
明細は、１つの動きに対して、1レコードを作って行き、それを後でまとめて集計、という形にすると、その伝票との整合性が良くなり、さらに、先進的なシステムへ発展させやすいです。
Offline
在庫伝票のフィールドですが、私でしたらもっと多くなっていきます。
まず、受注、納品、棚卸の各伝票とのリレーションキー用のフィールドがそれぞれ必要でしょう。そのフィールドへの値の入力が、伝票の種別（増減の理由）になります。
数量については、入数と出数を別のフィールドにしておきます。伝票上でマイナスの入力は不自然ですので。
その上で、入数 - 出数 という計算式を持たせたフィールドを用意しますが、それが増減数になります。
担当者、日付は、伝票側からの参照か、ルックアップで取得する様にします。
Offline
Pages: 1
[ Generated in 0.008 seconds, 10 queries executed - Memory usage: 545.94 KiB (Peak: 566.48 KiB) ]