「ポータルレコードのソート」指定による レコードのオープン状態 : 3 にご注意

Helpにも載っていない レコードのオープン状態 : 3 が存在するようです。

このレコードは見えていないだけで完全削除になっていません。
そのため例えば、伝票と明細というポータル表示をするレイアウトで、
伝票テーブルに計算フィールドで Sum(明細::金額)やCount(明細::ID)などがあった場合、明細行を「ポータル行を削除」で消しても、計算値に含まれたままになってしまいます。この時の見えていないレコードが レコードのオープン状態 : 3  です。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-26-20-14-30

では、レコードのオープン状態 : 3 のポータル行だけ計算対象から外せば解決かといえばそれでもダメなケースがあります。
ポータル親のレコードである伝票レコードが新規作成ホヤホヤの レコードのオープン状態:1 の時に、明細行を作成して確定前に削除すると、表示からは消えているが完全削除になっておらず、レコードのオープン状態 が今度は 3 ではなく 0 となっていて、やはりリレーション計算に含まれたままになります。

レアケースかというとそうでもなく、
レイアウト設定で「レコードの変更を自動的に保存する : チェック外す」のレイアウトや、OnRecordCommitで制御するレイアウトでは、計算フィールドのSumの結果と、実際に見えている明細の和が違う!という事象が発生するので、この症状はやっかいです。

解決法の一つはポータルのソート条件はやめる。必要なソートはリレーションのソート条件に変えれば解決でした。

レコードが確定されてしまえば上記の計算結果のズレは解消されますので、
そこまで大きな問題でもないかと思われます。
またver12からv15まで同様の動きのようなので、仕様と納得するしかないのかもしれません。

FMPA 15.0.1.119
Mac OSX 10.11.5

( ちなみに、それでもこれは見た目までの解決です。
レコード確定前に、伝票テーブルにある計算フィールド Sum( 明細::金額 )を「スクリプトで取得した値」と、実際に「見えている計算フィールドの値」が異なるという問題解決は、さらに計算式を工夫する必要があります。 )