Rounding Discounted Prices so there is no Decimal in Total price(With custom BPM)

Hello Epic Help Community,

I did not know what an ERP program was 3 months ago and now I’m in charge of the transition to Epicor at the company I work for and it is very first job out of college. So I will try to explain what I need help with as best as I can.

Summary of my question: I need my BPM to be able to recalculate(Round it up or down) discount amount(OrderDtl.DspDiscount) in Sales Order Entry, so that I do not get any change in my total price after discount. Which Method Directive I should place this under so that it saves the calculated price when sales order is saved?

Detailed explanation:
So we went live on Monday(12/24/2018) and no body told me that our discounted product prices for customers were rounded up and then given to customers as their price for the product. As of now, our Epicor multiplies MSRP price with quantity then applies Customer’s appropriate discount percentage. However, this gives us a different price with change and as the quantity increases the difference becomes bigger.

I wrote short a C# expression which does the rounding we want. I added a custom UD checkbox in Sales Order Entry so that ideally when it’s checked the custom code will round the discount price and don’t change when SO Entry is saved.

Unfortunately, I was not able to find the correct Method directive to place this BPM. I tried out the C# expression under Erp.SalesOrder.ChangeOverridePriceList Method directive and it work correctly rounding the discount the way we want it but when saved, the discount amount gets recalculated and goes back to the amount before it was rounded.

The rounding expression:
Math.Round(((ttOrderDtlRow.DocDspDiscount)/ttOrderDtlRow.SellingQuantity), 0)*ttOrderDtlRow.SellingQuantity

I’ve also tried a couple more directives like update, changesellingquantity but they also got updated back to original when saved.

Where would be the correct place for a BPM like this so that it saves the discount amount like user entered it manually?

I’m sorry if this is a very simple question or if I wasn’t able to explain it clearly. I will gladly explain more if you have further question. Thank you all!

Are you using pre or post processing directives?

We have a couple pre processing directives from before I replaced the guy before me. One of them is to check one time shipment chkbox, another for checking duplicate PO number and one more for sending acknowledgement emails to customers. All in pre processign and under ChangeCustomer,Update and master update respectively.

I’ve tried using the discount rounding C# under preprocessing only. I’ve never tried post processing before.

I was referring to which you were using on the BPMs for the discount

I am not sure exactly what you are asking me. If you are asking about how discounts are done right now, it’s by Price list and different discount amounts for different product group.

If you are asking where I placed the BPM that I want to round discounts with, it is no where right now but I’ve tested it in:

  • Erp.SalesOrder.ChangeOverridePriceList(when I used the override price list checkbox to trigger the C# expression): It rounded the price but got overwritten after save.
  • Erp.SalesOrder.Update: Did not work
  • Erp.SalesOrder.ChangeDiscountAmount: Did not work(and now that I think of it this was a stupid idea)
  • Erp.SalesOrder.ChangeSellingQuantity: this also did not do anything.

And I’ve tried all these using Pre Processing.

Hi OnurCam,

I am working on something that I believe is is similar to this. I used the following:

  1. An In-Transit Data Directive on the OrderDtl table. Does the discount calculation using the rounding required then sets DocDiscount to the result of this calculation.
  2. A Post-Processing Method Directive on ChangeUnitPrice that saves the discount percentage entered by the sales person. Performs the rounded discount calculation sets DocDspDiscount to the rounded discount amount, sets DiscountPercent to 0, then calls ChangeDiscountAmount. Finally it sets the DiscountPercent field back to the original discount
  3. A Post-Processing Method Directive on ChangeDiscountPercentage. Performs the same logic as #2
  4. A Post-Processing Method Directive on ChangeSellingQtyMaster. Performs the same logic as #2

The method directives take care of the user interface aspect and the data directive is there to catch anything else that may be posting orders like DMT. Still testing though so this may not be a complete solution.

1 Like