Output doc PDF filenames

[mike_monin]

I do not currently see a config setting to control the format of the PDF attachment "file name" so it appears to be hard coded. Currently, the file name is saved to the server using this naming convention: <Output Document SFM Transaction Id>_<SFID of the header record>_<yyyyMMddHHmmss> when generating a report PDF. For example: Field_Service_Report_a1LJ0000001jGzEMAU_20141021095745.pdf

Can this be configurable? This would be similar to using the ServiceMax Setup --> Event Subject rules which allow you to define the format of the Event Name based on defined rules. pdf‌ outputdocs‌

[rangarajan_v]

File names are not configurable and its defined to be in this format. We can make this configurable if needed. Suffixing/prefixing an unique value like timestamp will be required to make the document unique.

[mike_monin]

Thanks Ranga.  I just wanted to confirm in case I missed where that config setting was.  ;-)

[dawn_plaskon]

I think the filename should also include the ParentID since this makes it easy to set up custom activity for the attachments.  That is 'select id, name from attachments where name contains ParentID.  ParentID is a fixed unique identifier on the filename.

[colin_jolliffe]

Our customers would like us to be able to include serial numbers in the file name. As this would allow them to identify what IP the report relates too, especially when there are hundreds of IPs on site.

[russjaco]

We would like the file name to be short as possible, we have some Professional Services code that automatically emails the service report to the customer, and quite often it gets caught in customers spam filters due to the long name of the attached file.

[johnw]

This thread makes me sad .

We just configured our Service Report in our Sandbox, our Service Management team is pushing to get the Service report generated from the iPad when our FSEs close the call. this will impact how we can move forward with this functionality.

A customer facing document should be clear as to what it is. The SFDC ID Key and a 17 digit date time code equal  what the FDA called "Gobbledygook". Both the US and EU have published guidelines for clear writing.

As a Medical device manufacturer, our Service reports become a part of the Device History record which is regulated. Our current method to label our manually created PDF Service Order (outside of ServiceMax) is FSO_WorkOrderNnumber_Serial Number. FSO is Field Service Order in our ERP. If we were to generate two documents for the same work order, I would add a version number as in the standard SF Quote documents.

[sjef_wijnen]

What is the current status? For us it would be great if we could setup our own naming convention for all output documents, generated by ServiceMax.

[jeroen_schwankh]

Tip: As a work around we have created trigger code. When synchronized from the mobile client or generated online we have the attachments of service reports renamed to a desired output. But I agree it would be better if ServicMax supported formulas to do this.

[alex_langston]

This is a clever workaround - can you post a portion of the Apex code for others to emulate?

We use something similar - except we change the name of the report during the process of EMAILING it to the customer:

                    // Use information in the most recent Attachment to populate the email message attachment info.

                    Messaging.EmailFileAttachment emailAttachment = new Messaging.EmailFileAttachment();

                    emailAttachment.setFileName('Service_Report_' + wo.Name +'.pdf');

                    emailAttachment.setBody(woServiceReportAttachments[0].Body);

This does not fix the filename on the server - but does fix it from a customer-facing standpoint

[dbrieck]

I don't think a trigger will work with the way the emails are being sent, which is why it was never posted. It works great when you add attachments from the web, but the code for sending it via email is a little convoluted.

I wrote a trigger that does the rename before insert, and that didn't work. It just made 3 copies of the attachment because the iPad apparently kept trying to sync it, but was unable to find it by Name.

I then re-wrote it to work before update, which worked nicely and only gave me one copy, but it ended up breaking the email code.

I think the solution is to modify the apex code (RAPID_SVMXC_AttachmentHelper) that sends the email, but there are some validation issues I need to sort through.