Enable Hub to set default inventory level for each product / variant, so that you can quickly ‘re-stock’ to your preferred level at the start of each order cycle, without having to manually do them all
e.g. Producer Shops often have approximately the same amount of products / variants available each order cycle e.g. 50 doz. eggs. It is onerous to have to reset the inventory levels for each order cycle, when they are always the same to start with.
The inventory function still needs to be used to ensure that too many are not sold in this Order Cycle (e.g. can’t use ‘on demand’)
How could we do this?
new field in Variant and/or Variant Override called ‘reset to’ which holds the ideal inventory reset level for that Hub
button for ‘reset inventory’ on Order Cycle summary screen, which checks for Variant Overrides and resets the inventory to allowed level
NB. Best to do using VOs because then Producer can have different level for different Hubs BUT for Producer Shops would be onerous to create VOs . .
if OC Coordinator is ‘own’ then uses core variant levels, if is ‘any’ ?? not sure about this
ok, good news @lin_d_hop - @oeoeaio and I reckon we have a pretty manageable way forward with this. yay. Have a look and see what you think, and whether you want to do this or alternatively we could get @maikel started on it . .
The key to it making sense to do it this way, is that we have a general plan to move more functionality into the VO page as an ‘inventory management’ page, where Users can easily manage which products and variants they actually want to work with (which is often NOT everything the producer has available). Will write this up properly
but in the meantime, perhaps all we need is
a new field in variant overrides page for ‘reset level’
a button / function that resets ‘on hand’ to the amount in the ‘reset’ field
the VO ‘on hand’ levels already override the underlying product ones so these will be the levels then reflected in the shopfront for the hub
function called manually for now, but then once is working we can work out where else / when to activate it from (e.g. when opening a new order cycle)
[Note to self . . Q: is there any reason we would want to have the inventory levels set at the order cycle rather than the Hub? Only if we want each outgoing Hub to draw from same inventory, but then we can just set that in OC ‘draw from Coord inventory’]
Am I correct in thinking that at present the variant overrides page only actually handles variants. If a product has no variant, ie just the master available, then you can’t actually do anything from the variant overrides page and would instead need to use the products page?
So is the plan to allow VO page to handle reset values for all products?
omment from @NickWeir on github, should be taken into account in implementation
Stroudco producers (and the hub admin on their behalf) need to be able to set stock levels in one of 2 ways: 1) that the stock level available from this product for a new order cycle reduces by the amount sold in the previous order cycle OR 2) that the stock level of this product available for a new order cycle reverts to the original total set at the beginning of previous order cycle.
In this way the producers who hold a stock in the Stroudco shed can have their stock levels automatically reduced using option 1) above and producers who always produce a maximum of 5 loaves of bread every week can use option 2)
Hi, new UK dev Steve here having a go at this. I’ve implemented the new default stock field in the variant overrides model and the reset function as suggested in the May 22 post. I’m going to move onto hooking this up to the front end variant overrides page once I’ve learned some Angular…
A couple of thoughts I had while doing this:
As I’m writing it, having a default stock level of nil means that the levels should not be reset, while a value of zero would reset the on hand level to zero when the function was called. Assuming this behaviour is ok, there needs to be a way for the user to clear the default level for a variant. The level can be changed or set to zero in the normal way (by entering a new value and calling the bulk_update function on the variant overrides page) but I think there would need to be a separate [x] button or similar for each override [that has a default level] that will set it back to nil (i.e. disable reset behaviour for that override).
I’m writing an analogous method to bulk_update in the controller that will go through all the overrides and set the on hand level to the value in the default level field. Another way could be to have a script that fills in all the on_hand fields in the front end with the default value, then just use the current bulk_update button. This could be a nice way to do it if ad hoc changes to the default values for an individual cycle might be necessary, as won’t have to go through two database update steps? Don’t know if there’s a preferred style here?
Please bear with me if I’ve got the wrong end of the stick with any of this!
Have confirmed with user operating two hubs with same products that maintaining stock at order cycle level is preferred, so no problem doing it this way for now (i.e. some future user may want to set stock levels that apply to multiple hubs). This could be implemented through @oeoeaio’s idea of eventually allowing ‘inventory lists’ ie. multiple sets of settings for different hubs, and enabling selection of which one you want to use at the order cycle. next step
@RohanM just flagging you to this one. Could you have a look at @stveep’s comments above and see if is ok in line with our discussion?
Also, @stveep and @lin_d_hop - I’ve copied a comment in above from @NickWeir. Does my understanding of this match yours? Just wanting to make sure Nick’s request is covered by the proposed implementation
Case 1: is what happens automatically. If you control the producer, you set the base stock level and each consecutive OC just draws down from that. If you set VO’s for your hub, and don’t ‘reset’ them, then the next OC will just draw down
Case 2: the levels set in ‘reset’ can be restored by clicking the new button. So as long as you set them right last time, and you remember to hit this button, you will be able to start again with the same levels
Sorry I didn’t pick this one up straight away. In future could you make sure you tag anyone you’d like to respond eg @lin_d_hop as that way we’ll get a notification
RE Nicks comments, sounds the same as the original spec to me. The Reset level field can be enabled, giving the case 2 functionality, or disabled leaving at what happens now (case 1). Variant overrides are already available per hub for hubs and producers so this feature should just tie in nicely.
On @stveeps first thought, perhaps a checkbox ‘Enable’ in the column that then expands to a field to input a number? This will help reduce any user confusion.
On your second thought, I think the idea of setting on on_hand values to the reset_level is a good one. This field on the variant_overrides table is specific to a product and hub so tying in with the existing on_hand functionality seems like the simplest and cleanest route to me. When reset_level is disabled the on_hand value will just remain as is unless updated.
The function to do this update will reside in a button in the order_cycle screen. I suspect it will go beside the ‘Send Producer Emails’ button that @pmackay has been working on in https://github.com/openfoodfoundation/openfoodnetwork/issues/275.
This is coming on ok - sorry for the late response, I’ve been away. I have one question that has come up when writing the tests. I was having some authentication problems when running my tests for updating the variant overrides, except when I used an :admin_user from the factory. I’m worried that this creates a super (instance-level) admin and is therefore not what we want? I guess the desired behaviour is that the admin of the associated hub can update but no one else? Would I simulate this in the tests by making a regular user who is the owner of the enterprise? I got an “unauthorised” redirect for the POST request when I tried it this way. I was finding it hard to figure out which user types/roles are available and what they correspond to just from the code, is there some kind of reference for it anywhere?
Anyway this authentication uncertainty aside it seems to be working fine, I implemented a method to refresh the data after updating as we discussed so thanks for the help with that. I’m now working on a toggle to enable/disable automatic resetting of the stock levels - @lin_d_hop and I thought about adding a checkbox for each override on the VO page to do this. This means it can easily be switched on or off temporarily for an order cycle (say) without having to re-enter all the default stock levels afterwards. @NickWeir@Kirsten does this sound sensible? We’ll also need to think about whether/how to trigger this from the “New Order Cycle” page I guess.
Sounds great @stveep - I’m not sure if @RohanM is yet in the desert with the bugs at burning man, so have just pinged a couple of others in case they can help with your question of testing different users (which @lin_d_hop or @pmackay may also be able to help with), or @maikel@oeoeaio
Thanks Steve - this sounds great. Yes it sounds like a "nice to have"to be able to switch on or off for an order cycle but if this is a lot more work it would be fine for each individual producer (enterprise) to be able to choose either automatic resetting of stock levels or a stock level that reduces by the total orders from the previous order cycle. Thanks Nick.
Hows this coming along? Maybe you’ve progressed since you wrote this but if not…
In answer to your questions about users, you are right that we want to test the functionality with more than just admin level users.
To get a flavour of the user and enterprise types have a look at: Users and Enterprise Types
I’m not sure if this will be useful in your case, in other testing I have done I have created a user and an enterprise then assigned the user to have an enterprise_role.
enterprise = create(:distributor_enterprise)
I suspect that the issue is more likely to do with setting up the test than the implementation, but you could always confirm that to yourself by logging in as an enterprise manager and testing that your functionality still works.
If you have a pull request I could do a code review on it if that would be helpful? Obviously Rohan will have more to offer than me but if nothing else it’ll help my learning
I put in a PR as we discussed on the Skype. I’m about to go on holiday for a couple of weeks so haven’t had a chance to look into the auth problems further…but I ran into it again when writing the feature tests, even though all the user stuff was set up already in this case and works for e.g. the bulk_update method, so I still don’t really understand. It’s probably something simple and just down to my inexperience so if you or @oeoeaio have time to check it out that would be great - if not, no worries and I can pick it up when I get back. Hopefully something in there is useful anyway…
Yes I got the data refresh working basically as you suggested. Think I’m OK
for the moment, now going to work on a way to disable the reset to default
behaviour for an override, and add some tests for the front end stuff.
Thanks for your help.
Won’t be able to do anything until late next week due to impending wedding
OK this is ready to deploy to staging and test @NickWeir@pmackay (uk/default-inventory branch). Here are some details on the implementation. On the Products -> Overrides page in the Admin interface there are new columns to enable the inventory reset and set the desired default level:
Once the button is pressed, the database update is invoked by POSTing the relevant VOs to /admin/variant_overrides/bulk_reset, then refreshing the data on the page. Let me know if there is a more useful place to trigger this method from.
I haven’t done any testing to make sure that these values carry over to the order cycle etc, but this should use the VO values I think.
I’m not sure if this is desired behaviour or not, but as you see in the last image, any field that has been changed appears in blue - I think this is because the values from the variant have been overridden? Anything in the new columns will also appear in blue which makes sense if this is the case, but “dirty” (unsaved) entries on the page also appear in blue so this could be confusing. I haven’t consciously changed anything to do with this.
I started this before most of the translation work began in earnest and wasn’t thinking about it, so need to update strings to t calls for the new columns/button/messages.
Unrelated issue on this page - the hub selection dropdown can’t be reused after a hub is selected without reloading the page.