Create box calculation extension point and plugin

[brent-hoover]

Shipping providers that do dynamic estimates need a way of knowing what the size of the actual box is going to be as this is the only thing that they care about.

We need to create a way of mapping product dimensions to box sizes that the customer uses. Code that closes this ticket would do two things:

1. Create an extension point for something like provides: boxCalculation that provides a function that takes the cart and returns an array of box dimensions that can be passed to a shipper for shipping calculations.

2. Create a plugin that provides this including:

   • A simple method that just sums up the cubic dimensions of all products and distributes them over the available boxes. We are assuming that customers can build into their dimensions calculations any allowance for packing/padding/odd sizes.

   • A UI settings panel for creating these boxes and the dimensions that they accommodate

We probably want to ask design for input on the settings panel but I feel like we can start work on this without a design for now.

[lcampanis]

@zenweasel we can most probably work on this solution together as we have it on a semi-dynamic level.

At the moment, we have a supplier template with the available boxes they use, which in turn calculates each shipment in the cart and allocates them into their available boxes, generates shipping labels and tracking for each box in the order. That's for suppliers.

For sellers we allow them to put box dimensions when uploading the product, this gives us the box dimensions which are then calculated dynamically during checkout.

The above points you mention are the basis of all multi-dimensional shipment calculations, however the complexity we had to solve around labels, multiple sellers, payouts, etc is much much harder and needs good care.

Let me know your thoughts, and we could start by looking into the provides: boxCalculations part to start.

[brent-hoover]

Yeah, we are looking at just creating a pretty simple implementation to start as just a prototype since I think the solutions for this are going to vary a lot per installation. I think we will probably start work in this in the next week or so, so feel free to hit me up and discuss if you want.

[hfmw]

Many operations have different box types available for products of differing type. E.g. if there is branding on the boxes; for fragile items; or if items are already boxed.

It would therefore be useful if: i) sellers could choose which boxes sizes/types each product may be packed into, and ii) there was an option per product to not consolidate shipping (if the product is already boxed) - in which case a multi-piece shipment should be produced - https://goshippo.com/docs/multipiece

Another thought, it could also be useful somewhere to let sellers group their products into types, and allow changes to dimensions, packaging types, etc in bulk. I realise bulk changes to product visibility and pricing etc are already on the map?

[brent-hoover]

So as discussed I think this is going to require a change to the schema that we should probably work out.

Since we use the billing/shipping record to represent shops in a marketplace I don't want to add more shipping records. I would propose adding a shipments array right beneath the shipping record and move shipmentQuotes, shipmentQuotesQueryStates, address, shipmentMethod, workflow and items all into this array (this would be a breaking change for sure but I think you could migrate existing users pretty easily). So really only shopId would remain at the top level.

This would give us the flexibility to have as many shipment/boxes per shop as we need. (A similar change for billing/payments has been proposed but we can work that out later, but I think this is a good pattern)

Would love to get some input from @spencern before any work would begin though, and input from @lcampanis. Also especially any community members who are integrating OTHER shipping methods besides Shippo.

[prinzdezibel]

As a side-note: ATM, different billing records do not always designate different shops in a marketplace setup. E.g. In a single shop scenario, one could pay with credit card AND discount code, which would result in two different billing records.

[brent-hoover]

I don't think that's correct. If so, it's wrong and needs to be fixed

[prinzdezibel]

FYI, @zenweasel

[lcampanis]

@zenweasel your proposition seems correct. We're happy to adjust around that. If you could implement the proposed schema, we could surely get started on the calculator based on that and review payments soon after.