전화번호는 주문시 입력폼에서 입력한 값을 그대로 출력하는 게 맞다고 생각합니다.
엑셀에서 0이 사라지는 것은 ' '.$row['od_b_tel']); 와 같이 공백을 추가하면 됩니다.
그리고 입력폼에서 통일된 값으로 체크를 하는 게 어려운 이유는 쇼핑몰을 제작할 때 전화번호
입력폼을 변경하기 때문입니다. 입력폼히 하나의 경우 3개로 분리한 경우 selec 를 사용하는 경우 등
다양하기 때문에 어떤 환경에 맞춰서 코드를 작성할 수는 없습니다. 쇼핑몰에서 입력폼을 변경하면
그에 맞춰서 코드를 추가해야 하는 것이 맞다고 생각합니다.

입력폼을 여러가지로 선택할 수 있도록 만드시는 것이 좋을듯합니다. 여러가지로 만들어진 입력폼중 입맛에 맞는 것을 선택하도록 만드시면 그에 맞춰 코드를 수정하지 않아도 좋도록 하는 것이 고객의 니드를 수용하는 결과라 보여집니다. 사용자 입장에서 소스수정이 가능하도록 여러가지 가능성을 열어두시는 것도 좋지만 굳이 수정하지 않아도 동작하도록 만드시는 것이 사용자 유입에 효과적이라고 생각합니다.

개인적으로는 이상을 발견하고 수정해서 쓰고있지만 수정하지 않았을때의 영카트5에서 제공한 저 부분 엑셀출력물이 제 값어치가 있는지에 대해서 다시한번 생각 해 보아 주셨으면 합니다.

적어도 "엑셀에서 0이 사라지는 것은 ' '.$row['od_b_tel']); 와 같이 공백을 추가하면 됩니다. "
라고 답변하신 그정도로 까지는 소스가 수정되어 있어야 버그라는 글을 올리지 않게 되는것 같습니다.

애초에 엑셀로 불러오는 소스는 영카트5에 기본으로 들어있는 소스입니다.
기본으로 들어있지 않고 유저들이 스스로 엑셀모드를 소스에 수정 가미한 후 인풋하는 과정에서 이러한 일이 있다면 "사용자께서' '.$row['od_b_tel']); 와 같이 공백을 추가해서 쓰세요." 라고 조언할수 있을듯 합니다.

엑셀이되었든 다른 output이건 원래 010xxx1234 식으로 입력되었던 데이터이면 최소 010xxx1234로 그대로 불러들여져야 최소한 버그가 아니라는 의미로 이 글을 올렸습니다.

저 소스가 바뀌지않고 원본db에 잘 들어있는 앞부분의 '0'이 엑셀로 불려오면서 사라지는 현상때문에 사용하지 못하는 사용자가 있거나 해당루틴을 고쳐 쓸 정도의 사용자라 하더라도 저 부분의 소스를 손보지 않는이상 사용이 불가능한 부분이라면 그것이 바로 버그이거나 사용불능한 부분이 아닌지 모르겠습니다.

답변하신 부분을 제가 잘 이해를 못한것인지, 편리성은 차치하고 그 부분만큼은 해당 함수부분을 적용해 주어야 합당한 부분인지 한번 더 고려 해 보셨으면 합니다.

PS : 버그라 할수는 없지만 편의성 부분에 대한 비합리적인 부분 한말씀만 더 드리고자 합니다.
영카드4 시절부터의 회원db 필드중 회원가입시 전화번호등 기입상황을 들여다보면...
전화번호 부분에 입력된 db field 데이터들을 들여다보면 입력형태가 다양하기가 이를데 없습니다.
.000-0000-0000의 착실파에서 시작하여
.00000000000 숫자로 11자리 입력까지는 모범생 입니다.
.0000000 국번호없이 7자리나 8자리만 적은사람.
.000 0000 0000 중간을 공백으로 했네요.
.000,0000,0000 심지어는 컴마를 쓴 사람도 있습니다.(CSV 데이터등으로 불러올때 필드가 틀어지는등 최약의 에러를 일으키죠 영카트4에서도 여러번 당했습니다.)
.(000)00000000 국번호를 괄호로 감싼사람등...수천 수만개의 데이터가 저렿게 각양각색 다양할수 있다고 생각 해 보시기 바랍니다.
위 상황은 회원가입자의 회원가입 순간만은 전화번호입력 한부분만으로도 어느형태의 숫자든 문자든 그야말로 다양성의 자유를 만끽하고 있습니다.
그런데 저 부부분을 회원가입자의 편의성을 위한 다양섬,범용성이라 말하기는 힘들듯 합니다.
분명 좋은 소스는 아니죠.
(절대 범용성이나,다양성이나,편리성과는 전혀 상관이없는 조금 심하게 말하면 어지러운 소스일수도 있다고 생각합니다. 죄송합니다.)

