Hi
I’ve tried support several times, since this is a recurring issue but now I am just tired of it.
For some reason, AP Checks get the wrong amount to letter string, sometimes is the connecting string (AND) sometimes it is the suffix of the checks (US CY, MN, etc) and this time the issue is the whole amount in the wrong language, strangely enough the connecting string is in the correct one.
So, after years of dealing with this. I prefer to hijack the process. I would like to change the calculated amount-to-letters string with a SQL Function already prepared for this. Do you have any ideas? I would like to override the DspWordAmt field, however I can’t find if that is possible in the RDD.
Another option would be to create a new field in the RDD and call de SQL function to fill it, Yet I don’t know if that is possible either.
My last intent will be to actually create the number-to-letter function in the RDL, yet I would rather to fix it from the source to avoid updating every RDL when required.
Regarding support, this time the issue jumped to Developement, yet the PRB given doesn’t appear on EpicCare as of now. Expecting response from them today.
Also, the report is supposed to be generated correctly. If I see the SSRS table(by keeping it one day on execution) I can see that the language id column has the correct one. In this case esm which is spanish. Yet the amount is in english. Probably the reason this time it jumped to the higher area.
So, as said before, I would like to skip that kind of issue by obtaining the letter amount myself.
I don’t know how to get SQL to fill data in RDD. I’d go the RDL route. Can you use the same language parameter passed that Epicor uses to make it work for any language/user need you have?
Yes I can use the language and currencycode to create the correct string, yet that is my last resort, because it will require to create a new function in every Check RDL. Copy an paste, of course, but still it can evolve to maintenance hell. Hopefully there is a way, otherwise I’ll have to go that way.
That’s odd, the logic is not simple but also not overly complicated. It takes the culture from the LangName table using the LanguageID from the report, and then uses that culture through some libraries to convert the amount. Definitely sounds tricky as to why it sometimes fail.
As for how you can customize it, maybe if you add the logic to a calculated field in a BAQ and then use that BAQ in the RDD, although not sure if this is possible.
And as you said, the last option is to add the code to the RDL Code in visual basic and use that on each RDL.
If you have the problem/case number I can try and take a look.
Yes, I don’t know why this fails in a continuos manner.
The case is CS0002935743, however, that case was entered by one of my workmates and pretty much everything was by phone, so the case doesn’t show much. At least to me.
Also, it is in spanish… But if you can shine light about it, I’d appreciate it very much.
Hello Jonathan
I dug deeper in this issue, it appears it is specific to just one thing. The user entering and printing the check is using esm(Mexico Spanish) as language.
This is happening when no supplier is used. Meaning, no supplier id is selected in the payment. This is being done for several payments that are addressed to a one time name. Settlement payments to former employees and things like that.
So it seems that in this cases, where no supplier is being used, Epicor defaults to English(kind of, since it still uses de conecting string in spanish) instead of using the user language. Still it is quite weird that the report language id is esm(Spanish Mexico) but just that part gets messed up.
