Price Lists Query

Epicor ERP 10
1

Hi Guys
We have been using E10 for about a year now, and, with staff changes, I am getting more involved. I have a bit of a query re pricelists

We sell to trade, but, we also have an outlet that is B2C, so, all our pricing is trade. I know about creating discount pricelists, but, is it possible to create a pricelist that is the opposite? So that team can add lines and it brings up the RRP? This would be pricing higher than standard

Hope that makes sense?
J

2

Hi and welcome!

I think most of the time your B2C price would generally be the Base Price on the Part and then your price list would reduce or replace that base cost based on which type of Price List it is.

With that said, if the Price List is set to Unit Price, you can make the price anything you want, so I don’t see why that couldn’t do what you want. Try it out in a test environment, but I think it will do what you want.

2 Likes
3

I second @Chad_Smith’s comments.

I wouldn’t think of them as “discount pricelists”… they’re just “pricelists”. They’re meant to provide different pricing to different Customers, or Customer Groups.

There are various types, “Discount”, “Unit Price”, and “Both”.

So, instead of making your new pricelist a “Discount” List, just make it a “Unit Price” List and assign it to the B2C customers and that’s what they’ll see.

2 Likes
4

Thanks guys, really appreciate that, I thought it would be possible

1 Like
5

price lists can be “stacked”, but this sets a hierarchy of prices… Lets say that you have multiple price lists, and you have assigned them all to one customer (or customer group)

price list Expires Type Name
HOTPL1 date in the past price list May HOT SALE Price List
HOTPL2 Future date price list August HOT SALE Price List
DPL2 Future date price list Distributor Price LIst
DDL2 Future date Discount Distributor Discount
RPL1 date in the past price list Retail Price list
RDL1 date in the past Discount Retail Discount
RPL2 Future date price list Retail Price list
RDL2 Future date Discount Retail Discount

What the system generally does, is it searches from the top down and stops searching when it finds both a price and a discount to apply. For example, someone purchases a part that is on the HOTPL1… it will skip that price list because it is expired, and then look in HOTPL2. If it finds it, then it takes that price, and continues looking for an active discount price list until it finds one and then stops.

IF after all the searching it doesn’t find a price, then it falls back to the sales price that is stored in the part table (bad in my opinion, but that is for another day).
So, in my opinion, it is best to create a “retail price list” that is all-encompassing, including ALL part numbers. This price should be the fall back (bottom) price that is included to all customers & distributors. Then you also create special price lists that are put in front of that base price.

2 Likes
6

Hi @timshuwy
If you wouldn’t mind doing so today, would you please explain why you recommend this all-encompassing base price list and suggest not storing the base prices in the Part.UnitPrice fields?

7

One reason is that it’s a LOT easier to update.

1 Like
8

@Ernie stated it correctly… if you create a single base price price list, and apply it everywhere, then you can easily update the price list (without DMT) using the price list export and import functions. Since the price in the PART table is simply a field, it does not support this easy update, AND it is open to everyone who can edit parts, vs a price list which you can protect to specific individuals.
It also allows you to do something else which I have done.

  1. we HID the price in the part table from anyone to change
  2. we left that price at ZERO, and even made a BPM that prohibited it from being updated, so that it STAYS at zero.
  3. we also made a BPM that fired when you sold an item for zero (because there was no price defined) that required you to confirm that you really wanted a zero price. (hmmm… maybe the BPM looked to see if there was an actual price list assigned in the OrderDTL?)
2 Likes
9

We update price lists routinely, with DMT, and updating Part.UnitPrice fields, with DMT, seems like it would be just as easy. However, I definitely get your points about access to that field being wide open to part maintainers and access to price list being more restrictive. We’ve had that discussion here, so that’s why I was asking for your feedback. Thanks!

10

We don’t use the price on the Part table and haven’t created a ‘retail price’ list either as our parts are really customer specific but we do have a BPM on invoicing that will pick up any zero prices

11

This is all really REALLY helpful. By using the method here, will it speed things up? Our system starts creaking when an order reaches 5 lines! I think its all the ridiculous calculations that were put in, as an example, it does this below. We are having this setup removed, but, i think its part of the problem I am having. It really shouldnt be this slow eh?

I do notice below, its starting at part price, but then best price. Does best price have to be included? Because, when I create the relevant pricelists I want it to take from that, I will just have
1 - Wholesale Pricelist (for 90% of customers basically)
2 - Class A Pricelist (for the major customers, just a 10% discount)
3 - Retail Pricelist (for our B2C accounts, there are 4 use this)

Part £4.56 4.56 GBP Part
Customer Price £0.00 0.00 GBP Not found
Customer Discount Price £0.00 0.00 GBP Price List: GDS-D expired
Customer Discount Price £4.56 4.56 GBP No price found
Group Price £0.00 0.00 GBP Not found
Group Discount £0.00 0.00 GBP
Best: £4.56 4.56GBP Part