Kryptronic Software Support Forum

You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.

#1 06-20-2016 21:50:19

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

Checkout has to be tested with different product quantities

The USPS has several different kinds of container sizes:  flat rate envelopes, Regional A, Regional B, Flat rate Medium, Flat Rate Large, and Priority Mail boxes.   The USPS api will work with the product dimensions sent to it and return the size of container to use when the customer chooses 1, 2, 3, 4 etc., quantities of a product. 
This is a tip to help tune product dimensions so the cart can fit the right number of products in a USPS box.   For example:  two of a certain product can fit in a USPS Regional A box, but 4 of that product will not fit in a Regional A box.   If the dimensions of the product are incorrect, the USPS api could try to fit 4 of that product in a Regional A box when 4 of that product will not physically fit in that box.  If you don't test this, then you will be making a lot of shipping adjustments to customer orders.
We can only detect this if we make a test purchase of 1, 2, 3, or 4 quantities of a product.   If the USPS api says 3 of a product can fit in a Regional A box you need to verify that 3 of that product actually will fit in a Regional A box.   If you can't get 3 of that product in a Regional A box then you have to adjust the dimensions of the product in the shopping cart so the USPS api says only 2 of that product will fit in a Regional A box.   If you don't do this kind of testing then you are going to be constantly adjusting the shipping on customer orders.   By doing this sort of testing up front, the number of orders that have to be modified will be minimized and less work will have to be done to adjust customer orders because the shipping isn't correct.
The USPS api can put a product in a Flat Rate envelope.   You may think it is not appropriate to put that product in a flat rate envelope because the product might not be secure shipping it that way.  To stop the Flat Rate Envelope as being a selection for your customer, you have to increase the dimensions of that product so the USPS api will not think the flat rate envelope is appropriate for the size of that product.  Again, this reduces the number of customer orders that need to be modified.  It cuts down on the time it takes to get orders packed up, paid for, and shipped out.

Offline

 

#2 06-21-2016 11:09:21

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19557
Website

Re: Checkout has to be tested with different product quantities

Thanks for the tips.


Nick Hendler

Offline

 

#3 03-01-2017 15:34:25

coatzel21
Member
From: Boston
Registered: 03-04-2014
Posts: 150
Website

Re: Checkout has to be tested with different product quantities

Are you using a customized shipping method?

We've had some problems finding the balance where the shipping estimate will be too high if everything is shipped together. But then packing items together we've had to eat some ups shipping costs when the shipping total is drastically different from what the cart's ups api charges.

Offline

 

#4 03-01-2017 17:22:01

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

Re: Checkout has to be tested with different product quantities

I did do some code changes to the v8 software.  I adjusted the software so it would accept priority mail regional Box A and Box B.  I am also using a third party vendor to print the US Postage and I'm passing along to the customer the commercial postage rates.   I also modified the software so the commercial postage rates would display in the shopping cart.   I don't use UPS as a shipper.  I ship only USPS and FEDEX.   
I understand what you mean by having to eat some shipping costs because the api doesn't seem to work correctly when multiple items are going into a fixed size box.   To minimize that problem I ran some tests to see what the shopping cart allowed in a box and then verified those items could actually FIT in that box.   Then, I would add another item to the order and made sure all the items would fit in that box.  If the shopping cart said they would fit, but there really wasn't enough room in that box, I had to fiddle with product dimensions so the correct number of items would actually fit in the fixed size box.   If you don't do this kind of testing, then you are going to have more occurrences where you will have to eat the shipping cost.   If you accept their credit cards off line, then you won't have to eat any shipping costs.   But when you process the credit cards online through the shopping cart, you are limited by the total amount on the card and if the shipping is more than what is in that amount, you will end up eating the shipping cost because you can't increase the credit card amount.
If you do your testing only when shipping exceptions occur, it may take longer to eliminate eating shipping costs.   A quick way to eliminate eating any shipping costs is to make the dimensions of the products larger by say 50%, or some percentage.   That way, the api won't tell you the total order will fit in a box that is too small to hold the order.   If you are using peanuts as packing material, they take up space in the box.   With this shopping cart you should pick up space for those peanuts in the dimensions of your products.   I bet that will go quite a way toward eliminating having to eat shipping costs.

Offline

 

Board footer