Sage 100

I have a client on Sage100 version 2015 sp2 Printing some direct deposit stubs and emailing others. Employees are receiving pay stubs that belong to other employees. This has happened twice with some REALLY scary twists. The employee can open the PDF using his/her password even though it is not their stub, AND they are getting PDF files from employees that are in DIFFERENT Sage100 company code?????? here is a short rundown of what happened. (I'm using first names to protect the innocent). the PDF files are password protected - the passwords are set to use the employee SS# **ON 6/6/2016** an employee in company ABC ""MATT"" received the Direct Deposit stub from an XYZ employee ""ERIC"" ABC Matt (mxxx@yahoo.com) XYZ- Eric NO EMAIL DELIVERY OF STUB - this employee was set to have his stub printed not emailed his stub printed and was hand delivered / mailed **Today**, we have another situation where Jeff received Fred's pay stub, but opened with Jeff's SSN ABC ""Jeff"" (jxxxp@gmail.com) xyz ""Fred"" (fxxx@gmail.com) We checked Paperless Destination Folders, each company stores PDF's in a different folder. I will need to call Sage I'm sure, but thought I would see if anyone else has seen this?

@MichaelMcDonald had the same issue. https://90minds-com.socialcast.com/messages/27926160?ref=stream

I have a client whose SO invoices sometimes go to another customer and Sage has not been able to provide and answer.

This has happened to 2 of our clients and I created a case with Sage and they said don't know about this happening at all in current versions.... Glad I'm not crazy!!

Sounds pretty scary. Out of curiosity, are they under the new Sage subscription pricing for Payroll yet? If not, are two different users processing payroll in two different companies, at the same time?

This has popped up before to me as well.

I have one client that this has happened to. It always occurred following an error 30 when printing the stubs, and was on both V2013 and V2015. I spoke with Diane Coffman about it in San Diego. Sage's resolution at the time was to change to non-graphical DD forms.

I contacted Diane Coffman in late March 2016 to piggyback on @DianaLaughner case. Diane C said she was gathering more info. That was the last I heard from Diane C. Client processes payroll remotely via terminal services (an added complexity). My client has not reported any additional problems with DD stub emails.

Thanks, I've read through the other posting; it is disappointing to see no real resolution. unless switching to non-graphical forms actually works. this client is setup with 90% of the users accessing Sage100 from a terminal server environment. I also considered that users may be updating at the same time it is possible but the check dates are not the same. The user did not report any error -30 messages. they are not on sage subscription pricing for PR just yet, but they are about to travel that road.

one thing Sage told us that applied for our client accessing Sage 100 Standard via terminal server was the printing times were too long - it was talking 20 to 30 seconds for each DD stub. Sage indicated that might be a factor. We had their IT make antivirus exclusions and that sped up the process a tiny bit, but it's still taking 20 seconds.

AHA, that gives me something to look at - I'll find out if printing is taking a long time.

@MaryMays Did that make the problem go away? or at least seem to? with random issues like this sometimes you can never be certain.

Seems to have helped - ALSO another tech in our office changed the Sage PDF Printer port from NULL to SAGE on the RD server. this resolved their error -30. They've run 2 payrolls since and are delaying sending the emails until they open EVERY one and make sure the stubs match the employee.

Interesting - didn't think you had to do that anymore. Good to know.

@BarbaraGoldstein I didn't think so either - but I was on vacation when all this happened and that's what Sage told our tech to do.

WRT to lengthy time to send paperless DD stubs - that's been an issue many people have reported. I had one customer where it took an hour to send 200 stubs. They gave up and moved to another (non-Sage) payroll providers. I believe this is some type of glitch in Sage. Good on them to blame a bug on slowness they introduced into their system.

To speed up DD stub process 1) Make sure stub is as simple as possible. - Change to a basic font and make sure all fields are the same font (we use Times New Roman 10 and 9) - Remove Bold, and underline (it makes a difference) - Remove unused text boxes, graphical images when possible 2) Make sure printer spool file is not being scanned by virus scanner (This implies that you are spooling print jobs and not going directly to printer) 3) Make sure printers are set to full duplex and don't go to sleep mode. Same with W/S nics 4) If batches are really large, and speed is critical, run the DD stub process from the server. - for this scary suggestion, we use a virtualized Win 7 workstation on the server, that can't shut down the server by accident. Steps 1-3 got us to about 8 seconds per stub on Sage 100 Std 2015. Step 4 dropped us from 8 seconds to 4 seconds. Client has about 10 companies with payroll. largest PR run is about 4000 stubs . We try not to run batches from different companies at the same time. You can also defer the stub emailing process and send them as a complete batch later.

