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

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

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.

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.

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;
    }

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…

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!

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

Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.

Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.