Sage 100

Error: ""The directory in P/L Form Maintenance is invalid or not accessible from this workstation"" 2013 Advanced - DD stubs. The path to the folder has not changed. I followed Sage KB article on this. User can create text doc in the folder. At least 3 users have same issue from different workstations. Client says IT hasn't made changes. PR journals were successfully generated, although to a different folder. I created a new folder right ""next to"" the journals folder, but they won't go there, either. Last PR was last week and there was no issue. Ideas?

Is this an issue with the account running the service / app server ?

Had this situation last week - the user account for Sage service password had changed, but not in the service. It took 2 and a half days for the service to balk! Maybe it's the same.

Hmm, running as app, not service. Will have to check if the account password changed.

Would this be relevant if running as app?

I think the account that is being used to run the App would be relevant - am dealing with another client, permissions issue with the user account that initiates the App.

The account has to be a domain not local. If it's local the server still runs but can't see any other server locations. I ran into this with an advanced install where the files were being stored on another server. It's easy enough to check if you can convince IT to change the account running the Sage app.

Just a reminder about this goldie oldie thread from @AlnoorCassim Can't say enough of the importance of it. https://90minds-com.socialcast.com/messages/20400621

Thanks - I had Sage on this for quite a long time - unresolved. Next step: get IT involved. The account running the App server is not the one it used to be, so looking into whether it's a domain or local account. I haven't been on their server in a while, so not sure what changed or why.

The easy way to test is to start up MAS 90 style. If it works then problem is the service account.

Turns out it was the account. I noticed that the user running the App Server was different from the usual one. Spoke with IT, who told me the new account IS a domain admin (it was their name). But they restarted under the old account and problem solved. Again, they run as a program, not service.

Whether the App Server is run as a desktop application like your case or as service as with others others, the principle is actually the same. The UNC path in P/L Form Maintenance is validated from the MAS server with whichever Windows login the App Server is running under (as an application or service). Also the new account IT setup even though it was a domain account already, I'll bet you if we were to have investigated further by trying the UNC path directly at the server in Windows Explorer that a ""challenge response"" would appear asking for the user / pswd OR a permissions error would appear. That is something that would block access. Anyway I'm very glad it worked out for you!!

Thanks @AlnoorCassim. Didn't think about trying MAS90 style. Appreciate your input, as always! Also for validating my question about app vs service. <Rant On> - Iif I had a nickel for every time an IT person told me an account they set up is in the admin user group and had all the same rights as the head honcho ADMINISTRATOR, I'd be awash in wealth. It just isn't so. But they fight me tooth and nail until something like this happens. <Rant Off>. Also, curious why all other Paperless docs generated, but forms didn't.

The quick wise-ass answer is it was coded that way. That is Paperless journal printing opens the Paperless path and PDFs from the wkstn/client side while with Forms it opens from the server (to validate the path I guess), then opens and PDFs from the workstation like journal. Could be a design bug but more likely it was either a) Different programmers or b)Inherited inconsistent design back when it was an Extended Solution.

Soooooo wish they would just go through all the code and improve the consistency.........

@JeffSchwenk you're such a dreamer! :-)

Update: sure enough, it worked in MAS90 mode; and from the server, navigating through the UNC path to create a file threw a permissions challenge. IT modified permissions and got it working.