added adding admin always cart changed clicking code customers delete disable item items likely listed lot menu method notice orders page preferences previous previously product products require sales seller sending settings site standard submit support system third-party wait wish

There is no such thing as a dumb question, right? Well, here is mine.

On the Cart Preferences menu, regarding containers, are the ounces listed the weight of the tube/box/envelope or the amount of ounces each can contain?

That's the weight of each container :)

While adding a product, you can specify how many of each item you can fit in the type of container you will use for that particualr item.

Not a dumb question at all... I spent a while trying to figure out what that meant as well and sent this same question to E-junkie via e-mail.

I'm thinking there needs to be a little better explanation in the Shipping FAQ section.

Good. Thanks.

So my follow-up questions are regarding the Shipping Options page in the item-specific section. I'm given the option of adding ounces, packaging type and packaging capacity.

The item I'm shipping is a 6 ounce book. The smallest container I use, a small envelope, will hold two books. I entered that into the shipping options page. I can get 10 books in a small box. After I submitted the small envelope info, I went ahead and added the small box and submitted this even though this did not indicate what packaging info was already associated with the item in the system.

I checked the code and it has changed ... now says resizeable, which I am figuring means the container. Is this correct? Do I then have to individually add and submit each container? That's fine; just want to make sure that's what I need to do.

Based on this, my assumption is that: To change a container capacity, I individually edit the specific container, submit it and override what was there previously. To delete a packaging option, I just put "0" in the packaging capacity field. Correct?

You can only associate one packaging type with a given product -- if you change those settings, then the new settings will override any/all previous shipping-packaging settings for that product.

You can either specify the smaller package you would use (e.g. the small envelope holding up to 2 books), or the larger package (e.g. the box holding up to 10 books). If you specify the smaller package and someone orders more, you can just consolidate into a larger box (rather than sending two or more envelopes :^) and pocket or refund any difference. If you specify the larger package and someone orders less, you can just ship in the smaller package (rather than sending two books in a larger box!) and again pocket or refund any difference.

I think it is fairly obvious that E-Junkie is geared towards digital downloads more than it is gear towards tangible good sales. While I do understand and respect that, I also wish for more support for those of us who sell tangible goods.

Things such as a discounted plan for those of us that do not use the storage space and getting that discounted rate that was discussed a while ago implemented. Other things such as a better way of keeping track of inventory much easier. For downloads, inventory isn't always a constantly changing parameter like it is for tangible goods. I know I spend a lot of time just clicking around my admin panel just trying to update my inventory.

Also being more on topic, the shipping is VERY basic. I have read many questions as to why things are the way they are when it comes to shipping here in the forums. The answer is that the system was never really optimized or geared towards shipping tangible items. At the very least there should be much more control over how the shipping is calculated. For example it would seem that having more than one shipping method available would make sense. What about the customers who want their products in 2 days and are willing to pay for the shipping? Most likely they will go to another site that offers a shipping service that is faster than Priority Mail. If you dont want to add another carrier, at least consider several options for USPS. Rate tables are available via USPS website!

This is more a general plea for more support for those of us who sell tangible goods. Like I mentioned before, E-Junkie is geared more towards digital goods. I love the shopping cart and love the service, I just would like to see more effort put into a few enhancements for everyone, including the tangible goods crowd!

(getting off my soap box now.....)

You are correct in that E-junkie originated as a digital-commerce, download-fulfillment application first, which later grew from that basis to facilitate shipment of tangible goods as well. However, even then, we were primarily catering to indie creative types (musicians, artists and artisans) and eBayers, who would all be shipping only one or a few items out at a time. Thus, our mantra of simplicity dictated that a basic shipping calculator would meet those needs, using either USPS rate tables or optionally following this basic formula:

((product wt. + package wt.) x (cost per oz.)) + (package cost) + (handling cost)

To disable USPS rate-table calculation, either set all your weights to 0.00, or omit your zipcode as the Shipping Origin from your Seller Admin > Cart Shipping Settings. You may notice here that, for Priority Mail shipments that fit into the standard flat-rate package categories, you can simply leave all the shipping-related settings at 0.00 except for the "package cost", which you would set as equivalent to the Priority Mail flat-rate for that size of package.

We may consider enhancement of our shipping calculation to include other carriers in the future, but for now that's not something we can easily just "bolt on" to the existing E-junkie platform. Implementing a more complicated dynamic lookup (probably interfacing with a third-party API) -- such as would be required for UPS or FedEx (whose rates all vary considerably depending on weight, size and distance, among other factors) -- would require substantial reprogramming of existing code not to mention additional code, so that's something that will probably have to wait until we tackle a ground-up "version 2.0" rewrite of the E-junkie codebase.