I’m trying to make the Commercial invoice show the Print destination settings dialog before printing and allow the user to select different template. I was expecting that template to be used for the printing, but for some reason it is not being used.
I think some of the classes that carry the template selection are not being packed/unpacked or are being overwritten by some old value stored in user settings. It is quite hard to follow all the logic and find where that could be happening so I was hoping you could provide me with some hints.
If I stop at SrsPrintMgmtController_DC_Extension.runReport() right after it reads the reportContract and examine the variable - I see inside printSettings.SrsPrintDestinationSetting_DC_Extension.srsPrintReportSettings_DS.templateId is empty. Is this where I should expect the template selected by the user to be? Is the beginning of runReport() the right time to expect the value to be there already, or it is too early and some other method will populate it later?
After that I see this contract reaches DocSrsReportRunUtil::constructPrinManagerFromSrsReportDataContract() where validateReportAndSelectedDocentricTemplate() is called and the check there finds that the template is empty, but it does not call fallbackToPrintSrsOriginalDesign() because most of the conditions in the IF statement before it fail (which is good I guess). Back in constructPrinManagerFromSrsReportDataContract() it creates new instance of DocPrintReportSettings and while populating it I see it sets the template with the empty value from the contract.
Further down when we reach DocPrintManager.overrideReportRunSettings(), when it reads the templateid from printReportSettings it already has value and the value is the default template for the report and not the one I selected on the Print destination settings dialog.
As I understand your scenario, (some?) users are not printing the invoice using Print management settings, but they are printing it individually, which results in each user having a last applied settings stored in User options.
Print management reports are easier to print using Print management. There you can set all aspects of printing. If your users are doing that and your Print management is correctly set, but they still get something else, there may be some overrides on a customer or a current invoice.
If you are using conditional print management settings, maybe not the correct one is activating.
You can try troubleshooting the processing by activating Tracing.
Yes, not using Print management. Let’s say we want to give the users this option - they want to print most of the time one template, but in some rare cases, that are difficult to define in Print management, they will want to print using different template. To achieve that, we show them the Print destination settings form and allow them to pick which template to use.
I can add more info from my debugging. In PrintMgmtReportRun_DC_Extension.execute() when it reads the reportContract using reportRunController.parmReportContract(), the template is there. But later when it reaches runReport() and reads the contract using this.parmReportRun().parmReportContract() - the template is empty.
That’s where I am at the moment. I will keep digging.
What you are trying to use are standard D365 features and should work fine with Docentric templates. Did you try resetting usage data? Sometimes this solves the problems.
I found that PrintMgmtReportRun.execute() calls reportContract.parmPrintSettings(settingDetail.parmPrintJobSettings()) and overwrites the good print settings it had with “bad” ones that have no templateId.
I found that I could fix it by adding CoC on method execute() and before calling next, I can get the settingDetail from _reportRun.settingDetail(), then get the printJobSettings from it and ultimately get to the template and set it from the contract
I see there is a bunch of code in Docentric’s extension of that method (PrintMgmtReportRun_DC_Extension.execute()), a lot of it dealing with overwriting different parts of these print settings, but somehow it misses to transfer the template selection, so I have to do it afterwards.
I think maybe if Docentric developers add this line of code somewhere near the top of the Docentric extension of execute() it won’t hurt -
Hello Kiril, thank you for your suggestions and the analysis.
As the questions are getting more and more technical and to avoid any confusion, we would like to invite you to continue our discussion by opening a support ticket.
May I ask you to send us an email to support@docentric.com, and we will get back to you with more details from the DEV team as soon as possible. Thank you!
After additional analysis, we found that there is no report contract class implemented for the TMSCommercialInvoice report and consequently the UsePrintManagement flag is not implemented.
So, if you extend the standard report controller and change the showDialog property to TRUE, you cannot make the report print to the user-defined print destination.
It will always be printed via the print management.
To make this work, you need to create the report contract class, define the UsePrintManagement flag, and then handle the switch between print management and ad-hoc print destination.
This is all standard Microsoft code, and you can follow the pattern used, for example, in the case of the CustAccountStatementExt report.
You need to analyze how the print management and user-defined print destination are handled and try to replicate the same flow for TMSCommercialInvoice.
On the other hand, the solution you suggest, which we could apply in the PrintMgmtReportRun.execute() method extension, works only in the case of the Docentric Screen print destination.
So, it would work only when the print management is set to Docentric Screen and TemplateA is selected.
Later, when the report is printed and the user changes TemplateId to TemplateB but still uses Docentric Screen as the destination, it would work.
With any other destination, an error could occur, especially if you switch between Docentric and SSRS designs.
We appreciate your efforts to contribute to the quality of our product. Based on our experience with various standard reports, we believe that the best way to show users the dialog and let them select and configure the print destination (including the selected template) is to use Microsoft’s standard approach, as in the CustAccountStatementExt example.
