From the information given so far I think you will nearly always only want an add to stock (SOH) option on this screen. However, as discussed below, this may add either to the system's idea of stock-on-hand, or to a running-total when performing a stock-check. (Essentially the same screen would be used for both actions).
The update/set stock option would most likely live elsewhere (possibly on a manager's screen only) and would only be used once a stock-check process is complete.
It's not entirely clear what processes your users' are performing, and therefore it's not entirely clear when adding to stock-on-hand (SOH) or updating/setting SOH make the most sense. If you haven't already, you need to clearly define the actions/processes your users will be performing in order to decide the best way of presenting the UI.
However, the two actions that immediately spring to mind are:
Processing incoming deliveries – a parcel/shipment arrives from your suppliers and users scan/enter a stock-code and the number of items received.
Performing a stock check – here they would be roaming the shelves (in a shop and/or a warehouse) manually counting what is physically present to check against the system.
and I will discuss these below. If these actions are incorrect, or there are other actions being performed, please indicate.
In the case of processing incoming deliveries, I can only conceive of add to stock being useful – the person opening a delivery has no idea how many items may actually be in stock (nor has any need to know); all they need to do is tell the system that there are x more items available.
In the case of stock-checking, it gets more complicated.
- If all instances of a given item are guaranteed to be in the same location, then the user can go to that location, count the items and enter that number. For this use, update stock (or set stock level) would be the appropriate option.
However, that use-case seems fairly limited: it won't work if there's any possibility that stock may be in more than one location (multiple places in a warehouse; in both the warehouse and on shop shelves). In addition, it won't easily allow anyone to analyse differences between what the system thought was in stock, and what is actually in stock. For a small organisation, this might not matter; however, a larger company may well want to know when there's a discrepancy between the two: this could indicate poor working practices (deliveries not being processed properly; items not being registered when sold); excessive breakages or theft.
To provide this level of checking, you will need to maintain two counts: the SOH as currently implemented (increased on delivery; decreased on sale) and a running total of stock-checked items. The procedure (for a given stock-item) would be:
Clear the running-total of stock-checked item(s). This might be for a single item you want to check, or for all stock items if performing a full stock check.
User(s) roam the shop/warehouse, either looking for any instances of the single-item being checked, or processing everything they find. In either case, they will scan/enter the stock-code and the number of items found and use essentially the same add to stock function (on essentially the same screen) as when processing deliveries (the difference being that the running stock-check-total is incremented instead of the normal SOH figure).
At the end of the exercise, someone – probably not the users doing the checking – will review the stock-check-total count(s). Only at this point (after noting any discrepancies for further investigation) will the day-to-day SOH count(s) be updated from the stock-check count(s).