Discount module - Any patch on this module?

Thanks for the info. I saw references to the checkout api in CVS, but not in the 4.6 release.

A few question:

Is the CVS version of the ecommerce module currently drupal 4.6.x compatible?
Do you have any idea when the checkout api will be finished/stable (if it's not already)?
Does this fit into the bigger ecommerce module picture in a way that you see as useful?

Thanks again!

I thought of two more ideas for this module:

1. Provide a list of required product types to be purchased as a group.
e.g. "10% off all orders when you purchase a lamp with a chair"

2. Indicating the discount on the cart page. This could be made generic for price adjustments. Basically, it would add info to the cart page indicating which discounts were applied, what they were applied to, and how. This would render differently for Product discounts as opposed to Gross Purchase Price discounts and Category discounts, etc.

..and to incorporate the role-based discounts, if the person editing the discount has "administer users" priviledge (would this be necessary?), offer a list of roles that the discount applies to.

Just some thoughts.

I've started work on this as a 4.6 module. I have a heavily customized 4.6 ecommerce setup, but I'm hoping that at least the discount.module should remain..well..modular. I also intend to keep its functionality abstracted enough to easily transition to the checkoutapi, etc that the latest ecommerce version is using.

Seeking advice..

I've compiled the basics of the module, but the longer I work on it, the greater the complexity grows.

I have the "order total"-based filter implemented such that discounts are applied to the order total (as opposed to an individual product's price or applying to products in a specific category). For auditing purposes, I feel the need to store the results of applying the discounts along with the transaction. Additionally, I'd like to store shipping costs there as well. Would it make sense to organize all of these price adjustments into a common format?

Here's an example of what I'm talking about:

qty               item                         price
-------------------------------------------
2             big widget                     $5.00
* Discount: 'qty > 1 save 20%'       -$1.00        -- product-based discount
1             small widget                   $3.00
1             red gizmo                      $6.00
Subtotal:                                    $18.00
==================================
* Discount: 'total > $10, $2 off total'     $16.00  -- total-based discount
Shipping:                                         $10.00
Total:                                              $26.00

Would it make sense to store all of this data with the transaction in the same way that products (items) are currently stored? This would allow you to reconstruct historical orders after shipping costs and/or discounts have changed. Is there a preference whether this would be serialized data vs. independent db tables?

Currently, the ec_store_transaction_product table looks like:

+---------+------------------+------+-----+---------+-------+
| Field   | Type             | Null | Key | Default | Extra |
+---------+------------------+------+-----+---------+-------+
| txnid   | int(10) unsigned |      |     | 0       |       |
| pid     | int(10) unsigned |      |     | 0       |       |
| title   | varchar(128)     | YES  |     | NULL    |       |
| details | varchar(255)     | YES  |     | NULL    |       |
| price   | decimal(10,2)    |      |     | 0.00    |       |
| qty     | int(10) unsigned |      |     | 0       |       |
+---------+------------------+------+-----+---------+-------+

Should this be expanded to include more generic order details such as those mentioned above? This could tie into the price adjustment api, too. In my current implementation, I've created a separate table that holds minimal discount details associated with a transaction, but I see a pattern here that could be made more general-purpose.

(btw, apologies if my illustrations look wonky. The 'preview' option here on drupal.org doesn't appear to be working today.)

Thanks for the input. Unfortunately, the only real promotion/discount that I need for the site I'm working on is order-based, not product-based. Also, for my purposes, I'm sending orders off to another existing backend system for fulfillment/processing and only using Drupal's e-commerce modules as a frontend. Somebody else is handling tax allocation ;)

As for logging transaction details, option 1 seems like the more flexible arrangement. That way, store.module can develop a transaction API for loading/saving transactions. The discount module could implement a hook that would store extra transaction details in a separate table. This would mean that store_transaction_save($edit) could call something like

module_invoke_all('store_transactionapi', 'update', $edit); and
module_invoke_all('store_transactionapi', 'insert', $edit);

Loading transactions could involve the invocation of something like
$data['extra_details'] = module_invoke_all('store_transactionapi', 'load', $txnid);

I basically have code in all of those locations persisting the discount data, but I think this could be made much more generic with something like this. I do have concerns of how this would impact other parts of the ecommerce modules. For instance, I've had to rewrite the cart/view pages (as well as the block) to accommodate these details. Also, I wonder how useful it would be given the transaction array's current structure - with products as items, shipping_cost, etc. all being pre-defined elements. There would be a lot of things rewritten to use this.

For instance, calculating the total would involve all of these plus the items array.
items + product adjustments + order adjustments + tax + shipping = total

I could see creative vendors wanting other means of adjusting prices, and this could document those adjustments.

In my mind at least, this seems like the way to go. I just know that I don't have enough time (or background knowledge) to rewrite all of the pieces of the ecommerce modules to utilize the reorganized data structure. Also, I haven't looked at cvs/4.7 lately, so something like this might be irrelevant for that.

That's where I'm heading with the module. For reference, here's what a discount currently looks like on my dev site:

Title:
Save 10% off your order when you buy 2 or more XYZ products

Body:
fpo discount copy

Deduction Amount:
10.00

Discount Type:
percent

Price From:
175.00

Price To:
-1.00

Start Date:
2005/01/01 00:00:00

End Date:
2006/12/31 23:59:59

Applies To:
order totals

Exclusivity:
always apply discount

Weight:
0

Additionally, making this Discount node a member of a particular category will restrict the application of this discount to that category. This allows you to filter the application of discounts based on date range, taxonomy and price. The discount can be applied to product price or order total. Giving a weight to the discount sets the order in which multiple discounts are applied, and the exclusivity parameter allows you the option of only applying the first matching discount.

I think this would cover a lot of circumstances. The only one that I haven't yet given a lot of attention to is the per-product discount. I don't think that would be too dificult to implement, though.

Unfortunately for me, my client seems to be reluctant to pay for the ecommerce site that would be using this module. I'm therefore losing motivation to continue development on it. I will post the current working version of the module and a patch of all required ecommerce module changes against the latest 4.6 branch soon.

This is only the module, and not any of the required ec module changes required to use it. I haven't fully documented it, either, but I suppose it'll have to do for now. I'd like to put together a patch with all of the minimum changes required to use it, too. That'll come later.

db schema