Dynamics Ax

PDF EP error - section overlaps footer

2010-05-25T22:01:00.001+02:00

Problem

Reports generated as PDF on the portal, such as the invoice, may result in a blank page on a Dynamics Ax 4.0 SP2.

Context

The client browser requesting the PDF file results in a blank page. No error to the client, how nice. When the user calls, a system administrator checks the eventlog to find the following error (translated from Dutch):

“An X++ exception occured. Section overlaps the pageFooter (the section could be to large)”. You check the report in a client: no problem. You check the site: problem.

Cause

The cause of this exception is a known bug in Dynamics Ax. Check Hotfix Rollup 95338 at microsoft (requires partnersource login). But since the report contains a footer, the PDF generation failes because the footer is overlaped by the content of the body. I figured this out by removing all footers and finding a 14 page counting invoice (big customer ;-) ) resulting in a single page PDF.

Solution

The best solution would be to install the kernel rollup.Microsoft doesn’t release these rollups just for the fun of it. However, this will result in testing of the entire application, since nobody exactly knows that objects are affected with a new DIS layer.

If you just want to fix this bug, see the class EPSendDocument, method makeDocument, line 31:

The virtualPageHeight is default ‘0’ (zero) in Dynamics Ax 4.0 SP2. The Hotfix of microsoft just changes this value to ‘–1’. Do it yourself, it will do the job just as good in the CUS layer.

Gerrit

PDF generated on portal has dots

2010-05-25T21:44:00.001+02:00

Problem

Several reports can be generated as PDF on the portal. For instance the sales invoice report. When a design is modified, you may encounter dots where normal text is expected.

Context

This problem resides only on the portal generated PDF files. When an employee generates the same report using an Dynamics Ax client, the text is readable. This problem exists in Dynamics Ax 4.0 SP2.

Example

A customer has modified the sales invoice with the following result on the portal:

The total amount are dots… when you select the text and paste it to notepad, the result is readable but still mixed up.

Cause

The cause could be a wrong setup of the font for the value. In the design for the total element I found the following properties:

You see the Font property is bold, but no value entered… but when you select the property:

A space is present. The PDF generator for the portal cannot handle this and results in dots in the PDF file.

Solution

Find the element on the design and check the font property. Clear the space, so the font property name is no longer bold.

Gerrit

No systemvariables, globalcache error

2009-07-04T08:48:00.001+02:00

Problem

In an Ax 4.0 environment, during startup of the client a weird message is printed (not info-log, translated from dutch):

No general systemvariables. Stacktrace: infolog\globalcache (line 3). No forms can be opened, from anywhere (main menu, options, about, etc.) When the client is closed, the client crashes (send / do not send).

Context

Two servers, AOS-A, AOS-B. Identical in hardware, no mayor differences between installed updates and software. Both with an Ax 4.0 SP1 AOS, and a kernel rollup (kb-935288). One client machine (Client-C) with Ax 4.0 SP2 client. Client-C has config files for the different environments.

When connecting to AOS-A, the system fails with the ‘no general systemvariables’. Debugging (placing a breakpoint in info.globalCache()) shows the globalCache variable to be ‘?’. Closing the Ax client is only possible now by terminating the ax32.exe client via the task manager.

When connecting to AOS-B, no problems occur and the system can be used as expected.

Reconnecting to the AOS-A environment, the client results in the same errors. Closing the client will crash, with a send / do not send. An error is logged in the eventlog:

I tried stopping and starting (not restarting, even though which is essentially the same…) the AOS service. No luck…

Cause

Since I did not yet install any debugging tools, I could not determine the exact reason of the client-crash. The error in the eventlog was insufficient to make any judgments.

Solution

To bad, I cannot explain the cause of this error message. What I did was modify the AOS-A environment that was having this problem to read a different Ax application. With the new application, the system worked. No recompile, no synchronize… I just closed the client with no error. I configured the system to read the previous application files, expecting the error… but no. The Axapta gods had something else in mind. The system worked…

It is not worth the name ‘solution’, but if anyone ever encounters this problem, try temporarily using a different application.

Gerrit

Access to a restored Ax environment

2009-06-20T12:26:00.001+02:00

Problem

After you restore an Ax database from an unavailable domain, you get the following error:

Even the domain administrators do not gain access.

Context

User in Ax are link to the domain controller for which the system is installed. The users are ‘imported’ into Ax, resulting in the user actually be able to startup an Ax client, logging into Ax and performing actions for which the user has been granted access in Ax.

