What is the need / problem ?
Very often we get asked if it is possible to limit the display of specific shipping methods or payment methods to specific order cycles.
Who does it impact ?
Hub managers that wish to offer more complex array of options for their users. This is a common trait of moderately complex food enterprises.
What is the current impact of the problem ?
Many hubs are currently running multiple enterprises to navigate this problem or trying to use the tagging system to solve this problem. The result of using these methods is that operation of their shop is much more complex and time consuming. It also limits the flexibility and there are many hubs that would like to try small innovations to support their shop but are not able to. This creates dissatisfaction.
What is the benefit of focusing on this ?
This would enable:
- People to be able to accept cash or card payment on pickup only at specific order cycles and collection points
- Courier shipping only for specific products
- Simpler wholesale OCs with specific payment methods for wholesale
- Many more things as per Louises list at comment 31 on this thread.
Essentially this feature offers lots more flexibility in the way that hubs can manage their shops!
Potential solutions that will solve the problem ?
[brainstorming to list feature candidates]
The current working solution is an option within the Order Cycle creation to turn and off shipping and payment methods for specific OCs. Technically this will be a flag on the OC to specific available shipping and payment methods.
Selection of a feature candidate
[value x ease matric if needed]
T-shirt size of our selected feature candidate
Small
Metrics to measure if need is satisfied after feature is implemented
Feature owners
Epic/projet where you can follow implementation
Connected wishlist and discovery discussions*
[list precedent discussions]
That would be a great feature. A lot of businesses use something like that. Iām just wondering if tagging is the right model. It looks like you want to associate order cycles with shipping methods. But does that association need a name (tag)?
Iām just bringing this up, because the data model could be simpler and more explicit if we introduce a new relation instead of using tags.
Hi @maikel
Totally agree that the tagging feature is actually a bit of an overkill for this relationship. However I did think about this and there are a few reasons I think it might be a good move anyway:
- Uses functionality that already exists. This would possibly mean faster development, and potentially easy for the user to understand.
- Allows tags to be reused. I can imagine this being really useful. For example you have a āSaturday Marketā tag and you can tag specific delivery, payment methods and customers all using the same tag.
Very happy to re-explore this with just a new relation. As you say @maikel it would be more explicit and simpler in this case.
@oeoeaio @Kirsten @sstead @mags @danielle @NickWeir @MyriamBoure what do you think on this one?
I think that this relates to conversations around Inventory 2.0 (believe it or not), because we are imagining a stripped down Order Cycle interface that basically just sets a timeframe and links a whole lot of things together for that timeframe. The key thing here is using Inventory Lists (exclusively?) to manage product and variant availability. We had talked about selecting which payment and shipping methods available to which shops at an OC level as part of this change. But not sure when it will happen.
I guess my point here is that if we are (eventually) heading in that direction, it would probably be better to skip the tagging thing and just enable selecting shipping methods at the OC . . any thoughts @oeoeaio @sstead
@lin_d_hop I agree that this functionality would be very valuable!
For the majority of our users (people running simple shops, and not using the tagging tool) tagging is not a very user friendly way to setup OC specific shipping methods. People get overwhelmed easily and I think they would prefer to select which shipping methods are available in the OC interface. It might suit more advanced users who use tagging already, but most of our users donāt fit that category.
That said, I donāt know what the āease of developmentā factor would be. And whether, itās worth developing this given the likely Inventory 2.0 changes, which might make it redundant.
@Kirsten Inventory 2.0 sounds brilliant. What kind of timescale are we looking at for that do you think? Would that be funded largely under the la poste work? Is there a spec anywhere?
I am not allowed to distract Rob at the moment (note not using his handle 
as he is exclusively focused on standing orders. But when that is done I would be keen to see if we can come up with an MVP of this. There are bits of specs in a number of places, so the first thing would be for me to spend a couple of hours pulling it together to do a draft ābig pictureā spec, from which we could attempt a phase 1. Funding for it is really not clear, as is always the case for these ācore but not urgentā things. I think there could be bits in a bunch of places and essential to some of the more advanced wholesaler to retailer or buying group operations weāre anticipating. I suspect it could also intersect with some of the trickiness in Spree Upgrade at the moment
Ha ha ha ha - laughing and crying 
I just came in to create a wishlist item for 'User can choose which shipping methods are available to specific order cycles" and found this discussion
Well it does seem that āinventory 2.0ā has come a long way from my comments above - but based on last nightās discussion might be strongly suggesting that we are comfortable with tagging as a way to manage complexity and flexibility (with lots of careful ux design)
So based on that - my vote is to progress this idea with tagging! and perhaps it might not even be that hard . . . anyone have a t-shirt size indication? @Matt-Yorkley @luisramos0 @maikel
1 Like
@Kirsten I havent validated with other devs that tags are a good idea. Here I see Maikel suggesting normal associations.
The power of tags is not only the name they bring, the major power I think is that they are not an association between two specific entities, they can be used to connect whatever we want. For example, you can tag shipping methods and than use that tag in OCs to filter available shipping methods but you can also then tag products to only allow certain shipping methods.
Tags bring more complexity to the implementation but are then very powerful tool to solve user problemsā¦ we need find the right balance between simple associations and powerful more complex tags.
The tags UI presented by Lynne above is quite complex for the user and also for the developer.
In this particular case, I tend to think a simple association between OC and ship methods is enough? Unless we have other plans for these tags and are willing to pay the complexity priceā¦
Maybe I donāt quite understand - can someone give me a quick example of how a āsimple associationā would work? It would just be that I can select which shipping or payment methods apply directly in the order cycle?
yes, thatās what I meant by āsimple associationā. can be many to many: you can select multiple ship methods for an OC. That is still a āsimpleā association compared to using tags.
So - its like a simple association now with an enterprise fee for example? I set up an OC, and can select which enterprise fee(s) apply. I would be able to select which of my shipping methods apply. I could select which of my payment methods apply. ??
But, doing it by tagging - like tagging a shipping method to an order cycle - gives us more power - and future potential - with a short term time trade off. Is that fair to say?
Apologies - because to me from a user perspective, simple association and tagging seem like the accomplish the same thing. Iād like to understand the power/future potential LOST if we go simple association now. Will it impact network features for example?
Alright everyone, I have a proposalā¦
I agree with @luisramos0 that tagging is an overkill for this and will introduce the kind of complexity that our support teams might murder us for when shipping methods are disappearing and reappearing in conjuction with random tag combinations between OCs/customers etc.
A simple association between OC and Shipping Method will mean that an Order Cycle can have Shipping Methods enabled and disabled for it. If a shipping method is enable for an order cycle tagging etc will work in the same way. if it is disabled then it will never be available on this Order Cycle.
By default all Shipping Methods should be ticked on an OC. The person creating/editing the OC can then disable as they see fit.
I would propose that the assigning of Shipping Methods to OCs is done within the OC set up process, probably on the first page. Here is a mock of what it will look like for a Hub:
This has been coming up as a request at least monthly for as long as Iāve been involved in OFNā¦
3 Likes
Very excited about this - and totally agree it has been coming up regularly as a need.
I have a question about how this will work when there is one or multiple distributors in the outgoing section of the OC (distributors other than that OC coordinator)
Right now, outgoing distributor shops pickup their shipping methods (and payment methods as well) from the distributor enterprise (as defined on the distributor enterpriseās profile). So - in the above - distributors in OC would have no way of selecting/deselecting their shipping methods.
Might we move the shipping methods selector to the table of outgoing distributors? (like beside the fee option or something) so we can give outgoing distributors the ability to make this selection too?
And as an aside - if we are doing this - would it make sense to do the same thing for payment methods at the same time? Just a thoughtā¦
1 Like
That makes sense @tschumilas to have this in the Outgoing section. Good thinking.
I agree it is also requested for Payment Methods. Personally I think Shipping Methods is the higher need hence opted to start with that. There is no reason it couldnāt be done for Payment Methods. But the bigger the scope the less likely we are to work on it so ā¦ this.
Sure. Agree this is a higher need. Iām probably the only one who wants this for payment methods But this doesnāt seem to be a global priority. Iād rather move on shipping methods than wait longer for both. (If that makes sense)
I def also want for payment methods. We could package the tasks. It might mean we get more buy inā¦ or it might mean less. Gamble gamble 
This is something that comes up regularly in Aus too and I think the proposal to include Shipping Methods in Order Cycle Set Up would be well received. We do get asked about tagging payment methods to order cycles too, but I think I would also put Shipping Methods higher on the priority list.
Here is another iteration on a mock for this feature.
Here I have included both Payment and Shipping methods.
3 Likes
Looks good for a 1st version of this functionality!
In terms of UX of this process thereās plenty to unpick, but that can come after we have desired functionality of shipping/payment method selection.
1 Like
as he is exclusively focused on standing orders. But when that is done I would be keen to see if we can come up with an MVP of this. There are bits of specs in a number of places, so the first thing would be for me to spend a couple of hours pulling it together to do a draft ābig pictureā spec, from which we could attempt a phase 1. Funding for it is really not clear, as is always the case for these ācore but not urgentā things. I think there could be bits in a bunch of places and essential to some of the more advanced wholesaler to retailer or buying group operations weāre anticipating. I suspect it could also intersect with some of the trickiness in Spree Upgrade at the moment
