always apply automatically available built buy centrally-managed code common correctly course customer customers due example feature features fee including issue item items limitations lower merchant offer order page problem product products require sell service setting software staff system try wanted working

Hi there,
I thought I had this figured out, but then one of my customers emailed me and said it wasn't working correctly.

I sell custom printed shirts at http://NoMinimumScreenPrinting.com .

I built a really slick order building process using the awesome e-junkie service that you guys provide. The customer adds three main items to their cart for each order they submit: Job setup fee $35, blank apparel items ranging from $11-31 (tshirts, sweatshirts, etc), and then they add printing fees (for this item I used product variations with unique prices and SKUs).

For the blank apparel items, each item, such as a tshirt, has 2 variations which tell more about the product (they do not change the price): size and color.

I wanted to give customers an automatic discount when they order shirts to be printed in bulk. But I only want this discount to be applied to the prices of the blank apparel items, not the printing charges or the Job setup fee.

So I went and created individual item discounts for each of my 13 different apparel items. For example, when a customer adds 12 or more of a certain type of tshirt, a 15% discount (which I converted to a flat amount for individual item discounts of course) is automatically applied to those 12+ tshirts.

I understand that the customer will have to order 12+ of the same type of shirt, aka the same item, the same SKU, and not 6 of one type of shirt and 6 of another type of shirt, as that would be two different items (2 different SKUs) in the cart.

However, the problem is that when they try to order 6 Larges of one type of shirt and 6 XL's of the SAME type of shirt (with the same SKU), the 12+ discount is not applied, even though they have ordered 12 of the same item. The only difference is that they have selected a different size through the Variations (not variants).

Am I to understand that for the e-junkie item discounts to be applied, they must order 12 of the same size and color of each shirt? Even though the size and color options are only variations which tell more about the product and not variants which have individual SKUs?

Is there a way to work around this? Am I missing something?

Thanks!

Yes, the product specific discount requires the discount to be the exact same, including the having the same options selected. Even though you are using variants and the products have the same SKU, they are different products and our system sees it that way. I'm sorry but there is not a work around for this.

I have the same problem. I offer a product with several different color options. I want to give a discount if they buy 2 or more sets of this product. But if the customer selects a different color for each set, then the discount will not apply, even if they buy 20 sets!

There should be a check box in the discount creation page that says "Ignore Variants for Discount Code".

Anyone have some creative ideas around this?

http://www.bagtoss.com/accessories.htm#bagsets

As the Ninja said before, unfortunately, there's no getting around that limitation. The only way to get a discount to apply to every line item in the cart is to use a cart-wide all items discount.

A product specific discount with a quantity setting cannot recognize the same product that is listed on different lines in the cart due to variations.

there is always a way to get around software limitations. just a matter of priority, skill set and funding. i'll assume it is a priortity issue.

True, every business has to operate within certain constraints and tradeoffs. Our budget for staff funding is constrained by our revenue minus hard costs, which in turn requires prioritization of the limited man-hours we have available to allocate for the limited number of Developers we can afford to employ with the skill sets we can afford to pay for.

Development prioritizes new feature requests according to broadest potential benefit and the simplicity of programming them into our existing codebase and systems. Because ours is a centrally-managed service that is shared in common among thousands of merchant subscribers, it's impossible for us to make a modification for one merchant that does not also affect all other merchants, so we place the utmost importance on maintaining bug-free stability for all merchants using our system.

Greater priority is given to popularly-requested features which many or most merchants could benefit from, and which can be written into our existing system fairly straightforwardly with minimal risk, whilst lower priority is given to features rarely requested and of benefit to fewer merchants, or which require substantial reprogramming or complexity that may introduce new bugs or instability problems in well-polished and stable parts of our existing system.