I came across something this week that has thrown me for a loop and seems crazy to me.
We have a ton of Misc Charges that are used in shipping and sales orders. They all have the flag set to clear for include in Terms Discounts. When I query the Invoice Header table, the field PayDiscAmt is calculating a discount based on the entire balance of the invoice instead of the invoice amount without the misc charges. I questioned Epicor about this and they pointed me to the field help which I read before however missed the fact that it applies only to Cash Receipts entry.
My question is Why would the PayDiscAmt field on the invoice header populate with a discount that includes the misc charge when the charge is clearly setup to not be included in the Terms Discounts?
According to my support response it has been submitted as a problem before and rejected.
The issue was rejected from Development for the following reason " currently the calculation occurs on Cash Receipt Entry, as description field says (MiscChrg.IncludeDiscount) if box is checked, this amount will be included when calculating the discount in cash receipts. Currently, there is not logic that considers MiscChrg.IncludeDiscount flag to calculate discount for InvcHead record, the final discount amount is calculated on the Cash Receipt."
This is a problem we have noticed as well, as we are using that PayDiscAmt field to send the owed amount to a payment portal (because it switches values after the terms have expired). The amount we are sending to the portal is discounting miscellaneous charges that are not marked to include in terms discount, causing us to under-collect.
Before re-working our logic to address this inaccuracy in the Epicor field I was hoping to find out if anyone else had any luck with resolving.
The description of the field certainly makes it seem like the amount should match Cash Receipt Entry: Amount of discount that would be given if paid on or before the specified PayDiscDate. Calculated using the Terms.DiscountPercent X Invoice total amount.
Sorry I don’t have more help, but thank you for posting. I will keep the previous declined problem in mind as I submit my ticket.
I’ve reworked my report logic to behave as if that field isn’t even available. The fact that the database doesn’t populate that fields with the actual discounted amount concerns me. We recently went thru a bunch of report re-design because a field was eliminated from a table. Even though we were not using it, it killed our RDD since whoever created it included all fields/labels in the RDD. I’m afraid the same thing might happen here since the fields isn’t really being populated with a valid answer.