Evaluating AbleCommerce, and disappointed - an honest review

[jasonhendee]

As a current AspDotNetStorefront user, my evaluation of AbleCommerce started out very positive. I was blown away by how things "just worked" out-of-the-box with this shopping cart, how well-commented and structured the code is, and also by how many features are included. This software, as a whole, is a HUGE improvement over the poorly coded, poorly organized and poorly commented / documented "competitor" that is ADNSF.

The problem, however, is this: the way that the folks at AbleCommerce chose to implement volume discounts is very different. Every cart I've worked with in the past shows product discounts inline - that is, the price of that product itself is discounted and reflected on that same line item. But the way that AbleCommerce chose to do this is to show the product with the base price on its own line, and then show a SEPARATE line item PER ITEM for the discount. This seems very messy to me, makes the cart details very difficult to read, and integrates very poorly with my order management software: Stone Edge Order Manager.

To take Stone Edge out of the loop, I honestly can't see this approach integrating cleanly with any order management software. And make matters worse, a few hours of searching through this very forum has shown me that there are quite a few users unhappy about this method of discount presentation - is AbleCommerce listening to these complaints?

I understand that some basic modifications can change the way these discounts are presented to the UI, but what concerns me is that the integration with Stone Edge is a much more complex fix because of the way the data is stored across multiple tables. So, as much as I truly want to use this shopping cart for so many reasons, I just don't think I can make that recommendation to my boss and colleagues at this point. We are a company that has offered site-wide quantity discounts for the 8 years that I've been with the company, and I don't see us getting away from them anytime soon.

Believe it or not, this one facet of the application could be a deal-breaker. Am I crazy? Is this an easier fix than I see it to be at first glance?

[Logan Rhodehamel]

Thank you for the honest feedback. I suppose there are reasons we have the discounts held on it's own line item in the basket. Speaking from memory it has to do with some of the features we have to accommodate... for example multiple shipping destinations and tax calculations.

It is always the case when looking at a specific merchant, some of those possibilities can be eliminated. If you had the source code to AC7, there is a class called DiscountCalculator that handles this step of figuring out the discounts and creating the line item. I can't really say what the impact might be if someone modified that code such that the discount were stored inline with the product.

It might be something we can reevaluate - whether it is necessary to keep the discounts separate or if the same features can be provided with inline discounting. Is there anyone else who wants to offer an opinion on this as a pro/con to the AbleCommerce basket handling?

[jasonhendee]

Logan,

Your response to my post is very refreshing.. and intriguing. I guess I'm used to software companies having a very firm stance on why something is the way it is, and having no interest in changing things. If AbleCommerce truly listens to these these types of challenges, and is willing to implement some changes, let's just say you have my attention.

If we moved forward with AC, we did have plans to purchase the source code. I guess without having access to the source at this time, and without knowing how deeply rooted this discounting approach truly is, I didn't want to assume that it would be a quick fix if & when we actually got our hands on the source - hence my "deal-breaker" attitude above.

I will be very curious to see what others have to say, and also how quickly a change could be implemented if the concensus was to move forward.

Thanks - Jason

[jmestep]

We have customized display code so that it rolls the discount into the product price on the display and I don't remember using the source code to do it. Also, some merchants want it rolled in, some don't. Some want to see how much the discount was for their records.
But I do recommend that you buy the source code if you're going to be doing much. For the price, it is a gold mine and there are times when we have just lifted part of it out and created a new class, for example, we adapted the product search to make a webpage content search. We have found that in some cases that is so much easier than trying to put code on pages to circumvent what Able is doing. We have created a custom discount class, for example. The client wanted discount rules to apply that were different from Able rules and on things like discounts and coupons, Able has so much validation going thru the checkout process that it's just easier to replace a couple of lines calling their classes and use ours.

[jasonhendee]

I'm somewhat surprised that no one else has responded to Logan's question, considering the number of threads in this forum I found where people were asking how to change the discount displays in various places (minicart, cart, invoice, etc).

Anyhow, I think we are going to continue moving forward with AbleCommerce. While this is still a pretty big deal, Logan and Judy's responses suggest that it shouldn't be that hard to at least venture down the road of changing the discount displays (and more importantly for me - the storage of discounted prices). I guess I would just rather the folks at AC make these changes to ensure I don't miss anything. But let's face it - seeing as how this is the biggest hurdle I've found so far, this cart as a whole is a VERY drastic change from AspDotNetStorefront - especially since this isn't really a bug, but rather a different way of approaching the complicated world of discounts.

I honestly continue to be impressed with most other aspects of the application. There have been several instances where I've gone in to change the code for one reason or another, and instead have been pleasantly surprised to find that certain methods or properties already exist, and all I have to do is call them, or call them a slightly different way. The organization and commenting of the code is truly top quality. I can already tell that I'm going to sleep much better knowing that my company has such a solid framework at the core. Seriously, I cannot tell you how many times AspDotNetStorefront just "breaks." Why should I have to spend my time fixing their careless mistakes? I'm really not trying to slam them, but that's my real review in the few years that I've used their software.

But to get back to the reason I started this thread originally... does anyone else agree that the discounts would be much more usable if stored and displayed inline instead of on separate line items? I really appreciate that Logan asked that question, and don't want to miss this opportunity to potentially get a change in place. Anyone?

