You can do that, but you'll need to rewrite the portal filter expression as:
Global::StartDate > register::Transdate AND register::Transdate > Global::EndDate
If these two global date fields are fields you can edit on the same layout as your portal, write this script:
Refresh Window [Flush cached Join results]
and use a script trigger on these two fields to perform this script to force the portal to use the new value(s) to update the list of records in the portal.
Figured a simple report like this would work for this user as the solution isn't too complex and this would make the report pretty versitile if I give him a pull down to select the vendor and popup calendars to select the dates, with the refresh script set to "on modify" for the 3 globals.
Just had a thought, it would work better if it was not a porta but a list view and I put the globals in the header and the total in the footer. That way it would show all of them without having a large blank space at the bottom of the portal if there are too few transactions or having to scroll the portal if there are too many.
Then I would need to use a find script rather than the portal filter, right?
Yep. And be careful, you may find the global fields in the header are "glitchy".
For More Information see: Sometimes global field in header become disabled
This is one of many acknowledged bugs that can be found in the Known Bug List here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
One work around is to use a button that pops up a dialog or small floating window for the user to enter the needed date range, etc instead of placing the fields in the header.