We use SAW to put the pick tickets in a folder for each warehouse, then IT has a script to monitor that folder & push to the physical printer. I haven't found a way to have SAW send directly to a printer yet.

Have you tried to put that script into SAW. It has the ability to run scripts. With SAW version 10.02 and newer, it supports VB.NET scripts in additional to VB. The WWB.NET Scripting language enables WinWrap script writers to use VB.NET style syntax in their scripts. WWB.NET Scripting Language scripts can access and utilize Microsoft .NET Framework’s vast array of public classes and interfaces.

We do this with Visual Cut.  It has a built in function for printing... which can be added to the command line used to generate the output.

If you need to do this real-time (not in daily batches), VC doesn't handle what's been printed on it's own... you'd need to update printed flags as part of your process, or use ActionQ to handle that part (where AQ sends the print command to VC...).

As with any command line parameters in VC, the printer name can be a formula field, so there is no need to manage multiple jobs for each warehouse.

Would using the multipart form printing affect anything going the VC route?  I know we cannot print the multipart form through our rds main sage server.

Does anyone know what temporary file the pick tickets are sent to before printing?  I thinking we can use SAW to catch everything in that file when we run the picking sheet printing task and then make sure those files/orders have printed.

Printing status is saved in a few checkbox fields in SO header, not a temp file.

If you are talking about the work table data, that is in a new file every time (tagged with user and date/time stamp).

The pick tickets are printed based on a Crystal works table that doe not exist until the printing program creates and populates it. I have done this in the past by recreating the works table in Access in a query and then changing the data source from Sage to the Access query and then SAW can sent it out.

Yes, talking about the work table, but in the work table file SO_PickingSheetWrk I do not see the "PrintPickSheet" field, which is what I am thinking we need to track. BigLouie I am assuming you could recreate in SQL the same as in Access?

SO header has the printing status.

The work table has the temp data used during printing... volatile... only contains the data for the few seconds needed for the printing program to process the output, and in a table copy (in Premium/SQL, you'd be looking in tempdb...).

Yes, you can create a SQL View to mimic the work table, but it is a very complicated to set up and adapt the form.  We typically just start with a fresh new report from the raw tables (instead of trying such a shortcut, which doesn't save much time, and complicates things long term... I'd say you only want to do this if you have many different form codes to convert, where pointing them to the View would indeed save time).

Yes you can. The trick is the name the query in SQL the same name as the works table so you can just switch data source and save the report without having to do a lot of editing work.