After a few minutes and a quick look, here's where I see issues just from a "mechanical" point of view (i.e. based on what I see with no definitive idea as to whether or not it will even support the business):
dealership info - name,address and such; OK. What they sell, no; that's another table.
contact info - first, last names; don't combine anything that can be combined in a query or form. No to dealershipname in that table; you get that by linking to the dealer table by ID. Otherwise, you're repeating information unnecessarily. That is all about the relationship part of design.
MInput - seems you linked productID to ContactID - makes no sense, and if they are autonumbers, definitely a no-no. No spaces in names (as you will/have read in the links I provided). As a rule, don't store calculations or concatenations. If Gross and PenetrationPercent (goals/product) are calculated, then don't unless you have a specific valid reason to do so. If data changes, the calculations must be managed, and there's no need to store in a table what a query or form can calculate with the most up to date data.
ReportingMonth will probably make a poor field to join on, unless it's text type and not date/time type. It seems unusual to me, but I don't have a clear understanding of what this db is supposed to support.
Why ID and GoalID in goals/product?
FullName in dataEntry is (again) a) repetitive and b) calculated/concatenated.
That should be enough to (hopefully) induce a pause in your project. Sorry if that all seems cruel - not intended to be. Primary intent is to prevent problems, not solve them.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.