Is this the relationships that you have?
Report::__pkReportID = Revenue::_fkReportID
Report::__pkReportID = Expenses::_fkReportID
If this notation is unfamiliar, see: Common Forum Relationship and Field Notations Explained
Thus, when a change in a revenue record is made that changes how an Expenses record calculates, it's via the same relationships as those for your portal.
if I change a record in the Revenue portal,
Have you tried using a script triggered by the OnObjectSave trigger on this field?
A better option might be to add this relationship to the above:
Expenses-----<ExpRevenue (ExpRevenue is a new occurrence of Revenue)
Expenses::_fkReportID = ExpRevenue::_fkReportID
Then define your calculation to refer to data in ExpRevenue and to evaluate from the context of Expenses.
The relationship is Events::_pkEventID to EventID in both Revenue and Expenses table.
Events::__pkEventID = Revenue::EventID [Indexed only]
Events::__pkEventID = Expenses::EventID [Indexed only]
Which differs only in the field and table names that I used in my example. If you substitute your names for mine, this should work.
Have tried all of the above, to no avail. Expense Amount Summary does not change properly unless I manually Refresh Window.
>Have you tried using a script triggered by the OnObjectSave trigger on this field?
Which field do you mean?
And ... is there any way to Refresh Window on *anything* changing in a layout?
As in duplicate the manual procedure automatically?
You could try ONRecordCommit as a layout based script trigger.
It should not be necessary, however. You might try Refresh with the "flush cached join results" to see if that makes a difference, but that's an option that can create it's own problems with long delays while the layout refereshes and thus is best avoided. It may be useful data here as a test though to see if it is the wrong trigger or the wrong script steps that is keeping the scripted update from working.
Did you try the relationship change? That method "cuts out the middleman" and thus the "tunneling" that can create refresh issues by linking the related data directly.
You might also experiment with using the Sum (RelatedTable::RelatedField) function in place of referring to the summary field from the related table.
I have it working, but knowing better and forging ahead anyway, don't know which step did it.
Will have to re-trace everything bit by bit.
Got rid of all the script triggers and simply put Expenses "downstream" from Revenue in the relationship graph, thinking that if Revenue feeds Expenses, then the variables will be properly accounted for. It definitely calcs properly, so believe it's the correct solution.
Uncertain why another table occurrence of Revenue did not do the same thing, but the following certainly works ...
Events::__pkEventID = Revenue::EventID = Expenses::EventID
There are other tables related to Revenue and Expenses, but are further down the line and do not appear to be affected in any way.
Uncertain why another table occurrence of Revenue did not do the same thing,
I can't tell for sure from here, but I'd guess that you added a new table occurrence but still referred to the existing occurrence. Adding a new occurrence of the table "down stream"--which is what I had in mind, should work, but your data references have to be to fields from the newly added occurrence.