There is no need to export and then import. You can just import from one table to another Whether tables are in the same file or not.
But the best option is not to put this data in a separate table at all. Just use a field in the record to show whether an item is sold.
My superior wants to keep all sold items separate, a "cold archive" as he would call it. He doesn't want the sold mixed in with the active inventory. As it stands we do have a field that lets us know an item is sold, which turns the serial number red etc. so our employees know that item is no longer active.
I'd prefer to leave it as it is- but he insists this is "cleaner".
So I can use a simple import script for these?
As I answered before, yes. It's just that your scripts are needlessly complex.
And unless your boss is a developer and snoops under the hood to see how you did it. You can design the interface and relationships used such that even though the records are all in one table, Sold and unsold items don't appear at the same time on any given layout. Whether that's a good idea in terms of having a good working relationship with your boss is a decision that you have to make.
All your scripts really need do is:
Isolate the record in a found set of that one record--that's what the find does in the scripts that you found, but a single find matching records step that specifies the record's primary key is a one step way to do the same thing.
Import records from Table A to Table B.
Delete the record from Table A
If the two tables are not in the same table, you'd need to add an external data source reference to the second file and an occurrence of Table B that refers to table B of that file to your relationships graph. But the script would look and work exactly the same once you've done that.