PDA

View Full Version : Export data into PayWindow



kunlenzo247
12-20-2004, 10:13 PM
I am wondering if there's a way to programmatically export data into the PayWindow system. The reason for this is because I have a Java-based application that I would like to interface with the PayWindow to handle all payroll duties. So I am wondering if there's a way I can export to XML, DB or any other related technology that can be used by PayWindow.

Thanks,
Kunle.

Paul Mayer
12-21-2004, 03:20 AM
The only fields that can be poked into PayWindow that we could use would be the hours worked. That's what our time clock will do as well as the time clock import tool that will be available before January 1st.

yticolev
03-28-2008, 03:16 AM
Sorry to reply to such an old thread, but I thought it better than starting a new thread with a similar question. This product is quite intriguing, but my needs require a high level of automation. I can handle the programming of the automation, but only if ZPAY is programatically accessible. Essentially, what I want to do is import pay information into ZPAY from a database, and export the results into another database and do this on demand from a program I create.

Is this possible?

Thanks!

Paul Mayer
03-28-2008, 01:59 PM
Our database is actually an Microsoft Access Database, see this FAQ for a link to the full database layout:

http://zpay.com/vbulletin/showthread.php?t=1009

yticolev
03-29-2008, 02:25 PM
Thanks for the reply. I do understand that the database is accessible to read and write, the question is whether I can then programatically get your program to crunch those numbers and output the data without other manual actions. If so, this is just what I want!

Paul Mayer
03-29-2008, 03:39 PM
Thanks for the reply. I do understand that the database is accessible to read and write, the question is whether I can then programatically get your program to crunch those numbers and output the data without other manual actions. If so, this is just what I want!

You said that you had a Java Based program that you wanted to interface. Of course I assumed that you were a software developer that knew how to interface with an Access database.

No PayWindow will not do anything other than what you see. We just import from a selection of time clocks and the exports you see in the Miscellaneous page of the Report Center.

yticolev
03-30-2008, 11:53 PM
Nope, I'm non technical. But I know enough to know that writing and reading a database is trivial. It is a question of whether I can command ZPAY programatically rather than interacting manually with entry/results fields.

From what the web guys tell me, they can work with any relevant language whether Java or PHP etc. (It was the OP that wanted to use Java). I'm just trying to collect preliminary information to determine if I should ask them to pursue a particular solution as their labor will far exceed the software costs.

I have not downloaded ZPAY so I can't see what you are seeing. But when you say you can import information from a selection of time clocks and export results, can this be done on an automated schedule, for example every Saturday night at midnight, or do these actions require a manual command?

Paul Mayer
03-31-2008, 01:20 AM
You need to download the program and search the help file for "clocks" and you will see the clocks we support with their export file examples. Before performing payroll, you would export from the time clocks and then import into PayWindow and then perform the payroll.

yticolev
03-31-2008, 05:22 PM
I appreciate your help, but my fundamental question is not answered. Can these export/import/export functions be automated or do they require manual input? Or programatically access any needed input commands to externally automate the process?

Paul Mayer
03-31-2008, 07:49 PM
I don't understand the question. It's as automated as possible. You need to now the time clock software to know what buttons to press to export and then in PayWindow, you click the Import button.

PayWindow is designed to be as error free as possible though where you need to open each person to pay them. So no, it is not a single click of a single button to do everything. You still need to open each person and then click the pay button to calculate the pay and then give it a visual review and save the transaction before going to the next employee.

Complete automation is how companies end up in trouble as they don't review the payments until it's too late and you've already lost thousands because of a simple error in the original data entry. This is why we require the user to review each transaction before saving.

If you want to see how it works, go look at our Tutorials at http://zpay.com/help. They say one picture is worth a thousand words and these are little movies that show you exactly how things work.

yticolev
03-31-2008, 11:49 PM
Clicking "Import" is a manual action. I need to do this every few seconds (or on demand from a website related request). Thus the need for automating this action via a schedule or programmatic access.

I am not running a real payroll, and only need relative accuracy, not absolute. No one will be paid from the results, it is only used for comparative purposes.

Paul Mayer
04-01-2008, 12:54 AM
In that case, PayWindow will not do what you are looking for and I don't know of any system that would short of paying a developer $30,000 or more to create such a system.

Sorry,

yticolev
04-01-2008, 01:54 AM
Not that it matters a lot for your business, but Symmetry Software (who also own paycheckcity.com) product is fully accessible by several programming languages. But they also have a $6,000 per year license for use, a bit too much for my budget. I did post on guru.com to find a programmer to do this and the bids are coming in at under $2,000. I would prefer an established product of course, but my needs are much simpler than the average user of a payroll company so if these prices stay firm, that will work for me. And since two of the proposals come from those already working in the industry, I suspect the quotes are good.

However, your database may well be worth the cost alone. I'll have to add local taxes, but that is far better than creating a database from scratch.