Difficult to answer as there is a lot of detail missing which would have an impact. Off the top of my head, it might look something like this - just a guide
TransactionPK
ProductFK - link to product
TransactionType - Transfer/Recd/despatched/StockAdj/etc - could store in a separate table
WarehouseFK - link
ReferenceFK - link to order/transaction header/etc
TransactionDate? - might store here, but more likely the reference table
Qty
first record qty would be positive, warehouseFK the receiving warehouse, second record (autocreated) qty negative, warehouseFK would be the sending warehouse all other fields except transactionPK the same (or you might use rec'd/despatched instead of transfer)
I know this is only a project, but your app is dealing with regions and countries etc in a simplistic way that does not translate to reality. Goods do not miraculously transfer from one warehouse to another in the blink of an eye (unless this is Star Trek
), it takes a day or even weeks. So at any one time potentially you will have an enormous amount of goods in transit, so neither at one warehouse or another.
You need to look at the order of events and potential consequences, eg:
Warehouse2 places an order on warehouse1
Warehouse1 receives the order
Warehouse1 despatches the goods (or perhaps an equivalent product if the ordered product is not available and the order is urgent)
Warehouse1 marks the order closed (or perhaps not because they have only despatched part of the order)
Warehouse2 receives the goods
Warehouse2 books the order
Warehouse2 marks the order closed (or perhaps not as above)
So for forms you might have several, each one completed by a different user in different locations. Or perhaps one form which shows/hides various fields depending on the action being taken.
Also depends if your project is just mapping the transfers which are managed by other systems/methods or is supposed to manage the process