Skip to content
This repository has been archived by the owner on Jun 13, 2018. It is now read-only.

Move rate-related package concerns to a RateEstimate/Shipment model #470

Open
jonathankwok opened this issue Jan 16, 2017 · 6 comments
Open

Comments

@jonathankwok
Copy link
Contributor

Discussion came up during #469, and a bit IRL:

Some concerns on the existing Package are not generic enough to be on the Package data model. For example, export reasons such as gift? or sale? are more intimately tied to the Shipment itself, which should be concerned with the actual shipment of a package from an origin to a destination with all the packages contained.

Similarly, information such as oversized? and dimensional_weight requires the knowledge of a carrier to determine - what constitutes oversized for UPS might not be oversized for USPS, for example. These can't live on the generic Package model.

I'm proposing a new model - a Shipment model, that represents the physical act of sending Package(s) from an origin to a destination with all the shipping options that may be included. Within a Shipment model will be one or more Packages, which each have a 1-1 relationship with a RateEstimate, since a RateEstimate is calculated by taking in the attributes of the Shipment as well as the Package.

Still a little amorphous in my head as to the exact implementation but just throwing these thoughts out there for discussion.

@jonathankwok jonathankwok self-assigned this Jan 16, 2017
@RichardBlair
Copy link
Contributor

Can you put together a small UML type diagram to model the relationships between these objects?

Additionally, we will want to nail down definition here. To me, I get a rate estimate for a package. It's not really a shipment yet, is it? Maybe it is? From http://www.dictionary.com/browse/shipment we can see a few definitions.

We should also sync on the direction we are going internally. It would be great if we were aligned, but if it doesn't make sense that is also okay (although less preferable)

@kevin-jj
Copy link

kevin-jj commented Jan 18, 2017

Thanks Shopify team for contributing this awesome gem.

Agree more with @jonathankwok. One shipment represents the delivery details containing several packages & origin/destination & shipping rates, but in my opinion one shipment should have many RateEstimate since one carrier has many service option such as 'Standard Shipping' and 'Express Shipping' etc.

@RichardBlair What you defined for RateEstimate is really a RATE CALCULATOR instead of entity-object relationship.

Thanks Shopify Team again. ActiveShipping Gem provides more insights for our team.

@jonathankwok
Copy link
Contributor Author

@RichardBlair I've thought this out a bit more, didn't draw a diagram but I've tried to put it in the clearest way possible:

A Shipment has an origin (Location), a destination (Location), and one or more packages (Package).

A Package represents a single physical package. A Package has many PackageItems, which represent items within the package (and are only really relevant when making international shipments, for customs).

We then operate with the Shipment object to get rates/labels - for example, to fetch rates, we should be calling find_rates(shipment), rather than find_rates(origin, destination, packages, options). Similarly, to purchase a label, we'd call create_shipment(shipment), and not create_shipment(origin, destination, packages, options).

This also gives us the flexibility of inheriting from Shipment, e.g. CanadaPostShipment, or StampsShipment, which solves for us the problem of dimensional weight being determined per-carrier, or money parsing being different per API.

We'd also attach shipping options to a Shipment, since you cannot have shipping options on one package within a shipment without applying it to the others, and they feel like carrier-specific things. I'd need to look into this more though, to be sure.

@RichardBlair
Copy link
Contributor

Do you buy a label for a shipment, or for a package? Or are you thinking about modeling this as 1 Shipment but multiple packages for carriers that support more than 1 package for a single label?

@jonathankwok
Copy link
Contributor Author

The latter - you can possibly have multiple packages for a single shipment but they'll still have only one "label" (that can be used on multiple packages within the shipment, e.g. FedEx multipiece shipment.

So you'd purchase a label for a shipment.

@developingchris
Copy link

@jonathankwok I like where you are going with the idea of a Shipment.
If you ever read the shipping guidelines or any memos from the carriers, they refer to this concept as a Consignment. Which is everything on a single label, signature requirements, delivery guarantees, tariff codes, number of pieces on the label.
I think Shipment is a more humane way to name and explain it.

@jonathankwok jonathankwok removed their assignment Apr 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants