If I were you, I'd really take a close look at your two portal tables to see if it might be possible to use one table where you have two and/or to set up a relationship that eliminates the need to loop through your portal rows to find the correct record.
The second thing that jumps out at me is that you have two portals, but your script does not do anything to make sure that the focus is on the correct portal before executing a Go To Portal Row script step. Since there is no way to specify which portal is to be modified by this script step as part of the Go to Portal Row step, you need to make sure that you have the focus on the correct portal first. Giving the portals object names in the name box on the Inspector's position tab enables you to use Go to Object just before go to portal row to make sure that you have the focus on the correct portal.
Okay, for simplicity's sake, I'm not going to tackle merging the tables because I'm still a filemaker newb and I didn't design this system. But I will name the top Portal RA Authorized using the Inspector tool and add the following lines to this script. Is my syntax right?
Go To Object [Object Name: "Ra Authorized"]
Go to Portal Row - Get(RecordNumber)
Why Get ( RecordNumber)?
Your original scirpt uses "first" and "Next"
Get (ReordNumber) returns the record Number of your current layout record , not a portal row number. The record number represents the record's position in your layout's current found set.
You're right, I tried it and that didn't do what I expected. I thought it would go to the record that was last marked as received in the top portal. Doing Go to Portal Row - Last instead mitigates the problem at least a little bit but I'd like the focus to stay on the last line item marked as received, and not jump if the scroll bar is pressed.
Well you've already done this in your original script by using set variable to capture the portal row number. You can capture the activeportalRow number to get the portal row number of the row where you clicked your button to initiate this script. A variable that you increment with each pass through your loop can keep track of the current row in the second portal if that is necessary.
And there's a "by calculation" option you can use with such variables in Go To Portal Row to jump the focus directly to the desired portal row.
You probably want to use that option to return the focus to the row where the button was clicked.
And there is a second way to loop through portal records without interacting with the portal. You can freeze the window and use Go TO Related Records to pull up a found set of the portal's records on a different layout where you can use go to record to loop through the records, delete record to delete portal records, and New Record to add new portal records etc before returning to the original layout.
The resulting script is often "cleaner" and less vulnerable to being "broken" by future layout changes, but also carries the risk of inadvertantly tripping script triggers that might be in place on either layout. This last issue can be, with a bit of forethought handled by using a global variable with an If block to "disable" your trigger performed scripts.