スモールビジネスのIT日誌

• (2009-03-26 09:32:43)

「クロネコヤマトの荷物お問い合わせシステム」は本当にありがたい。どういうシステムが返答してくれているのか見当も付かないが、細かい検索オプションがないものの安定した動作などからメインフレーム系のデータベースで運用されているかも？特にレスポンスの「軽快さ」は満足である。

商品発送後にクロネコヤマトの伝票番号番号を各顧客にメールにてお知らせする。宅急便や代金引換宅急便だけでなくメール便、メール便速達すべてが対象である。ヤマト運輸の送り状発行ソフトB2から打ち出した伝票は簡単にCSVファイルでエクスポートでそのままExcelに落としExcel上で各メールアドレスとマッチングして「発送通知及び伝票番号通知」のメールを自動発行を行っている。

「発送及び伝票番号」通知メールは顧客に喜ばれる。荷物がいつ来るのかある程度明確になるし、遅いモノは自分でチェックできる。それはそのまま当社への荷物配送状況問い合わせの電話や問い合わせメールの軽減にもなるので、ヤマト運輸・顧客・当社というすべての当事者にとってメリットになっている。心から「クロネコヤマトの荷物お問い合わせシステム」に感謝している。

ところでネットショップ側では発送した数十件、数百件の配送状況を一気に検索したい需要がでてくる。残念ながら「クロネコヤマトの荷物お問い合わせシステム」には一括検索オプションは提供されていない。ならば、Excelからプログラムを使い自動的に一括検索をかけれないか。

ExcelにはExcelをプログラムで操作するためにVBAというプログラミング環境が無償提供されている。Microsoft社の構想の偉大さはVBAをExcelの操作にとどまらずアプリケーション間でデータやコマンドをダイナミックにやり取りするための仕組み作りに余念がないことだと思う。この場合もExcelからブラウザーを起動し目標のURLに到着してそのページのフォームに必要なデータを自動的に打ち込む仕組みが準備されている。

VBAはプロのプログラマーでなくともインターネットに散らばる例文を参考にすれば私のような初心者でもある程度作れてしまう情報量の豊富さが魅力。「クロネコヤマトの荷物お問い合わせシステム」をVBAで一括検索したいという需要は多いはずだから誰かか、すでに・・・と期待して「クロネコヤマトの荷物お問い合わせシステム VBA」とググればまったくそのままのコードを公開してくれているサイトがトップページにでていた。

Navigate2メソッドで開いたタブをVBAで操作

読めば読むほど、そのまま使えそうなVBAのコードである。

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#4

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#3

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#2

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#1

• (2009-03-25 10:43:16)

「クロネコヤマトの荷物お問い合わせシステム」の恩恵を最大限に利用する

-------------------------------

ネットショップにとって重要なシステムの一つが発送商品の配送状況をレポートするシステム。当社が利用しているクロネコヤマトでは「クロネコヤマトの荷物お問い合わせシステム」なる配送状況のトレースサイトが提供されている。ここで伝票番号(トレースナンバー)を打ち込むと商品発送後10分程度でモニター可能となる。

※宅急便のシステム反映：

ドライバーさんが荷物を集荷する際、荷物に添付された伝票からバーコードリーダーで伝票番号を読み込む(発送登録)。このバーコードリーダーはauの携帯電話一体型の優れもので、ドライバーさんが営業所やセンターに戻る以前、集荷データはヤマト運輸のホストコンピュータに登録される。

バーコードリーダーで伝票番号を読み込んで何分くらいでシステム反映されるか何回かテストすると、私の調査では10分以内だった。完全なリアルタイムだとパケット代がかさむためか、データ転送による携帯電話占有時間を抑えるためか、おそらく10分程度で集荷データを自動的に定期バッチ転送しているようだ。

※メール便のシステム反映：

メール便はこの限りではなく、夜20時〜21時前後でシステム反映されることが多い。荷受けしたドライバーさんが営業所に戻った後、バーコードリーダー内に蓄積された集荷データをローカルに落とすか、もしくは各荷物が営業所に集荷された後、各地域の主管支店やベース店で仕訳作業を受けるときベルトコンベヤーを流れる間に伝票番号が採取されるのだろうか？詳細は不明だが、とにかくその日の夜間までシステム反映はない。しかし、これでも充分親切なサービスだと感心する。

