Would it do any harm to change "address1" on debtorsmaster and suppliers (and any other tables with the same address structure) to a TEXT field?
As "address2" is effectively already reserved for use by the postal town, "address3" for the county/state and so on, this means that all the address before the post town has to be crammed into address1, where VARCHAR(40) is patently inadequate.
Putting the local part of the address into a single field (which can included embedded newlines) also makes searching simpler when you are dealing with addresses where not all lines of the block/street/district are always included because you can run a match/partial match against a single field instead of having to check two or three different fields.
Well it would be more complex to allow sufficient space on the various reports where this comes out.
(02-27-2015, 09:44 AM)phil Wrote: [ -> ]Well it would be more complex to allow sufficient space on the various reports where this comes out.
Hello Phil. Yes, I can see that. But we have found that in practice, most people we supply systems to want some degree of customisation for their standard external documents anyway - to this end, we have made a small change in some of the report programs, so that it looks first for the named document format (PO_PDFOrderPageHeader.inc etc.) in the relevant "companies" directory before reverting to the default version in the "includes" directory. We have limited the "street" part of the address to two lines, because if all the other elements of the address are present, that is about the maximum that fits comfortably into a standard DL window envelope.
This also fits in nicely with the postcode/address javascript plugin that we are trying out.
Thankyou, Phil. Having taken a quick look at the latest release, I notice that you have indeed re-designated the address lines on debtorsmaster and custbranch, so that two fields are dedicated to the "street" address. Is there a corresponding SQL update to reformat existing address data? I can not see one in the sql directory.
To be honest I am not sure there is much point in trying to designate specific address fields to specific things. Different countries and different cultures have very different concepts of address. Apart from the country field and maybe a town/city field (I think this is needed for Ricard's freight calculation) then it's probably best to leave it up to each company to decide for itself.
Tim
(03-10-2015, 07:37 PM)falkoner Wrote: [ -> ]To be honest I am not sure there is much point in trying to designate specific address fields to specific things. Different countries and different cultures have very different concepts of address. Apart from the country field and maybe a town/city field (I think this is needed for Ricard's freight calculation) then it's probably best to leave it up to each company to decide for itself.
Tim
I can only speak with authority for the UK, but I am fairly sure most countries have a similar system and follow the protocol used by their national post office. It is essential that postcode and post town have dedicated fields - without this, import and export of data is a nightmare, the ability to use postcode/address lookup plugins is compromised, and searching for addresses is less reliable, which may be a particular issue if your marketing department is trying to target particular areas.
Hi Tom, in East Africa, (and I think in most other parts of Africa) there is no concept of a post code, and in most places not even a concept of building number/road name. I agree that each company should standardise on what fields they want to use for each type of address segment, but I have spent many hours trying to explain the concepts of post code, suburb, etc that have no meaning.
Tim