Skip to main content
Topics#Enterprise ArchitectureDeveloper Aviva's Question
Developer Aviva asked in #Enterprise Architecture
Jul 3, 2015, 3:23 PM

Be or not to be: PriceBook dilemma

Hello folks,

I've come to you looking for help in finding a solution so let me clarify the big picture here:

A project that I am working in has a special business requirement on pricing. I have 8 PriceBook levels (record types), each level corresponds to a specificity that will be relevant when ordering products. 

For instance, we have the level 1 (less specific) that is a common PriceBook with normal pricing and we have the level 8 (more specific) that has a special discount per client (Account Lookup in PriceBook Entry).

The big problem in having different pricing per client is that I cannot add the same product to a Pricebook even though each record is linked to different clients.

Owing to that, now I have to decide whether, Option 1, to create a custom PriceBookEntry object linked (lookup) to a PriceBook or, Option 2, to create one PriceBook per Client (e.g.). 

Regarding option 2, considering that I have 8 levels that can result in a expressive amount of PriceBook records and that the program will have to manage all that information when ordering products, I am inclined to opt for Option 1 but I am also concerned as it is not a native solution that will require custom development as well.

Any piece of advice on that?

Many thanks in advance.
1 answer
  1. James Loghry
    Jul 6, 2015, 10:28 PM
    Not knowing how many products are in your system, I would opt for the native functionality with products existing across different pricebooks.  This comes in handy especially when dealing with opportunities, campaigns, quotes, etc.  Otherwise, you'll need to do EVERYTHING custom, including a custom pricing engine to figure out the pricing structure.  In the custom scenario, you're looking at triggers, visualforce, supporting multiple locales, etc, and it can get expensive real quick.  That's my .02 worth, though.
Write an answer...
0/9000