続く・・・

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#4

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#3

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#2

ExcelからVBAで「クロネコ荷物問い合わせ」一括検索(IE6版)#1

• (2009-03-24 12:39:31)

郵便物に宛先を手書きで記入すると5分くらいかかる。数が多いと繰り返しの単純作業で書き違いやミスも発生する。現在、エイブリィマクセルの「ラベルプロデューサー」とA-oneの「ラベル屋さんHOME」を利用している。宛名・表示ラベル作成ソフトはフリーで使用できるので本当にありがたい。

私の場合、テキスト打ちだけなので機能差も使いやすさもどちらも甲乙つけがたい。サクサク動作する方がよい。横方向一列・縦方向一列・全面コピー機能があればよい。どちらも同じ。欲を言えば横方向一列・縦方向一列削除機能があればさらによいが、これはどちらにもない。

先日「ラベル屋さんHOME」がアップグレードしていてのでさっそく最新版に入れ替えてみた。非常に遅く扱いにくくなっていた。機能を盛り込みすぎたのかも？旧バージョンに戻す。

• (2009-03-19 11:47:47)

ネットショップ・ECサイトにとってメールはコミュニケーションの手段。ビジネスライン。ロバストなメールインフラはどうすれば構築できるか?

-------------------------------

●エラーメールの現状と目標

毎日たくさんのメールを発行している。受注の控えメールや発送時の発送通知メール、ご入金確認通知メール、フォローメール、問い合わせに対する返答メールなど。現在、90%程度は到達していると推測しているが、技術的に到達しても、お客様が読まない、気づかない、間違って削除、・・・というケースもあるだろう。

「技術的エラーにも遭遇せず、複数のフィルター処理(サーバーサイド、及びローカルサイド双方)もくぐり抜け無事に到着し、さらにユーザーによる無意識な削除などの処置に合わずに、ユーザーに認識されるメール」となる確率は80%程度でないかと考えている。この数字を90%にまであげるという長期目標を掲げる。

まずは技術的に到達しないケース。メールエラーはシステム管理者宛(postmaster、webmaster)にエラーメールとなって返信されてくる。それらはタイトルですぐにわかる。今まで必要に応じて個別対応していたが、今後は顧客データベースに取込み、顧客のメールアドレスとともにその有効性の補足情報とすることにした。

●エラーメールとして返信された際のメールタイトル(題名)

下記がある。タイトルはSMTPサーバーの種類や設定によっていろいろ変化するようだが、現状は下記5種類の対応で充分だろう。

・failure notice

・Mail System Error - Returned Mail

・Undelivered Mail Returned to Sender

・Undeliverable mail

・メール送信エラー

●エラーメールとして返信された際のエラー原因

・Unknown user

・User unknown

・Invalid recipient

・Address rejected

・No such user here

・Host not found

・mailbox is full

・mailbox unavailable

※Yahoo.co.jpのメールシステムでは下記のようなエラーが見受けられる。

・This user doesn't have a yahoo.co.jp account(宛先アカウントが存在しない。アカウント名が間違っているなど)

・This account has been disabled or discontinued(宛先アカウントが何らかの理由で使用不可または使用中止になっている)

●エラーメールとして返信された際、顧客にお願いする対応策

・Unknown user、User unknown、Invalid recipient、Address rejected、No such user here・・・宛先ユーザ名が存在しない。メールアカウントがない。宛先メールアドレスのユーザ名の中で@マーク(アットマーク)より左側が間違っている可能性があります。宛先メールアドレスに正しい「アットマーク左側のアドレス」を入力し直して再送信してください。

・Host not found・・・宛先ホスト名(メールサーバ名)不明のため宛先メールサーバにメールを送り届けることができない状態。宛先メールアドレスのユーザ名の中で@マーク(アットマーク)以下のドメイン名(アットマークより右側)が間違っている可能性があります。ドメイン名をチェックし、宛先メールアドレスに正しい「アットマーク以下のドメイン名」を入力し直して再送信してください。

・mailbox is full・・・相手のメールサーバー上のメールボックスに割り当てられた容量の容量オーバー。読込み・取込みしたメールをサーバーから削除しない設定をしたまま長い期間サーバーのメールボックスにメールを保存しているユーザーに多い現象。プロバイダーによって決められた容量をオーバーしてそれ以上受信できなくなっているため、サーバーから古いメールを削除してください。メールソフトで「サーバーにコピーを保存しない」という趣旨の設定をすれば読込みされたメールは自動的に削除されます。

