@Hurremoglu 

Assuming you are on app10 please check the correct path was given in document_ticket_temp value in document default values as below.

Usually this path is given inside the server ifs is hosted.

I suspect there is a \ in this values in yours which could be causing the problem

Can you provide a screen shot of that? 

Was your issue resolved? We are having the same issue for a customer of ours, and we see the same character ‘\’ at the end of the path which is not there in the path ‘DOCUMENT_TICKET_TEMP_PATH’ entered under Document Basic. Our customer is on APPs 10. Would appreciate if you could mention how you got it fixed.

If you are allowed to share it, what is the exact error message and what is the exact path you have defined for the ticket path?

@Hurremoglu

Assuming you are on app10 please check the correct path was given in document_ticket_temp value in document default values as below.

Usually this path is given inside the server ifs is hosted.

 

I suspect there is a \ in this values in yours which could be causing the problem

This solved the problem.

For the benefit of others, that works if there is a D-drive on the server, which is not always the case. This path is provided in the IFS Installer.

Hello Mathias,

The error our customer gets is the following:

This error is raised when they try to open an attachment when logged in as IFSAPP as well as an end user. But this happens only for the ‘Expense Sheet’ window, ‘Expenses’ tab. They say that attachments are working for other windows.

The strange thing is when we log in as an end user (for whom they get the error on their side), we are able to view the same attachment without any error.

Document Basic is set as follows:

Currently our team has asked the customer to clear the contents inside the 2.0 cache folder and restart the particular device and try again.

C:\Users\<Username>\AppData\Local\Apps

This has not worked for them.

The customer has even re-started their application server and this has corrected the issue for few minutes, and then they say that the same error gets raised afterwards.

So, we have currently asked them to check with their network team. Any other suggestions would be much appreciated!

Thanks!

@Hurremoglu

Assuming you are on app10 please check the correct path was given in document_ticket_temp value in document default values as below.

Usually this path is given inside the server ifs is hosted.

 

I suspect there is a \ in this values in yours which could be causing the problem

This solved the problem.

Thanks for the response! Ours is a different issue then.

@Periwinkle 

Firstly, ask them to double check that the specified server and share is correct.

Secondly, and this is a long shot, ask them to use backslashes instead of slashes. It looks like the code adds one at the end, probably since it didn't find one.

It's also important to understand that it's the application server that access the share/folder, and using the user that runs MWS, so the access needs to be setup correctly as well.

@Periwinkle 

I guess I have to, but I almost don't believe this:

> The strange thing is when we log in as an end user (for whom they get the error on their side), we are able to view the same attachment without any error.

Are you and them testing in the same environment?

This is also very strange:

> The customer has even re-started their application server and this has corrected the issue for few minutes, and then they say that the same error gets raised afterwards.

How can the MWS access the share for a while, then not? It doesn't make sense.

Another thought: instead of providing a UNC path, can they map it to a drive letter and try with that path instead? Just to see…

Are there files created under the ticket path when users download?

@Mathias Dahl , Both the customer and ourselves were checking in their production environment. This morning they have told us it is working. I do not know what was done to correct it from their end. Thank you for your responses! 

Thanks for the update. If you can get information about what they did and report that back here, it might help others in the same situation. Clearly, something was not set up correctly and now they have fixed that.

Thanks!