Mailing payslips - Attachment sent to wrong employee

[carolx]

I have a routine that emails employee payslips. If I send the payslips as text file each employee receives the correct payslip. I set up the routine to send the report to Bullzip in order to create a PDF attachment. Now some employees are getting the payslip of another employee and it is the same report file that created the text files.

Is there any other way to send pay slips in PDF format that works.

 

[JRB-Bldr]

You need to clarify if the problem you are encountering is:

1. PDF document(s) are being created but with the wrong employee's content​

2. The Wrong PDF documents are being attached to an employee's email​

3. Correct PDF document(s) are being created, but sent to the wrong employee email address.​

Regardless - First, there are a variety of other ways to create PDF documents from your VFP application.
I am sure that if you used this forum's Search tool you would find MANY of those options discussed.
Some of the alternatives are Free and others are not.

Regardless, I used Bullzip for multiple years to programatically create PDF documents for 200+ individuals each and every day and it worked just fine and reliably.

Perhaps the issue(s) you are encountering may be an issue of how you are using Bullzip.

I merely pre-configured the client's Bullzip to ALWAYS create a PDF with the same name and in the same directory.
1.Then when the VFP application needed to print it would temporarily change the workstation's default printer to Bullzip
2. Print the document with REPORT FORM <whatever> TO PRINTER
3. Change the workstation's printer back to its original default printer.
Once the VFP application created that document it 'knew' where it was located and what its file name was.
With that 'knowledge' it then Moved the document to where I really needed to be and renamed it to the final intended file name (NOTE - each PDF document was uniquely named in the end)
And then finally sent out the PDF as an email attachment.

Again this approach worked for 200+ email documents each day without fail for years.

There is another way of using Bullzip that does not involve pre-configuring it.
That way is by means of command line execution, but I have never used it so I cannot speak to its effectiveness.
However even if I were to try that approach, I think that I'd still follow the same basic methodology - just using the command line approach instead.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

That sounds like you misunderstand the timing. If you start a report with bullzip PDF printer driver, the pdf is not there immediately, so you may send the pdf for the previous employee.
You start an external process and that runs in parallel. Adjust your process and timing, maybe even set the pdf name for each employee, so you get a unique name.

Bye, Olaf.

 

[GriffMG]

I have a thought:

Always make sure you delete any existing pdf before you print the new one

Are you sure the data environment is right before/during the printing.
It could be that the report form is reopening some or all of the files
as it runs - not using the record you are expecting?

So, either put a scope clause (for invoiceno=17 or whatever) on the report
or try closing the database before it runs and see if it still does...


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Tore Bleken]

FoxyPreviewer can create the pdf and also email it. Plus it's free!

https://foxypreviewer.codeplex.com/

 

[Mike Lewis]

What exactly is the sequence of steps that you are performing?

It seems to me that you should be doing something like this:

Start at first employee
For the current employee:
  Set the PDF filename to Employee.Name + ".PDF"
  SET PRINTER TO Bullzip (or whatever other PDF driver you choose)
  REPORT FORM PayslipReport FOR the current employee
  DO your email routine, sending Employee.Name + ".PDF" to Employee.Email
Next employee

Obviously, that's not meant to be actual code, but it should reflect the overall logic. If you are doing something like that and it doesn't work, there is clearly an error somewhere in how you do it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

What exactly is the sequence of steps that you are performing?

This.

We can solve a lot of problems, but not until they're spelled out. What are the steps you're using?

 

[carolx]

I made changes to the code based on the suggestions but the payslips are still being mixed up. See part of code below.

SELECT empmail
SCAN
lcAttachment = ''
DO empslip IN pyempslipnew_1 WITH 17,"A","email",empno
SELECT payslip

*IF FILE('c:\email\payslip.pdf')
*DELETE FILE 'c:\email\payslip.pdf'
*ENDIF

=APRINTERS(arrPrinters)
lcBullzip = 'BULLZIP PDF PRINTER'
IF ASCAN(arrPrinters, UPPER(lcBullzip)) > 0
oNET = CREATEOBJECT("WScript.Network")
oNET.SetDefaultPrinter(lcBullzip)
SET PRINTER TO NAME (lcBullzip)
REPORT FORM empslip14tmplate NOCONSOLE TO PRINTER

*> Use Windows Scripting To Restore Orig Default Printer
oNET.SetDefaultPrinter(gcPrinterDefaultx)
RELEASE oNET
SET PRINTER TO NAME (gcPrinterDefaultx)
ENDIF

lcAttachment = 'c:\email\payslip.pdf'

*> rest of code
-------------
-------------
-------------
-------------

.Send(0)

ENDSCAN

 

[carolx]

I think the problem is with the Deny/Allow dialog in Outlook. If I click Allow manually it works. If I use ClickYes or Outlook Warnimg Doctor the problem occurs. Any suggestions. There are over 300 employees.

 

[Mike Lewis]

I don't understand why you are using both Windows Scripting and native VFP commands to change the target printer. If I've understood your code right, both

[tt]oNET = CREATEOBJECT("WScript.Network")
oNET.SetDefaultPrinter(lcBullzip)[/tt]

