I started to comment on harrisben's note here: http://d7uc.org/node/72 but got a little off topic so I decided to start my own. I'm trying to be relatively comprehensive here, so comment if you need more info.

Philosophy

First, there are some philosophical differences in the way that Ubercart handles pricing from the reality of most businesses. Prices are typically not just a single field, but the complex interaction between multiple fields. Examples of this include:

• Price list variations based on role


• Price list variations based on user


• Unit prices varied by coupons, discounts, etc


• Unit prices varied by factors (dimensional data - think of buying a fence)


• Line totals varied by applied freight and tax

Price List Concept

In order to handle the first two bullet points above, we need to consider a set of pricing values for a specific product in ubercart to need to change based upon who is buying. This is especially true in the B2B world, and is relatively prevalent in the B2C world too. The concept of a price list is used almost universally in back-end systems that are often the driver for pricing decisions. By allowing multiple values for the base price of a item, and being able to easily sort, distinguish, and update these values, you create a system where you don't have to write custom logic and create custom fields each time you want to manage prices based upon who is logged in.

I'm not sure if this warrants its own object, or if we just need to create a way for pricing to hold multiple values and construct a system of views to be able to organize and edit them, but this would go a long way toward making it easier to integrate Ubercart with other systems that use the same principals.

Base Price Concept

As mentioned, pricing is really not just a static field, but the interaction of multiple fields. As such, it's prudent to think about the price that is originally assigned to an item as the item's "base price". This base price would come from a price list as described in the previous section. Then various manipulations can happen to that base price (i.e. a discount being applied). This creates the need for a second field (we'll call it "calculated price". This ability to have a base price, perform some logic, and come up with a calculated price, would be sufficient for about 80% of our client base. The next level would be this:

Have a base price, a calculated price, and then a total price. The total price would allow you to vary the amount of freight and tax applied to the row in the order, and assign it to that row. Often, this is used for costing in back-end systems, or because of clients that have complex reseller agreements or tax policies (tobacco products in California and agricultural products in Washington come to mind). Allowing for a way to assign both freight and tax to a line, along with discounts, and come up with a total price, would be robust enough to handle about 99% of the cases I can think of.

Discount Types

Also, I totally suppose where harrisben is going with his pricing ideas, but I think they're more likely to be used for discounts. In the ERP industry, we call what he's talking about here period and volume discounting:
* Quantity - should include a greater-than/less-than/equals modifier which will allow quantity-based pricing.
* Validity
o From date/time - if blank is considered from the beginning of time.
o End date/time - if blank is considered until the end of time.

Now, period discounts provide effective dating for pricing fields, whereas quantity price breaks come in two forms:

1. Quantity purchased discounts (buy 12 get the 13th free)


2. Threshold discounts (buy 10 and it's X/unit, buy 11 and it's Y/unit)

Having a way to set up and configure these in core would rock. Almost everyone does some sort of discounting or alteration of price at the time of order, and most of the discount modules that are out there are somewhat limited (hence, we usually end up writing our own stuff with just tiny variations each time)

Factors

Factors are a big part of most back-end accounting systems, and many businesses use them to sell items that are related but do not necessarily warrant different item types. The best example I can think of this is a fence. When you buy a fence, you are asked the total number of linear feet (factor 1 - material needed), the total number of corners (factor 2 - number of cuts needed), the number or frequency of posts (factor 3 - more materials), and the fence height (factor 4 - raw materials and more cutting). All of these are important parts of buying a fence, and factor into the price of that fence. Also, they're very inter-dependent, and it's difficult or confusing to have a customer choose multiple items to make the factor system work with the current model. Thus, by allowing factors in pricing we crate a more flexible and configurable way for businesses to create robust pricing for their customers.

This would require the most robust functionality of the base price concept talked about above.