社内SEの徒然なる日記

移行データ取得のための徹夜が辛い

■ 移行データ

今、基幹システムの移行プロジェクトを進めているのですが、それも大分良い感じで進んできました。つまり、そろそろテスト工程に入りそうです。

そういうことで、テスト工程で使うための移行データを準備することにしました。取得したいのは、月次処理(夜間処理)の直前のデータ。これを移行して月次処理を実行すれば、新旧の比較テストができます。

このデータなのですが、日々の運用で取得しているバックアップが使えれば良かったのですが、そうも行きません。

■ 徹夜

日々のシステムのバックアップは、夜間処理の直前と直後の2回取得しています。直前の方は、ストレージの機能を使用したバックアップ。直後の方は、Oracleexpdpです。

移行で使いたいのはexpdpの方なのですが、月次処理が終わった後のデータでは意味がないので、手動でバックアップを取得することにしました。

・・・徹夜だよ。

■ 調整

流石に辛いので、夕方から出勤させてもらいました。本当は、もっと遅い時間に出勤したかったのですが、夕方に会議が入っていたので断念しました。

さて、手動でバックアップといっても、これが意外と手間です。夜間帯って結構色々な処理が動いているので、その順番を変えると辻褄が合わなくなって処理が異常終了したりします。

下手にスケジュール自体を止めると、後で戻し忘れるっていうオチが付きそうなので、当日のみ起動しないように調整します。この辺りは、やっぱりジョブの運用監視ソフトは設定が楽で良いです。Windowsのタスクスケジューラでも多少は出来ますが、やっぱりちょっと不便です。

■ 辛い

そんなこんなで処理を調整しているうちに、あっという間に深夜に到達。遅出だったので日中はゆっくりと休んでいた(というか、寝ていた)のですが、やっぱり深夜になると眠いです。

なんだか頭も回らなくなってくるし、コーヒーを飲んでも頭にモヤが掛かった感じだし、色々と宜しくないです。

・・・うーん、私も歳ですかね?

ま、ある程度は体が辛いだろうと思っていたので、月曜日は有給を取得しているので、ゆっくりさせてもらいましょうか。

■ 後書き

実際には色々と問題が出ました。肝心の移行データの取得処理が異常終了。なんだろうと思ったら、バックアップ処理が日付を跨いだことが原因でした。

処理の開始時点で当日の日付でフォルダを作成します(20170203とか)。そして、処理の最後でログの解析をするために作成したフォルダにアクセスするのですが、その時のアクセスの仕方が当日の日付のフォルダを探すというもの。

この場合、開始時点は2月3日ですが、終了時点では2月4日なので見事にフォルダ存在エラーとして異常終了しました。

その他、まぁ、色々と軽微な問題に気がついてしまいまして、ちと考えものでした。移行前に、夜間処理を色々と見直さないとマズそうです。

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

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

PageTop

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