We are starting to batch invoice daily, and have anywhere from 200-300 invoices that post. We have gone through test, and have had great success, with the number of postings that should happen.
We are using Print Management, so we can utilize email for most customers, and have about 1/4 customers that request a hard copy printed and stamp mailed to them.
The Log for the batch job we have export to Excel, so we can review daily, until we are satisfied for the next few weeks on what we see going through the system. We have a current situation, where there will be no info log record for a Sales Orders' printing, on it's successful or failed attempt to print/email using print management. That worries us, on if the customer was emailed successfully (or a printout) so they know they have an invoice pending.
Here is what a snippet of the log looks like, when a successful post and email occurs for 99% of our orders, and you can see about mid way, that there is no info log for order SO-6, on it's success/fail through print management. It's a non-sample, non $0.00 order, where and invoice should go for all purposes. Has email setup in print management, can email customer otherwise successfully from previous invoice postings through batch, and from outlook client.
SO-6 is the sales order example in question.
(For info security purposes, I renamed emails, printer, PO, and sales order items for this post)
Order ID: SO-1
Report SalesInvoice.Report was sent to printer \\server.network.net\printer123 (Invoices).
Order ID: SO-2
The report has been successfully sent as attachment to email. firstname.lastname@example.org subj-Sales Invoice for Purchase Order 333444
Order ID: SO-3
The report has been successfully sent as attachment to email. email@example.com subj-Sales Invoice for Purchase Order 4444455555
Order ID: SO-4
The report has been successfully sent as attachment to email. firstname.lastname@example.org subj-Sales Invoice for Purchase Order 433463456
Order ID: SO-5
The report has been successfully sent as attachment to email. email@example.com subj-Sales Invoice for Purchase Order 999999999
Order ID: SO-6
Order ID: SO-7
The report has been successfully sent as attachment to email. firstname.lastname@example.org subj-Sales Invoice for Purchase Order 07658757685
Order ID: SO-8
Order ID: SO-9
Order ID: SO-10
The report has been successfully sent as attachment to email. email@example.com subj-Sales Invoice for Purchase Order 12343456568
Order ID: SO-11
We have spent a few days researching this, looking through code, any modifications…. Can't seem to pinpoint anything about the order or the customer setup, that would prevent an email from attempting to be sent, or why the info log won't have a record that this was attempted. And in fact, when refreshing our test system for another test round, different random (1%) of customer won't get emailed, and the customers invoice on the next test, would run successfully…. Very weird… no repeatable pattern.
Only input I have received so far, is changing our Print from "Current" to "After", which would print all of the invoices to print management "After" all the posting for all orders is completed. Not sure what is preferred, but If anyone has input, seen this before, or have insight on how to troubleshoot this "random-ness", I'd be all ears.
AX 2012 R3 CU8
The 5-second delay didn't actually resolve the emailing issue I mentioned previously, so I'll eventually remove it.The info message was added because AR had no way to determine which invoice was printed or emailed. We're on AX 2012 R2 CU7, and the invoicing infolog previously only indicated that an invoice was either successfully printed or emailed.I put the this.outputReports() statement in a Try-Catch block to prevent the batch job from erroring-out when an error was encountered during printing or emailing.
Being a good AXUG peep, and posting a resolution, although this is an older post I initially created.
So we figured out the issue with some invoices not getting emailed, without any notification in the Info Logs. Keep in mind, we do have some modifications to our print management, but a lot of what I have described below is native AX processes.
When running in a batch, AX makes use of the service account you have setup in AX. In a lot of cases, yours may be something like "AXPROXY" or "BusConProxy", depending on your initial setup of AX or if a VAR did it for you.
When the batch jobs run, it uses the temp folder of the users account in /%USERNAME%/AppData/Local/Temp to create a .tmp file (ex. TmpAC4F.tmp) of the invoice after it posts.
Then, the batch job transfers it to a folder with the same name of the .tmp file (ex. TmpAC4F). It then renames that .tmp file SalesInvoice.pdf after it's in that folder. From here, the batch job sends it off to your SMTP server you have setup in email settings.
The issue, is that AX is generating a random 4-digit hex number, for the name of the .tmp file (ex. TmpAC4F.tmp). This allows only about 64,000 different naming possibilities. Eventually over time, if you are running invoices through a batch, the folder will fill up (in our case about 40,000 temp folders with a hex name). So AX was generating duplicate files names randomly, but had a system io error that could not write back to ax (basically no type of Try…Catch statement) to say "I have a file/folder with duplicate name." Hence, no info log generated that there was a success or failure… AX basically went on to the next sales order to post and invoice.
So my first reaction here, is to delete the contents of the users local temp folder before every invoice run. Although this works, there is still a 1-in-64k chance, that a duplicate file and folder name can be created when running invoices daily. We did this for a few days, and most of the days ran without issues, but one day we did have 1 duplicate. This was noticed because there was 1 .tmp file that was in the root of the Temp folder, which means there was a duplicate folder created before this one, and was moved to a temp folder with same name.
We decided to do some AX code modification, to clean up that specific temp folder for that invoice after the classes to send mail to SMTP. After it's sends the email, we don't need the folder anymore, it serves no purpose after it's sent.
If you don't have the ability to do this at your company, you can run a scheduled task to clean up the folder, or manually clean yourself, if you are cautious about item in that temp folder that could be needed for system processes.
I know this may all sound a bit confusing, but for those having the same troubles, you are free to contact me and I'd be glad to point you in the right direction.
In the SrsReportRunPrinter class, we modified the toEmail method.
From comparing our code to the SYS layer, there is a comment labeled "// render the Report." What we modified is below this, where the file name is created in the tempSubDirectory. Changes you may need at a minimum (with whatever other custom code you may have in your class) are in BOLD ITALIC, surrounded by //EDIT and // <-- EDIT.
// render the report
files = this.renderReportToFile(attachmentFileName, fileFormat);
if (files != null && files.lastIndex() > 0)
attachmentFileName = files.value(1);
fileNameOnly = reportContract.parmReportName() + SRSPrintDestinationSettings::findFileNameType(fileFormat, imageFormat);
// rename the temp file and move to a unique directory to prevent problems when
// multiple threads are emailing reports using the same temp directory
tempSubDirectory = System.IO.Path::Combine(System.IO.Path::GetDirectoryName(attachmentFileName), System.IO.Path::GetFileNameWithoutExtension(attachmentFileName));
attachmentPath = System.IO.Path::Combine(tempSubDirectory, fileNameOnly);
// EDIT --> Check to make sure target doesn't already exist. If it does, then delete it. This is for any other batch job that might have ran
// and made a tmp folder that could already be there, with an existing name.
// <-- EDIT
// The report has been successfully sent as attachment to email.
info(strFmt('%1 to-%2 subj-%3', "@SYS344685", emailContract.parmTo(), emailContract.parmSubject() ));
// EDIT - Display an error in the infolog if email failed, so an end user can resend manually.
warning(strFmt('%1 to-%2 subj-%3', "Failed to email report.", emailContract.parmTo(), emailContract.parmSubject() ));
// EDIT --> Cleanup temp file and directory, because once the document is emailed, we don't need the document nor
// the folder. It can always be reprinted from AX client if needed.
System.IO.File::Delete(attachmentPath); // Delete file
System.IO.Directory::Delete(tempSubDirectory); // Delete directory