みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
請求書テーブルと売上テーブルがあります
請求書を作成するときには、
日付と取引先でリレーションして抽出したポータルをつくり、関連レコードへ移動します
(グローバルフィールドとリレーションして、日付を指定しています)
このとき、ポータルで抽出した結果に追加でポータルに入力して、請求書をつくりたいことがあります
その時に期間外の日付を間違って入力していしまうと、ポータルのリレーション条件からはずれてしまうため
レコードがはぶかれて修正できなくなってしまいます
上記の仕組みが根本から間違っているからこうなるのであり、一度売上を入力するレイアウトから入力して
その後で請求書の抽出レイアウトにいく仕組みにするべきなのでしょうか？
FileMakerは様々なシュチュエーションにも幅広く対応出来ます。柔軟すぎるがゆえに時として弊害をもたらしたりします。
フルスタック開発と違い、仕様の変化にも柔軟に変更することも可能なので、構造上問題があるレイアウトがあったとしても、新たなレイアウトと再構築したオカレンス構造で対応が可能になります。（一つのレイアウトにこだわらず、複製などしながらもより良い構造を探していくのも手の一つです。）
FileMakerは対象レコードを絞り込むために様々なアプローチが存在します。
レコードの範囲を返すリレーションシップを構築することにより、割と簡単に希望のレコードを探すことも出来ます。
その時に思いついた最善だったのだから、根本が間違っているとは言えません。むしろそういった経験をすることにより、新たなアプローチ方法が思いついたり、創意工夫が出来るものです。
端からデジタル思考で考える必要はありません。自身の机の上で書類を整理していたとします。目次であったり、日付であったり、照合番号であったり、顧客名であったり、都道府県であったりと何を参照しながら逆引き的に目的のものを探しますか？
アナログ的思考も大事になってくる時があります。根幹となる最も重要なデータの始まりを考え、どの値と照らし合わせていくのか、どのデータと比較して参照していくのか、良く考えていく必要があります。
検索は非常に重要なセクションになります。クイック検索による検索、リレーションによる照合検索、範囲指定による検索、etc、様々な検索アプローチがあり、その時々で変化させる必要があります。
＞売上を入力するレイアウトから入力してその後で請求書の抽出レイアウトにいく仕組み
これは双方向から作成出来るような仕組みも可能です。
オススメする仕組みはあっても、100％こうした方が良いというものは正直存在しません。
「自分は請求書を作る際にこうこうこういう流れにしたいんだ！」っと言うものがあれば、FileMakerの仕様から大きく外れない限り、恐らく実現可能です。
とかく、成功失敗関わらず、臆病になることなく様々な経験をしたほうが良いと思います。
Offline
この場合は難しく考えなくても、関連レコードへ移動するのは印刷のためでしょうから、入力は元のポータル画面でやれば済む話では。
「追加でポータルに入力して、請求書をつくりたい」というのは、単に入力漏れがあったのと同じことでしょう。
「関連レコードへ移動」を新規ウィンドウにすれば、ウィンドウを閉じる（通常は印刷完了、この場合はキャンセル）だけで元の画面に戻ります。
と書いてから気づきましたが、「売上を入力するレイアウト」はまた別にあるんでしょうかね？
そのレイアウトは日付のフィールドに範囲外の日付を入れられなくなっている？
そうでなければどのレイアウトで入力しても結局「期間外の日付を間違って入力して」しまう可能性はありますよね。
売上明細を追加するという事ですか。実際の売上(納品)との相違がでますが。
または、請求単位での値引きなどの処理でしょうか。これでしたら、空の売上伝票を上げて、明細を作るべきでしょう。
日付については、構造的に自動入力できるように作り込むべきでしょう。
ファイル構造がわかりませんが、売上伝票に対して明細を作っていると思いますが、明細レコードは直接触らせずに、伝票テーブルから触らせるようにすると、日付に矛盾は出ません。
Offline
> 一度売上を入力するレイアウトから入力して
これが基本なのでは？
運用が分かりませんが、
日付入力の問題だけなら、
期間外の入力はできないようにすることもできますよね。
Offline
Pages: 1
[ Generated in 0.008 seconds, 10 queries executed - Memory usage: 558.56 KiB (Peak: 565.7 KiB) ]