Have you tried adding some sample data to see what it looks like, sometimes easier to picture it?

Hi Alex.  I have not yet.  I feel like I"m missing a connection between the three tables on the left and the rest on the right.  I"m not even sure if I have them related correctly.  Thank you for your prompt reply.

I will start by giving my tables more descriptive names:
For example, an order table if it is an order you are placing with your supplier, I will name it purchase order table.

What about orders you receive from your customers? Do you keep track of that?
The shipping table - does that contain trailers shipped to you or does it contain trailers that you ship to your customers? You can do both in the same table, but you need to identify that in the table itself.
Do employees place purchase orders? If so, you need that information stored on the purchase order as well.

Alex gave you very good advice.

More importantly than defining all these relationships at this point is to have these relationships defined in the forms that will run your business.

Even map it out in excel or even on index cards
Move them about on your desk, attach string to them to show the physical relationships. Get it sorted in your head first then apply it via Access.

I'll try responding to both in one reply.  Sami, I like your table suggestion on "Purchase Orders."  So, the business owner is the one who places all orders on a set of trailers.  Based on the trailers needed, there are various suppliers we order from.  One order of trailers can contain five different types of trailers from a particular supplier.  We'll received that order from a shipper who charges us freight.  At that point, the trailers will sit on our lot waiting to be purchased by a customer or company.  One customer/company can purchase more than one trailer at a time.  One employee will make that sale.  In short, we have various "Suppliers."  We'll "Order" a set of trailers to be "Shipped" to us.  Now we have "Inventory."  Of those five trailers, we could have five different customers.  Each customer will be assigned to one employee who will make that sale.  Alex, thank you for your suggestion.  I've done this several times (on paper and in my head), then mapped it out in Access.  Should I relate all the tables by connecting PK's & FK's.  I've done that already on some of the illustrated tables above.

John

I would break the system into modules so I can deal with it more easily.

The first module would be the Purchase Order Process, which would require your suppliers' inventory (trailers) and shipping information.

The second module would be inventory. All the information regarding inventory (on-hand types, quantities, suppliers, costs, selling prices, etc.)

The third module would be sales. For that, you need your customers, your inventory, and your salespeople. You will also need invoice header and invoice detail tables.

I will start there.

Thank you Sami!  "Modules" meaning the layout of things (i.e. Tables)?  Sorry, but I'm a beginner/intermiate user of Access, so I'll do my best to understand Access terminology as we go.  The spread of tables I attached above would be what I think I need at the moment.  The "OrderT" could be renamed to your suggestion Sami (PurchaseOrderT) w/those fields in place.  It does make sense to connect that table along w/inventory & shipping since it has everything to do w/that particular order of trailers.  On the inventory table (Module?), the fields u mentioned make good sense (i.e.  Types, quantities, supplier, unit cost, selling prices, etc.). As u've suggested w/the sales module, that could definitely b related to:  Customers, Salespeople, and Inventory(?).  This database will only b used for internal purposes and I don't intend to handout invoices from here yet.  Am I on the same page w/u Sami?  🙏🏽. Thank u so much for ur time and thought process.

Module is just a word that indicates part of your System. It has no additional significance.

So let's take the first part (module).
What I was trying to say to you is to think of each part as a process.  What is the process of creating a purchase order? What information do you need on the form? Which tables contain the information you need to see on the form and potentially print on a report?

In this part, you are missing a table which is the purchase order detail. You said you can purchase multiple trailers from one supplier, each at a different price and quantity. Where are you going to store that information in the purchase order? They don't belong there, they belong in the purchase order detail table.

Look at this video to see what I am talking about with OrderT and OrderDetailT
Invoicing

Ok, let me start w/the acutal order.  I'm not needing to create a Purchase Order Form because the trailers r being ordered online.  I do need a table though so I can input the information from the online order invoice.  This would give me the ability to track any given order.  I would create an Orders table (or PurchaseOrder table) consisting of:  OrderDate, Manufacturer or Supplier, InvoiceNumber, *LineItem field(?), Quantity, UnitCost, & TotalCost.  The line item field from the online invoice would give me the specs on each trailer from that particular manufacturer/supplier.  Each trailer arrives w/their respective title, invoice copy, and shipping info.  I believe this would take us into the next module(s):  Shipping & Inventory.  I hope this makes sense Sami.

*LineItem field(?), should go into the (new) PurchaseOrderDetailT

Ok.  So now we have a PurchaseOrderT and a PurchaseOrderDetailT.  My next modules could b:  Shipping, Inventory, Sales, Customers, and Employees correct?

Correct.
at this point, send me the design of the purchase order tables, and I will be happy to check them out for you.

Ok great!  I'll work on those soon and I'm hoping to upload them on here?  Thank u very much Sami!

What do u think Sami?  I ended up adding a Products table as well.  I haven't decided on what to name that table just yet.

This is Looking great.
ProductT is a better name.

Avoid using the plural. Product not Products OrderDetail not OrderDetails.  you will thank me later.

Hello John,

   I just wanted to understand in your orig screenshot, that the left 3 tables related to orders coming in and the right 5 relate to your sales?
   As coming from the accounting world and used to using SAP in large business, I fully agree w/ generating PO's; honestly even for online orders for ease of accounting traceability later.  If you have a PO, then you have a central document linking the purchase (just as a Sales Order does on sales end) w/ vendor, invoice, freight carrier/cost, receipt date of trailers, etc.

   Going back to Access, I feel the trailer (especially since a unique item), is the table central between purchase/sales sides of your business, thus perhaps have PO#/Sales Ord # as fields in TrailerT w/ 1-to-1 relationships to PurchaseT & SalesT tables, then those tables having links to vendors/customers/etc.

Hope that helps with your thoughts on how to lay it all out along with the other great suggestions.

Thank u Sami and Bryan.  Bryan, the 1 to 1 realtaionships sounds like a viable option.  Perhaps this is where I'm going wrong.  All of my connections are one-to-many.  My knowledge in this area is lacking, but it might be what I need to do.

Not a problem, John, that's why we're all here!
   To me, the key is to thing of any field whose value shows up in another table, is it truly unique or not, though keep in mind that PO/invoice/etc could show up more than once in a table if those documents have more than 1 line item (thus you may need Line Item # fields for some document types), but something like Trailer ID/VIN, that isn't going to show up more than once ever.
   Not to muddy waters possibly inhabited by gators, but in the PO and Line Item example, what I have done is set TWO relational "1 to" lines out of the table's PO # and LI # fields, since doing two fields of relationships then makes it a unique identifier.
   When I started learning Access design back in '02, it was a heck of a learning curve, but very rewarding as you get it to do what you want and learn new strategies.