Print Management Settings in Dynamics AX Seem to Disappear or Reset after a Code Move

By Laura Lake | March 19, 2018

A client recently reported that their customer overrides for Print Management in Dynamics AX had suddenly all reset to Screen. They used Print Management extensively to email Invoices to their customers. Having these emails suddenly “wiped out” was a critical issue for them.

In discussing the issue, it came to my attention that a recent code promotion to Production had occurred. I found that the SrsPrintDestinationSettings class had been modified, and the packed version had been changed from 1 to 2 as in the example below.

Print Management Settings

If you have not had to dig into the details of Print Management before, you may not be aware that when the settings are overridden in Print Management, such as adding an email for a customer invoice, the values packed in this class are actually stored in the PrintMgmtSettings.PrintJobSettings field in a container – EDT PrintJobSettingsPacked.

When the class was moved to production with the new version (2), users could no longer see the values stored previously as version 1. Those values were still in the container in the PrintJobSettings field, but they could not be accessed using version 2.

Let me give an example. We have modified customer 100023 to override the Destination setting for invoices. This modification was done prior to the class change when the packed version was 1.

Print Management Setup

You can use code similar to this in order to see what was packed via debugger…

Define a macro using the list defined in SrsPrintDestinationSettings. You will need most of the variables defined there also.

#localmacro.oldList
        version,
        packedPrintMedium,
        printMediumType,
        printerName,
        printerPageSettings,
        landscape,
        printerStatus,
        printerType,
        printerWhere,
        printerComment,
        printAllPages,
        fromPage,
        toPage,
        numberOfCopies,
        emailTo,
        emailCc,
        emailSubject,
        emailAttachmentFileFormat,
        emailAttachmentImageFileFormat,
        fileName,
        fileFormat,
        imageFileFormat,
        overwriteFile,
        printToArchive,
        overridePageSettings,
        overwriteFileIsSet
    #endmacro

Write a select to find the record you are interested in…

    select DocumentType, Name, ReferencedRecId from printMgmtDocInstance
    join  custTable
    where custTable.RecId == printMgmtDocInstance.ReferencedRecId
        && printMgmtDocInstance.ReferencedTableId == tableNum(custTable)
        && (custTable.AccountNum == "100023") // specify customer account here, if needed
    join printMgmtSettings
        where printMgmtDocInstance.RecId == printMgmtSettings.ParentId;

    if (conPeek(printMgmtSettings.PrintJobSettings,1) == 1) //version 1

    {
        [#oldlist] = printMgmtSettings.PrintJobSettings;
    }

Print settings

Since these values were stored as version 1, they will not show up once the class has changed to version 2. Now we will see something like this…

Print settings

There are a couple of ways to handle the problem:

1.  Try to avoid modifying framework classes to begin with. I understand that sometimes we have to go against our better judgment to accommodate our clients.

2.  When you change the packed version in any class, consider whether you should add a switch statement in the class to pull the previous version’s values from the field (or usage data) if they exist. Most of the time it is probably unnecessary since users don’t expect their usage data to be permanent. However, as in this issue, those values may be stored in a table. The code would look something like this…

switch (version)
	{
		case #version1:
			[#version1List] = packedClass;
			break;
		case #version2:
			[#version2List] = packedClass;
			break;
	}

3.  My client opted for updating the version directly in the PrintJobSettings field from 1 to 2. In this way, the previously entered values will magically appear again.

Here is some sample code to illustrate the update. Literals were used for clarity.

while select DocumentType, Name, ReferencedRecId from printMgmtDocInstance
    join  custTable
    where custTable.RecId == printMgmtDocInstance.ReferencedRecId
        && printMgmtDocInstance.ReferencedTableId == tableNum(custTable)
        && (custTable.AccountNum == "100075") // specify customer account here, if needed
    join forupdate printMgmtSettings
        where printMgmtDocInstance.RecId == printMgmtSettings.ParentId
    {
        if (conPeek(printMgmtSettings.PrintJobSettings,1) == #version)
        {
            [version,#oldlist] = printMgmtSettings.PrintJobSettings;
            ttsBegin;
            printMgmtSettings.PrintJobSettings = [2,#oldlist,0];
            printMgmtSettings.update();
            ttsCommit;
        }
       
  
    }

Note: The zero in the version 2 container was added for a new variable in version 2. You could just retrieve the record and call update() without changing anything since it would be saved as version 2 by default.

TaDa!

Print settings disappear

If your Print Management Settings in Dynamics AX  Disappear or Reset after a Code Move, I hope these tips can help you.

Start the Conversation

It’s our mission to help clients win. We’d love to talk to you about the right business solutions to help you achieve your goals.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!

X