ゆうプリRを使って業務システムを刷新した話の3回目は、一体型伝票と、発送方法の変更にどのように対応したかを記録しておきます。

１　明細行と属性数

今回一番制約が大きく苦労したのはこの点だった。一体型伝票の右側のピッキングリスト、または納品書の明細行のレイアウトについてである。

　まず、明細行数だが、結論から言うとゆうプリRでレイアウトを詳細設定（カスタマイズ）する場合でも、最大行数は、10である。そして、行数が10を超えるオーダーを投入するとちゃんと2枚目に左側の送り状部分は空白で、右側だけ表示される形で印刷される。そして、ページ番号も入れられる。

　ただ、当該顧客の場合、11行以上が必要になるケースが月に1，2ケース程度あり、できれば16行まで増やすとそれが年に1ケースがあるかどうかに収まるのと、2枚目のピッキング漏れという事故をなくす観点から増やせないかと探ったのだが、方法は仕様上なかった。

　もう一つは属性数の問題。インポートするデータは、「発送先や発送日に関する受注伝票に関する情報」の項目が続いたあと、「明細行に関する情報」が上のように最大10回繰り返される（これが明細行ごとに別のレコードになっていても結果同じインポートができ、かつ11行以上の明細への対応が容易ということも分かった）というデータとなっている。そして、インポートするデータには、「商品備考1～10」までの項目があり、SQLServer上にインポートできる。デフォルトの一体型帳票には商品コード、商品名、数量、単価、金額ぐらいしかないのだが、ピッキングリストとして使おうと思うと、「ロケーションコード」（棚位置番号）も欲しいし、明細行番号も欲しい…と考えると、商品備考の１，２，３あたりをこの辺に当てようと考えて試した。

　しかし、結論としては、一体型帳票に印字できるのは、「商品備考１」だけである。商品備考2以下は、ゆうプリRにインポートはできるが、印字には使えない。となると何のためにあるのかという悪態もつきたくなるものだが、仕様として対応していない、ということが、延々サポートとのやり取りの中で徐々に明確になっていた。

代替案として数字だけで7桁まで使える「金額欄」を使うことも試した。インポート自体はこの方法で可能である。しかし、ゆうパックプリントR上で、1か所でも住所や発送情報の修正を行うと、単価×数量に基づいてこの金額欄が再計算されてしまい、結果全部が(単価欄が０なので）0に書き換わってしまうということがわかり、この方法は採用できないことが分かった。これが判明したのは、夜12時を過ぎていたのだが、連絡をくれたエンジニアに、本当に申し訳なかった…こんなところは、ゆうプリRはちゃんとできていたのである。どうせ再計算しないと高をくくって作らせた私がいけない。

　仕方がないので、協力してくれるエンジニアの発案で、別の対応を取ってロケーションコードの表示を実現した。それをどうやったか、は彼の将来のいくばくかの収入の足しになるようここでは記載しませんので、お問合せください。

　この点が一番最後まで対応が残った点だったが、ここにこう書いておけば、後に続くユーザーさんは最初から対応方針を決められるだろう。

２　かご車番号

　次にかご車番号を印字する方法だが、内容物欄に黒抜き白文字のアルファベットでA～Iまでを表示するようにした。どうやってそれを表示するかはこれも、協力してくれたエンジニア独自のノウハウ（わかってしまうと何でもないが、それを要領よく実装するのもまたすごい）なので、ここでは記載しない。

　そのうえで、このかご車番号は郵便番号先頭2桁に応じた番号なのだが、当初は「ネクストエンジンカスタムデータ作成」の中で、条件分岐機能をたくさん組み合わせて作成しようと考えていた。しかし、最近、別の機能部分でネクストエンジンでのデータベースの「遅延」による業務トラブルが生じていて、あまり負荷の大きい業務をネクストエンジン上で走らせることには不安もあった。

　そんなさなか、日本郵便の取扱局の幹部との業務すり合わせの場で、「このかご車分類を繁忙期だけでもさらに細かくできないか？」という相談があった。時期によって分類が変わるというのは事故の元なので、細かくするならするでずっと細かくないと困るのだが、この分類自体が決して固定ではなく可変性があるものであることがこのやり取りから判明した。

　とすると、ネクストエンジンカスタムデータ作成でこれを作ると、00～99までを条件式として固定的に作成してしまうので、改変時にメンテナンスが大変になる、というか私がいないとできなくなってしまう。カスタムデータ作成を使いこなせるのは、この顧客の中でもそうはいないのだ。(そもそもこの機能は1社3人にしか公開されていないのだが、ここにも実は突破口があった。これは支障がありそうなのでこれはここには書かない。これにお困りの方はお問合せください。）

　一方、ネクストエンジンから出力した伝票（送り状情報と明細情報がセットになった）印刷用CSVは、通常では伝票番号順に並んでいるのだが、協力エンジニアの協力を得て、第2期開発においてはこれを一定の条件で並び替えて生産性を向上させる策を取りたいとなると、このCSVファイルをいずれにせよ、ソート・加工してからゆうプリRにインポートする工程が必要になる。それならば、このかご車番号について、郵便番号先頭2桁と対応するかご車番号のCSVという形で外部ファイルにしてこれを読み込む形でかご車番号を付与することした。かご車の設定を変える必要が出たら、この外部ファイル（ＣＳＶテキストファイルだが、先頭00～09もあるので、ＥＸＣＥＬで不用意に開いて保存しないように担当者には言い聞かせないといけない）を書き換えればよい。

ということで一本、GUIなしのプログラムをかませることにした。この方がスピードもはるかに速い。ただし、業務担当者にファイルをハンドリングさせることへの不安もあるにはあるので、そこは改良の余地はある。

３　商品名

ゆうプリRの印字可能な商品名は全角25文字分しかない。これで、サイズ違い、色違いまで全部をきちんと表現する必要がある。昔のPOSの登録名称のようである。いや、そういう文化を引きづっているのだろう。90年台は、PC-9821V13/ S7RCのように名称がついているものが多かった。しかし、今、ECの世界ではデータ量制約が大幅に緩和されているので、「魅力的で何を売っているかわかる商品名」をつけるのが主流である。たとえば、こんな感じ「Mainetti マイネッティ サルトリアーレハンガー NSAR40 スーツ・コート用ハンガー 肩先起毛仕立て 肩幅40cm ブラウン」

　長い…そして、この末尾のサイズや色の情報が欠落してしまうと、誤配してしまうことになる。

　しかも、このデータのエクスポート元であるネクストエンジンは、「半角と全角を区別しない」という仕様上の「特徴」がある。仮に半角カナの商品データをメーカーからもらってそのままネクストエンジンにインポートすると、「ﾊﾝｶﾞｰ」は「ハンカ゛ー」とメーカーは5バイトのつもりだったものが、10バイトになるという事件が起きる。この「特徴」には視認性とレイアウトの問題でたびたび悩まされてきたのだが、それを25文字にすることは1万を超える商品登録がある中で無理だった。

　そこで上の「商品備考」(最大50バイト＝全角25文字）のうち、1だけは印字に使えるので、ネクストエンジンの商品名を2項目に分割して収納し、これをすき間なく印刷するようレイアウトすることで対処することにした。それでも数十は商品名を50文字以内にならず、手作業で商品名を短縮する作業をしたが、これが顧客からは見えないよう、「表示用名称」欄をネクストエンジンで別に設けて対処している。

３　お名前、住所の長さ問題への対処

　同様にお名前、住所が長いケースもある。知れていると思われるかもしれないが、店舗で買われる場合には、住所の後にショッピングセンターのビル名が来て、さらに階数がきて、おしゃれで長くて読めないようなアルファベットの名称が来て、そのあとのご担当者様の名前●●様宛　がようやく来るので、とても長いケースが存在するのである。この辺は過去2年分の受注レコードのご注文者、発送先それぞれのお名前、住所の最大長を全部調べて、それに基づいてレコードをあらかじめネクストエンジンカスタムデータ作成で分割して出力し、ゆうプリRにインポートする方法を採用した。

　実は、文字数を節約するため、カナと英数を半角にしたうえで、ゆうプリRの項目分割機能（あるんです）を用いて、複数項目に流し込む案を最初に試した。しかし、そうすると、前半の項目の最後の文字が、続きの項目の最初にも出現するという現象がたくさん起きた。原因はすぐわかった。発生しているのは、50バイト目までに半角文字が奇数個ある場合である。
　このゆうプリRの分割機能は、50バイト目が2バイト文字の1バイト目になる時に、49文字目で切らずに、51文字目で切り、2項目目は、49文字目から表示してしまうのである。それでも郵便局のご担当者様は何とか届出くださるのでしょうが、お届け先にバカな会社とお客様が思われるのもよくないので、結局この機能の使用を回避して、ネクストエンジンの機能を用いた。ネクストエンジン内は全角と半角を区別せず、1文字としてカウントするという特殊仕様なので、ネクストエンジンで、「25文字」「50文字」と区切りを指定すると、このような問題は起きない。

　ネクストエンジンのカスタムデータ作成のメニュー「設定」の中の項目を使いこなすと、２，３のような条件分岐処理や文字列分割処理が比較的柔軟にできるので、便利は便利である。ただ、これを今後同じ社内で改良していってくれる人がいるのか？という点では中小企業は弱い。また何年もこのままになってしまうのだろう。

４　内容物名

　これもシステムというよりも対処に苦労した…宅配便を送る際には、皆さん、送り状の下の方の枠2「内容物の説明欄」があって、そこに「衣類」とか「ノートパソコン」とか中身がわかるような日本語を書くことと思うが、それをどう書くかという問題である。
　今回の対処をするまで知らなかったのだが、この項目には重要な意味がある。それは、遠方への発送には宅配各社とも航空貨物を使ってできるだけ早く届けるように努力してくれているのだが、その際、この内容物名の記載とX線画像を元に、「危険物がはいっていない（例えば高濃度アルコールなどの発火物）」ことを確認しないと、航空貨物に積み込めない、ということである。この安全上の規定はまず尊重しなければならない。そして、この内容が適切ではないと、航空貨物に乗せてもらえない、つまり陸送になる。(沖縄行きはどうなるの？と聞いたら、トラック+船だと言われた。）これは顧客に迷惑を掛けてしまうので何とか解決しなければならなかった。

　この「適切な内容の分かる商品分類名」を商品の属性、分類名として付与する、ということを各社ともしているのだろうか？少なくとも本件では、していなかった。以前、商品分類に取り組み、仕入先×商品分類×連番でのコード化にとりくもうと思って途中までやったのだが、連番発行の仕組みがネクストエンジンにはないことが主因で断念した経緯があった。また、前述の目的からすると、「 PC-9821V13/ S7RC 」のような「型番」では不可で「デスクトップパソコン」、せめて「パソコン本体」程度の記載が必要である。また、日本郵便担当者と協議を進めると、包括的な「●●類」という記載は不可という事も言われた。これは上記の航空検査の目的からしたらそうだろう。

　相当難しかったのだが、仕入先コード、商品コードを元に、適切な商品名を出力するような仕組みをネクストエンジンカスタムデータ作成上に構築して、出力するようにした。

５　サイズ入力問題

　このプロジェクト最大の関門は、正しい荷物サイズをデータに反映する、ということだった。つまり、梱包した後、箱サイズを計測してそれを元に、ゆうプリR内のデータを更新する、ということである。出荷センターで使用している箱自体は、上位５種類で95％程度に収まるし、実は半分以上が一つのサイズ(100サイズ）であるので、デフォルトを100で出力し、修正の必要なものだけを修正することとした。この修正は、ゆうプリRから出力したEDI伝送用ファイル（テキストファイル）を追跡番号（伝票番号）をキーにサイズ項目を上書きする、ということを行う仕組み（サトー製）を導入することにした。
　競争のない商品なので、なかなかのお値段であるが、毎年大きなお金がかかるようなものではないところは助かる。ただ、サトー様にこの周りの一式を丸投げして確実に完成させようともしたのだが、それは製品に直接関係する部分以外は受けてもらえなかったし、製品に直接関係する部分も非常に高価(普通のちゃんとしたSIerの値段ともいうが、中小企業にとっては）であった。

　先ほど、箱の種類は半分が100サイズと言ったが、一日2000個もあると、それでも1000個も読み取り作業をしなければならない。そこで、ベルトコンベアで自動でサイズを読み込んでくれる仕組みを入れられないか？ということも調査したのだが、どれも非常に高価だった。仮にシステムを5年で考えるとしても（保守費もかかるわけだが）年間15万個の5年で75万個だとして、そこに1200万円をかけると、1個16円の負担になる。3000万円といわれたベンダーもあった。人がやると慣れると1分間に10個ぐらいはできる。一時間ならば、600個。1時間1200円払うとすると、1個2円である。人手不足の中でこういう計算もどうなのかと思うのだが、人の方が安いのである。しかも、この自動計測の問題は計測するだけでなく、搬送された先で結局人がまたどこかに積み直さなくてはならない、ということもあり、結局、そうとう大規模に自動化しない限りは「人がいる。」のである。

　ただ、メーカーからの仕入れた荷姿のまま出荷するものもあるので箱サイズの本当の種類は実にたくさんある。そのため、やはり計測が必要になる。その辺から次回のお話しを続けたいと思います。