Shipping + Fulfillment module and improvements

[olivermrbl]

The Shipping/Fulfillment module manages everything needed to ensure that merchandise purchased by a customer gets to them. In a digital commerce context, goods can generally be shipped to the customer or a pick-up spot, or the customer can pick up their purchase in a retail store.

The fulfillment module enables merchants to configure the different fulfillment possibilities and makes it possible to easily display them to customers during checkout.

The key features of the module are:

• Create shipping options that have a name, a price, and carrier service.
• Specify which areas each shipping option can ship to. E.g., an option might only work in a country or a state.
• Understand the type of fulfillment that the option represents; e.g. will the goods be shipped or picked up.
• Calculate shipping rates for a given location and list of items.
• Record fulfillments and shipments of goods.

The new fulfillment and shipping functionality will be introduced in a new package, @medusajs/fulfillment.

[stefanrehm]

@olivermrbl - I am the founder of www.intelipost.com.br and love what you are doing with Medusa. We run a logistics tech company in LATAM and are heavily focused on exactly these features that you are thinking about. Here are a few things you could think about (in no particular order):

1. There is a difference between the "price" (what the consumer is paying) and the "cost" (what the store is paying to the carrier) of a shipment. There should be a concept for both in the module. Example: Even though a retailer is offering Free shipping (price = 0) for all products, the only shipping option the retailer wants to display is the one below a certain cost.
2. Another important data point for every delivery option is the shipping time, which can be expressed as a number (delivery in 5 business days) or as a date (Delivery date is on the 2024-03-01). The latter has shown to have higher conversion rates at checkout (aprox. 10%), but is more complicated to produce as there are public holidays, weekends, etc..
3. A delivery coverage area for a carrier can be based upon: Area (ex. country, or state), ZIP codes (range, or specific ones), Lat/long or a combination of those (ex. in the USA, it is by state, but in Brazil by ZIP code).
4. In omnichannel or marketplace contexts, a certain sale can be broken up into different deliveries with different origins and destinations, which also produces different delivery options for every combination. This allocation can be easy (1 certain SKU is always in one origin) to really difficult (minimum stock, fulfilment capacity or tax implications, etc..). Probably nothing for a standard module, but there should be an interface to get into this allocation logic easily, and be able to modify it.
5. There are several pick up types: Store, Curb-side, Locker or Pickup Points, which have different implications for consumer choice, costs, delivery time and operational details. Also, the frontend should be able to consult the different pickup locations available to display to the consumer.
6. Allow for shipping gateway providers to jump in and regulate some of the aforementioned complexity: Shippo, Intelipost, etc.. There are globally quite a few companies.
7. It might make sense to split fulfilment (where to ship from, dispatching the right quantity and SKU, route planning, etc.) and delivery (managing the delivery promises and costs/prices) into separate modules.
8. Allow for Address Auto-completion during checkout (via a professional provider, or google maps)
9. Tracking data - Receiving differentes formats and then display that data in different parts of the site to the consumer + allow for transactional emails/sms/whatsapps...

Anyways, I am available to go into more detail if you would like to.

All the best, thanks and good luck!

[olivermrbl]

@stefanrehm, thanks – this is great. I appreciate you taking the time to share this with us.

The implementation of the fulfillment module will begin shortly, so we might revert back in the near future to dive into some of these elements.

[stefanrehm]

Sure. I'm glad to help!

[mezzat11]

@stefanrehm **Very important Points to be implemented . hope to see soon in medusa **

[danielrodcaball]

Hey guys, Is there any estimation for when this will be ready?

[olivermrbl]

We expect to announce a release candidate in a couple of months :)

[danielrodcaball]

@olivermrbl do you if it's possible to start using this module in the current state in the latest medusa version (1.20.4)? Is there any ui work already in the admin-ui or admin-next?

The thing is that I need to use almost the same features this module already provides (geo zone restrictions and delivered_at event), and I'll prefer to reuse what's already done instead of writing it myself.

[olivermrbl]

You cannot use the module in 1.20.4. The module is part of 2.0, which is still under heavy development and the logic to bootstrap the application with new modules is hidden behind a highly experimental feature flag.

I would advise you to wait for the release candidate.

The same goes for the new UI.

[guibovo]

@olivermrbl I'm looking into creating a Print on Demand store, are you planning to make it able to use PoD providers such as Printful or Printify?