Thanks for the suggestion Catgirl. Unfortunately this is not something that can be made possible within our system :(



Will having a minimum checkout amount for the cart come close to your requirement?

We have no way of adding a handling fee that is unrelated to Shipping, so I think E-junkieChef was only asking if having a required-minimum order would be helpful to you (i.e., so buyers would be unable to checkout unless their order total was at least $x.xx amount).

I'm terminally confused as to what the PROGRAMMING difference is between:



A) setting a handling fee of $4.99 and a flat shipping charge of $0.01 for 1-1000 items, and

B) setting a handling fee of $5.00 and a flat shipping charge of $0.00 for 1-1000 items, and

C) setting a handling fee of $1.00 and a flat shipping charge of $4.00 for 1-1000 items.



However, I apparently could do "A" and "C", but not "B". How is it possible that "B" is "not something that can be made possible within your system," if "A" and "C" are in fact already possible?



I DON'T like the cart ZIP code entry either. And I ship physical items.



I ship items that are under 13oz, and can be shipped first class - which of course means that they pay the same rate over the entire continental U.S., AK, HI, and Puerto Rico. Therefore, the entry of the ZIP code is completely superfluous and serves no useful function whatsoever in relation to shipping.



However your system refuses to calculate the postage until the customer enters a ZIP code - even though your system ought to be capable of applying the rule that all items totaling under 13oz may be calculated immediately because they are flat rate (as applied to destination). This confuses and annoys the customers.



Further, I don't like the fact that I have no control (except by applying exotic fudge factors) over whether the shipping calculator goes into flat-rate Priority Envelope/Box prices or per-ounce Priority prices. I can create a "1oz" infinitely small (fits, say 1,000 per envelope) hypothetical item and that doesn't bother your system a bit.



But if I ship 1,000 of these across the country (say from 95928 to 21228) your system is happy to charge $97.60 - the 1,000 oz per-ounce-Priority-cost, when my items, by definition, would fit just fine into a $4.95 Priority Mail Flat-Rate Envelope. By my stripes, unnecessarily charging the customer and extra $92.65 in shipping is rather extreme.



Yes, the example is silly - but I'd remind you that your own system has no problem with the concept of 1,000 1oz items fitting into a single envelope. Therefore, it should be capable of doing it correctly and intelligently.



From my perspective as your customer, a business owner, and professional shipper, this level of uncertainty, confusion and lack of control of postal rates on e-junkie is not acceptable.

We rolled out some significant upgrades to our Shipping Calculation feature last week and are still working on updating our old help page documentation accordingly; meanwhile, you can read the announcement with a summary of the improvements here:

http://www.e-junkie.com/bb/topic/3656



The setting for a Handling charge is a legacy holdover from our older Shipping settings, before the recent improvements. It simply adds a flat amount (or optionally an extra percentage now) just once to the Shipping amount calculated for each order. As you have surmised, this may serve little purpose if you're already defining Shipping Rules that use the flat-rate calculation method, and it does require that the Shipping Calculation feature be enabled for the product, since a Handling charge is an integral component of Shipping Calculation.



Our USPS and UPS Ground rate-lookups only ever obtain a weight-based rate for a regular Package; they do not ever lookup flat-rate box rates, envelope rates, oversize packages, etc. The Container Type names (Small Envelope, Large Box, etc.) in Seller Admin do not affect live rate lookups; those names are just to help you keep track of which container is which easier than just naming them Container A, B, etc.



If you wanted to use flat-rate boxes, you would assign each of those flat-rate price levels as the Cost of a specific Container type, then configure each of your products with the appropriate Packing Container and a packing capacity declaring how many units of that product would fit in that Container.



Speaking of Packing Capacity, note that this affects the rates we obtain. If a product is configured with a Packing Capacity of 1, then ordering 30 units of that product would obtain rates for sending 30 separate parcels; if that same product was configured with a Packing Capacity of 30 or more, then the same order would obtain a rate for only 1 parcel. As you might well imagine, the rate for (30) 1-oz parcels is much higher than sending (1) 30-oz. parcel!



Packing capacities and packing container types also determine whether items can be shipped together in the same parcel for rate-lookup purposes. Suppose you have Product A configured to ship in a Regular Box with capacity of 2, and Product B also ships in a Regular Box with capacity of 4. If an order comes in for (1) unit each of A and B, we would look up a rate for the total weight shipped in 1 package, since the empty "slot" in A's box could be taken up by 1 unit of B. Our Tube container types also have the ability to consolidate from smaller tubes into vacant space in larger tubes; in the previous example, if A used a Large Tube and B used a Small Tube, an order for one of each would be consolidated into 1 Large Tube.

Thanks Tyson - I understand how to structure flat-rate containers, and your new upgrades are an improvement. However, I still have complaints about your shipping structure.



The problem that I have with your system is that it does not mirror the real-life decision-making process of how professional shippers in the real world determine the cost of shipping physical objects.



As a professional shipper, I follow the following decision path just within a USPS shipping calculation:

*All of the items ordered will, by default, be shipped TOGETHER

*The number and size of the items DETERMINES the general container size into which they are all placed.

*Having determined the general container size and weight, I compare flat-rate types with per-ounce types to determine the least expensive option. This is not necessarily completely straightforward, as a zone 1, <2lb package could be cheaper to ship by per-ounce rate, while the same package to zone 8 could be cheaper to ship by flat rate.

*This is further complicated by the fact that if I have single (or multiple) items under 13oz shipped, then the intelligent choice is to ship them by 1st Class - even though adding additional quantities of the same item may push the shipment into Priority.

*More additional items may further push the package into Large Priority flat-rate box.

*If the total size of the shipment exceeded what I could ship in the largest Priority box, I'd probably ship by ground.



Using all the criteria above, I stock padded envelopes in 5 different sizes, as well as a complete assortment of both Flat-rate and non-flat rate Priority boxes and envelopes. And then, I ship using the method that costs both myself, and my customer, the LEAST amount of money for the service provided.



This is because I'm not in business to support the Post Office by paying any more than I absolutely have to, nor to bankrupt myself by adding on the endless labor costs of shipping say, 27 items in individual packages.



I started running a shipping department in 1982. I understand that your company, as programmers (and being founded by someone who sold digital products) may not truly understand the needs of people who ship physical products.



But the purpose of programming computers is to MODEL real life and remove endless duplication of efforts. It is not to force people in real life to go through endless jiggery-pokery and fudge factors attempting to make the results of the programming come out somewhere near real life. And that it what I feel like, when I attempt to set up shipping rules in your system.



So, I'm asking for SCALABILITY. Real life shippers don't say "30 of this item will fit into a 3"x9"x14" box, so I'm going to ship any number of items between 1 and 30 in the exact same box". Frankly, that's just stupid. They vary the container according to the shipment size, which is done within the blocks of items which will fit into each larger container. Then, according to THAT result, they determine the cheapest way to ship by comparing alternatives.



Thanks.