社内SEの徒然なる日記

iPhoneでホームページが文字化け!文字コード指定の追加

■ 投稿記事の一覧

しばらく前から、ブログの最後に投稿記事の一覧ってリンク(http://harikofu.web.fc2.com/)を貼っていました。

先日、外出先で自分が投稿した情報を参照したくてiPhoneからリンクをたどったのですが、その結果が、こうなっていました。
iPhone文字化け対応 - 1

・・・どこの言葉なんですかねぇ。

パソコンで表示されることは確認していましたが、iPhoneからは未チェックでした。

■ エンコードの指定

まぁ、システム業界で長く働いていると珍しくもないことです。文字コードの判定に失敗(か誤認)してエンコードがうまく動いていないんでしょう。

私のホームページ(というか、HTMLファイル)の文字コードはシフトJISです。これを使っているって宣言してやりましょう。設定方法は、METAタグを使用して文字コード(charset)を指定するだけ。私の場合は、charset=SJIS って定義で良いのかな。

HTMLファイルの先頭部分はこんな感じ。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="ja">
<meta http-equiv="Content-Language" content="ja">
<meta http-equiv="Content-Type" content="text/html; charset=SJIS">
<head>


色々書いていますが、実際に必要だったのはココだけ。
<meta http-equiv="Content-Type" content="text/html; charset=SJIS">


まと、SJISの部分はshift_jisってのが正しいかな。ま、これできちんと表示されたので、良しとしましょう。
iPhone文字化け対応 - 2

■ 後書き

この記事はFC2ブログなのですが、投稿記事の一覧はFC2ホームページを使っています。そちらのコンテンツは自作のHTMLなので、自力でなんとかしないといけませんでした。

ブログの方も文字コードはshiftjisのはずなのですが、それで大丈夫ってことは、使っているテンプレートの方でキチンと指定してるんでしょうね。ホームページもテンプレートを使えば良かったかもです。

・・・まぁ、ただのリンク集なので格好つける必要もないのですが。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

基幹システムの電子記録債権への対応 Part19 手戻&マスタ項目の追加

■ 不安

とりあえず、現在の支払手形の作成処理を解析しながら似たような作りで設計を始めたのですが、どうも変な感じがする。見た目は綺麗に見えるのですが、ふと業務レベルで深く考えると、本当に運用できるのか心配になってきました。

・・・これ、良くないなぁ。

ここまでの解析結果と、試作品(Excelで書いた画面や帳票のレイアウト)を携えて、ちょっと方向性を確認することにしましょうかね。

■ 手戻り

結果、ほぼ作り直し。

・・・フザケルナヨ(小声)。

こちらは手形ベースで考えていたのですが、実際の電子記録債権の運用方法は、振込に近い扱いになっているようなんです。なので、振込をベースにして、そこに電子記録債権の特有の機能(ぶっちゃけると期日)を加味する方向で作って欲しいと。

・・・あぁぁぁぁ、これまでの作業が水の泡だよ〜〜〜〜〜〜!

そもそも、電子記録債権の基本設計が手形ベースだったし、受取側(入金)については問題なく機能していたので気にしていませんでしたが、話を聞いてから実際に発生している電子記録債権のデータを見てみると、確かに変な感じ。

具体的に言うと、債権金額がやたらと細かい。手形の場合、100万とかキリのいい数字になることが多いのですが、113,985円みたいな細かいデータがゴロゴロ転がっています。

■ でんさいネット

うーん、どうやら当初からの設計が良くなかった気がします。

このシステム、そもそも「でんさいネット」っていう全銀協のシステムを利用することが大前提なのですが、直接使用できるわけではなく、窓口となる銀行を経由して使用するものです。これがまた厄介さを増しています。

「でんさいネット」のホームページを見ると、「現在利用している窓口金融機関をそのまま利用できる」「金融機関の創意工夫によって、それぞれの利用者ニーズにあったサービスを提供できる」といった、さぞ良いことのように書いていますが、そんな訳がありません。

複数の銀行を窓口金融機関とする場合、各銀行が個別に提供しているサービスに合わせた機能がいるってことか?

直接的な影響としては、複数の銀行を支払元銀行とする場合、各銀行を窓口金融機関として別々に使用する必要がありそうな感じじゃないですか。

例えば、窓口銀行がA行だった場合、B行の口座を支払元とすることは出来ない。それをするためには、B行にも窓口銀行となって貰わないとならないってことですかね?

■ 方針

手形で支払う場合、必要な情報は支払元銀行、額面金額、期日、印紙税。このくらいでしょうか。それをベースに考えていたのですが、電子記録債権の場合、支払先の銀行や利用者番号(1法人に付与される一意の番号)なども必要になってきます。

お客様の口座情報はすでに取引先マスタに持っているのですが、それは振込用の口座情報。振込と電子記録債権で口座情報が変わることもあるらしいです。

さらに、電子記録債権を使用する場合、1件ごとに手数料が発生するのですが、最近では手数料を支払先に負担してもらうことが出てきているようです。この考え方、振込については振込手数料の負担先(取引先 or 自社)を設定する区分を取引先マスタに持っていましたが、手形についてはノーチェックです。

うーん、マスタ項目を見直す必要があるなぁ。これは結構手間取りそう。

■ 後書き

開発開始時点では結構真剣に設計して、これまでも大きな不備はなかったのですが、これは大掛かりな方向修正が必要みたいです。開発開始時点で、支払系の知見が私になかったことが響いていますね。

・・・・・・・・ま、なんとかなるさ!

前回:基幹システムの電子記録債権への対応 Part18 支払系の開発開始
次回:いつか

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

基幹システムの電子記録債権への対応 Part18 支払系の開発開始

■ 今回こそ最後!

さて、このブログを始めた当初からズルズルと引きずっている電子記録債権の開発ですが、そろそろ決着を付けたいところです。

運用部署からは再三にわたって開発を要望されているのですが、はっきり言って余裕がない。合併とか(子会社との合併に伴うシステム移行 No1 始まり)、合併とか(子会社とのシステム統合 No19 再び)、もう、勘弁してくれ。

それでも、隙を縫って支払系の一部機能は実装したんですがね(基幹システムの電子記録債権への対応 Part11 本稼働、そして・・・)。

・・・裏書、いまだに使ってない。あれ、結構苦労したんだけどなぁ。

■ 開発方針

支払系の大まかな流れは、支払の金額、金種を確定させてから、金種(振込、手形)別の処理を行っています。

金種別の処理を大まかに言うと、支払元銀行、支払先銀行、手数料の負担(取引先に負担してもらうなら、支払金額から減算)、といった細かい項目を設定して、FB用の連携データ(テキストファイル)を作成したり、手形用のソフト(詳細は知らない)に渡すデータ(これも、テキストファイル)を作っています。

さて、電子記録債権については、支払の金額、金種の確定の処理については前回までの開発で実装済みです(裏書するのに必要だった)。なので、金種別の後処理さえ完成させれば、それで良いはず。

話を聞くと、手形と同じ方法で良いと言っていますが・・・

なんだか嫌な予感がするなぁ。

■ 後書き

当時の記録(っていうか、このブログ)を遡ってみると、電子記録債権シリーズの第1回は2012年の末に掲載していました(基幹システムの電子記録債権への対応 Part1 始まり)。

今が2016年6月なので、3年6ヶ月も経つんですね。時の流れって早いです。

人手があれば一気に開発するって手もあったし、上位の管理者目線で考えれば、それが正道と思うのですが、個人的には開発を分割したのは正解だったように感じています。

スモールスタートすることで、業務レベルでの知見が蓄積できた。当時は理解しきれていなかった支払系の仕様が見えてきた。大仕事(合併とか)の経験で、規模の大き目な開発案件の管理手法が整備されてきた。などが利点でしたね。

ま、結果論ですけどね。

前回:基幹システムの電子記録債権への対応 Part17 裏書の開発完了!
次回:基幹システムの電子記録債権への対応 Part19 手戻&マスタ項目の追加

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

指定請求書ってものが分かってきた(愚痴)


お客様が指定した様式で請求書を作ることが多々あります。手書きするのが面倒なのでシステム化したいところなのですが、これが一筋縄では行きません。

単純に書式を合わせて印刷するってだけなら良いのですが、そうは問屋が卸しません。

まず、大抵の場合は複写紙になっています。1枚目と2枚目を提出、3枚目を控え(それを保存しろってこと)とかです。複写紙なので、普通のレーザープリンタではダメ。ドットインパクトプリンタが必要になります。

次に、用紙サイズ。素直にA判やB判に合わせてくれれば良いのに、なぜか独自の用紙サイズにしたがります。普通のA4用紙で良いってこともあるのですが、今度は、専用のExcelがあるから、それに必要項目を入力して印刷しろとか・・・

挙げ句の果てに、用紙はそっちで買えとまで言ってくるのです。もう、何なんだよ(疲労)

■ 書き方

ここまでは百歩譲って我慢するとしても、今度は書き方や条件がとても嫌らしい。

良くあるのが、現場別に集計して合計金額を表示しろってパターン。現場名、お客様の担当者名、合計金額、これで1書式。それとは別に、納品した商品の明細を別途添付。

これだけなら可愛いものだと思えるのですが、値引き分は別にまとめろとか、お客様が採番した現場コードを入力しろとか、注文番号を書けとか、あまりにも煩い。

もっともキツイのが、お客様の独自の商品コード体系があるから、それを記入しろってパターン。もう、本当にこれは最悪。ちゃんとメーカーの品番がある商品でも、独自のコード体系に固執して、それでないと受け付けないとか、もう最悪です。

■ 後書き

私の知る限るだと、ハウスメーカーゼネコンなどの建設関係のお客様が多いイメージです。そして、提出期限も厳しいことが多い。酷いところだと、15日締めなのに、15日中に請求書を持って来いとか要求してきます。

まぁ、相手の事情も分からない訳ではないのですが、事情があるのはこっちも同じなんですがね。何というか、殿様商売ですよね。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

子会社との合併の伴うシステム統合 No39 鬼門は手形

■ データが変

移行の翌日、手形を管理している部門から手形の内容が変だという問い合わせを受けました。

管理手法にもよるでしょうが、銀行の情報は複数必要です。受取手形だと、相手の振出銀行と取立銀行とか。ただ、取立を依頼する銀行が1行しか無い場合、データ上は取立銀行を保持していないってことはありえます。

・・・ってことだったようです。

こちらの場合、取立依頼をする銀行って数行あるらしいので別途項目を設けていたのですが、相手は振出銀行しかデータ上はない。移行する手形データを見たとき、何か変だと思ったのですが気が付きませんでした。

■ やっぱり変

これについては、私の分析ミスでした。手形の運用って概念的には理解できているつもりなのですが、どうも業務感覚がピンとこない。この辺りがミスの原因ですね。

ま、取立依頼済みの区分は設定できていたので、単純に銀行の情報を上書きして対応。とりあえずはこれで良いかな?

って思ったら、今度は自振手形と廻し手形の区分が違うという指摘。でも、データを見ると間違えていない。区分は持っていなかったので裏書人の入力の有無で判断したのですが、まずかったかな?

それに、現物と突き合わせていくと、振出銀行も間違っているものがあるらしい。

・・・そっちは知らんよ。

■ 失敗だったかな?

結局、現物と突き合わせて手入力で修正してもらいました。

前回もそうだった(子会社との合併に伴うシステム移行 No17 移行後)のですが、どうも手形の移行が上手くいかない。

理由は色々あるのですが、データの精度が悪いことも一因。

事前に現物と突き合わせることができれば良かったのですが、その辺りはシステム部門の役割とは違うので手を出せなかったんですよね。こんなことなら、手形については移行しないほうが良かったかも知れません。

私の勤め先は、管理系の部門がうるさ・・・もとい、しっかりしているので、データの精度はかなり高い。それに、手形は部署別に債務レベルまで管理できるようになっているので、間違えがあれば、どこかで気づくのですが、相手はちと違いますね。

いくつか他社のシステムを見たことがあるのですが、手形管理システムって会計上に繋いでいるだけで、債権債務にまで連動させているものを見たことがない。そうだとすると、使う情報って未決済かどうかってくらいだろうし、期日と金額が正しければ十分ってことになりかねない。

結局、精度の悪いデータを移行するよりも、頭数を揃えて人間が手入力したほうが良かったかもです。どうせ手形なんて大した件数はないんですし。

■ 後書き

だらだらと書いてきたこのシリーズも、もう少しで終わりそうです。読み返してみると、書くことは色々とあるのですが無理に引っ張ってもなんだし、キリのいいところで切ろうかと思います。

これで、今度こそ完結ですね。

・・・まさか、次はないよなぁ。

前回:子会社との合併の伴うシステム統合 No38 移行当日
次回:もうちょっと続くんじゃ


最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop