Quote Update Unit Price

Epicor ERP 10
,
1

I’m banging my head against a brick wall trying to make Epicor’s quotes behave like our users want (long story, and pushing back hasn’t helped so I’m stuck with it). I’ve been down multiple routes but keep getting hit by E10’s insistence on re-setting the price to something other than that entered by the user.

I’m now trying something totally manual, mimicking the direct trace from the standard Quote Entry screen, just to try to get to grips with the problem, but doing exactly what the trace does still means the price entered is ignored. I can see a few previous posts complaining of similar problems - has anyone solved it?

According to the trace (10.2.200.24): set DocDspExpUnitPrice, call GetDtlUnitPriceInfo_User (which sets a lot of other fields in the changed row), then call Update.

From Quote Entry, the result is a new user-set price. With copy code, all prices are OK before the update, then re-set to the previous post-Update. Am I missing something?

2

Yeah setting the price on a quote is a damn nightmare. I believe I got around this by using the LockPrice checkbox (or something similar can’t remember the name of the control at the moment)
but I’d try that.

1 Like
3

I so wanted to be able to tick “solution”, but unfortunately that hasn’t worked for me. Thanks anyway. I’ll keep digging, since I don’t have the option of stopping.

4

Lock Price works for us. When is the price getting changed?

5

One of the user bugbears (not the only one) is that they hate Epicor hiccupping to check and save after each significant field change. For simple quotes they want to be able to blast on through entering everything and then save. (They also want to be able to re-order the lines at any point, not just for display but true line order which would carry through to a sales order, but that’s a separate issue).

My most recent approach, having had a few others rejected, has been via uBAQ. They can add as much as they like and change as much as they like, and the only user delay is when they save. But sometimes the price doesn’t save, it reverts to whatever it had been previously.

So I’m just testing the quote save process within the uBAQ code, replacing the UpdateExt with the standard Quote calls, using the BAQ results table as a template to update the Quote more directly. Again, it works for everything except the price, and in this case the price NEVER changes. Not even when following the exact sequence from a trace log and checking the data passed at each stage. And explicitly setting LockPrice doesn’t seem to make a difference either. There must be some other difference between server-based calls and client ones, I assume, but it’s proving painful finding what that might be.

6

I like the uBAQ approach. Can you just update the Lock Price earlier than the trace does it?

7

In uBAQ code it doesn’t seem to make any difference setting the LockPrice field at all.

What DOES seem to make the prices stick is to separately change QuoteQty first and call Update before stepping through the rest and Updating again. But the trace isn’t doing that so there must be a way of avoiding repeated Updates. I will say that two Updates are still quicker than one UpdateExt, though.

1 Like
8

I am feeling the pain on this also. My users are seeing prices wiped out (to zero) when they enter quantity. I have a solution (so far) but I don’t know if this applies to others.

In short, parts with “Run Out” checked in Part Entry are the ones that get messed up in Quote Entry. But I’d like to explain this a little more.

Oddity #1: Line number
So, a new line on a quote always starts out life as line zero until you save it.

For a part that behaves, as soon as you enter the part number, the line is saved and the line is given a real number.

For a run-out part, we get that warning. (“Part 90368 is being phased out. Good only while supplies last. Continue?”) After that, the line number stays zero. So I think the pop-up warning is preventing the line pre-save.

Implied here is that any sort of update BPM is worthless. The misbehaving parts are doing this before any save.

Oddity #2: The problem goes away if you save immediately
Kind of a corollary to #1, if you manually save the line right after entering the part number, Quote Entry honors the price. You don’t need lock price there unless you literally want that.

Oddity #3: LockPrice
I tried this BPM, but again, with no save, it’s worthless. So I tried manually setting it. (You can see it in the list view, way toward the right end of the columns.)

Without the record being saved, Epicor does not honor the lock price flag. So this is a non starter.

Oddity #4: The price itself
We use a base price list for pricing. So the price on the part is zero. I set my run-out part to $1.23 for testing.

For the run-out parts, at first I thought it was just setting the price to zero. But Daryl’s note made me investigate that. It’s actually pulling the Part table price ($1.23).

1 Like
9

The run-out bug is to be fixed in PRB0224113 (says it has been “accepted”).

@josecgomez See, I do report stuff sometimes…

2 Likes