Splitting the transactions table is fine (better normalisation) although it makes queries a bit more complex. There is a saying 'normalise until it hurts, denormalise until it works'
You use the same form but providing you know what type of transaction you will be doing when you open the form (perhaps based on the user profile, perhaps based on a menu the user selects from) you can set some properties such as a label caption or form back colour to indicate what type of form it is - and modify the rowsource of your combo (which I would rename as cboTranType). Personally I would put this combo at the top and hiding or disabling all the other controls. Then showing or enabling the relevant controls when a selection is made.
for your stock adjustment, there are many types but if this is to do with a stocktake adjustment you can include an additional field in tblTransactions (you could put it in tblTransactionsMain but makes things a bit more complicated with no real benefit) called say 'StockCount' with a default of null. This would be hidden in your form unless the user is doing this sort of transaction - you are using a datasheet so you would set columnhidden to true (or columnwidth to 0).
If the user needs to make this adjustment (or perhaps you have a routine for just entering the stocktake count, and not worrying about comparing values), they enter the stock count in this field and in the afterupdate of the control populate the the quantity field with the difference between actual and theoretical - code would be something like
me.quantity=me.stocktake-dsum("quantity","tblTransactions","itemsFK=" & me.itemsFK)
so say the calculated value is 10 units and the stocktake is 12 you would have
12-10=2
The benefit of storing the stockcount value is as the amount of data grows the dsum might take longer, so you calculate from the last stocktake date - simpler is a query otherwise you need to use nested dsums and dlookups.
Alternatively you can have a control on the main form to show the current stock - controlsource would be something like
=DSum("qty","tblTransactions","itemsFK=" & [tblTransactions Subform].[Form]![ItemsFK])
and in the current event of your subform you would need code
parent.nameofcurrentstockcontrol.requery
user would then need to calculate the difference themselves
or you can just include the dsum in the recordsource of the subform - you will need to use dsum, otherwise the query becomes unupdateable. But why do potentially 100's of calculations when you only need the odd one?