システム開発■ 今回こそ最後！
さて、このブログを始めた当初からズルズルと引きずっている電子記録債権の開発ですが、そろそろ決着を付けたいところです。
運用部署からは再三にわたって開発を要望されているのですが、はっきり言って余裕がない。合併とか（子会社との合併に伴うシステム移行 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 —
スポンサードリンク
0
0
