You received great guidance from @bdbd and @Malcolm (as usual), but I'll offer a bit about how I do this. This "location history" is something that I do in most of my solutions (due to the primary space in which I tend to specialize).
Typically, I have an "Inventory" table which contains the records of inventory items, or library items, or technical lab submissions, etc. I also have a "LocationHistory" table which is related to the "Inventory" table via "LocationHistory::InventoryUUID_fk". This field in the history table is populated at the time of processing a transaction concerning the item in question (book, inventory item, specimen, etc.). The process script handles the LocationHistory transaction when an item is transferred to a new location, technician, sold, returned, etc.
In my solutions, part of the Process Transfer script, or Process Sale script, etc. store $variables for each pertinent field in the LocationHistory table: $iventoryUUID_fk, $transactionType, (and a bunch of security stuff). If there are multiple items to be processed, the $variables which pertain to all equally are set, and then we loop through the line items of the event or transaction to build the appropriate arrays for the history records.
Finally, as we process the transaction(s) we simply open a window to the history table (a blank layout, off screen) and request a new record for each line item. The LocationHistory table is made up of entirely Auto-entered fields for which the $variableName is simply the auto-entry value (plus a few calculation fields sometimes for certain data types). So... Loop > set the $variables which are unique to each line item > new record request... etc. No set field steps are used, just set the $variables for auto-entry to each new record.
Back on the Inventory or Library or Specimen layout there's a portal displaying the LocationHIstory records associated with each inventory record. I typically display it on a Slide Control if space is an issue (often is in my apps). On each portal row there are various merge fields displaying transaction type, date, time, user name, client name, etc. The portal displays the transactions with newest at the top in our cases.
In our solutions users want to see all the history, so the last several rows are displayed and can otherwise be scrolled. @Malcolm mentioned how to display only the current state using a single-row portal.
Hope this is of some help.