How Drupal Commerce 2.x is creating a stronger shipping architecture

So back at MidCamp AndyG and I spent a lot of time talking about shipping, packages, fulfillment and basically anything revolving around actually handling the physical goods after the “ecommerce” part of things is finished.

I also chatted with Matt, Ryan and Bojan from Commerce Guys on separate occasions, as well as some other developers here at Acro Commerce about how this should all work in Commerce 2.x. Below is a rough outline of where we are at so far.

In Drupal Commerce 1.x, there is no common shipping data, so everything is based on an order. This usually means everything just does its own thing and you can’t depend on much to do any fulfillment. You have to go directly to the products themselves and generally, it takes 10 modules to do anything. It feels like the bad old days of multi-language.

In Drupal Commerce 2.x, a shipment entity will be the base that everything will extend and build off of, much like an order or product being the “base” for their respective sections.

The shipment can control what products and stock are put into it and then everything can work off of shipments, for things like packaging, pricing and duty. Since once something goes into a box, no one cares what order it was attached to, it is what is in the box that matters.

An order does NOT equal a shipment, as orders might be split into multiple shipments due to multiple warehouses, product sizes or stock levels. In short, one order can have multiple shipments.

Base shipment

List of Products w/ Quantities
Ship To Address
Ship From Address
Order Reference
Status (using State Machine)

We’d then like to have a number of standard extendable options that other services can depend on to exist, but can be extended by additional modules. The idea is to handle these using Drupal 8’s new plugin system for swappable behaviour, so we know we’ll have some functionality, but how it works is configurable and extendible. I’ve detailed my first attempt at some standard plugin types below. It might also make more sense to just have one overarching plugin type, but I thought it might be nice to just touch certain parts.

The idea is to have all relationships be 1:Many, so they have flexibility even if they will most often just be a 1:1 ratio. I was also thinking we could cover some sort of active flag to handle options vs selected, for stuff like shipping rates or packaging choices.

Boxes

How the order is physically packed, what size box, how many, where is this box located.

Default – 1 box for everything, the box has no specific parameters and is more of a conceptual “box”

Example – Specific USPS compatible boxes of multiple sizes used to package up the order. Each box has dimensions and IDs attached to it and can be used both for rates and for the warehouse.

Packing Slips

Information such as a packing slip, might be a generic one generated by commerce, or it might be specific to a warehouse or some inventory software. It might have additional information for international shipments or shipments with specific products.

Default – A simple list of the products and quantities contained in the shipment.

Example – A list of the products and quantities in the shipment, with NAFTA codes and values for international shipping and duties.

Rates

How much is it going to cost to send this shipment wherever it needs to go. We might set this by weight through calculations, or connect to a shipping carrier for real-time rates. There might be many different rates from many different carriers all attached to one shipment, one of which can be picked as the “active” rate.

Default –A single flat rate shipping price

Example – A number of rates pulled from FedEx with different prices and delivery information attached to them.

Duties

Do we have to track additional charges based on the destination country, these might not be the same as the cost per order as they are based on the shipment and not the customer's order.

Default –No duty applied

Example – Multiple line items added covering specific duties for multiple good types specific to a country.

Drupal Commerce 2 creates a strong shipping architecture

Customization

Also, we would like to open up the shipment creation itself to plugins, to allow for “intelligent” automatic sorting of products into shipments. By default, we will just dump everything into one shipment per order that you can sort out manually, but we’d like to be able to have the ability for plugins to try and organize shipments based on box availability, pricing, size limits, etc.

What's next?

We will be discussing and prototyping at DrupalCon next week. If you want to chat further about Commerce 2.x shipping or anything related you can hit us up at the event. Acro Commerce and Commerce Guys will be sitting side by side all week in booths #622 & #623. Not at DrupalCon? Sorry about your luck, but you can still join the convo on Twitter @shawnmmccabe and @acrocommerceinc

To learn more about Drupal Commerce visit our Drupal & Drupal Commerce page.