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 **********************************************************************
