How to start a warehouse accounting system?

Question

Database

The task was set: to manage the warehouse inventory of the store on its own platform.
Now the warehouse looks like a table, each column of which subtracts the value for the write-off of the goods and adds the value of the article for replenishment.

The darkness is utter, no good.
I minimize work to atomic units:
For a start created a DB.
First, the warehouse table (a collection in my case) with the main fields:
[ {article of goods, number of goods in stock} ].
Below is a table with orders containing goods to be written off:
[ {item of goods, number of goods to be written off} ].
There are still deliveries and returns - these are the reverse actions for an order, but the essence is the same:
[ {item of goods, number of goods to be replenished} ].
Everything else under these conditions does not play a role.
Connoisseurs, attention, question:
Please indicate how to properly organize the calculation of the current number of commodity items in the warehouse, if:

• you cannot directly subtract and add values ​​when creating a new order or delivery, because irreversible operations cannot be performed. (Or do you need to make transactions without options?)
  
• at each call, calculate the previous state of the warehouse, subtract 3-4 thousand orders from it and add 3-4 hundreds of deliveries is not a solution
  
• it will be necessary to add subgroups of the number of goods in the warehouse "in reserve" "marriage" and others
  
• When a new order is received, a check for the availability of warehouse items should take place, as well as reservation of products from the availability for this order.
  

At the moment, I already know that this class of tasks belongs to WMS (Warehouse Management System) subsystems, but I can’t find information anywhere about how these systems are arranged, so I’ll be glad not so much for ready-made answers as for information about sources on methodology, design and implementation related to my problem.
The language, DBMS, and other technical aspects are of absolutely no importance, since the question in this plane is purely theoretical.

Answer 1

In my practice (and I work with accounting systems), I can recommend the following structure from the normal ones:
1) Income Income table (header, where the date of arrival is indicated, the department where it came from, etc.) + IncomeGoods - (header body, where the goods are indicated, quantity and price)
2) Outgo Expense Table (header, where the date of consumption is indicated, the department from where it left) + OutgoGoods - (header body, where the goods, quantity and price are indicated)
3) relationship table - RelationIO (identifiers of the goods incoming item from IncomeGoods and OutgoGoods )-> income and expense relationship table.
What is the essence of the table: you have an income, let's say 20 pieces. You need to pick up 10 pieces from it. You record in RelationIO the amount that you took from the parish and what took it.
You just need to write a procedure for posting an invoice - by posting I mean a set of free balances for consumption.
Now for the individual items.
For carrying out this is the only correct solution. Otherwise, get ready for a big F... in income and expenses when your whole system grows.

Create in the headers the storage locations "Main" and "Marriage" + others

I will not write about the latter. Too many there. If such a system is of interest, I can send an approximate table structure with an algorithm (or MS SQL code) for conducting

Answer 2

by squares:
1. only transactions
2. nothing needs to be calculated: batch processing with a batch length of N-operations between states
3. this is a couple of properties (if you need it in detail, then a subset) of the product offer
4. see item 1
I advise you to design statechart in UML, so you can visually analyze the movement of data between final states.