To be able to say what is the correct data type, one needs to know the business domain, which no one here does. What I can give you are general guidelines.
Dates - always store date-only value as date, never anything else.
Date and time - always use the datetime2 data type, never the old datetime. Make a conscious use of scale, since the default is 7 which is 100 ns. For values captured inside SQL Server with sysdatetime() use datetime2(3). For values from the outside second precision may be enough, that is datetime2(0).
Strings - For strings that are codes use varchar, since they typically are ASCII only. (And it would make sense to always use a binary collation for these for efficiency, but it may not be worth the hassle.) For strings that are names of things, use nvarchar, so that you can handle data in any script of any language. This is an expensive to fix as an afterthought. As for the length, only use MAX when there is a direct requirement. MAX types cost in performance. Determining whether you should have nvarchar(50), nvarchar(100) or whatever can be difficult. You will need to ask for the business rules, but don't expect to always get a good answer.
For numbers that are ids or counts of thing, use an integer data type. For ids you need to have a feeling for whether you need bigint. Selecting int and having to change later when you are close to hit the ceiling will be expensive! Since space equates to time in a large table, there is reason to use smallint and tinyint where applicable.
Note: I see that you have a ProductNumber in your list. This is a kind of data where you need to check the business rules to get the right data type. Just a single sample is not enough. They may be true numbers, but they be formatted or have characters in them. Or leading zeroes.
Non-integer numbers - this is the most difficult. decimal numbers are exact, but if you pick a to narrow precision and scale you may not be able to store data. If you use float, you evade that issue, but then you may get rounding errors which can disturb users. For things that are technical measurements, float is usually not a problem, whereas it can be problematic for financial data. If you go for decimal, you will need talk with the business side and see what the requirements they have. Expect blank stares when you ask, and sinister looks when they get an error because you in lieu of information picked something to narrow.