[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Could anyone help us understand batch printing for AR Aging in 1.2.x?

Thank you for the response!

I am about to pack up and go do an errand or two, and then test this on the printer at the Think Electric office... however, I just noticed (bearing in mind also what you said about only being able to download one file) that the one file I am downloading is actually receiving all of the data from all of the pdfs - you can only see the last one, presumably because they each have start/end formatting, so only one of them makes sense to the reader, but the document is three times the file size it should be if I had only printed one, which would seem to be another good clue. 

Thanks again for the help, we'll let you know how it goes.



On Tue, Aug 9, 2011 at 5:58 PM, Chris Travers <..hidden..> wrote:
Hi Chris;

On Tue, Aug 9, 2011 at 10:20 AM, Chris Calef <..hidden..> wrote:
> Hello,
> We have been struggling for some time to make customer statements & AR Aging
> print in batches.  The behavior we observed in stock LSMB 1.2.x was that
> when we went to AR->Reports->AR Aging, and selected a number of customers on
> the list, the function would print only the first one.  Further research
> uncovered the following in rp.pl:
> ----------------------------------------------
> sub print {
>     if ( $form->{media} !~ /(screen|email)/ ) {
>         $form->error( $locale->text('Select postscript or PDF!') )
>           if ( $form->{format} !~ /(postscript|pdf)/ );
>     }
>     for $i ( 1 .. $form->{rowcount} ) {
>         if ( $form->{"statement_$i"} ) {
>             $form->{"$form->{ct}_id"} = $form->{"$form->{ct}_id_$i"};
>             $language_code            = $form->{"language_code_$i"};
>             $curr                     = $form->{"curr_$i"};
>             $selected                 = 1;
>             last;
>         }
>     }
> ...
> ----------------------------------------------
> That "last" statement at the end exits the loop after the first selection,
> hence our problem.  However, if we remove the "last" statement, then it
> prints only the last statement on the list, rather than the first.  We are
> calling the print functions and parse_template once per loop, but apparently
> parse_template is getting piled up (or something) and is unable to complete
> a series of calls to the printer (?) in quick succession.

That doesn't sound right to me.  if it was a pileup problem I would
not expect the last document to get through at all.  So something is
wrong here and my guess is it happens after the loop.

Here's what I would suggest you can do to show this.  After the loop
closes, add $form->error('breakpoint');

I am willing to bet nothing will be printed and you will just get a
nice error to your screen.

My guess is that something is happening with the $form and that it
isn't actually getting printed there....  Could be a scoping issue or
something.  However, it does sound like a bug we'd like fixed and
would be happy to integrate your fixes here if you get to it before we

> We even tried
> calling sleep() to put a mandatory pause in the process, but with no effect
> except slowing down the same undesired behavior.  The behavior is not solely
> related to the printer either, however - when we try to print PDF to screen,
> we get the same result: one download, not several, only the last one gets
> created.  When we disable the Form::cleanup function, however, we find all
> of our PDF files waiting in /tmp directory, they just do not make it to the
> final step of being sent to the browser or the printer.

You can only have one download.  We can't currently send multiple
files to you.  In 1.2 printing multiple documents is only meaningful
if you send it to the printer.

> We next went into rp.pl from LSMB 1.3, and found that the problem had
> apparently been addressed, by the following means:
>    $printhash = &print_form;
>    push @batch_data, $printhash;
> and then later,
>     try {
>         $template->render({data ="" \@batch_data});
>         $template->output($form);
>     }
> However, this approach seems to be dependent on the fancy new 1.3 templates
> system, and we lack the resources to port our whole project to 1.3 at the
> moment...

Of course.  If you had to, you could probably copy over the Template*
modules from 1.3 and use them with the old system though.  Just make
sure to install the dependencies first.
> SO, my question is, within the context of LSMB 1.2.x, does the preceding
> description sound familiar to anyone or are there any pointers anyone can
> give us as to where we should look or how we might proceed?

I am betting that:
1)  Printing is happening later than you think  (looks like it
actually happens in rp.pl when print_form() is called)
2)  By the time it is actually called, some important data is overwritten.

The code in question is sufficiently opaque however that I can't see
what it is off the top of my head.
> Oh, and another related question is: how does any of this relate to the
> actual "batch printing" (bp.pl) part of LSMB, using the print spool, which
> seems to be called only from Queue Invoices and other similar lists - and
> why does the AR Aging list not call bp.pl to do its batch printing?

Batch printing is to store documents for later printing.  We haven't
extended it to handle aging reports yetc.
> Sincere apologies for not understanding anything here that should be
> obvious.
Having stared at the legacy codebase for long enough, nothing is
obvious, which is one reason we are removing it in chunks.

Best Wishes,
Chris Travers

uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at:  http://p.sf.net/sfu/wandisco-dev2dev
Ledger-smb-devel mailing list