function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
VPVP 

Multiple list prices for same product

How do we take care of a scenario where variations of the same product need to use the same product id but also need to have different list prices at the opportunity lineitem level. There is a list price at the opportunity level - but it seems to be read-only - any way to make that updateable from esp. from api?
ScotScot
The list price comes from the related PricebookEntry record. Because of this, I don't believe there is any way to set it in an opportunity differently.

The two methods I've used for this are:
1) To use a different price book with the referencing the same product.
2) To make several "products" with the same product code

An example of method 1) is two pricebooks:
Direct Sales
Reseller
Direct sales might have a list price of $30.00 for widgets, while Reseller might have $17.00 for the same product. Each opportunity, of course, can only choose line items from one of the price books. Both books reference the same "widget" product record, with the same code and description.

We used method 2) to handle other distinctions, such as a software license which can be either per-seat or per-user. Example:
SE-ABCD-S is the ABCD product, in the per-seat license,
SE-ABCD-U is the same product, with a user-based license.
These are two different product entries in the product table, thus they can both appear in the same price book, and can have different list prices.

While it would be possible to give both the same product code, I find it clearer to have each product table entry have a unique code. In order to enable reporting for the ABCD product, however, we have custom fields in the product record to calculate summary codes. For example, for both the codes above,
Product Group = SE
Base Product = ABCD

Ours are stored; today you could probably define these with calculated fields instead.
VPVP
Thanks...I was actually contemplating the second method - but the concern is that with the number of variations, the number of product and pricebook entries might go out of control.
ScotScot
A very good concern!

It gets even worse if you have multiple currencies ...

I ended up with enough redundancy that it proved worthwhile to build a spread-sheet to maintain the products and pricebooks. That way, I work with a smaller source list, and generate the larger number of entries (3-7 salesforce products for each "real-world" product, with 6-9 pricebook entries - including different pricebooks and 3 different currencies - for each of those ).