and

[tt]SET PRINTER TO NAME (lcBullzip)[/tt]

do the same thing. And why bother to do

[tt]oNET.SetDefaultPrinter(gcPrinterDefaultx)
SET PRINTER TO NAME (gcPrinterDefaultx)[/tt],

when you can simply do

[tt]SET PRINTER TO DEFAULT[/tt]

Also, you don't need to do that inside your scan loop. Just set the printer to Bullzip at the outset, and set it back again at the end of the process.

Admittedly, this doesn't solve your underlying problem - unless I have misunderstood your code, in which case my apologies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[carolx]

Mike I made the change you just suggested. I think the problem is with Outlook Allow/Deny dialog. If I click Allow manually everything goes okay. If I use ClickYes or Outlook Warning Doctor the mix up happens. There are over 300 employees. Any suggestions.

 

[Mike Lewis]

Carol, I didn't know you were using Outlook. This is the first time you mentioned it.

It really does sound like this is a timing issue - that the delay while it is waiting for you to click the confirmation is giving it time to complete the creation of the PDF. I wonder if it is worth putting in, say, a 2000 ms delay (for example, using Sleep()), and seeing if that solves the problem (at the expense of slowing the whole process).

Alternatively, have you considered adding an ID of some kind to the PDF's filename - to make it unique to the employee; then, when you come to do the email, test for the presence of that specific PDF, and if it is not there, wait until it is?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I'm with Mike to a point

if you reinstate the housekeeping code at the beginning:

IF FILE('c:\email\payslip.pdf')
   DELETE FILE ('c:\email\payslip.pdf')
ENDIF

And the have a limited loop looking for the new file before you try to email
it should work better.

Watch out though, FILE() can give false positives if a similar file exists in
VFPs PATH somewhere.

When you spot the new file, you also might wait a few moments to make sure your AV etc
hasn't decided to hold it for scanning.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Mike Lewis]

I just took a look at an application I wrote a few years ago. One of its functions was to email PDF invoices to customers.

What I did was to generate all the invoices first. Each invoice filename had the customer ID embedded in it. After all teh PDFs were done, I did a separate loop, taking each of the PDFs in turn, extracting the ID and emailing it to the relevant customer. In other words, I separated the PDF creation and the emailing into two separate processes.

I don't recall any problems with this, and I'm certain no customer ever got the wrong invoice (I would definitely have heard about it if they had).

I used XFRX to generate the PDFs, but the same general principle would apply with other PDF tools.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The best way to avoid wrong attachments is making the file names unique. Perhaps even first generate all files and then start mailing.

Bye, Olaf.

 

[carolx]

The solution is all about timing as you guys had suggested. It is so obvious but I would never have thought about it on my own. Thanks a million.

See snippet below.

SELECT Payslip
IF FILE('c:\email\payslip.pdf')
DELETE FILE 'c:\email\payslip.pdf'
ENDIF

REPORT FORM empslip14tmplate NOCONSOLE TO PRINTER
DO WHILE .T.
IF FILE('c:\email\payslip.pdf')
EXIT
ENDIF
ENDDO

 

[GriffMG]

I would put a limit on that loop.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Having a timeout of the last loop as Griff suggest, will be a good idea to not get stuck when the report fails for one or the other reason.
Anyway, just waiting for the existing if the file is not enough, it could still be incomplete, while you attach it into a mail item.

The best thing to wait for is getting an exclusive file handle on a file.

If Adir(laDummy,'c:\email\payslip.pdf')=1
   Erase 'c:\email\payslip.pdf'
Endif

* 1st pass: generating payslip PDFs
Select Payslip
Scan
   lcPayslipfile = Textmerge('c:\email\payslip<<Payslip.ID>>.pdf')
   Report Form empslip14tmplate Noconsole To Printer
   To = Seconds()
   Do While .T. And Seconds()-t0<20
      h = Fopen('c:\email\payslip.pdf',12)>0
      If h>0
         Fclose(h)
         Rename ('c:\email\payslip.pdf') To (lcPayslipfile)
         Exit
      Endif
      DoEvents
   Enddo
Endscan

* 2nd pass: mailing
Select Payslip
Scan
   lcPayslipfile = Textmerge('c:\email\payslip<<Payslip.ID>>.pdf')
   If Adir(laDummy,lcPayslipfile)=1
      * send mail
      Erase (lcPayslipfile)
   Else
      * payslip missing for employee
   Endif
Endscan

Bye, Olaf.

 

[Olaf Doschke]

And actually erasing the files right after sending the mail might be too soon, remember you have parallel runnning processes and outlook first needs to read in the file as attachment. You already continue in the loop while outlook does that.

Bye, Olaf.

 

[Dan Freeman]

Do we REALLY still put computers into hard-charging loops when it's so easy to call the Sleep() API function?

VFP is a notorious resource hog. Keeping it in a loop just makes it more likely that the other process will take longer.

DECLARE Sleep IN kernel32 INTEGER dwMilliseconds
Do While Not File(whatever)
   Sleep(5000)
   * test exit conditon
Enddo

(Obviously that code needs fleshing out, but it doesn't constantly use the CPU!)