Is the database structure for the stationery ordering service in the organization correct?

Question

Database

I want to try to write a service for my organization that will allow you to make a list of ordering stationery. We take stationery in Komus. There is an option to upload data from csv to cart.
I'm thinking of doing it this way: the accounting department itself creates a new order for stationery as funds are allocated for it
(maybe once a quarter an order is created automatically - I'll clarify this point) and employees add an order there on their behalf. Then it is transferred to the "approval" status. At this point, only accounting staff can manage the composition of the order. After approval is received, the csv file is uploaded.
Here is an example database structure:
employee;id;login;pass;full_name;id_departament
department;id;title
goods;id;id_komus;title
orders;id;date;id_employee;Id_goods;quantity;date;status
What do you say?

Answer 1

1. If id_komus uniquely identifies a product, then there is no point in a separate id field.
2. It is necessary to separate the entities 'order' (id, date, status) and 'order string' (id, order_id, employee_id, goods_id, quantity).
3. If you add a price to the product table, you can automatically calculate the cost of the order.