[Koha-bugs] [Bug 12035] New: Purchase Order Overflows Incorrectly

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12035

            Bug ID: 12035
           Summary: Purchase Order Overflows Incorrectly
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Acquisitions
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: dcook at prosentient.com.au
        QA Contact: testopia at bugs.koha-community.org

Currently, if you add a large number of baskets while using a "OrderPdfFormat"
of "pdfformat::layout3pages" or "pdfformat::layout3pagesfr", the basket table
will overlap over the bottom footer (which includes the page numbers), and the
overflow will start mid-way down the new page.

This is because we've configured our PDF::Table objects incorrectly for the
printbaskets() sub. 

Of course, the chances of having enough baskets in a basket group to trigger
such an overflow might be quite small, so this might not happen very often.
Still, it's a bug nonetheless. You can test it out by filling your database
with bogus baskets; I've included some SQL at the bottom of this bug report to
aid with that.

Layout Config:

layout3pages.pm,layout3pagesfr.pm:

Current config for printbaskets:

start_y =>  230/mm,
next_y  => 230/mm,
start_h => 230/mm,
next_h  => 230/mm,

Note that the "next_y" and "next_h" are the same as the "start_*". This means
that they'll start midway down the page on the new (overflow) page.

My suggested replacement for printbaskets:
start_y =>  230/mm, #($start_y - $start_h = $bottom_margin), according to
PDF::Table source code
next_y => ($height - 5)/mm,
start_h => 210/mm,
next_h  => ($height - 25)/mm,

I'm using the $height variable here because that's the same measurement used by
some page headers in the printorders() sub in this same module. 

--

The printorders() subs are all right in all the "OrderPdfFormat" options. The
bottom margin is probably too large in layout3pages(fr).pm, but better too
large than too small.

layout2pages.pm:

printorders:
start_y => 285/mm,
next_y  => 285/mm,
start_h => 260/mm,
next_h  => 260/mm,

layout3pages.pm,layout3pagesfr.pm:

printorders:

start_y => 270/mm,
next_y  => 285/mm,
start_h => 250/mm,
next_h  => 250/mm,

---

[Note: the following SQL was created based on a Koha 3.8 database so YMMV.]

*Create bogus baskets:

INSERT INTO aqbasket Select null,rand() as
basketname,note,booksellernote,contractnumber,creationdate,closedate,booksellerid,authorisedby,booksellerinvoicenumber,basketgroupid
from kohatest38.aqbasket where basketno = 8;

*Create bogus orders:

INSERT INTO aqorders Select null, 1,
entrydate,quantity,currency,listprice,totalamount,datereceived,booksellerinvoicenumber,freight,unitprice,quantityreceived,cancelledby,datecancellationprinted,notes,supplierreference,purchaseordernumber,subscription,serialid,(SELECT
basketno FROM aqbasket WHERE basketno not in (select basketno from aqorders)
limit 1) as
'basketno',biblioitemnumber,timestamp,rrp,ecost,gst,budget_id,budgetgroup_id,budgetdate,sort1,sort2,sort1_authcat,sort2_authcat,uncertainprice,claims_count,claimed_date
from aqorders limit 1;

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.