I have encountered an issue with the PQuoting line system.
Enter in “Part 1” into PQuote and line autoloads price for “Part 1”
If You change the line item from “Part 1” to “Part 2”, cost pricing from “Part 1” stays behind.
This has lead to when I’ve changed product lines, them being submitted to the vendor with incorrect pricing. Obviously this isn’t as bad of a problem is the price is lower, then the vendor just let’s us know to update the price. But if the price is higher, an untrustworthy vendor could easily overcharge us for the product because of this update error.
Thanks for reaching out, Spencer. I’m sorry you’re running into this issue and it makes sense that you wouldn’t want to send an incorrect price out to a vendor.
Unfortunately, updates to existing rows on that page do require a manual update to cost in order to prevent unwanted updates to special case costing/pricing. A workaround would be to avoid changing a line item from one part to another, and instead delete the unneeded part and then add a new one.
I’ll also have our engineering team take a look at this just in case this is something that can be changed.
“Unfortunately, updates to existing rows on that page do require a manual update to cost in order to prevent unwanted updates to special case costing/pricing”
This doesn’t seem to apply to what’s happening because if I completely change the part record line item, why should special case pricing still apply to the new item?
I guess what I’m asking is, in what case would replacing a component keep the pricing of the old component?
I talked to our engineering team and this was their response to your question:
The reason we don’t change the cost is, what if you choose Part 1 and Cetec defaults the cost, but then you find out by looking on the website that the cost is lower. So, then you modify the cost manually. Then if you change the line to part 2, you may or may not want the cost to change.
They also plan to look into this issue and consider whether a change in the software is needed here.
I circled back with engineering and it sounds like, after discussing it, they decided against changing the software in this case. The reason is that the pattern in place is for the system not to override someone’s data once there is a value; they aim to make that consistent across the Cetec software. And making this change would affect many other users.
However, you should be able to avoid listing incorrect pricing data by deleting the first part entered and then creating a new entry for the correct part rather than changing a part that was already entered.
“The reason we don’t change the cost is, what if you choose Part 1 and Cetec defaults the cost, but then you find out by looking on the website that the cost is lower. So, then you modify the cost manually. Then if you change the line to part 2, you may or may not want the cost to change.”
This logic doesn’t necessarily follow. I don’t see how in this case this makes any sense for the line cost to stay the same when you change the line to part 2. You looked at the website, noticed part 1 was wrong, adjusted the price, and then for no reason changed the line to part 2 and want the cost to stay the same?
I apologize for seeming a little disgruntled but I have posted too many bugs on this forum to get fairly complacent excuses to not change logic errors. It’s just a little frustrating when you try to help improve a platform by bringing up the flaws within their programming and are told that there is no error when obviously there is.
There is no instance where I would ever be changing a part and want the cost that I put in that line to ever stay the same and I can’t imagine one either. It would be one thing if the scenario you provided made sense but it doesn’t and isn’t a real world applicable scenario.
I really do enjoy using CETEC and I think that it is a powerful platform that has a lot of potential, but I have to admit, with the intention of wanting CETEC to be everything that it can be and more, that the kind of user support CETEC offers leaves a lot to be yearned for when every bug report I submit is replied to with “everything is fine and this is the way it’s supposed to work”.
I found an instance where the programming functions like it should as reference.
When I am in a PO and I edit a line and replace it with another part record, it replaces the Cost as well. This is how the PQuote lines should function as well.
The use case we are attempting to protect here is as follows.
Numerous Cetec ERP users do not have any pricing pre-loaded in any pricing table, i.e. “blank” pricing for part numbers. These users enter their pricing manually on line items each time.
If that is the case, and in the instance when a user has spec’d out a quote line… and then at a later point that user goes in and modifies a part number to a different part number that has “blank” pricing, then the system would automatically blank out the price that the user had previously manually entered as the price on the line item. That’s bad, because 1- the user may not notice that the system blanked out their price; and 2- the user had to double their efforts to re-enter it manually. We’ve gotten… “loud” feedback from users about this behavior in the past.
That being said, as you point out above, there are some consistency problems in the software currently, where some transaction pricing autopopulation behavior occurs as you describe above, and some doesn’t.
Our first order of business will be making the behavior across the system consistent and predictable. Likely the design pattern we are settling on is the one you are expressing a preference for here, so that’s good news. To cover the other use cases and other users’ preferences, I believe we will have to introduce some UI alerting in those cases when prices get blanked out requiring manual re-entry of pricing.
Thanks for your feedback and ongoing patience here @spencer - we’ll post back on this thread with updates.