그럼에도 불구하고 위 상황이 쇼핑몰이 아니고 일반 친목게시판등의 입력사항이라면 100%는 아니더라도 반반은 이해해줄 상황입니다.

하지만 쇼핑몰의 인적사항및 연락처는 주문과 배송이 이루어지고 각 데이터가 규칙있게 편리하게 가공되어 외부로의 인풋과 아웃풋이 어느정도 안정적이고 걸림돌이 없고 통일성이 있어야 함은 너무나 당연한 일이라고 생각합니다.

영카트5는 공개소스이므로 기본제공 한 정도에서 사용자편의에 맞게 맞추어 쓰는것이니 고쳐서 쓰라고 하면 할말은 없습니다.

그러나 이 한가지 원칙은 분명히 있어야 할듯 합니다.
1.입력은 한두가지 방식으로 통일한다.(전체를 숫자만 붙여쓰거나 '-'를 넣어쓰거나 공백이나 '('를 써 넣어도)
2.입력받은 데이터를 분석하여 숫자만, 혹은'-'를 넣어 둘중 한가지로 통일성있게 db에 넣어준다.
위 1.2항은 어려운일도 아니고 당연히 어느 한 방향으로 이루어져야 할 통일성인 것이며...

이때 인풋형태를 숫자로 통일할 것인지 '-'포함인지 여부를 영카트 개발자 취향이나 생각대로 결정 하는것은 누구도 무어라 할 대상이 아닌것이 될것입니다.

그러한 연후에 누군가 '-'가 불편하다고 하소연할때, '그 부분은 편의성있게 사용자가 고쳐서 써라 그것까지는 다양한 유저의 니즈에따른것으로 자신의 성향에 맞게 쓰는것을 조언한다.'라고 한다면 너무나 당연하고 수긍할수 있는 상황이 될것이라 생각합니다.

말씀하신 내용은 충분히 공감이 갑니다. 하지만 이런 경우를 생각해볼 수 있습니다.
전화번호를 입력하는 기준을 정해서 코드에 적용을 했습니다. 그런데 주문시 내선번호가 있어
기록하시는 분이 있을 때 1544-6789 (내선 : 209) 라고 적으면 숫자가 아닌 것도 포함되어 있기 때문에
정한 규칙에 어긋나는 부분은 제거가 되고 DB에 기록됩니다. 결국 주문자는 내선번호를 적었지만
송장에는 내선 이라는 문자는 사라진 이상한 번호가 표시됩니다. 또 해외에서 쇼핑몰을 운영하는 경우
전화번호 규칙이 우리나라의 그것과는 다를 수 있습니다. 이런 경우도 미처 코드를 수정하지 않았다면
전혀 다른 형식의 번호가 db에 기록됩니다. 이렇듯 어떤 기준을 정해서 그에 맞지 않으면 제거하고
db에 정보를 기록하는 것은 예상치 못한 문제를 야기할 수 있습니다. 그래서 따로 규칙을 정하지 않은 것입니다.
쇼핑몰 운영자가 전화번호는 '이렇게 입력받을 거다.' 라는 정책을 정하면 그에 맞게 코드를 수정하면 되는 부분을
SIR에서 처음부터 어떤 특정한 규칙을 정해서 그것만 허용한다는 것은 제가 생각하기에는 맞지도 않고 해서도
안됩니다. 그리고 처음에 지적하신 0 이 사라지는 부분에 대해서는 코드 수정에 대한 방법을 알려드린 것으로
코드를 수정하지 않겠다고는 하지 않았습니다. 실제로 버그 확인 후 다른 부분의 코드까지 수정을 했습니다.
다만 위의 버그 하나때문에 패치를 배포하는 것은 어려움이 있어 코드 수정법을 알려드린 것입니다.

잘 이해하였습니다.
지금 답변하신 부분은 그렇게본다면 전화번호가 필드가 아니라 '연락가능한전화번호등메모'칸 정도로 보고 사용하면 불만없이 사용할수 있을듯 합니다.

그누의 경우 전화번호필드 부분은 필요한 사람들이 해당필드 데이터를 가공하여 사용할수 있도록 다양성을 제공했으니 수정해서 쓰는것을 추천한다 정도로 이해하면 빠를것 같습니다.

조금 아쉬운점은, 문법이 HTML5로 발전하면서 전화번호 추출및 처리에관한 정규식도 나와 있는걸 보면 무언가 그 부분의 보완이나 통일성, 합리적인 처리등이 필요하니 그러한 정규식도 나와있고 아예 전화번호항목,이메일항목, 등으로 못박아 합당한 공식을 정하여 처리하고있지 않은가 하는 생각에서 쓴 글입니다.

말씀하신 1544-6789(내선:209) 혹은 1544,5679(내선,209)등으로 어떤 규칙도없이 입력받는것이 과연 최초소스로서 합리적이고 적합한 정보처리 인지는 고려해볼 문제라고 생각합니다.
일단 개발자님의 의견은 존중합니다.
감사합니다.