We are encountering a strange print error when printing Canadian Payroll report - Posting Journal - this is a long time client, not new.
When they print the resulting posting file from the GL - there are no error in the printing. So it appears to be in restricted to the Payroll printing report only.
I modified the report to select a different font - the same result.
Wondering if I am missing something.
Hi Bill-
Thank you for your post, could you offer a screen capture of the issue? (Do not include any personal identifiable information as these forums are available to the public.)
Is the font strange or is there an error message?
What build of GP is being used?
I appreciate your feedback when available.
Nicole Fiskum
Support Engineer
Microsoft Dynamics
Printing Posting Journal from Canadian Payroll. While this is the printed result, the posting to the General Ledger is not effected by this matter.
There are no error messages - just the strange transposed font. When I look at the font in the Report Writer - it shows as Courier - I have changed it to Helvetica and there is no difference - other than size and spacing of the font.
Bill,
is this a customized report in GP ? have you tried to return it to the default ? other than the font, I could think of the field format / type (i.e. being a special format instead of a date or string). I don't believe this is a font issue...
Beat, the challenge is that the client has used and printed this report over the past 5 plus years - it was modified once - and then nothing has changed until the day it printed out like this.
I will export the modified report - change the security to point to the default and not the modified and then see what happens. I will post back shortly.
Thanks for the details Bill,
If nothing has changed on the report side, something else must have.. it could be the printer or the drivers or Windows updated.
Nothing happens without a good reason... Sometimes it could just be the printer that got an updated driver and suddenly doesn't translate the font commands the way it used in the past. I've seen weird things when it comes to printers in my long life in IT.
Glad that you pushed me to look - I printed the Trial Balance report and the Account number in that report was also printed as 'strange' characters. So one report in Canadian Payroll and the other in Financials are presenting the same 'strange' output.
As they are both Account Numbers - is there a field type or data type I need to look for - I am totally open to sugestion on next step as I know we have ruled out an issue with the report formats being the problem (haven't we?) by getting the same error in two different modules.
Look forward to thoughts.
Thanks Bill for providing more details..
That makes me think about a similar issue I ran into years ago, but can't remember right now what the root cause was..
I've you ruled out a printer issue by printing the report to PDF and / or to another printer ?
It could also be a corrupt REPORTS.DIC and the best would be to export all the custom reports into a package file and start from scratch with a new REPORTS.DIC (rename the old one) by re-importing the .package file.. This doesn't take long and it often helps fixing quirks like this.
Along the lines of Beat's recommendation to recreate the reports dictionary, also recreate the Forms.dic. I saw this happen quite a bit with GP 18.3 upgrades. (I am sure there is some logical explanation about why the forms.dic issue impacts the reports.dic but I will leave it for smarter people to explain.) I saw this happen on both modified and unmodified reports where recreating the reports.dic didn't fix the problem but recreating the forms.dic did. (And now I am motivated to finally write up an idea for importing forms.dic like we have with reports.dic. Vote here: Microsoft Idea · Import forms.dic (dynamics.com))
You got my vote Lisa!
Thanks for the suggestion and the idea about the FORMS.DIC rebuild.. definitely not something that would be obvious in first sight.
Just wanted to update you on this, and hope it shakes loss some idea of what is happening.
Now when I print either to paper or screen or pdf, I am getting this any time an Account Number is part of the report. If there are no account numbers on a report, there are no issues with the report.
Looking at account detail in the application does not present a problem - so that is making me believe it is something to do with the printer driver.
The reports that contain account numbers are not modified and modified - so some are in the Reports.dic while a majority of them are not found there.
In an earlier step the recommendation was to Export them to Package and then 'Delete' the Reports.dic - does this still make sense.
Share
Report
All responses (
Answers (