Is anyone using QuickShip rate shopping at Order Entry? If so, have you found any way to modify the data flow for the package information? Out of the box, the Gross Weight is a summary of the Part.NetWeight field for the parts and quantities entered, which is perfect for the weight. The problem is that many of our products are large and bulky but lightweight, so we are actually paying freight on a dimensional weight factor. There is a spot within rate shopping to enter package dimensions but that is information that our sales team wouldn’t know and we wouldn’t want them to have to manually figure out and fill in each time. We are primarily a distribution company running on Kinetic, so we have tens of thousands of items in stock and orders can consist of any combination of items to be picked, packed, and shipped.
We do have part weights and dims on all of our products, so I have a formula that can be used to estimate the package size based on the contents, but I can’t figure out how to actually use that to pass dimensions into the rate shopping utility. The only settings within QuickShip that I have found are to use the Part Specific Package Codes in rate shopping, which essentially creates a separate package for each line item and fills in the dimensions based on the Part Package Code.
Anyone worked on anything similar or have any advice on customizing the flow of weight/dimension data between Epicor Kinetic and QuickShip Rate Shopping?
I’d be interested in what you find out. I’ve not had the technical conversation with the QuickShip folks, but we have a similar problem in that all of our stuff is Custom. The configurator will calculate the weight, but it doesn’t go on the Part table, so we need QS to read from the Quote or Order Line user-defined fields.
@MikeGross and @jepp we do not have a customization on rate shop. We do have products that fit that but it’s all our custom pipe so our sales team knows to set the ShipVia as “Truck” for a human to do the work. QS isn’t too great at figuring out truck shipments it’s great at normal boxes though.
I’m on the same journey as you. We’re working on developing an online store and a key component to it is going to be shipping estimation. We have loaded in dimensions and weights to our part table. How does the Rate Shopping work? Does it assume it’s all in one package/box? Or does it assume them as all separate? Is it flexible and/or requires some user input? We don’t currently have Rate Shopping but are in the process of investigating it as a potential solution since we are already using Quick Ship.
We are still working on this, but here is what I have found so far:
If you have Package Control Specific UOMs with Package Codes setup (Part-level setting on the Part > Detail tab of Part Maintenance and then Package Codes Assigned on the Part > UOMs tab), rate shopping will create a “Container” per unit with the appropriate weights and dims. If you don’t have this setup, Quick Ship rate shopping assumes a single package and sums the Part weights but doesn’t fill in any default dimensions.
Neither of these solutions were perfect for us, so we are still working through how we might customize this. There are API services out there that will allow you send in a query with all of your individual items sizes and it will use some machine learning and calculations to estimate the final package size and weight. Most of the ones that I have found charge a per API call rate. That part would be pretty slick for our use case but the problem is how to use that with Quick Ship’s rate shopping. Even if I could get that estimated final box size back from the service, it would require the user to manually key that into rate shopping, since I haven’t found any way to customize the rate shopping “call” and pass in the a package size.
I hope that makes sense. I can attach a few screenshots later, if you need them.
Thank you for taking the time to write that up. My Package Code is greyed out on Part > UOMs. Is there some setting I need to set somewhere to enable it?
Yeah, there’s a checkbox on the Part > Detail tab that says “Package Control Specific UOMs”. If I remember correctly from my testing, this needs to be checked.
There’s also an application setting within Quick Ship that I think has to be set to true for the rate shopping to actual use the package code data:
Nevermind. I did it again. I just read more in the help and there’s a check box on the Part Detail screen that says: Package Control Specific UOMs. That needed to be enabled. I don’t think I needed to enable Package Control at the Site Configuration level.
We’re in the early stages of looking at ShipperHQ to solve this problem. It looks promising but we’re still trying to push through the sales and marketing rigamarole and get to a technical deep dive evaluation before we commit…
I’d be super grateful if you could provide an update here once you get further into your evaluation and/or implementation. I have seen ShipperHQ mentioned several times and I do know that they are a preferred partner for shipping for some of the big eCommerce guys (BigCommerce, Salesforce, etc.), so I am definitely intrigued.
Did you you or @jepp make a decision about ShipperHQ? I’d love to hear an update.
Upgrading to a Magento site may be on the horizon, and freight estimation is going to be a big project for us, especially in offering multiple shipping options at checkout. Same boat here - lots of large but light items that get dimmed, as well as probably millions of combinations of items at a wide variety of sizes and weights. Some so big/heavy they incur additional handling, which adds another layer of complexity to estimation.
Yes! We did go ahead and implement ShipperHQ and it’s been pretty good so far, I give it a solid 9/10.
We split the project into two phases - 1) implement a ShipperHQ customization in Epicor 2) implement ShipperHQ on our Adobe Commerce (Magento) website. We completed phase 1 during the summer and are working through phase 2 now.
In Epicor our customization was basically a Function Library that called ShipperHQ’s API. In Quote and Sales Order Entry we have a button to trigger the Function API request, and it sends weight and dims data about the parts on the quote/order. ShipperHQ figures out how to box it and then the API returns a dataset of different carriers / rates with different packaging options. We display all that in a grid for the user and they can select an option from the grid and click a button to add a freight Misc Charge to the quote/order and also update the ship via.
Here’s the thing though… The true challenge is NOT about anything technical. It’s about data and knowing your company’s shipping scenarios inside and out. @doug.harvey led the implementation for us and spent months architecting how all of our goofy products and shipping scenarios mapped on to how ShipperHQ thinks about packaging and carriers, etc… You need someone like Doug to mastermind how all the pieces come together, otherwise your shipping estimates aren’t going to be that good.
