Re: Suggestions wanted on reducing time to assemble month-end invoices

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Hi Booth

I hear you on your approach. Our Print services folks are looking at a 
machine that, in fact, does what you suggest at the final end. Trouble 
is, it is limited to stuffing maybe 8 sheets, and our bundles can be an 
order of magnitude larger, so can't be processed with this machine.

The idea of looking at the end first, though, is worth more looking, I 
think.

Vern

On 11/2/2017 8:04 PM, Booth Martin wrote:
> 8 person-days is a hefty uptick that helps frame the cost/benefit 
> order of magnitude.  I'd consider a solution that started at the 
> back-end and worked forward.  Something along the lines of finding a 
> printer solution that prints, folds, and stuffs.  Having found that 
> piece, I'd then have to prepare a scenario where I feed the print 
> streams to a data file that feeds the printer.
>
>
> On 11/2/2017 4:07 PM, Vernon Hamberg wrote:
> > Y'all
> >
> > We are at 7.1 and cannot upgrade to 7.3 at the moment, as we want to do.
> >
> >
> > We have a month-end process (Robot job) that prints invoice reprints 
> > for customers who want snail mail.
> >
> > In that same process we print an itemized statement of those invoices 
> > - separate programs.
> >
> > Both outputs are in order of the billing address - we send everything 
> > together that goes to a single billing address, while each invoice 
> > may be for different service addresses.
> >
> >
> > Currently it takes 8 person-days to riffle through the stacks of 
> > invoices and the stacks of statements and match them up, then stuff 
> > them into envelopes or whatever.
> >
> > Our central print services has been talking with us about a machine 
> > that can print or sort, burst according to, say, a 2D barcode, and 
> > stuff each set into some kind of envelope.
> >
> > Problem is, it can stuff only up to maybe 8 sheets. Our bundles often 
> > have over 100 sheets to the same billing address.
> >
> >
> > I was told that there might not always be a 1-to-1 relationship 
> > between statement and invoice.
> >
> > Invoice reprints can either be AFPDS or USERASCII (we are using the 
> > AFPRSC keyword at 7.1 and converting for inclusion of PNG signatures).
> >
> >
> > It seems we need some other way to handle this, to reduce the 
> > person-time involved. And help with accuracy (that hasn't been 
> > brought up, I just mention it, since people currently go through the 
> > stacks and scan by eye for a change in billing address).
> >
> >
> > So I/we have been talking about finding a way to combine the output 
> > of the 2 programs in a way that would improve the time to do this by 
> > hand.
> > 1. Put in a colored separator sheet or other marker to help people 
> > identify a set of invoices
> > 2. Combine the output from the 2 programs in the correct order 
> > (statement first, then related invoices)
> >
> >
> > I've done a little research on a setting on the DEVD for separator 
> > drawer and separator program, as well as other separator settings on 
> > PRTF and OUTQ. And am aware of separator settings on printers, though 
> > not very much up on that.
> >
> > We are open to commercial solutions within some kind of reason.
> >
> > Regards
> > Vern