This information, which user in which domain is allowed to perform which action is part of the Ax database. This includes any trusted domains, for example in case of a traditional perimeter network.

But what if you restore an Ax database that was part of another domain? Even if you are the domain administrator, you will get the ‘You are not a recognized user of Microsoft Dynamics Ax. Contact your system administrator for help.’ message.

Solution

The reason for this error is that the system only recognizes users from the old domain. This can be solved to updating the data directly using the database manager. In case of MS SQL server:

- Go to the Ax database. You can determine which database instance and database is used by checking the AOS configuration.

- Find the dbo.USERINFO table

- Open this table and find the record with ID value ‘Admin’. This user has in a normal scenario all rights, but may differ per installation. You can also use SQL to update the record, what ever makes you happy.

- Update the following fields to reflect the current domain credentials. Bottom two lines can be ignored in this screenshot, the top line has the ID ‘Admin’ in this example:

- SID – The Security Identifier of the account specified in the networkdomain and networkalias. See section ‘Get your SID’.

- NETWORKDOMAIN – you current login domain

- NETWORKALIAS – your current windows login name

- You might want to make sure the field ‘ENABLED’ has the value 1. Otherwise the user is disabled, and you will still not be able to login.

- Save the record

- Open Ax

- Create your own users / import from the Domain.

Get your SID

Create a file with the extension .VBS. Copy the following info:

--------------------

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set objAccount = objWMIService.Get _("Win32_UserAccount.Name='<user>',Domain='<domain>'")
Wscript.Echo objAccount.SID

---------------------

Replace <user> with your user name, and <domain> with the domain. This script can be run from any computer in the domain, it does not have to be the domain controller. A popup will appear with your SID:

Sending a report as PDF with embedded fonts has no extension

2009-04-28T14:26:00.001+02:00

Problem

In Dynamics Ax 4.0 SP1, when the report is send as a PDF file with embedded fonts, the extension .PDF is not added to the file name of the attachment.

Context

When a report is generated, any kind of report, the option is provided to send the document in a specific format by mail. There are two options when it comes to PDF:

- PDF

- PDF with embedded fonts

The second type will add all used fonts to the PDF file itself, so the receiving client does not have to have all fonts used in the document. This is only useful if certain non-standard fonts are used like barcode fonts and such. The document will become quite big, compared to the ‘plain’ PDF file.

When sending a report via mail, a file is generated and attached to the mail. This file contains the extension related to the chosen file format, so the receiver knows what to do with it.

Example

When printing the invoice of a sales order, the following dialog appears:

Note the selection PDF (embed fonts).

When pressing OK, the following mail is generated:

Note that the attachment is called axaptareport, and not the desired axaptareport.pdf.

Cause

The reason why there is no extension is a piece standard Dynamics Ax software. Class Info, method reportSendMail:

void reportSendMail(PrintJobSettings p1)
{
SysINetMail m = new SysINetMail();

str fileName = 'axaptareport';

if (p1.format() == PrintFormat::ASCII)
//fileName = subStr(p1.fileName(),strLen(p1.fileName())-3,-999)+'TXT';
fileName = fileName + '.txt';
else if (p1.format() == PrintFormat::RTF)
//fileName = subStr(p1.fileName(),strLen(p1.fileName())-3,-999)+'RTF';
fileName = fileName + '.rtf';
else if (p1.format() == PrintFormat::HTML)
//fileName = subStr(p1.fileName(),strLen(p1.fileName())-3,-999)+'HTM';
fileName = fileName + '.htm';
else if (p1.format() == PrintFormat::PDF)
//fileName = subStr(p1.fileName(),strLen(p1.fileName())-3,-999)+'PDF';
fileName = fileName + '.pdf';

m.sendMailAttach(p1.mailTo(),p1.mailCc(), p1.mailSubject(),'axapta report', true, p1.fileName(), fileName);
//m.sendMailAttach('','', '','Axapta report', TRUE, p1.fileName(), fileName);

}

Personally, I would not have written this method as such. A nice example to show the benefits of a case statement. But that is not the issue here.

Solution

In order to leave as much of standard Ax as possible, change line 16 of the method reportSendMail of the Info class to:

else if (p1.format() == PrintFormat::PDF || p1.format() == PrintFormat::PDF_EMBED_FONTS )

Gerrit