[jasonhendee]

Oh, and one more thing - I really appreciate that my posts in this forum don't have to go through an approval process! I posted once in the ADNSF forum, and my post didn't actually appear publicly for several days. Thanks for not trying to hide user's opinions, AC!

[jmestep]

Personally, I would like it rolled into the price, but some merchants wouldn't and I have worked with merchants that don't want it rolled in or don't care. There might even be a state tax issue involved. I think with some states, they want to charge tax on the total before discounts, coupons, etc.
Able has different ways of displaying tax based on merchant settings, so maybe they could add a configuration option to roll the discount into the price or show it separately.

[AbleMods]

does anyone else agree that the discounts would be much more usable if stored and displayed inline instead of on separate line items?

"more usable" is unfortunately completely relevant to the "use" involved.

In my situation, I need discounts separated in some form or fashion for accounting purposes. From an accounting perspective, you have to record discounts to a separate GL. If they aren't separated from the product charge, I have no way to post it correctly to QuickBooks when my QuickBooks module transfers the data.

From a display perspective, again it's relative to the use. Some businesses prefer discounts inline so the price shown is the final price given. However others want it separate so their customer sees the benefit of purchasing from their store immediately and visually.

Since the data itself is stored as separate line items, and it has a ParentId value corresponding to the line item that generated the discount, it's relatively simple to change the basket displays to render a new column for discounts. This gives the illusion of inline discount amounts while maintaining a cleaner basket appearance to the shopper.

For me personally, I like it displayed as a separate column on the same line item instead of a totally separate line in the basket. It looks cleaner. It's easier to read for the shopper. And mathematically you can easily go left-to-right on the basket line item to see exactly how the system arrived at the final price.

[jasonhendee]

does anyone else agree that the discounts would be much more usable if stored and displayed inline instead of on separate line items?

For me personally, I like it displayed as a separate column on the same line item instead of a totally separate line in the basket. It looks cleaner. It's easier to read for the shopper. And mathematically you can easily go left-to-right on the basket line item to see exactly how the system arrived at the final price.

This doesn't sound bad - I would be happy with discounts being in a separate column of the relevant product line. I think the biggest reason I don't like discounts being in a separate line item is because of how Stone Edge Order Manager imports them. The products are imported first, and then the discounts are imported one by one, with no real clarification as to which discount belongs to which item (they all simply say "Discount" for the SKU, and the name of the discount for the product name, i.e. "Reseller Discount" or whatever label you apply to the discount within AbleCommerce). So the only way to truly know which discount belongs to which product is to do the math. And when there are backorders in the mix.. well, it gets messy.

So perhaps its fair to say that this is more a problem of how Stone Edge imports the orders than a problem within the shopping cart. But at the same time, the two most recent carts we've used before AbleCommerce (MonsterCommerce and AspDotNetStorefront, respectively) have stored the discounts inline, but were also able to show the regular price in one column, and the discounted price in a second column as AbleMods is suggesting. To me, this is the best approach. It shows the customer the value, creates an easy-to-read basket, and integrates nicely with order management systems.

[AbleMods]

So perhaps its fair to say that this is more a problem of how Stone Edge imports the orders than a problem within the shopping cart

To me it seems this is more the case than anything else. The key fields necessary to compute it into a single value are there, StoneEdge just doesn't process it.

I have the same issue with Sales Tax and my QuickBooks module. Sales tax is stored as a separate line item as well. So I have to use special handling to process it correctly into QB.

The underlying design that Able uses is the result of offering both product-specific discounts and store-wide or basket-wide discounts. Some discounts can easily be applied to a specific line item. Others are based more on basket total or overall volume. At that point your computing against an aggregate total instead of any specific item. So it becomes more difficult to assess those aggregate discounts against individual line items and store them accordingly.

[deverill]

Hi Jason, to answer the question you and Logan pose, it really doesn't matter to us either way. We are doing so much customization, and our business rules are so far removed from a typical store, that we'd have to modify it regardless.

Were I to be coding a typical store I think I would prefer the way you mention but also see merits for the current method so it would not be a vote either direction from me once you consider 'retooling' costs to change AC and all their customers that may be using that feature in a non-standard way.

Jim

[jasonhendee]

... If you had the source code to AC7, there is a class called DiscountCalculator that handles this step of figuring out the discounts and creating the line item. I can't really say what the impact might be if someone modified that code such that the discount were stored inline with the product...

Follow-Up to my original complaint (regarding discounts being added as a separate line item, instead of being applied on the same line as a discounted product):

Logan's suggested fix location was spot-on, and this proved to be a very easy modification. The encapsulation of the application as a whole is so well done, that the folks at AC have made it very easy to apply what might initially seem to be a deeply-rooted modification. Thanks Logan, and all AC developers, for making a great quality product! I look forward to jumping into other modifications, now that I've seen how incredibly clean your code is!

If you want to see this mod in action, click into any product (most standard products on our site offer a discount), and add different quantities to see the discounts applied / displayed in both the minibasket and cart item details:

http://www.cablesforless.com

Since the discounted prices are actually being stored in the db (and not just altered to display properly on the front-end), these discounted prices import properly into Stone Edge Order Manager, making a very clean integration!

[plugables]

Now you might consider changing the title of this post ... it could be misleading for casual reviewers.