・mailbox unavailable・・・相手メールボックスが何らかの理由で動作しない。原因不明です。システム管理者などによって意図的に、あるいはトラブルで受信できない状態にあります。プロバイダーやシステム管理者にご相談して下さい。

●エラーメール対策優先順位1

今後対応策を検討し実施していく予定の中で、特に急ぎたいことが携帯電話各社が設定しているデフォルトの「受信拒否初期設定」(PC・パソコン、システムなど携帯電話会社のメールサーバ以外から発信されたメール以外はすべて「拒否」とする設定。携帯電話各社は「スパム対策」としているが、現状この設定は今後も継続される見込み)。携帯電話ユーザーが増加傾向にある中、頭の痛い状況。

• (2009-03-17 10:24:33)

郵便番号からの住所自動入力プログラムを掛けている限り、住所記入欄で番地の記入忘れは撲滅できない。どっちも外せない。

-------------------------------

お客様の住所記入欄で番地の記入忘れがたまに発生する。自宅の番地をなぜ書き忘れるのか？興味深い問題である。この検証と対策はまた別の機会に行うとして目先の対策として当社でチェックし、発送前に連絡するようにしている。

しかし、ここが悩みどころ。人の目でチェックするので必ず漏れるものがでてくる。先日お客様から「なかなか来ないので明細を確認したら番地が抜けていました。再送よろしくお願いします！」というメールが来る。この種のトラブルはなんとか事前に回避したいものだ。

システムで番地忘れのフィルタリングしたいのだが、なかなかよいアイデアがでない。思いつくことは下記の不完全な条件：

・通常住所は番地、すなわち数字で終わる

・数字で終わらない住所は部屋や階を示す「号」「室」「F」「階」「方」などがある

とりあえずこれらの条件に合わない住所のレコードをピックアップすれば人の目での検査も検品確率の精度も上がるだろう。またまた受注データベースのACCESSを眺める。クエリで上記条件をセットすることにしたが、やり方がわからずクエリをしばらく眺めていた。

思うにACCESSのクエリはMicrosoft社の技術者が「SQL文をビジュアルに図式化したらどんな図になるか」というテーマのもので作られたのだろう。この図表が簡単にSQL文に落とせる理由はそこにあるのかも。

クエリ図表の骨格フレームワークになるものはレコードの各フィールド。図表(テーブル)を引いて横方向に必要なフィールドを入れていき、各フィールドの選択条件や並べ替え条件を記入できる欄を下に追加するというテーブルになっている。

選択条件や並べ替え条件は横方向のフィールドに対して「And(かつ)」結合となっている。選択条件を「Or(または)」結合したい場合は選択条件の行を下に追加していく。並べ替え条件が複数ある場合、ソートの優先順位は左側優先となっているようだ。

住所フィールドの「最後の1字」を拾い出して、それが数字かどうか、また「室」や「号」や「F」などでないかという判別にはちゃんとMicrosoft社から関数が提供されていた。本当に感謝したい。

「最後の1字」を判定する計算式をどの欄に入れてよいのか、「とっさにわからなかった」ということが今日のテーマ。

反射的に「住所フィールド」の下の選択条件欄に入れようとした。この選択条件は住所フィールドそのものに対して成されるので、できないことはないかもしれない。入れてみた。既存のフィールドに何かの関数を噛ませることは認められないようだ。しかし、自動的に関数に住所フィールドを通して生成された「新しいフィールド」がテーブルの横方向に追加された。驚くべき賢さ。

おそらくやったことはルール外ながらよく間違われるのだろう。その対策としてMicrosoftの粋な計らいの結果だろう。今となってみれば、関数に住所フィールドを通して生成された「新しいフィールド」をダイナミックに一つ追加するという考え方の方がはるかにすっきりしている。ダイナミックで仮想的に新しいフィールドを追加できることがクエリの醍醐味か。Jetエンジンのコアな部分ってこの辺かもしれない。

というわけで新しいフィールドを2カラム追加：

・新フィールド1：式1: IsNumeric(Right([住所1],1))

選択条件：False

・新フィールド1：式2: Right([住所1],1)

選択条件：Not Like "室" And Not Like "号" And Not Like "F" And Not Like "階" And Not Like "方"