Number of employees has nothing to do with how stock is acquired and tracked.
Slight revision to my comments about payments. I was seeing the structure as card payment for every order, then I noticed your 'payment type' field. These would be cash, cc, other? If you want to allow for none cc payment, consider:
1. Customers table has a record for customer named Cash
2. Customer Cash has one 'card', say number 9999 9999 9999 9999, security 999, card name Cash, start 1/1/2000, exp 12/31/2999
3. Orders table has field for customerID and maybe for CardID if child table for credit cards - still recommend card info in Customers table or a child table
I know you are doing this for coursework and want it to be simple so maybe just design for ideal world, not real world. What is ideal in your db world - everyone pays by cc, every customer has one cc that is never declined? Establish your assumptions and givens and design within those parameters.
Reality of db design is it is a balancing act between data normalization and ease of data entry/output. I ignore/break/corrupt many 'rules' for sake of convenience and to make my db do what I want.