Having "multiple product tables" sounds like a recipe for major confusion. If you can possibly merge the data from your different tables into a single table, your database design will be much simpler and thus easier to work with.
You can't set up a "switchable portal" that selects different tables as its source of records.
You can create identical layouts where the portal specifies a different table in each copy. By setting up a button that selects a product table by switching layouts. This will create the illusion of having a "switchable portal". Can't say that this will meet your needs nor does it sound like good database design though.
One product table it is then, I guess by what you have said that you must somehow sort the data in the products table to what one is looking for before you pick at the portal, (by manufacturer and or Range and or product type) especially with a products table with over thousands of products in it.
I am just trying to figure out the best way to choose items to put into the invoice portal without going through 1,000's of items
is there a best practice way for this procedure ?.
You might want to set up a filtered portal. There are numerous examples in this forum if you search under those terms.
In short, you can include an extra pair of fields in your portal's relationship like this:
Parent::Manufacturer = PortalTable::Manufacturer AND
//Include whatever fields you are currently using for your portal.
Give Parent::Manufacturer a drop down value list of manufacturers and you can limit the portal rows to just those entries matching the value you choose from the drop down.