I have been asked to assign add an automatic 2% on each line on quotes for specific customers. Anyone know of a way to accomplish this without having to create new pricelists for customers? Customers will often order parts that are not included in pricelists.
This bracket is related to slow payment history and current past due status, and as such it wouldn’t always and forever apply. More than likely Finance would manage which customers get this rate, so I am off the hook for conditional triggering it.
Raise all prices by 2.56%, then give good customers (all but the slow payers) a 2.5% discount. That discount would be set on the Customer record.
The most straightforward way would be a BPM on the GetPrice method. Then lookup the customer to see if a UD field (named SlowPay_c perhaps?) is set. If so, update price to price * 1.025
I am going to try that route, Calvin. The FC or LC has been batted around, but is thought to result in too many credits of those and additional load on CSRs and AR folks.
Instead of a UD field on the Customer, how about a Customer Attribute?
I prefer to use Attributes as much as possible, especially for Boolean like data.
(I once saw a UI screen for marketing software that was nothing but a page of checkboxes for customer email subscription, I love attributes now.)
Not that is would be a good solution, but this got me wondering if a negative discount would work, is it even possible (OrderDtl.Discount?)
But an Order MiscCode called ‘SlowPay’ with a negative percent that is auto added to an Order if they have a Customer Attribute of ‘SlowPay,’ or perhaps you can evaluate if the customer is slow pay or not on the fly, so you don’t have to store anything. What would be criteria for Slow Pay? I thought once, I called an Epicor Method that of other things it returned the ‘Average Days To Pay.’
(Friday snide remark: perhaps the Misc Code Description could be ‘Do Better Fee’)
Oh man; that’s the first thing I tried, but Epicor won’t allow the field to be negative…
So for slow pay criteria: we are seeing an alarming trend where especially the big name food producers are pressing for longer terms. We are talking 90-120 days being forced on us. Not sure if anyone else has noticed this? So technically not delinquent as they are paying according to “their” terms, but still we are going to be waiting for 4 months until we see cash…
I would love for a solution that applies on the fly and places the customer back in a more favorable bracket, as we see this type of slow pay behavior coming from the spare parts sales. So yes; I could use that option too!
I like the idea of using a customer attribute for it; I’ll try that route. I am still not sure how to pass a Customer Attribute value onto the BAQ. I might be going about it the wrong way, but I am still trying to figure out how to copy or look at a value from the Customer table and use it in a Method Directive that deals with Sales Order Dtl? Once I figure that out, I can do a lot more with BPM’s…
The code in that exact post is what would go in a Execute Custom Code widget. If you’re setting a BPM variable via a Set Arg/Var widget, drop the variable type name and assignment (equals operator), and the semicolon at the end.
I wasn’t able to locate the GetPrice method in my eagerness to try, but came up with the following to make it work in OrderDtl; just in case someone else wants to do something similar:
Create CustAttr: “120” with a description tying it to a specific upcharge rate
Create In Transaction Data Directive on OrderDtl
Add: Set Argument / Variable, Condition, and 2 Set Field elements (one to update the DocUnitPrice, the other for the DocExtPrice)
Create “GetMarkup” String variable
Code to pull CustAttr value for the Cust in Set Argument.Variable element:
Db.CustAttr.Where ( r=>r.Company == ttOrderDtlRow.Company && r.CustNum == ttOrderDtlRow.CustNum).Select(r =>r.AttrCode ).DefaultIfEmpty(“Not Found”).FirstOrDefault()
On Set Field element Set the ttOrderDtl.DocUnitPrice field to this expression:
ttOrderDtlRow.DocUnitPrice=((ttOrderDtlRow.DocUnitPrice)+ ( ttOrderDtlRow.DocUnitPrice/1000)*15)
Note: The 15 value at the end translates to 1.5% markup due to CustAttr being 120. No decimals allowed in that function, so hence.
Set IF Element to look for 120 value by creating the following condition:
The GetMarkup argument/variable is equal to the “120” expression
Others can be added for different brackets (need matching CustAttr for each alt value)
Connect the dots: Start–Set Argument/Variable–Condition–Set Field
When I create an order for a 120 day terms customer I add a line and the part drops in at regular price. As soon as I hit save the price changes to the marked up price.
-I would have expected this new Doc Unit Price to be used in to calculate the Ext Price, but it didn’t. I ended up just putting the same modifier to carry the upcharge over to the total. It seems to work.
-Very nice detail is that the modifier also changes Parts on the Fly prices.
It might be that a BPM of a different type would have recalculated it better/more efficient, but this way worked well enough for me as a proof of concept. Any suggestions to refine my crude hacking are welcome.
I’d like to think that modern compilers will handle this properly, and not first divide by 1000 (with a result with no decimals), before multiplying by 15.
For example if DocUnitPrice is 123.45, and the division by 1000 happens first, then the result would be
123.45. Because:
123.45 / 1000 = 0 (as no decimals are supported)
0 (the result from step 1) multiplied by 15, yields 0
123.45 + 0 = 123.45
If the multiplication happens first then you get:
123.45 x 15 = 1851 (the int portion of 1851.75)
1851 / 1000 = 1 (the int portion of 1.851)
123.45 + 1 = 124.45
So neither really work.
try using 1.5% as a decimal → 0.015M
ALSO
Your BPM might need something to make sure this only happens once. What if another field changes (like NeedBy date). Will another 1.5% be added on when it updates for that?
It did calculate properly, but 0.015M is a much better way. I changed a few things, but was not able to bring about a compiling of the calculations. How do I make sure it only executes once, and that it executes in the first place? I did find that if I create an order for a fast paying customer, save it and then change the customer to the slow paying customer it does not recalculate the line, and leaves it. When I add a new line for the same part, I do get the marked up price. In reality this is not a show stopper for us, but I would like to figure out for my own piece of mind that I can do this.
First you’d need to consider all the conditions when the price should change and when it should not.
A condition to see if it is a new OrderDtl record, or if the price changed from 0 to anything else. Either of those should only update the price when the record is “new-ish”. But wouldn’t update if you were changing the price of the line, using a “normal price” that needs the 1.5% adder.
It might be too annoying, but you could use a BPM form to prompt the user if an increased price is warranted. Only do this when it is a change to an existing record (doesn’t meet the “new-ish” record criteria).
That way, when a user changes the price from a price goes from $96.43 ($95 + 1.5%) to $100.00, the user can be prompted to see if it should really be $101.50.