Hi Platinum Digital,
Showing your UI in browse mode doesn't help us understand which fields are set up under which table; regardless, it is too small for me to read, sorry. Here are some thoughts to help you decide:
If you have a Company which purchases from you and a Company which sells to you, they are both companies and should belong in the same table with a field Type to designate 'seller' or 'customer'. If all companies only have one employee (contact), the employee can be in the company table but that is rarely the case.
One company can have multiple contacts so these contacts are the many side to the one company, known as 1:n. This means that contacts should have their own table and also have a field called CompanyID which holds the unique ID from the Company table. If one contact can have multiple phone numbers then you need a Numbers table with a Type field to specify whether the number is: Home, Office, Beach House, Warehouse, Garage, Fax Number etc.
If you ever find yourself creating multiple fields which contain similar information, stop yourself short. An example, when we see this in someone's file, we know it is wrong:
If you wish to upload your file somewhere, we would be happy to review it and make suggestions. If you wish to message us privately, we can review the file in private but it is preferred to keep the discussions on this forum, if possible so others reading this thread can know how it was solved. If you can not upload your file (you can clone it without records), then I suggest you post a screen shot of your relational graph. :-)
While developers can readily argue both sides of the issue as to whether or not tables should or not be defined in a single file, most new users will find that putting them all in one file makes developing and managing the database simpler to do as it avoids a number of issues with multiple file solutions.
Once you get things working to your satisfaction, it's not terribly difficult to transition your database into a Convert to Seperation Model to make deploying updates to your file easier to manage.
The term databases does not apply to FileMaker. FileMaker has files which can have multiple tables within it. Some consider tables to be databases which would be more accurate.
"thought that with a recommendation from some people that I may be better off having them all in the one file under different layouts. "
Whether using one file or many, ALL data can be viewed and handled within one file on various layouts. I see the question more about how to split up the data into various tables within the file. I think we need further clarification on what is being asked.