Enable products dispatch per distribution location

Software improvement 1-Voting Candidates
,
1

What is the need / problem

Mary delivers the products to her customers in different pick-up points. She needs to know what quantity of a given product needs to be delivered on each distribution location.

Who does it impact

Multi-delivery places hubs

What is the current impact of this problem

  • Entreprises duplicates and lack of efficiency: Today in order to be able to manage different pick-up points, a hub needs to create one entreprise per pick-up point and create complex order cycles with all the entreprises in the outgoing session > duplicates, and time consuming.
  • Prevent users to transact on OFN: For some hubs who have many pick-up points it simply prevent them from using the OFN (like Alterconso in France, 14 pick-up points, unmanagable)

What is the benefit in focusing on this

  • Improve hub’s management efficiency
  • Avoid duplicates
  • Clarify discovery for multi-pick-up location hubs

Links to more details

Potential solutions that will solve this problem

  • Add “location” concept in the OFN Data model + Review shipping method creation to link a shipping method with a location : “The spree object address is extended in OFN with geocoding info, so, this is already a location (we could refine/expand the address object).
    So, what seems to be required here is link shipping_methods to addresses (and not to enterprises as I suggest above) and then use this info in different parts of the app.” (from Luis)
    Then:
  • Enable filters based on location
  • Include that into reports filtering/extractions
3

This is interesting. Happens in Portugal, one farmer, 5 distribution points. I share some thoughts below.

I dont think we need more data model complexity for this. The data about what quantity needs to go to what location is in the system and should be provided using the shipping methods.

What I have done in Portugal was to create the enterprise for each location, open the shopfront for each of them and link to the main Enterprise where the shopfront is setup (in the main shopfront the locations are also shipping methods):


This has the advantage that users know where they can buy from through the map.
If additionally we build a packing report with shipping method, the problem is solved.

So, what we could do without making the data model more complex is to say that a shipping . method can be linked to an enterprise, which would be the concept of “pick up at X”, X being the enterprise. this is a little shift from “pick up at Y”, Y being a location
I think this change makes the model more simple and can still be used to solve the problem.

For example, the shopfront page of enterprise A that works as pick up point for enterprise B can be changed to include a link to B’s shopfront or maybe even show only enterprise B’s shopfront…

4

I understand your point but I think it’s more complex, especially because in some cases to enable easy sorting of data / reports we duplicate effort of creating more enterprises, which makes more OC to manage, more inventories, etc. You did it yourself given your example, and could have only managed one enterprise.
Also if we start thinking interoperability, the first use case we manage today in DFC is about logistics optimization, and the geolocalisation of delivery point is a compulsory info we cannot not have if we want to do anything about logistics :wink:
So if we could associate a given shipping method to a “place” (a physical address with GPS coordinates, like it is done when you fill in the address of an enterprise) it would make it easier to sort, add to reports, etc., but also it enables logistics optimization strategies.

5

ok I think I get it.

We may not need a new concept though. The spree object address is extended in OFN with geocoding info, so, this is already a location (we could refine/expand the address object).
So, what seems to be required here is link shipping_methods to addresses (and not to enterprises as I suggest above) and then use this info in different parts of the app.

6

That’s great @luisramos0 ! Yes if we have that then it’s just using this address concept linked to shipping method, I think it’s all what we need :slight_smile: It’s gonna be pretty useful for inception what you just said, seems easier than expected :slight_smile: