Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Text issue in invoice footers
02-01-2018, 02:42 PM, (This post was last modified: 02-01-2018, 03:03 PM by TurboPT.)
#1
Text issue in invoice footers
I have a proposal to this matter, so hopefully this post is not TL;DR.

While working this issue to add controlled stock info to the landscape invoice and also due date to both portrait and landscape invoice footers, I discovered that after applying similar changes and testing the portrait mode that Romalpa clause and the 'invtxt' fields have the potential to cause trouble in the footer. (I will also test the landscape footer for similar trouble, as expect there will be after the portrait footer discovery)

The Romalpa and the invtxt fields are both capable of storing up to a little over 65,000 characters each! Granted, that an entry of that size may never happen (especially simultaneously in both fields), but in the portrait footer, after having added dummy data to test with the due date the 'invtxt' did not wrap and wandered off into the totals. Also, the Romalpa can fill the footer until it reaches the bottom margin, then other text will be garbled.

It seems that invtxt was limited to 3 lines in the landscape file, based on the comment to this code:
PHP Code:
$LeftOvers $pdf->addTextWrap($Left_Margin+5,$YPos-12,280,$FontSize,$myrow['invtext']);
if (
mb_strlen($LeftOvers)>0) {
    
$LeftOvers $pdf->addTextWrap($Left_Margin+5,$YPos-24,280,$FontSize,$LeftOvers);
    if (
mb_strlen($LeftOvers)>0) {
        
$LeftOvers $pdf->addTextWrap($Left_Margin+5,$YPos-36,280,$FontSize,$LeftOvers);
        
/*If there is some of the InvText leftover after 3 lines 200 wide then it is not printed :( */
    
}


However, the portrait file has this handling for invtxt:
PHP Code:
$LeftOvers=explode("\r\n",DB_escape_string($myrow['invtext']));
for (
$i=0;$i<sizeOf($LeftOvers);$i++) {
    
$pdf->addText($Left_Margin$YPos-8-($i*8), $FontSize$LeftOvers[$i]);

...and since my dummy string did not have "\r\n" (or even if it did) the string ran off into the totals One reason the the addText() call instead of addTextWrap(). Which I have added, but there could still be trouble if the text is too long. Is it necessary to strip the "\r\n", as the landscape does not have this handling?

The romalpa clauses in both files have similar handling, with offset differences for the two modes, and a $YPos calc difference:
PHP Code:
// Portrait handling:
$LeftOvers $pdf->addTextWrap($Left_Margin$YPos-18,280,$FontSize,$_SESSION['RomalpaClause']);
while(
mb_strlen($LeftOvers)>AND $YPos $Bottom_Margin) {
    
$YPos -=10;
    
$LeftOvers $pdf->addTextWrap($Left_Margin$YPos-18,280,$FontSize,$LeftOvers);
}

// Landscape handling:
$LeftOvers $pdf->addTextWrap($Left_Margin+280,$YPos,220,$FontSize,$_SESSION['RomalpaClause']);
while (
mb_strlen($LeftOvers)>AND $YPos $Bottom_Margin) {
    
$YPos-=12;
    
$LeftOvers $pdf->addTextWrap($Left_Margin+280,$YPos,220,$FontSize,$LeftOvers);

Which has the potential to not leave any space (or cause garbled text overwriting with other footer data) to also contain the term, due date, and account information as well.

===========

In my current copy of the portrait (and though the romalpa clause is NOT yet limited to two lines, but the string is longer to test), I limited the invtxt to two lines, like this: (note the comment too)
PHP Code:
$LeftOvers $pdf->addTextWrap($Left_Margin$YPos-10290$FontSize$myrow['invtext']);
if (
mb_strlen($LeftOvers) > 0) {
    
$pdf->addTextWrap($Left_Margin$YPos-$line_height-2290$FontSize$LeftOvers);
    
/* Only the first two lines will be printed (both having a 290 width) as the footer space is limited! :( */


With that change applied, 2 lines of romalpa and 2 lines of invtext (width of both extended to 290), terms, due date, and account info look like this:

[Image: j0wwad.png]
The first two lines are romalpa, the next two lines are invtxt, and the rest as-is.

Without the longer texts, which means the 'default' romalpa and no invtext, the output looks like this:
[Image: 2r2b3eo.png]

SO, with all that being said: (my proposal is option 1, below)
  1. Limit the Romalpa and invtext fields to two full lines in the footer, so that we have room for the other details?
  2. Should we consider placement elsewhere on the invoice for the account info, terms, and due date, so there's a bit more room for the other two?
Are there any other ideas, proposals, suggestions, or thoughts about limiting the romalpa and invtxt fields to two lines max, or some other potential handling?

Keep in mind that I'll be testing the landscape footer tomorrow. Getting these two footer areas consistent is the only matter keeping these files from commit at the moment.
Reply
02-01-2018, 09:39 PM,
#2
RE: Text issue in invoice footers
Sorry I am putting forward problems not solutions, but in many countries some the text that appears on invoices is governed by law, and may not fit within the two lines.

Tim
Reply
02-02-2018, 12:16 AM, (This post was last modified: 02-02-2018, 12:17 AM by TurboPT.)
#3
RE: Text issue in invoice footers
Would that specific to the Romalpa clause only, or other details as well?

I was wondering if any law(s) might also be a factor (as the Romalpa "sounds official"), but wasn't certain.

Here in the U.S., and likely other places I'm sure, the laws could vary from state to state, county to county, etc.

============

So, I guess I'll have to leave the Romalpa clause as-is until we get complaints about handling.

...but to the 'invtxt', which comes from the debtortrans table, could this be limited to 2 lines?
It is limited to 3 in the landscape, but not with portrait.
Reply
02-02-2018, 03:53 AM, (This post was last modified: 02-02-2018, 03:57 AM by TurboPT.)
#4
RE: Text issue in invoice footers
On second thought, until we have complaints about the footer, and to save time (and a few less changes), I will likely leave the current footer handling as-is for both PDF's, and locate the due date elsewhere on the page.

Here is the idea at this point:

On the portrait PDF, I'll put the due date above the salesperson column title, on the same line as, but to the far right-hand side of the page on the same line with "All amounts stated in...".

On the landscape PDF, I'll move the page number to the upper-right corner above the tax invoice box (in the same place that it appears on the portrait PDF), and then put the due date in the old page number position.

This way, the page number and the due date will have the same location/position on both PDF page formats, and the footer's handling will not change from how it is now.
Reply
02-02-2018, 11:43 AM,
#5
RE: Text issue in invoice footers
Paul

"Romalpa" AKA "Retention of Title" Clause https://en.wikipedia.org/wiki/Title_retention_clause
Just Romalpa was shorter.
Guess it is important to have a default invoice format that works! However, I fully expect many will have their own format to print.
Your ideas sound good to me!!
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
02-03-2018, 10:38 AM,
#6
RE: Text issue in invoice footers
Thanks for that info, Phil.

I've applied the changes, but I remained cautious about the footer, for now.

Should any future trouble arise with the footer data/handling, at least this post is here for future reference!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)