I will think about this, but my first response is unfortunately “is this the problem we need to solve”
I don’t know if now is the time or not, but part of our architectural issue is that Shipping Methods are getting used often to transmit Locations and Times (and probably other things) for buying group locations - rather than being used more strictly as shipping methods e.g. collect or deliver
The alternative is to create a whole lot of duplicate Enterprises (w same business information) so that they can be managed with required flexibility in Order Cycles (e.g. issue that @rbarreca raised today)
I feel like 2 would be a much more acceptable solution if we didn’t require creation of these different Enterprises in order to manage timing issues in Order Cycles. Given that people use this as a workaround (and end up w multiple enterprises), making them duplicate their shipping methods (and have to change each of them if they want to increase their home delivery price for example) might be harsh?
BUT that also means that perhaps taking the 2. path is heading us in the right direction (as well as being technically much easier), because perhaps where we want to go is that Shipping Methods are connected with particular Enterprises, and those Enterprises might have multiple Locations (which are identified more with place and time). @oeoeaio have had something like this on our ‘refactor in magic fairy resource land’ list for a long time
@sstead will have a better idea than me, but my understanding of Aus users is that Most are only operating the one Hub enterprise. Except Food Connect which has a couple, but more like 2-3 than 15, so 2 is probably pretty manageable
Sorry it that muddied rather than helped