Hi Ken,
I've got some experience with this sort of thing and have a number of
thoughts and suggestions - in no particular order.

Before starting I'm assuming we can be certain all invoices to be processed
are already reviewed and OKed by a human somewhere.

#1) the PDFs. Potential for huge headaches. We get invoices from several
vendors by email which are simply emails with the invoice data. There's no
rule that says "invoice" = PDF. You could render a very nice html document
for the invoice along with a perfectly serviceable text representation and
be done with it. The crucial parts are the customer/vendor, date, invoice
number, terms, and amount. Maybe the PO. If that's on a piece of paper it's
an invoice. The rest makes it look nice.

If you don't do that use a scheme for producing PDFs that doesn't depend on
a print driver. Rule out MS PDF printer, PDFCreator et al. Spend the $$ and
get Rob Laveaux's plugin or download the presentation from a couple of
years ago on making your own in native 4D (I did this) but you must have
something that runs in code without OS print resources.

#2) dedicated email account. I really recommend your client have an account
only the database will use. Humans can check it but create a special one
for 4D.

#3) I like having two tables for these operations: [Email_que] and
[Email_log]. You could use one table with a status flag too, this is my
personal pref. I build the emails into a record in the que. Once they are
all ready I loop through those records and send them. You can link these
back to the specific invoice to provide a good audit trail.

If they send successfully I move that info to the log (I don't bother
saving things like the attachments but you may want to) and delete the
record. If it doesn't go I log the error in the Email_que and after some
number of attempts it falls out of the loop. Most common is a bad email
address but it can be other things.

A real key I found is to really break the operation in its discrete parts.
So building the email record is totally complete before dealing with
sending. Building the invoice document is totally separate from anything
else. The email loop is only dealing with sending (or not) an email. Makes
life much easier.

You mention doing batches and this fits right into that. You after the
sending loop you can report the errors or simply add them to the print que.

You can get more sophisticated by having your app check the mail box. I
wouldn't worry with that right away but pretty soon it may be worthwhile.

The other thing this will bring up is customers being able to pay on line.
If you all haven't looked at that yet this may start the conversation.

Does this help?

On Sun, Jul 30, 2017 at 1:07 PM, Kenneth Geiger via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> A typical batch of invoices (run monthly) is between 100 and 200 individual
> invoices. Any recommended plugins and/or suggestions, recommendations, or a
> direction in which to head would be most appreciated!
>
>


-- 
Kirk Brooks
San Francisco, CA
=======================

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to