View Full Version : Must Close Re-Open ShipRush between every label; Label not sent to printer otherwise

12-04-2007, 12:11 PM
This is the problem I am having:

1. I open QuickBooks, and open the receipt I want to ship for.
2. I open ShipRush, then select the shipping method
3. I fill out the ShipRush form as normal
4. When I select for it to be shipped, the Save As dialog box comes up (We have Microsoft Document Writer selected as the printer).
5. I save the file and move to the next receipt, and repeat steps 2 and 3.
6. When I attempt to ship this second label, the postage appears to be purchased, but the label is not sent to the printer.

If I we want to print the labels as we go, we have to close and re-open Shiprush between each label. Also, if we go ahead and pay for the postage for all of the labels, and go to View in order to print, we have top close and re-open ShipRush between every printed label.

Is anyone else having this problem? Does anyone know what might be causing this?


12-04-2007, 12:35 PM
Just as a test:
Go into Settings and change the printer from the MS Document Writer to a physical printer
Run two test shipments (if using Endicia, set the print in demo mode so you don't get charged for the testing)
Does it print correctly?

If so, this would be an issue with Microsoft Document Writer. Possibly you can turn off Fast Printing in the Print Settings in SR to see if that helps.


12-06-2007, 09:55 AM
Last night we tried the following:

1. Microsoft XPS Document Writer: it printed the first one, then wrote 0 byte files for all subsequent labels
2. Fast Printer On//Off: no effect

since we have no physical printer (this is on a server), we can't try it out. However, it does fail for multiple printer types/drivers.


12-06-2007, 09:58 AM
Help | About in ShipRush. What version\build is this?


12-06-2007, 11:25 AM
Posted response to the wrong post:

ShipRush version :

12-06-2007, 03:24 PM
You mentioned: "since we have no physical printer (this is on a server)"

This setup sounds.... unconventional ?

Can you help us understand the setup?


PC model X, running Windows version Y, connected to a brand A, model B printer using an XYZ cable....


12-09-2007, 11:48 AM
We are running Windows Server 2003, I believe, and our employees are accessing the server remotely using Remote Desktop Client. The only printers available are document printers: PDF, XPS, and TIFF. These files are copied over and printed physically on the local computer. This printer cannot be shared across the Remote Desktop Client.

The local printer is a Brother 8065DN network printer, but this does not matter as far as the ShipRush software is concerned, since this printer is only used once the files are copied over.


12-09-2007, 02:04 PM
OK. This is an unusual setup.

So the problem might be stated this way:

"If I use remote desktop to access the win2003 terminal server, I can open Notepad, type TEST, and print ten times to my tiff printer. Every tiff created is valid. But if I use ShipRush to print to the same printer, the first label is valid, but the next 9 are size 0. I have tried the Fast Printing checkbox on and off and it makes no difference."

Is that accurate?

Can you follow those steps, and confirm that it actually comes out this way?

12-09-2007, 06:40 PM
Yes, I can print multiple times outside of ShipRush. The only falsehood seems to be that, actually, not all of the files are 0-sized, but they are all not proper files of whatever format. So, your statement is accurate othe than that.


12-15-2007, 09:37 AM
Bump. Any news on what could be causing this? Every other piece of software prints fine.

12-15-2007, 12:10 PM
Sorry, we do not have an update on this.

We agree that this setup should work. However, it is not a conventional setup for ShipRush.

We have opened a case on this, ZF Case 15107, but it may be some time before it is examined.

If you like, you could open a Level III support incident ($195) with customer service, referencing the above case #. That will push it up so it at least gets looked at within a week of opening the incident.

Sorry we do not have a fast answer for this.