Hard to say for sure without knowing more about your data and the tables.
You could certainly import all the records from the customer specific table into the other table, using a value in an additional field to distinguish the two types of records, but that may or may not be practical.
It's kind of complicated, but the short story is that we print vitamin labels. Each customer has their own background(s) - we call them "blanks," but some customers choose to customize their product information (unique name, font, placement, etc.) and some choose to use the generic version.
When a specific label gets ordered, the order table pulls the pertinent label information (size, special or generic, which press it runs on, reprint quantity) from the appropriate table (special or generic) and displays it for the pressmen so they can fill the order correctly.
I suppose having two tables is probably the best method, especially since I'm adding versioning functionality, but I was hoping to consolidate the tables to make them easier to manage and to "clean up" the code responsible for pulling all the information...i.e. if I had one table, I could use portals and related fields instead of calculating fields.
At present the labels are ordered by customer number and product number. We're changing, however, to an ordering system based on unique part number - and I'm trying to implement this as well.
However, I'm not sure how to relate records to the generic versions unless I use what was previously printed as a guideline. I'm also not quite sure how to handle new labels that have never been printed before.
Sounds like you could use a consultant who can sit down with you, analyze your business model and then help you revise your design to work better. The fact that you are using a quite elderly version of FileMaker also complicates this.
Just from what you have posted, I don't see any reason why you can't merge the data in your two files into a single file that combines the generic and customer specific data. That would seem to simplify a lot of your issues here.
Relationships, Finds, scripts that use Go To Related records, and summary reports that group records can all be used to manage such a combined table (file in your case) in ways that will be much more difficult to do with your current structure.
Clients---<Labels>----formats (---< means one to many )
Any given label record should have a client ID field to identify the client and a format ID to identify the format used to print that label.