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.
While this is a slow process, having to export each form into a unique PACKAGE document, I sure hope people vote for Lisa's suggestion to make the export / import from FORMS the same as from REPORTS.
experience.dynamics.com/.../
Vote here and spread the word - send the link to your co-workers and get this voted up - then Microsoft might act on the request.
I agree with Beat about importing via a package. If there haven't been recent forms modifications, I expect starting with a new empty forms.dic and importing your package should solve the issue. (You'll have to undo security changes to get users back to the modified versions.)
I too don't know what the connection is between forms.dic and report printing; I just know that recreating forms.dic has worked when I have run into the problem. (I think this is a common problem during when upgrading versions. I am not a fan of upgrading modified resources so I started a different process with GP 18.4 updates to see if I can avoid the issue as it was pretty prevalent with GP 18.3 upgrades/updates. I definitely include printing a modified GL Trial Balance in my upgrade steps to hopefully resolve the issue before releasing the upgrade.)
[P.S. Thank you for up-voting the feature request for a forms.dic import tool like we have with reports.dic.
https://experience.dynamics.com/ideas/idea/?ideaid=23a0ea93-ef30-ec11-b76a-0003ff45e08b]
Bill,
Ok, you narrowed down the problem to be related to the FORMS dictionary and some custom forms.
Have your tried to export the custom Forms one by one and then start from scratch, adding one custom form after the other ? does any of those forms have some VBA code attached ? remember that VBA is something Microsoft recommends to get away from, being too much prone of problems related to Windows & Office updates.
If you can pinpoint the custom Forms that's causing the problem, then maybe you can then edit the form and check if anything was changed in the Field format for Account number ...
Lisa, I know you posted this message about the FORMS back in October and I said it made no difference. Well, I am not sure what I did since then, but I tried the removal of the FORMS and REPORTS dictionaries once more today - you know last try before I uninstall and rebuild everything - not my favorite idea.
So anyway, removed the two dic's from the SET file and POW - it printed the Account numbers correctly.
I added back the Modified Reports and POW - it printed the Account numbers correctly.
You got to the punch line - added FORMS back and WHAM OH - not printing the account numbers correctly.
NOW it is going to be a real pain to figure out, but why would the FORMS dictionary have an impact on the printing of the Account Number field on ALL reports - modified or out of the box.
Client and I have been working on this for the past month and 1/2 and he is not really pleased that this has happened ( at his year end no less ) and it is really not something that should happen - so who and how do we resolve this now?
Who is Lisa?
Running the sync does not change anything on your Forms and Reports.dic file.. it just sync the code to the account format.
It is safe to run anytime and even with users in GP. *someone from Microsoft Systems tech support team told me this some time ago.
LIsa, to your point about the forms and reports synchronizing - I have removed the reports and forms dictionaries from the system - modified the security - but now with the forms and reports gone we are still getting the same issue.
Do I run the Synchronization (in Utilities) with or without the modified forms and reports dictionaries in place?
Try to synchronize (@dex.ini, there's an option to Synchronize=FALSE, change to TRUE), re launch GP, run Utilities... this process will synchronize the GP code to the account format. It is safe to run anytime and you will need to run it on all your servers or VMs or workstations if there is a local gp code in it.
Another thing you can try, not sure if you had done already: try creating a new report option.
It is possible the report option that the users had been using all this time is already damaged.
... just my 2 cents... hope it helps.
Thanks for the suggestion, I will have a look at that. I will need to get access to a workstations to complete that work - will update as soon as I have something.
Thanks for the update Bill..
I saw that you tried to rebuild the REPORTS.DIC to no avail and still running into the same issue.
One thing that makes me tick is the 'Account' number field.. you said it only happens when there are account numbers to show. I'm thinking about something's broken at the COA level and the local dictionaries.
Have you tried to rename the GP program folder on one workstation and run a repair of GP in the control panel ? GP setup will re-create the GP folder without the ISV products (naked bare GP) and you should try to start that and see how the report prints..
PS: try to send the output to .TXT files and analyze the output with a tool like NotePad++ that can show hidden characters.. I'm wondering if the strange symbols would be sent to a .txt version too ?
#1
André Arnaud de Cal...
292,516
Super User 2025 Season 1
#2
Martin Dráb
231,432
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
