Skip to main content

Hello Community,

My question relates to the filename that is created when using docman functions VIEW and PRINT in IFSCloud 23R2. 

When printing a document using File Operations\Print Document in DOCMAN, the filename that is generated is FILENAME.DOCX, where as when using the View Document command, the filename that is generated is Copy of FILENAME.DOCX. 

The value that is provided in the Macro ScriptValues of COPY_OF_FILE_NAME is Copy of FILENAME.DOCX, so I dont understand why the filename doesnt follow. 

I have no Document Class Process Actions setup, so that is not manipulating the file name. 

Does anyone have any ideas? is this by design?

David.

Cloud 23R2

@david.harmer 

It sounds like a bug, or unwanted behavior at least and I think you should file a support case.

By the way, what kind of problem does this cause for you?


Hi @Mathias Dahl

I will log it as a case and post the outcome here. The problem comes as we are trying to intercept documents as the “Print Attached Documents” process is run with Document Macro’s to populate the documents with info. This works well in Apps9, however we have found 2 issues with this existing process when migrating to Cloud 23R2. 

  1. The problem with the filename, which we can fix with some VBS code to check for “copy of” and if not found, search/replace the COPY_OF_FILENAME value of “Copy of “, with “” and that works OK, 
  2. In Cloud, it appears we have lost the ability to run Macro’s as part of the Shop Order Report (Print all attachments) functionality, it appears, that there has been some changes here. 

We can run a Macro when calling the Print command from Document Revision page, Aurena Agent looks like this:

Here is from Doc Man (enabling Macro)

5/06/2024 3:53:13 PM: Executing method:GetLocalProperty
5/06/2024 3:53:13 PM: Execution SUCCESSFUL!
5/06/2024 3:53:13 PM: Executing method:GetLocalProperty
5/06/2024 3:53:13 PM: Execution SUCCESSFUL!
5/06/2024 3:53:13 PM: Executing method:FileExists
5/06/2024 3:53:13 PM: Execution SUCCESSFUL!
5/06/2024 3:53:13 PM: Executing method:GetLocalProperty
5/06/2024 3:53:13 PM: Execution SUCCESSFUL!
5/06/2024 3:53:14 PM: Executing method:Download
5/06/2024 3:53:24 PM: File saved to :C:\Users\me\Temp\INSPECTION (TCMD_AV - 1089182 - 1 - AL1) - 1.docx

5/06/2024 3:53:24 PM: Execution SUCCESSFUL!
5/06/2024 3:53:24 PM: Executing method:RunLocalMacro
5/06/2024 3:53:34 PM: Execution SUCCESSFUL!

 

Here is from ShopOrder (not enabling Macro)

5/06/2024 3:31:00 PM: Executing method:EnumeratePrinters
5/06/2024 3:31:01 PM: Execution SUCCESSFUL!
5/06/2024 3:31:17 PM: Executing method:GetLocalProperty
5/06/2024 3:31:17 PM: Execution SUCCESSFUL!
5/06/2024 3:31:17 PM: Executing method:DownloadAndPrint
5/06/2024 3:31:28 PM: File saved to :C:\users\me\INSPECTION (TCMD_AV - 1089182 - 1 - AL1) - 1.DOCX
5/06/2024 3:31:28 PM: Execution SUCCESSFUL!

It appears ShopOrder printing calls the command “DownloadandPrint”, where the Download and Print actions are executed as a combined command. 

We have also logged this with IFS support, as the behaviour is not the same as Apps9, of which our working process is established. 

 

Not sure if you have any insight into this at all, but would love to hear if you do!

David.

 


Thanks!

About problem 1, it's a simple mistake in the conversion from IEE to Aurena/IFS Cloud. Macros are not used by that many customers and I think it's not very common to use print macros.

As for problem 2, it should be directed at the Manufacturing team who owns the shop order printing feature.

What kind of documents are you printing and what information does the macros fill in? What file type is used?


Hi Mathias, again, thanks for responding, 

These are Word documents, that detail the specific instructions on how to perform MRO activities. We have a regulatory requirement to have them completed by the technicians as the work is being performed. Arguably, these could be control plans, however the instructions are detailed, and we found it time consuming to complete online by techs, who’s roles are more suited to performing the tasks, rather than input into a computer. 

The Macro populates the word document with the part/serial, the operation no and the shop order no, as well as some other details from the SO, this also is an FAA and EASA regulatory requirement. 

I think the issue needs to be directed at the framework team, as the behaviour is different than Apps9, as I said, of which a trusted process has been defined. I understand that some processes will be adjusted as part of the upgrade to Cloud, but for us in Aviation, this is one that needs to be corrected. 

Thanks,

David.


@david.harmer 

Thanks for letting us know more about the use case.

And no, it's not a framework problem, one issue is in Docman (the file name problem) and the other in Manufacturing (not running macros when printing the shop order).

 


Reply