Last address field could be country...

[PakRicard]

Hi all:

Last address field on debtormaster or suppliers is usually used for Country. I can't imagine use the latest field of an address for continent or planet or something larger than country (at least on this century).

So, could we have a table of countries and fill this field from the countries table?

It will avoid the problem of manual entry of the same info in different ways. Ex.: US, U.S., U.S.A. United States, etc all OK, all possible and all living in my DB to refer to one country. If we had this info in a table all the records would have the same entry, so we could filter by country easily.

I have a table of countries (found somewhere on the www) already populated (attached) we could use as a base.

Does it make sense to the developer team?

[phil]

Yes - makes sense to me... could apply to suppliers and debtorsmaster.

The only potential snag is the table of countries would need to be in a number of different languages depending on the language selected. Unless we do something clever with the display of country and use the retrieved sql in a gettext function and have all the countries in an array somewhere to enable them to appear in the translation as strings to be translated. Given that we have to have the country displayed in the appropriate language of the reader, perhaps it makes more sense to have it as an array perhaps in another include includes/CountriesArray.php rather than a table that holds multiple different values based on selected user language. Better to use gettext for translations.

A shame we can't recycle currencies table or LanguagesArray somehow. I think you are right though it is should be an array though

[PakRicard]

Hi Phil:

Then... touché!

I did not think about the translation thing. I don't know how to overcome this, also applies to the Main Menu options. I saked if could be maintained at DB and we faced the same issue.

Unless some smart solution comes up... I'm lost ;-(

[phil]

Well I was thinking we just make an array of countries like we did for the languages array

perhaps we make up a new file called includes/CountriesArray.php:

Code:

<?php
$CountriesArray = array();

$CountriesArray[] =_('Albania');
$CountriesArray[] =_('Botswana');
.
.
.
.
?>

Then include this file in the suppliers and customers scripts - and use it to populate a select box with foreach loop - the array will be populated based on the users language selection and we are away :-)

[PakRicard]

Hi Tim:

A problem with adding this abstraction level in is that the array would need to be downloaded with each page that it is used on, which will increase the page size considerably in those cases, which is not really in line with the guidelines.

So, which is your idea, should we go for a DB table (even with the translation problem) or should we go for the array?

Also whilst the concept of what exactly is a country sounds obvious in theory, but in practice people can get very emotional over it. For example is Northern Ireland a country or is it just part of the UK, or even is it part of Ireland? The answer very much depends on who you ask, and this holds true for lots of countries.

Well... personally I'm one of those feeling emotional for this issue, and would be happy to find my country into the list I sent few days ago, but it is not there (yet...).

BUT, almost 99,99% of software around us have the "country" field. When you buy anything, register in almost any website or even open a gmail account, you are required a country field. So, I think the "official" list can be very simple, is the one of the UN members.

Also, everyone is able to add or delete entries into their own installation, so webERP is not forcing to a "offcial table". I will for sure add some entries to the official table

[phil]

I don't see this as abstraction?
It does add a bit to the overhead of the page though.
However, I am relaxed on this as it is quite a nice improvement.

I will for sure add some entries to the official table

Your perogative as the Doer of the Do'ocracy

Hope this is not one "anyone" will get too emotional over!!

[PakRicard]

Hi Tim:

I need to code this functionality. Regardless of guidelines enforcements...Which is the best approach from your point of view? The array, a table in DB loosing the translation, or another one?

[PakRicard]

Following with this:
In Customers.php we have
Address Line 1 (Street):
Address Line 2 (Suburb/City):
Address Line 3 (State/Province):
Address Line 4 (Postal Code):
Address Line 5:
Address Line 6:

1) Should we remove the texts "Address Line X"? I guess we should.

Should be:
Address Line 1 (Street):
Address Line 2 (Street 2):
Address Line 3 (Suburb/City):
Address Line 4 (State/Province):
Address Line 5 (Postal Code):
Address Line 6: (Country)

As in some countries, street needs 2 lines. If you need only 1, it should not affect anything.

2) Also, on Suppliers.php there are only 4 lines, not 6 (even if there are 6 fields on DB). We should go for 6, I guess, unless we restrict suppliers to be on the same country (whatever definition you use). Not cool on a global world right?

[phil]

I am not sure it is necessary to change these fields to more specific names... some people may wish to use the fields differently and it is up to them.
The country field line 6 makes sense to change it as there it will be obvious it can now only be used for that.

[PakRicard]

Hi:

Already uploaed to SVN and modified Suppliers.php to use it.

Please check if it's according webERP rules (I hope so). If OK, I will continue with customer scripts.

Regarding the address fields names, we could set them up in SystemParameters, so each installation could have the correct ones to their needs. Currently, having Address 1,2,3,4,5 it is not clear enough for most users. Our DB has many changed fields (City name in field 2 or 3 or 4). Our final users say it is not clear enough, and I do think so. So if it's a parameter, everybody will be happy.

---

Sorry, I'm having problems commiting changes...

So files are attached here, until I fix the commiting problem.