thanks @ChrisStAmand I'm going to try all of those steps!

For clarity, my issue seemed to resolve around emailing stubs.

Wayne, our issues were with almost all of the stubs being emailed as well. Even then, there seems to be a spooling function going on. David's original post, with multiple companies getting mixed in together, makes it sound like the print jobs are possibly overwriting each other, with the PDF creation and related security getting matched with the wrong document. I just don't know enough about that process to have a helpful opinion. I do think that shortening the time each batch takes to process, and separating batches when possible , should help to reduce the possibility of batches from different companies ending up intermingled.

I get that Wayne, but in the big picture it sounds like Sage ""might"" think that it is caused by slow printing. I am going to check with the client and see what kind of printing times they are experiencing. this client has a BUNCH of company codes but I think that they don't have a lot of employees to pay at each company so they might have slow printing time and not ever reporting it since there are not many employees (probably less than 30)

I'll update everyone that the client's issue went away. We did look at spooling and printing times. I later had another idea that might be worth considering and I've added it to my arsenal if I ever run into this problem again. I would try running *UFAR on the paperless office log file for that company(s). The log file name is PR_EmployeePDFLog.m4t and it can be found in ""..\MAS90\MAS_XXX\PRXXX"" where ""XXX"" is the company code https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=32360&sliceId=1&cmd=&noCount=true¤tmsID=MS_Customer&docLink=true&isDocLink=true&languageId=&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl

to resolve one client's issue - we have them remote directly to the server and print the DD Stubs - that has solved their slow issue. Their IT people have built new servers and new virtual Win 10 workstations and the slow printing is still happening from the workstations and not from the server. They uninstalled all antivirus as well to rule that out. If the stub printing takes longer than 20 seconds per stub they will get an error -30; from the server it takes 2 seconds to print each stub. We CANNOT duplicate this slow printing issue in our lab - I brought their data and set up a virtual Win 10 desktop and printing is around 3 seconds per stub. Client's IT people want to blame Sage but I think there is something wrong with their setup. This client has 2 companies with 2 people processing payroll each Monday and they never had an issue until the stub printing started taking too long (moving from virtual servers in their location to virtual servers in a data center in another city). They never get the stubs 'crossed up' if they don't print at the same time.

UPDATE: Oct 28 2016. When I first encountered this ""mix-up"" issue I assumed the problem occurred during Paperless Office e-mailing phase (during check register and direct deposit register update). Now I realize the issue was Paperless Office generating the DDStub PDF (during DDStub printing phase). On Friday 10-28-16 I spoke with SAGE tech support person Ryan Clarke. He said he is aware of this ""mix-up"" issue with generating DDStubs and Sales Order PDFs while connected to a SAGE 100 system via a terminal server. SAGE cannot duplicate the issue, however Ryan gave me these steps to follow: 1) on the remote workstation make sure there are no local printer drivers that are SAGE 100 PDF converter (v2013+) or SAGE PDF converter (prior to v2013) 2) on the terminal server - run SAGE 100 - select company code where the issue has occurred (Note: these settings are company specific) - File > Run > PL_AdvancedOptions_ui - make sure the box = ""Use Lockfile"" is checked. 3) make sure an instance of **SAGE 100 PDF converter** is install. Use step 2) above to install it on the terminal server. 4) remove any old SAGE PDF converters (prior to v2013) on the terminal server (my client had a older SAGE PDF converter and that could be the cause of their issue) 5) change the port setting on the **SAGE 100 PDF converter** to ""C:\Users\Public\Sage"" - you may need admin login to do this. 6) verify there are no other ""Redirects"" to a remote SAGE 100 PDF or SAGE PDF converters on the terminal server. Ryan Clarke said please contact him at ryan.clarke@sage.com if you are experiencing this PDF creation ""mix-up"" issue while connected to a SAGE 100 installation via a terminal server. Since my client has experienced this issue once every six months for the last year - I cannot tell you if the above worked for my client. I will update this thread if this issue occurs again.