Hi guys,
I know 'phone format' is already discussed many times in this forum! I hereby simply want to share my thinking about XRMS way to deal with phone format.
Actually XRMS is eliminating all character other than digits from the fields 'phone', 'fax' etc. I understand the reason, which is to convert into a dialable phone address format.
Frankly speaking, I believe not many people in Europe know about 'standards' like this and never ever heard about "canonical phone address".
Form experience, we type the phone number in many different ways even in Germany. Guys from Italy, UK and France have much more versions, I believe ...
It can look like this:
+49.211.4397.301 or
+49 (0) 211/4397-301
0211/4397-301
(0211)4397-301
and so on ...
I think it is impossible, that a admin of a CMS like XRMS can give strict advise to the users to follow one strict rule for the phone format only. I tried .... I failed!
However, it is unacceptable for my users of XRMS, that when they type in +49(0)211/4397-301 to read 4902114397301, which is also incorrect.
After having a deeper look into the sources I found that XRMS is using grep_replace function looking like this:
$phone = preg_replace("/[^\d]/", '', $_POST['phone']);
As an intermediate step it would help me much, if the great developers of XRMS could replace the search string "/[^\d]/" by a global variable, which is maybe specified in the vars.php file. I would then edit this global variable acc. to my needs. Anyway, I do not really understand, why you need the 'dialable' format all times anyway. I believe it might be sufficient to do the translation only when needed. But this is a different discussion!
Thanks for your patience reading this stuff!
Holger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your insightful notes on this topic. This is a very important topic, and one that needs more discussion and input.
First, why are all non-digit characters stripped from the string?
Answer: becasue if you don't do that, you can't search for it. From your example:
+49.211.4397.301 or
+49 (0) 211/4397-301
0211/4397-301
(0211)4397-301
If we didn't strip the non-digit characters, you'd hardly ever get the search results you wanted. Now, with current code, users could type in any of the 211 4397 301 digits, and get the correct search result. A secondary and much less important reason is that CTI integration to Asterisk,Cisco, or Skype only passes digits, and as you note, the non-digit characters could be stripped then.
Now, what do we do about display?
I've been thinking about this, and I need some input. I'd like to think of a way that we could do phone format matching from Right to Left, rather than the other way around.
The Microsoft document that you reference defines a canonical phone number like this:
+ CountryCode Space [(AreaCode) Space] SubscriberNumber | Subaddress ^ Name CRLF
Now, XRMS has already separated the 'Extension' from the main number for CTI integration reasons. So, we can safely ignore the 'SubAddress' part of the phone number, since there is a separate part of the data model to hold this information.
Now, if we are formatting phone numbers from Right to Left, the
AreaCode SubscriberNumber portion of the number is *usually* standard in any given country, with either a fixed number of digits, or a *maximum* number of digits in each section. I believe that we need to match phone numbers from Right to Left for the AreaCode SubscriberNumber portion of the number.
In Holger's example, the database would store
02114397301
or
2114397301
for the right-most digits in all the user-entered number formats that he presented. If XRMS could store a number format something like this:
(0) ###/####-###
Then the numbers in Holger's example would always be formatted:
(0) 211/4397-301
which I believe would be understandable to all of his German users, and would not be incomprehensible to non-german users trying to dial a German phone number.
We also know the country code based on the address. We should be able to look this up and match it, strip it, or add it to the stored phone number, as we need to. For Germany, this is
49
if we added the country code to the number format, thus:
+49 (0) ###/####-###
then, when matching from Right to Left, we would find all the other digits, and find a 0 and a 49 (94 rtl) perhaps not entered by the user. I suggest that the database should *not store* these 'optional' digits, as they don't change. But I suggest that the database should *always display* any optional digits. I also suggest that we should *always display* the country code *if* the Contact is in a different Country than the XRMS user. As I suggest below, I think that Country Code should probably have it's own database feild for lookup reasons, but any matching should work.
Note that I added AccessCode to my cononical phone format. We know, or should know, what the AccessCode is for each of our users: based on the user's address, based on our internal phone systems(s), etc. In the United States, this AccessCode is 011. As I recall, when in Europe, I usually need to dial 00 to tell the phone system that I need to make an international call. I believe that we need to address this in our phone formatting system as well, becasue many users will type in the Access Code as part of the number that they need to dial.
In contrast to the other parts of the number, the Access Code is specific to the location being dialed *from*, not the location being dialed *to*. So, when matching from Right to Left on a typed in number, we would need to look up the Access Code for this user based on the location of that User.
So, for the purposes of changes to XRMS, this would require that we store AccessCode and CountryCode separately in the country format table for each country, with Access Code for the outbound calls and Country Code for the inbound calls.
Now, if we have all this, we can match the conoical format that I described above and create a completely consistent Country number format.
The bad news is that this required work on how the phone_format function works in XRMS.
The good news is that with a little caution, I think that we won't mess up any data already stored in the database.
I really need comments on this from the international users of XRMS, and probably from Glenn and Beth on the XRMS development team, before we run off and change any code. Also, I'd really like an international developer to step up and work with us on this functional change, as this isn't something that is going to be high on my personal priority list. (I've got lots of other things I need to be working on for the next while, sorry.)
Holger, thanks again for bringing this up, it really does need some work.
Comments Please!
Regards,
- Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to centralize this discussion in this thread, make some decisions about what we're going to do and who's going to do it, and get this dealt with once and for all.
Information and contributions from XRMS's international community are especially important for the useful resolution of this problem.
Regards,
- Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brian's comments are really well thought out. I like his approach. I have only two comments:
1)
The 'access code' differs between countries and network providers. If you dial a cell phone, the '+' e.g. Vodafone network, the the '+' is required. In Germany the '00' is correct for fixed lines, but in UK the access code is different.
2)
I do not use the existing extension field for one simple reason. It is not displayed in the "recently viewed" window. I first tried, but later I gave up to explain to some of my users, that the number shown is not complete. However, I have a 'gut feeling', that maybe my understanding of the extension field is not correct. For clarification, if the telephone number looks like this +49(0)211/4397-0 the the country code is 49 for Germany, the area code is 211, the subscriberNumber is 4397 and the extension for the central office is 0. If you want to reach me in this company then you need to dial a 301 instead of the 0. If you dial from Germany then you do not need to dial the country code, but must add a 0 in the beginning.
Here are some more examples of phone address formats from companies throughout the European Union. From my experience European comapnies tend to use the phone address format of their homepage more or less identical to their internal databases.
I hope it helps.
One remark from my side: Please do not underestimate the 'space' between digits. Quite often it is delimiter between area code, SubscriberNumber or ext.
Holger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. Why not make the Intenational access code a user defined in settings? (e.g 011 or 00 or 001 etc).
For example we have an office in Thailand and official international code is 001, but we use VOIP for international calls and on our system (US Based VOIP) we need to dial 011. so in this case we need to define the international code as 011 and not as the Thai standard.
2. Removing the (0) from city code if exist when dialing international no. is prety much world standard (to the best of my knoledge). Shouldnt XRMS know from user settings the country location and then either dial international access (011) no (0) for city code or dial (0) for city code and no international access (011).
This ofcourse aplly only when (0) exist so that would not be a problem with city codes that dont have (0) like the USA.
Just thought.
Ori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
looking at brians posts I miss a solution for region numbers of different length... Hamburg or Berlin (and certainly some more) are have 3 digits: 040, 030. Smaller cities can have up to 5 digits.
I know that there was a limit of 8 digits for subscriber numbers. But since numbers are getting rare in some regions, the Deutsche Telekom adds one more.
On the other hand, big companies or people in small cities sometimes only have 3 digits (and for the companies a long extension)
how the country extension is shown does not matter (for us), but it would be nice to have some kind of delimiter between region code and subscriber number, and I think the "#### ########" is too simple to match out variety of formats.
I even thought of a DB table to store region codes related to cities. On first entry, one could regexp the phone and save it with the city name or zip. For display, I could easily extract the regioncode from the deflated phone number and format the output.
Bjrn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just thinking about storing the phone number internally in a single field as "00|49|040|1234567|89" but having multiple gui fields for inserting the number.
Then searching could be easily done whenever the search routine also has multiple fields in the gui.
And displaying the number is just a matter of definition, e.g. |+#####|(#)#########|### ### ### ### ###| -########### (the first 00 would not be displayed in this example)
This way the database could be searched and the display would be as defined by the enduser's admin. You also would not have to add any database fields but only gui fields and a small formatting routine which you will need anyway.
So the current database structure could be left intact, just add | as a separator (or use any other token) between parts of the number.
The gui would need a max. of 5 fields (AccessCode CountryCode AreaCode SubscriberNumber SubAddress) and everything else is up to php interpretation.
The phone number database field would then contain:
This is an intense topic. I wonder how feasable it is to get users to input the data correctly. In other words, as in Brian's post above, is it safe to assume that after a certain number of digits (from right to left) we are now looking at (or proccessing) area code, and then after another certain number of digits (still counting right to left) we are proccessing country codes? I think its a brilliant concept for the application to generate access and country codes from the other contact data, but it only works if the users don't put those numbers in.
What about a simpler, "user proof" system that basically stores 2 fields, a pure numeric field with the the non-numeric characters stripped out, and a mixed field with the original data for display purposes. The search routine would strip non-numeric characters out of the search string before searching. Not at all elegant, but "user proof" in the respect that it is both searchable for the application, and readable to users.
Just a thought.
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't you think you make things much more complicated as they should be?
Why not simply enter strings for phone numbers (including any other non-numeric characters...) and convert them into the pure number strings at the time of comparison?
This way, any number can be displayed in a form most suitable for the user, but still any non-numeric characters wouldn't disturb the search.
Why keep numbers as user formatted strings? For many reasons - in Slovenia, we have for a regular phone/fax numbers format:
+386 (0)X XXX-XX-XX, which is sometimes more convenient to write as +386 (0)X XX-XX-XXX - if some bigger company has a few 100 of numbers block, as example; on the other hand, a mobile network numbers are using format +386 (0)XX XXX-XXX. So, there is no chance to use a single common way to form phone numbers. Besides, why to force usage of country code all the time? For domestic phone numbers, I enter simply (0X) XXX-XX-XX or (0X) XX-XX-XXX or (0XX) XXX-XXX.
What would be a problem to convert both the search string in any form and the database strings into the pure numeric strings as 0XXXXXXXX and search as instring (so even parts of phone numbers would return some results - where it could also be chosen if it has to be a beginning of a string, anywhere in the string or exact match - all without taking care about formetting)?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You asked:
<quote>
What would be a problem to convert both the search string in any form and the database strings into the pure numeric strings as 0XXXXXXXX and search as instring (so even parts of phone numbers would return some results - where it could also be chosen if it has to be a beginning of a string, anywhere in the string or exact match - all without taking care about formetting)?!
</quote>
Two reasons:
Searching strings is very inefficient, and CRM data tends to have four to five times the number of phone number records as it does Contact records.
Your model requires that every user enter the phone number the exact same way if they want to find it. If you entered a number like this:
(0XX) XXX-XXX
and a user searches for the number like this:
(0X) XXX-XX-XX
it *will not match* on a string search.
We are going to change the phone format function to not strip string digits in countries where there is no phone format defined. This will preserve the user front end experience in these countries, but will make searching very frustrating (see above)
I think that right to left processing is the best way to go at this time. I'm open to better options, but any better option needs to preserve searching capability.
Regards,
- Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've suggested to do search on a pure numeric strings, as it is done now. But, instead of transforming user formatted phone number string before storing it to the database, I would read numbers from the database as they are, strip non-numeric characters from it and:
- do comparison in MySQL on TEMP tables with "cleared" phone numbers
- do comparison in PHP on array of data (not the MySQL query)
I am aware it would require some additional processing time, but I'm sure for a majority of not too big databases it could not be too big problem. At the end, how many times you expect this type of search is used (relatively to the other searches)? I'd say in less than 1% of all searches (mainly by name, location, type or category etc.). Or, make it an option in configuration file. I would probably choose this option I suggest, and someone who has a huge database and maybe not so complicated phone number formatting would choose a way it is done now...
Regards,
Marko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you said <quote>
I've suggested to do search on a pure numeric strings, as it is done now. But, instead of transforming user formatted phone number string before storing it to the database, I would read numbers from the database as they are, strip non-numeric characters from it and:
- do comparison in MySQL on TEMP tables with "cleared" phone numbers
- do comparison in PHP on array of data (not the MySQL query)
</quote>
I understand your suggestion. I'm not going to maintain a poorly performing way of doing the storage and search. I've seen XRMS databases with hundreds of thousands of Contact records, and well over a million phone records. For companies with more than 100 users, this basic size will probably be normal, not unusual. Our installation here, which I consider much more 'average' based on what I know about current companies of more than one employee using XRMS, has tens of thousands of phone records.
Your suggestion does not allow for a database-based index to be used to manage the search. This will vastly increase the [phone search time. We saw one case where searching on a phone number took almost 30 seconds on a very large dual processor server, without the several extra operations and the temporary table that you suggest.
Please try an experiment to illustrate my point. Generate one million random numbers and insert them into the database with random extra formatting characters. Select these into a temporary table, stripping out all non-digit characters. Then try to find one of these numbers. This is a very large, very expensive operation. I suspect that even on one of my large dual-Opteron servers that this type of search would take multiple minutes to complete.
Please identify problems as you see them of doing Right-to-Left (RTL) formatting of numbers by country?
RTL formatting seems like the best technical solution, as it will allow both fast database searches as well as standardized, consistent display formatting for users.
Regards,
- Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a non-trivial problem to solve, I suspect, and RTL parsing doesn't always work. For example, in the UK London numbers are of the format "020 1234 5678" but _most_ other numbers are of the format "0123 456 7890". The only solution I can think of (and it's by no means perfect: see below) is to have a mirror field for each phone number which contains only digits. In other words, the formatted number may be "020 1234 5678" and the corresponding mirror field would be "02012345678".
But even that isn't right. For a start the data is no longer normalised so if one (ill-advisedly) edits a phone field directly in the database then the mirror field won't be in sync (but it is reasonable to insist that database updates are done via the application, and in any case on most databases triggers and stored procedures could handle this - but then the code is more database type specific). Secondly, how does one parse "+44 (0)20 1234 5678"? The first zero is only dialled if the country code is not used, so what goes in the mirror field?
For me, what is more important than the ability to search by phone number - something I hardly ever do - is to have the formatting as I want which makes it easier to read the number off the screen when calling.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand your point and I've also already written that I am aware of additional expense - therfore I've also suggested 2 options user can choose. For situations like in your examples users would probably choose the way it is handled now, but I would for sure go for a pure formatted strings (as i am also doing in y installation also now, but it would be easier using an option instead of patching a number of files...).
And, I see Keith shares the opinion that a handy formatting (meaning certain flexibility against the common defined rules) is mainly more important that an efficient search by a phone number (which happens very rarely in fact and, at least in Slovenia, can be resolved also searching in Telekom phone book).
I find also the idea of a mirror field very interesting (probably it would be a good idea to introduce some cron job maintenance sooner or later in any case, and it shouldn't be a problem to go through he database synchronizing a mirror field over the night, as well as do some other cleaning or synchronization...). By my opinion, formatting as most suitable for each customer, is very important and it should be somehow preserved and displayed exactly as entered. Some common (generalized) rules would probably become too complicated, whatever the approach is...
At the same moment, I have also a question - why XRMS is not allowing to enter phone numbers as addresses, meaning the arbitrary number of them for a company (or, contact). The fact is some of my contacts (and companies in particular) do have more phone numbers, like a direct number, the secretary, the number in the other room or other location he/she sometimes works as well or so... And, on the other hand, sometimes a group of people shares the same phone (or, fax in particular) number.
But, all this are just my thoughts. XRMS is for me the best solution of what I've tried until now anyway, and I appreciate the work you've done, guys. Thank you. I'm also aware not everything someone wishes can be done just for him. And, excuse me for my not perfect English, I hope everything is still understandable...
Kind regards,
Marko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just one more idea about the formatting - if phone numbers would be in a separate table, it would be possible to select also the format type for it (types would be stored in another table) - independent of the country or so (few types could be defined through administration, and one of them selected as default one - if possible for a phone, fax and mobile numbers separately, so user does not need to specify the type all the time, but just when some non-default format is needed).
For example, I can define format types:
1. SI-phone-1: +386 (0)# ##-##-###
2. SI-phone-2: +386 (0)# ###-##-##
3. SI-mobile: +386 (0)## ###-###
and all my needs are satisfied if I can select for each number from Slovenia one of the 3 types defined above. Also, the database usage can be quite efficient, as only 8 digits have to be stored, and the rest can be appended when the number is used (the country can be specified with type, not with every number...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Although the RTL implementation for number formating makes sense from a programming aspect, it is not necessarily the best for end-users.
I suggest as an intermediary fix:
1) Create a admin preference that allows either formatting or no formatting. The table should be ok, since it seems to store more than number information.
2) If formatting is turned off, then number search is turned off. It will just save what you type in.
3) When the formatting feature request is completed, the on will format, with the caveat that only certain numbers can be formatted, but then number search is on.
This I think also makes sense for a lot of companies using open-source, since they tend to be smaller, and don't really a need the ability to search by phone number.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brian,
I´ve just re-read the thread because of dbaudone´s patch, and I still think, that RTL will not fix the problems for german phone numbers as the formats are too different (one of our recent customers has an area code with 5 and a subscriber number with 2!! digits).
I prefer the solution with the mirror field, mentionned above. Or just a way to disable number formatting within the administration. (same for the second reason of your reject, the automatic activity generation, when you click on an email, since we use a mail-to-xrms script that takes this part)
Did you already take some efforts to implement the RTL-methods? I´ll have to take a look at the phone formatting next week for one of our customers. Maybe I could add the switch instead of just hard-deactivating it?
Bjoern
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We've the same problems here with phone numbers and the users are fairly negative on the feedback. Biggest complaint: the numbers are very hard to read.
In Ireland we do not have fixed area codes so fall foul of any simple RTL templating solution. Area codes can vary from one digit for Dublin (01) to three (0xxx) for many smaller towns and villages. Phone numbers can vary too from 5 to 7 digits.
Apart from that, as a language school we operate with MANY countries and I don't want to have to keep on updating phone formats from Mongolia, China, Russia and other former CIS countries (some very strange formats indeed), through all European countries (again very messy) to the US.
My idea:
The standard way to format numbers in Ireland (and the EU?, internationally?) is: +(country code) (area code) (subscriber number):
+ is the international access code and is commonly understood in any country using GSM (replace with 011 for the US, 00 for us, etc.
Area code is entered without the leading zero
Subscriber number without spaces.
eg: +353 1 1234567 or +353 507 12345 or +1 123 4567890
Spaces occur between the area code and the subscriber number ONLY.
You can validate this as follows:
1. Must begin with '+' and one to three digits
2. Then a space
3. Then the area code without the leading zero
4. Then a space
5. Then the subscriber number WITHOUT spaces.
There is a trade off but reasonable validation rules can be carried out, the user is presented with a readable number (minimising human error). They are also forced to think about the number they are entering rather than just hammer it into the keyboard and I feel that this may result in fewer data entry errors.
As I see it, we would need to store the international access code as a system preference for the purposes of inbound calls with CTI (which we don't use, so please correct me if I'm off the mark.) This means a new function to retrieve the unformatted phone number from the database for caller ID matching:
- retrieve the phone number from the database
- strip all spaces
- remove the leading '+' and replace with the international access code from the system preferences.
I am able to do this in SQL as follows:
SELECT * FROM (
SELECT REPLACE( REPLACE( phone, ' ', '' ) , '+', '00' ) AS phone
FROM companies
)
AS ph_cti
WHERE phone = '00496921234567'
(Phone is in the database as '0049 692 1234567' others are there using a leading '+'. The number was imported that way)
I only have 686 companies in the DB. Performance-wise it takes:
=> .0055 sec to list all, ordered on an indexed field
=> .015 sec to list all, ordered on an unindexed field
=> .015 sec to run the above query
(Blistering quick Dual PIII 450MHz - eat your hearts out) ;-)
(I don't know how this scales - would it take 1.5 secs to search 68000 companies? Any SQL heads know about this?)
For outbound calls, we can either pass the number 'as is' (if the CTI system can handle it) or do a substitution as above.
This means the only thing we need to store is a system preference for our own countries international access code.
Issues (apart from everything else that has been mentioned in this thread!):
1. I'm no benchmarking guru, so I don't know if the 3-fold increase in query time is acceptable. Any SQL dudes(dudettes) out there?
2. I do make assumptions about international numbering (but have a good knowledge based on the amount of countries our business deals with)
3. I know bugger all about CTI! (We did have an intelligent faxboard on our old Netware box and it never had problems with spaces in the numbers passed to it.)
4. A System preferences setting could choose between a) traditional XRMS template based formatting, b) formatting as above or c) no formatting at all.
I'd be quite happy to help code this.
What do you think? (Shoot from the hip - I can take it!)
(Sorry about adding more very verbose thoughts to an already very long thread, and apologies if this has come up in the thread previously.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've submitted my thoughts already, but still would like to stress that for me it would be very important that ANY phone number could be arbitrary formatted, not on a format, defined per country. Why an additional field would be such a problem (to have a formatted string as entered and a dial/search string in a separate field, which is automatically calculated when a phone number is entered/edited)? And, I still suggest more phone numbers per entity (contact, company...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
NB: CVS hosts a development version, so do test first before using in production. Many developers (myself included) use CVS versions of XRMS in production.
After download make sure you go to Administration -> Database Structure Update.
In order to maintain backward compatibility, there is a new setting in Administration Preferences: Phone/Fax number cleaning. This defaults to the old XRMS behaviour of removing all non-digit characters.
The alternative is ITU-T Recommendation E.123 (+xx yy zzzzzzzz) as follows:
'+country_code area_code subscriber_number'
ITU-T E.123 cleaning is done from left to right as follows:
1. first character grouping must be '+' followed by digit(s) or digit(s) followed by a space. A space after the '+' character is discarded as are any extra spaces.
2. second character grouping is composed of digit(s) followed by a space.
3. third character grouping are all digits. Any spaces are discarded.
As there is no data validation it is possible to 'break' the formatting rules. Basically a number may begin with '+' and digit(s) and can only contain digits and up to two spaces.
Gotcha's:
This will affect how numbers are stored in the database i.e. the '+' and space characters are stored there along with the number. This will affect searching for companies or contacts by telephone/fax number. This is something that needs to be looked at.
IMPORTANT: If you are using CTI do not enable this setting (see above!).
Feedback:
Feedback is needed - please post here.
Thanks,
Francis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I get the raw database format (which is already cleaned before storing it to the database) without any special chars, which is conveniant for me in Germany.
In the get_formatted_phone function we could build the format as we prefer it for special countries.
The admin/country-address-format/index.php ist not working correctly - someone could check that, if he or she likes to :) .
Best regards
Axel Arnold Bangert - Herzogenrath 2016
Last edit: Axel Bangert 2016-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I know 'phone format' is already discussed many times in this forum! I hereby simply want to share my thinking about XRMS way to deal with phone format.
Actually XRMS is eliminating all character other than digits from the fields 'phone', 'fax' etc. I understand the reason, which is to convert into a dialable phone address format.
Anyway I found interesting website about 'standard' phone formats. I believe this is no news to you, but it was to me. Ok its from Microsoft. Sorry .....
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tapi/tapi3/address_ovr.asp
Frankly speaking, I believe not many people in Europe know about 'standards' like this and never ever heard about "canonical phone address".
Form experience, we type the phone number in many different ways even in Germany. Guys from Italy, UK and France have much more versions, I believe ...
It can look like this:
+49.211.4397.301 or
+49 (0) 211/4397-301
0211/4397-301
(0211)4397-301
and so on ...
I think it is impossible, that a admin of a CMS like XRMS can give strict advise to the users to follow one strict rule for the phone format only. I tried .... I failed!
However, it is unacceptable for my users of XRMS, that when they type in +49(0)211/4397-301 to read 4902114397301, which is also incorrect.
After having a deeper look into the sources I found that XRMS is using grep_replace function looking like this:
$phone = preg_replace("/[^\d]/", '', $_POST['phone']);
As an intermediate step it would help me much, if the great developers of XRMS could replace the search string "/[^\d]/" by a global variable, which is maybe specified in the vars.php file. I would then edit this global variable acc. to my needs. Anyway, I do not really understand, why you need the 'dialable' format all times anyway. I believe it might be sufficient to do the translation only when needed. But this is a different discussion!
Thanks for your patience reading this stuff!
Holger
Holger,
Thank you for your insightful notes on this topic. This is a very important topic, and one that needs more discussion and input.
First, why are all non-digit characters stripped from the string?
Answer: becasue if you don't do that, you can't search for it. From your example:
+49.211.4397.301 or
+49 (0) 211/4397-301
0211/4397-301
(0211)4397-301
If we didn't strip the non-digit characters, you'd hardly ever get the search results you wanted. Now, with current code, users could type in any of the 211 4397 301 digits, and get the correct search result. A secondary and much less important reason is that CTI integration to Asterisk,Cisco, or Skype only passes digits, and as you note, the non-digit characters could be stripped then.
Now, what do we do about display?
I've been thinking about this, and I need some input. I'd like to think of a way that we could do phone format matching from Right to Left, rather than the other way around.
The Microsoft document that you reference defines a canonical phone number like this:
+ CountryCode Space [(AreaCode) Space] SubscriberNumber | Subaddress ^ Name CRLF
I'm going to simplify it like this:
AccessCode CountryCode AreaCode SubscriberNumber SubAddress
for the purposes of this discussion.
Now, XRMS has already separated the 'Extension' from the main number for CTI integration reasons. So, we can safely ignore the 'SubAddress' part of the phone number, since there is a separate part of the data model to hold this information.
Now, if we are formatting phone numbers from Right to Left, the
AreaCode SubscriberNumber portion of the number is *usually* standard in any given country, with either a fixed number of digits, or a *maximum* number of digits in each section. I believe that we need to match phone numbers from Right to Left for the AreaCode SubscriberNumber portion of the number.
In Holger's example, the database would store
02114397301
or
2114397301
for the right-most digits in all the user-entered number formats that he presented. If XRMS could store a number format something like this:
(0) ###/####-###
Then the numbers in Holger's example would always be formatted:
(0) 211/4397-301
which I believe would be understandable to all of his German users, and would not be incomprehensible to non-german users trying to dial a German phone number.
We also know the country code based on the address. We should be able to look this up and match it, strip it, or add it to the stored phone number, as we need to. For Germany, this is
49
if we added the country code to the number format, thus:
+49 (0) ###/####-###
then, when matching from Right to Left, we would find all the other digits, and find a 0 and a 49 (94 rtl) perhaps not entered by the user. I suggest that the database should *not store* these 'optional' digits, as they don't change. But I suggest that the database should *always display* any optional digits. I also suggest that we should *always display* the country code *if* the Contact is in a different Country than the XRMS user. As I suggest below, I think that Country Code should probably have it's own database feild for lookup reasons, but any matching should work.
Note that I added AccessCode to my cononical phone format. We know, or should know, what the AccessCode is for each of our users: based on the user's address, based on our internal phone systems(s), etc. In the United States, this AccessCode is 011. As I recall, when in Europe, I usually need to dial 00 to tell the phone system that I need to make an international call. I believe that we need to address this in our phone formatting system as well, becasue many users will type in the Access Code as part of the number that they need to dial.
In contrast to the other parts of the number, the Access Code is specific to the location being dialed *from*, not the location being dialed *to*. So, when matching from Right to Left on a typed in number, we would need to look up the Access Code for this user based on the location of that User.
So, for the purposes of changes to XRMS, this would require that we store AccessCode and CountryCode separately in the country format table for each country, with Access Code for the outbound calls and Country Code for the inbound calls.
Now, if we have all this, we can match the conoical format that I described above and create a completely consistent Country number format.
The bad news is that this required work on how the phone_format function works in XRMS.
The good news is that with a little caution, I think that we won't mess up any data already stored in the database.
I really need comments on this from the international users of XRMS, and probably from Glenn and Beth on the XRMS development team, before we run off and change any code. Also, I'd really like an international developer to step up and work with us on this functional change, as this isn't something that is going to be high on my personal priority list. (I've got lots of other things I need to be working on for the next while, sorry.)
Holger, thanks again for bringing this up, it really does need some work.
Comments Please!
Regards,
- Brian
For completeness, I'd like to post links to some of the other threads that have discussed this issue:
Phone_Format() fn doesn't work well for some countries
https://sourceforge.net/tracker/index.php?func=detail&aid=1207068&group_id=88850&atid=588128
Phone Format example?
https://sourceforge.net/tracker/index.php?func=detail&aid=1222523&group_id=88850&atid=588129
How to use Phone format?
https://sourceforge.net/forum/message.php?msg_id=3128824
Space in company/contact phone number
https://sourceforge.net/forum/message.php?msg_id=3248913
Web and Phone Format Best Practices
https://sourceforge.net/forum/message.php?msg_id=2954756
I'd like to centralize this discussion in this thread, make some decisions about what we're going to do and who's going to do it, and get this dealt with once and for all.
Information and contributions from XRMS's international community are especially important for the useful resolution of this problem.
Regards,
- Brian
Brian's comments are really well thought out. I like his approach. I have only two comments:
1)
The 'access code' differs between countries and network providers. If you dial a cell phone, the '+' e.g. Vodafone network, the the '+' is required. In Germany the '00' is correct for fixed lines, but in UK the access code is different.
2)
I do not use the existing extension field for one simple reason. It is not displayed in the "recently viewed" window. I first tried, but later I gave up to explain to some of my users, that the number shown is not complete. However, I have a 'gut feeling', that maybe my understanding of the extension field is not correct. For clarification, if the telephone number looks like this +49(0)211/4397-0 the the country code is 49 for Germany, the area code is 211, the subscriberNumber is 4397 and the extension for the central office is 0. If you want to reach me in this company then you need to dial a 301 instead of the 0. If you dial from Germany then you do not need to dial the country code, but must add a 0 in the beginning.
Here are some more examples of phone address formats from companies throughout the European Union. From my experience European comapnies tend to use the phone address format of their homepage more or less identical to their internal databases.
Germany, Austria:
Siemens.de : +49 89 636-00
datawerk.de: +49 (0)561 70164-70
Vaillant.de: +49 (0) 21 91 / 18-0
SAP.de: +49 / 1805 / 34 34 24
Bosch.de : +49 (0)1803/ 33 57 99
zsolsnay.at : +49 (07 21) 941 43 26
wienerzeitung.at : 0316/8015/212
France:
SaunierDuval.fr : + 33 (0)1 48 76 89 32
GazdeFrance.fr : 0 811 01 3000
Valeo.fr : +33 (0)1 40 55 20 74
PackardBell.fr : 0825 16 50 71
afaq.org : +33 1 46 11 37 00
Italy:
elsag.it : +39.010.6582339
casic.it : ++39 070 2481
lucchini.it +39 030 3992.1
malbes.com : 06-68193274
Belgium, Netherlands:
liguecardiologique.be : 09/226.59.11
ua.ac.be : 03/265.3552
psv.nl : +31 (0)40-2 505 512
Rug.nl (050) 363 4376
mensys.nl: 023-5482020
Norway, Sweden, Finland:
tel-tek.no : 35 57 40 00
lanekassen.no : + 47 22 72 45 45
tel-hi.org : 415.421.6443
ra.se : 031-778 68 27
adobe.se : 031-711 25 40
alvaraalto.fi : +358 (0)14 624 809
Polandn Slovenia, CzechRep:
pascal.pl : (0-33) 82-82-816
biznespolska.pl : (22) 437 97 00
oikos.si : 01 722 64 00
epceurope.cz : +420-312500333
UK, Ireland:
Vaillant.co.uk : 01634 292300
calmac.co.uk : +44 (0)1475 650100
npl.co.uk : 020 8943 6796
cso.ie: +353 (0)21 453 5423
I hope it helps.
One remark from my side: Please do not underestimate the 'space' between digits. Quite often it is delimiter between area code, SubscriberNumber or ext.
Holger
In reply to Holger email.
1. Why not make the Intenational access code a user defined in settings? (e.g 011 or 00 or 001 etc).
For example we have an office in Thailand and official international code is 001, but we use VOIP for international calls and on our system (US Based VOIP) we need to dial 011. so in this case we need to define the international code as 011 and not as the Thai standard.
2. Removing the (0) from city code if exist when dialing international no. is prety much world standard (to the best of my knoledge). Shouldnt XRMS know from user settings the country location and then either dial international access (011) no (0) for city code or dial (0) for city code and no international access (011).
This ofcourse aplly only when (0) exist so that would not be a problem with city codes that dont have (0) like the USA.
Just thought.
Ori
Hello,
looking at brians posts I miss a solution for region numbers of different length... Hamburg or Berlin (and certainly some more) are have 3 digits: 040, 030. Smaller cities can have up to 5 digits.
I know that there was a limit of 8 digits for subscriber numbers. But since numbers are getting rare in some regions, the Deutsche Telekom adds one more.
On the other hand, big companies or people in small cities sometimes only have 3 digits (and for the companies a long extension)
how the country extension is shown does not matter (for us), but it would be nice to have some kind of delimiter between region code and subscriber number, and I think the "#### ########" is too simple to match out variety of formats.
I even thought of a DB table to store region codes related to cities. On first entry, one could regexp the phone and save it with the city name or zip. For display, I could easily extract the regioncode from the deflated phone number and format the output.
Bjrn
Just thinking about storing the phone number internally in a single field as "00|49|040|1234567|89" but having multiple gui fields for inserting the number.
Then searching could be easily done whenever the search routine also has multiple fields in the gui.
And displaying the number is just a matter of definition, e.g. |+#####|(#)#########|### ### ### ### ###| -########### (the first 00 would not be displayed in this example)
This way the database could be searched and the display would be as defined by the enduser's admin. You also would not have to add any database fields but only gui fields and a small formatting routine which you will need anyway.
So the current database structure could be left intact, just add | as a separator (or use any other token) between parts of the number.
The gui would need a max. of 5 fields (AccessCode CountryCode AreaCode SubscriberNumber SubAddress) and everything else is up to php interpretation.
The phone number database field would then contain:
AccessCode|CountryCode|AreaCode|SubscriberNumber|SubAddress
To be honest, this souds so simple that I nearly expect a mistake in this approach.
Regards,
Torsten
isdn4linux uses (or used) a library called areacode:
---8<---
The data file contains area codes for germany, austria, switzerland,
the netherlands, and some codes for the UK and US.
---8<---
maybe this could be of some use for formatting.
Bjrn
I forgot to post the URL:
ftp://ftp.musoftware.de/pub/uz/areacode/
This is an intense topic. I wonder how feasable it is to get users to input the data correctly. In other words, as in Brian's post above, is it safe to assume that after a certain number of digits (from right to left) we are now looking at (or proccessing) area code, and then after another certain number of digits (still counting right to left) we are proccessing country codes? I think its a brilliant concept for the application to generate access and country codes from the other contact data, but it only works if the users don't put those numbers in.
What about a simpler, "user proof" system that basically stores 2 fields, a pure numeric field with the the non-numeric characters stripped out, and a mixed field with the original data for display purposes. The search routine would strip non-numeric characters out of the search string before searching. Not at all elegant, but "user proof" in the respect that it is both searchable for the application, and readable to users.
Just a thought.
Paul
Don't you think you make things much more complicated as they should be?
Why not simply enter strings for phone numbers (including any other non-numeric characters...) and convert them into the pure number strings at the time of comparison?
This way, any number can be displayed in a form most suitable for the user, but still any non-numeric characters wouldn't disturb the search.
Why keep numbers as user formatted strings? For many reasons - in Slovenia, we have for a regular phone/fax numbers format:
+386 (0)X XXX-XX-XX, which is sometimes more convenient to write as +386 (0)X XX-XX-XXX - if some bigger company has a few 100 of numbers block, as example; on the other hand, a mobile network numbers are using format +386 (0)XX XXX-XXX. So, there is no chance to use a single common way to form phone numbers. Besides, why to force usage of country code all the time? For domestic phone numbers, I enter simply (0X) XXX-XX-XX or (0X) XX-XX-XXX or (0XX) XXX-XXX.
What would be a problem to convert both the search string in any form and the database strings into the pure numeric strings as 0XXXXXXXX and search as instring (so even parts of phone numbers would return some results - where it could also be chosen if it has to be a beginning of a string, anywhere in the string or exact match - all without taking care about formetting)?!
You asked:
<quote>
What would be a problem to convert both the search string in any form and the database strings into the pure numeric strings as 0XXXXXXXX and search as instring (so even parts of phone numbers would return some results - where it could also be chosen if it has to be a beginning of a string, anywhere in the string or exact match - all without taking care about formetting)?!
</quote>
Two reasons:
Searching strings is very inefficient, and CRM data tends to have four to five times the number of phone number records as it does Contact records.
Your model requires that every user enter the phone number the exact same way if they want to find it. If you entered a number like this:
(0XX) XXX-XXX
and a user searches for the number like this:
(0X) XXX-XX-XX
it *will not match* on a string search.
We are going to change the phone format function to not strip string digits in countries where there is no phone format defined. This will preserve the user front end experience in these countries, but will make searching very frustrating (see above)
I think that right to left processing is the best way to go at this time. I'm open to better options, but any better option needs to preserve searching capability.
Regards,
- Brian
Brian,
I'm afraid you haven't understood my idea.
I've suggested to do search on a pure numeric strings, as it is done now. But, instead of transforming user formatted phone number string before storing it to the database, I would read numbers from the database as they are, strip non-numeric characters from it and:
- do comparison in MySQL on TEMP tables with "cleared" phone numbers
- do comparison in PHP on array of data (not the MySQL query)
I am aware it would require some additional processing time, but I'm sure for a majority of not too big databases it could not be too big problem. At the end, how many times you expect this type of search is used (relatively to the other searches)? I'd say in less than 1% of all searches (mainly by name, location, type or category etc.). Or, make it an option in configuration file. I would probably choose this option I suggest, and someone who has a huge database and maybe not so complicated phone number formatting would choose a way it is done now...
Regards,
Marko
Marko,
you said <quote>
I've suggested to do search on a pure numeric strings, as it is done now. But, instead of transforming user formatted phone number string before storing it to the database, I would read numbers from the database as they are, strip non-numeric characters from it and:
- do comparison in MySQL on TEMP tables with "cleared" phone numbers
- do comparison in PHP on array of data (not the MySQL query)
</quote>
I understand your suggestion. I'm not going to maintain a poorly performing way of doing the storage and search. I've seen XRMS databases with hundreds of thousands of Contact records, and well over a million phone records. For companies with more than 100 users, this basic size will probably be normal, not unusual. Our installation here, which I consider much more 'average' based on what I know about current companies of more than one employee using XRMS, has tens of thousands of phone records.
Your suggestion does not allow for a database-based index to be used to manage the search. This will vastly increase the [phone search time. We saw one case where searching on a phone number took almost 30 seconds on a very large dual processor server, without the several extra operations and the temporary table that you suggest.
Please try an experiment to illustrate my point. Generate one million random numbers and insert them into the database with random extra formatting characters. Select these into a temporary table, stripping out all non-digit characters. Then try to find one of these numbers. This is a very large, very expensive operation. I suspect that even on one of my large dual-Opteron servers that this type of search would take multiple minutes to complete.
Please identify problems as you see them of doing Right-to-Left (RTL) formatting of numbers by country?
RTL formatting seems like the best technical solution, as it will allow both fast database searches as well as standardized, consistent display formatting for users.
Regards,
- Brian
This is a non-trivial problem to solve, I suspect, and RTL parsing doesn't always work. For example, in the UK London numbers are of the format "020 1234 5678" but _most_ other numbers are of the format "0123 456 7890". The only solution I can think of (and it's by no means perfect: see below) is to have a mirror field for each phone number which contains only digits. In other words, the formatted number may be "020 1234 5678" and the corresponding mirror field would be "02012345678".
But even that isn't right. For a start the data is no longer normalised so if one (ill-advisedly) edits a phone field directly in the database then the mirror field won't be in sync (but it is reasonable to insist that database updates are done via the application, and in any case on most databases triggers and stored procedures could handle this - but then the code is more database type specific). Secondly, how does one parse "+44 (0)20 1234 5678"? The first zero is only dialled if the country code is not used, so what goes in the mirror field?
For me, what is more important than the ability to search by phone number - something I hardly ever do - is to have the formatting as I want which makes it easier to read the number off the screen when calling.
Brian,
I understand your point and I've also already written that I am aware of additional expense - therfore I've also suggested 2 options user can choose. For situations like in your examples users would probably choose the way it is handled now, but I would for sure go for a pure formatted strings (as i am also doing in y installation also now, but it would be easier using an option instead of patching a number of files...).
And, I see Keith shares the opinion that a handy formatting (meaning certain flexibility against the common defined rules) is mainly more important that an efficient search by a phone number (which happens very rarely in fact and, at least in Slovenia, can be resolved also searching in Telekom phone book).
I find also the idea of a mirror field very interesting (probably it would be a good idea to introduce some cron job maintenance sooner or later in any case, and it shouldn't be a problem to go through he database synchronizing a mirror field over the night, as well as do some other cleaning or synchronization...). By my opinion, formatting as most suitable for each customer, is very important and it should be somehow preserved and displayed exactly as entered. Some common (generalized) rules would probably become too complicated, whatever the approach is...
At the same moment, I have also a question - why XRMS is not allowing to enter phone numbers as addresses, meaning the arbitrary number of them for a company (or, contact). The fact is some of my contacts (and companies in particular) do have more phone numbers, like a direct number, the secretary, the number in the other room or other location he/she sometimes works as well or so... And, on the other hand, sometimes a group of people shares the same phone (or, fax in particular) number.
But, all this are just my thoughts. XRMS is for me the best solution of what I've tried until now anyway, and I appreciate the work you've done, guys. Thank you. I'm also aware not everything someone wishes can be done just for him. And, excuse me for my not perfect English, I hope everything is still understandable...
Kind regards,
Marko
Just one more idea about the formatting - if phone numbers would be in a separate table, it would be possible to select also the format type for it (types would be stored in another table) - independent of the country or so (few types could be defined through administration, and one of them selected as default one - if possible for a phone, fax and mobile numbers separately, so user does not need to specify the type all the time, but just when some non-default format is needed).
For example, I can define format types:
1. SI-phone-1: +386 (0)# ##-##-###
2. SI-phone-2: +386 (0)# ###-##-##
3. SI-mobile: +386 (0)## ###-###
and all my needs are satisfied if I can select for each number from Slovenia one of the 3 types defined above. Also, the database usage can be quite efficient, as only 8 digits have to be stored, and the rest can be appended when the number is used (the country can be specified with type, not with every number...).
Although the RTL implementation for number formating makes sense from a programming aspect, it is not necessarily the best for end-users.
I suggest as an intermediary fix:
1) Create a admin preference that allows either formatting or no formatting. The table should be ok, since it seems to store more than number information.
2) If formatting is turned off, then number search is turned off. It will just save what you type in.
3) When the formatting feature request is completed, the on will format, with the caveat that only certain numbers can be formatted, but then number search is on.
This I think also makes sense for a lot of companies using open-source, since they tend to be smaller, and don't really a need the ability to search by phone number.
Brian,
I´ve just re-read the thread because of dbaudone´s patch, and I still think, that RTL will not fix the problems for german phone numbers as the formats are too different (one of our recent customers has an area code with 5 and a subscriber number with 2!! digits).
I prefer the solution with the mirror field, mentionned above. Or just a way to disable number formatting within the administration. (same for the second reason of your reject, the automatic activity generation, when you click on an email, since we use a mail-to-xrms script that takes this part)
Did you already take some efforts to implement the RTL-methods? I´ll have to take a look at the phone formatting next week for one of our customers. Maybe I could add the switch instead of just hard-deactivating it?
Bjoern
My 2c:
We've the same problems here with phone numbers and the users are fairly negative on the feedback. Biggest complaint: the numbers are very hard to read.
In Ireland we do not have fixed area codes so fall foul of any simple RTL templating solution. Area codes can vary from one digit for Dublin (01) to three (0xxx) for many smaller towns and villages. Phone numbers can vary too from 5 to 7 digits.
Apart from that, as a language school we operate with MANY countries and I don't want to have to keep on updating phone formats from Mongolia, China, Russia and other former CIS countries (some very strange formats indeed), through all European countries (again very messy) to the US.
My idea:
The standard way to format numbers in Ireland (and the EU?, internationally?) is: +(country code) (area code) (subscriber number):
+ is the international access code and is commonly understood in any country using GSM (replace with 011 for the US, 00 for us, etc.
Area code is entered without the leading zero
Subscriber number without spaces.
eg: +353 1 1234567 or +353 507 12345 or +1 123 4567890
Spaces occur between the area code and the subscriber number ONLY.
You can validate this as follows:
1. Must begin with '+' and one to three digits
2. Then a space
3. Then the area code without the leading zero
4. Then a space
5. Then the subscriber number WITHOUT spaces.
There is a trade off but reasonable validation rules can be carried out, the user is presented with a readable number (minimising human error). They are also forced to think about the number they are entering rather than just hammer it into the keyboard and I feel that this may result in fewer data entry errors.
As I see it, we would need to store the international access code as a system preference for the purposes of inbound calls with CTI (which we don't use, so please correct me if I'm off the mark.) This means a new function to retrieve the unformatted phone number from the database for caller ID matching:
- retrieve the phone number from the database
- strip all spaces
- remove the leading '+' and replace with the international access code from the system preferences.
I am able to do this in SQL as follows:
SELECT * FROM (
SELECT REPLACE( REPLACE( phone, ' ', '' ) , '+', '00' ) AS phone
FROM companies
)
AS ph_cti
WHERE phone = '00496921234567'
(Phone is in the database as '0049 692 1234567' others are there using a leading '+'. The number was imported that way)
I only have 686 companies in the DB. Performance-wise it takes:
=> .0055 sec to list all, ordered on an indexed field
=> .015 sec to list all, ordered on an unindexed field
=> .015 sec to run the above query
(Blistering quick Dual PIII 450MHz - eat your hearts out) ;-)
(I don't know how this scales - would it take 1.5 secs to search 68000 companies? Any SQL heads know about this?)
For outbound calls, we can either pass the number 'as is' (if the CTI system can handle it) or do a substitution as above.
This means the only thing we need to store is a system preference for our own countries international access code.
Issues (apart from everything else that has been mentioned in this thread!):
1. I'm no benchmarking guru, so I don't know if the 3-fold increase in query time is acceptable. Any SQL dudes(dudettes) out there?
2. I do make assumptions about international numbering (but have a good knowledge based on the amount of countries our business deals with)
3. I know bugger all about CTI! (We did have an intelligent faxboard on our old Netware box and it never had problems with spaces in the numbers passed to it.)
4. A System preferences setting could choose between a) traditional XRMS template based formatting, b) formatting as above or c) no formatting at all.
I'd be quite happy to help code this.
What do you think? (Shoot from the hip - I can take it!)
(Sorry about adding more very verbose thoughts to an already very long thread, and apologies if this has come up in the thread previously.)
I've submitted my thoughts already, but still would like to stress that for me it would be very important that ANY phone number could be arbitrary formatted, not on a format, defined per country. Why an additional field would be such a problem (to have a formatted string as entered and a dial/search string in a separate field, which is automatically calculated when a phone number is entered/edited)? And, I still suggest more phone numbers per entity (contact, company...).
After discussion here there are some changes in CVS for how XRMS cleans phone and fax numbers.
The changes are now in CVS. See http://www.xrms.org/apps/download/download.php for instructions on how to download from CVS.
NB: CVS hosts a development version, so do test first before using in production. Many developers (myself included) use CVS versions of XRMS in production.
After download make sure you go to Administration -> Database Structure Update.
In order to maintain backward compatibility, there is a new setting in Administration Preferences: Phone/Fax number cleaning. This defaults to the old XRMS behaviour of removing all non-digit characters.
The alternative is ITU-T Recommendation E.123 (+xx yy zzzzzzzz) as follows:
'+country_code area_code subscriber_number'
ITU-T E.123 cleaning is done from left to right as follows:
1. first character grouping must be '+' followed by digit(s) or digit(s) followed by a space. A space after the '+' character is discarded as are any extra spaces.
2. second character grouping is composed of digit(s) followed by a space.
3. third character grouping are all digits. Any spaces are discarded.
As there is no data validation it is possible to 'break' the formatting rules. Basically a number may begin with '+' and digit(s) and can only contain digits and up to two spaces.
Gotcha's:
This will affect how numbers are stored in the database i.e. the '+' and space characters are stored there along with the number. This will affect searching for companies or contacts by telephone/fax number. This is something that needs to be looked at.
IMPORTANT: If you are using CTI do not enable this setting (see above!).
Feedback:
Feedback is needed - please post here.
Thanks,
Francis.
Please post further followups to:
https://sourceforge.net/forum/forum.php?thread_id=1725911&forum_id=305409
"CHANGE TO PHONE/FAX NUMBER FORMAT"
The phone number format is built up in xrms\include\utils-misc.php in the
function get_formatted_phone ($con, $address_id, $phone, $country_id=false)
{
//row 817 - outcommented //$phone = preg_replace("|[^0-9]+|", "", $phone); //row 832 - changed $expression = $phone; //row 845 - changed $phone_to_display .= $extra;}
So I get the raw database format (which is already cleaned before storing it to the database) without any special chars, which is conveniant for me in Germany.
In the get_formatted_phone function we could build the format as we prefer it for special countries.
The admin/country-address-format/index.php ist not working correctly - someone could check that, if he or she likes to :) .
Best regards
Axel Arnold Bangert - Herzogenrath 2016
Last edit: Axel Bangert 2016-04-23