処理区分なるもの - 六の日記はこっちになったぞ

データのとある属性の如何によって、その後の処理が変わってくる場合ってのは当たり前にありますよね。その処理の違いの分岐をどうするかって話しなんですけどね。

例えば、例えばですよあくまでも。こう云う業務フローがあったとします。

支払登録と云うのは、仕入に対して何処の銀行口座から（勘定に紐付いてる）何日に幾ら払うってのを登録する。登録するだけ。この段階では未確定支払、てな扱いとします。

登録された未確定支払を帳票で確認、実際の物理的な支払伝票と突合させてOKだったら、確定処理します。確定処理は、支払登録で登録された情報に基づいて仕入仕訳に対して振替伝票を作ります。実際の消し込みと云う訳です。で、支払情報は未確定支払から支払実績って扱いになります。

振替伝票作っちゃうと後戻りは大変困難となるため、この様に間に未確定状態を挟んで十全に確認して戴く作りになっておるのです。

この確定の仕様が、支払通貨によって違うのです。

邦貨の場合: 振替伝票作成、支払データのステータスを確定済みに更新、その上、ファームバンキング用ファイルを銀行口座毎に金額を集計して作成。ファームバンキングへの連携は手動。
外貨の場合: 振替伝票作成、支払データのステータスを確定済みに更新のみ

以上をボタン1クリックで一気にやるのです。

で、邦貨と外貨で確定画面自体が別になっています。また、支払登録時の支払日のルールも若干違います。

ここで、それぞれの確定画面で扱う対象の支払データを、通貨コードを見て判断します。

 邦貨用
 WHERE 通貨コード = 'JPY'
 
 外貨用
 WHERE 通貨コード <> 'JPY'

ってやりたくなりますわな。業務ルールがそのままSQLに落ちていて、とても可読性が高い。

これが、稼動後数年経ってから不都合が出て来ました。

困りましたなー。で、苦肉の策。

これでいいやと思ったら、実は支払日が過去日付なんですな。あくまでも海外仕入先との取引なので、業務ルールは海外向けと同じなので、過去日付の支払伝票が回ってくるのです。

画面での日付入力チェックに引っ掛かっちゃう。じゃあそれを外すかと云うと、今度は通常の邦貨支払が不安です。

苦肉の策パート2。

これだと、債務関連の帳票で、通貨ごとに集計するような所で、JPYと新コードで分かれてしまうのが難ありでしたが、業務要件上それで全然構わない（というかそっちの方が良かった）ので、新コード案で何とか乗り切りました。

さて、何でこう云う事になったかと云うと、処理の分岐を属性の如何で判断したからですわな。前にも請求対象を計上日とか赤黒区分とか色んなのを見て判断したらややこしくなったのでフラグ追加しましたが（id:rokugen:20050324:1111649274）、これも同じ事情ではないかと。

つまり、支払情報に明確にファームバンキング対象フラグを作って、おいた方がよかったんではないか、と。で、確定時、ファームバンキングファイルを作るか作らないかは通貨コードは見ないで、フラグだけ見る。

当初の仕様では、JPYなら問答無用で対象だったんだから、システム側で通貨みてフラグ立てちゃう。で、今回の様な変更があった場合、支払登録画面に対象・非対象のラジオボタンでも追加してやって、自動セットはやめる。

でもねー、こう云う、属性によって処理の如何が変わるってのは、それこそ山の様にある訳で、それに対していちいちフラグ持ってたらもう大変だと思わないでもない訳です。

ルールの複雑さでやるやらないは判断しろって話だと思うんだけど、今回みたいな事があるとなあ。仕様変更なんだからきっちり貰える物貰ってやりゃいいんで、前もって考える事はない、ってのもそうなんだけど、やっぱり胃は痛むのよねぇ。