webERP Forum

Full Version: Missing Address Data on Invoice PDF
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
When invoicing to the HO the "Sold To" area in the PDF is missing address data, specifically Address5 and Address6. This data shows if viewing HTML version.

Looking at the code I see these fields are excluded when invoicing HO but included when invoicing Branch.

I also see these fields are excluded for the "Delivered To" area in the PDF.

I changed the code to suit in but I have to ask what is the rationale behind these exclusions from PDF but not HTML? Is this intentional functionality?
Sounds like they should be in there. In the parts of Africa where most of my customers are addresses don't run to that many lines so I never notice. Does it all still fit once you have made those changes? If so can you submit the line changes you made on here?

All fits just fine. I will post changes shortly...
Paul, were there any changes to know here, or are they already covered by some other update?
(01-08-2018 01:39 PM)TurboPT Wrote: [ -> ]Paul, were there any changes to know here, or are they already covered by some other update?

Sorry... I forgot about this...

I attached my files for reference but please note I added a few commas for my USA locale.
Yes, I see in the two additions for the address6 in the non-portrait file, plus the comma and extra space for these two lines and the rest.

I'm a little hesitant about adding the comma separation specific to US address between city and state (for example: Atlanta, GA ... or Atlanta, Georgia).

Is there a better way to handle such situations for locale addresses, or should we just leave the comma out for now? I can perceive a conditional check to meet US needs, and no comma for others, but I also realize would be a daunting task to apply to all areas in the code base where such a change would be necessary. (without some sort of helping functionality to ease the effort) Thoughts?
Addresses are a very country specific thing, and even within a country address formats are not always consistent. For instance in the UK I live in a town (Didsbury) that is within a city (Manchester) and frequently one or the other gets left out of the address, but any communications still reach me. The only field that is really important is the Post code (Zip Code) and that should always have it's own field. Other than that it is possible in the UK to have 4, 5, or 6 line addresses. In East Africa the concept of postal addresses as we understand them doesn't really exist. The best that you find is a town/PO box combination. Many times I have been training people to use webERP and when they get to the address fields they look blank.

So, my preference would be to have it as free form as possible. That means in PDF reports ignoring blank lines so the address

Line 1 - 123 My Road,
Line 2 - My Town,
Line 3 - My County,
Line 4 -
Line 5 -
Line 6 - M5 1TH

is printed out as:
123 My Road,
My town,
My County,
M5 1TH

Does any of that make sense?

Yes, that makes sense. That is very similar to a US address, the zip code is most important, with a usual 3 or 4 line format:

Person or Business name
(address1) a street name with postal#. (alternatively, this could be a Post Office box#, if used)
(address2) typically used as 'extra info' to address1: an apartment#, suite#, or other reference, such as 'c/o' (care of) or 'Attn' info. [left blank if not used, no output if blank]
(address3) normally contains the city, state and zip code together on one line.

By the nature of the "other fields" being blank (and even if separated by a space or two), would still seem to print as you show in the 2nd part in the previous comment.
Of course, I realize that this might not be true for all areas where addresses are printed, but I've seen this to be the "general case" in other areas.

So, based on that info, I'll leave the comma's out, but add the additional address6 part that only occurs in two places. One file already has this included (the portrait), but the other does not, so Paul (Becker's) change makes this consistent.
I just checked ECi M1 ERP (from AUS) and it is not free form like webERP. Seems a bit odd...

Since their target is "the world" I wonder how this works out for them?

Not the comma's (per the previous commentary, however, I did replace the comma's with a space for this commit), but the added address fields and several areas where the diff showed that an extra space was added between some address fields (which I assume was for spacing?), have been committed to SVN.
Pages: 1 2
Reference URL's