卸組織変更とキーの洗い替え

実消化システムにとって、これは重要な機能です。

卸から入手する実消化データには、卸のどの組織が納入したかのコードが設定されています。製薬会社は、卸の組織コードに対して、自社コード体系で卸組織を定義しており、その変換を行いますが、卸の組織は当然ですが定期的に改編されます。組織改編の場合もありますが、卸同士の合併や、コンピューターの共同利用なども規模の大きな組織改編といえます。

実消化システムは、改編にあわせて、『卸組織・自社コード変換マスタ』や、 『卸組織マスタ』の修正を行います。

その際、卸組織別の実績を経時的に捉えるために、実消化システムに蓄積されている「実消化累積データ」の組織コードも、何らかの方法で読み替えてやる必要が生じます。

上図は、2つの営業所が統合された場合の実績表の例ですが、①の実績表は実績が分断されていますが、②の実績表は、元々から新宿営業所であったかのように、統合が遡及されて表現されています。一般的には、②の形式で実績を追いたいわけですが、それには何らかの対応が必要です。

その対応方法は、その実消化システムが、どのような状態のデータを累積しているか、また、日々の処理でどこまで最新マスタを引き当てているかで異なってきます

データウエアハウス的に考えると、累積してあるデータには手を付けず、ナビゲーションブリッジテーブルで遡及する方法が浮かびますが、累積データに何らかの修正を加えるのが割と一般的ではないかと思います。

以下で、いくつかのパターンについて検討したいと思います。

『東新宿営業所』と『西新宿営業所 』が『新宿営業所』に統合される様なケースでは、『卸組織・自社コード変換マスタ』と、『卸組織マスタ(自社コード)』を修正することで対応できそうです。

ただし、この方法は、卸組織が統合される時には有効ですが、分割される時には使えません。

さらに、これは毎日『実消化累積データ』の全件について卸組織コードを変換している場合には有効ですが、変換後のデータで累積している場合は『実消化累積データ』の変更が必要となります。

次に、統合ではなく分割される例を見てみましょう。

組織が分割されるため、卸組織単位の対応では解決することは出来ません。卸納入先毎の対応が必要です。上の例では、『実消化累積データ』の卸組織をアップデートしています。一方、下の例では、『卸納入先・自社施設変換マスタ』に 卸組織コードを持たせて、 その卸組織コードを設定するような方法となります。

繰り返しになりますが、 対応方法は、その実消化システムが、どのような状態のデータを累積しているか、また、日々の処理でどこまで最新マスタを引き当てているかで異なってきます。

すべてがマスタの制御で解決すれば、それに越したことはないのですが、それには潤沢な処理能力を持つハードウェアが必要ですし、それ以外にも、マスタだけでは解決しにくい要因があります。

マスタだけで解決しづらいケースの例

特定事業だけの営業権譲渡のケース

卸のB社がA社に営業権を譲渡するような場合も、実消化システムには、卸組織変更対応が必要となりますが、B社が『OTC薬販売事業』のみ譲渡し、『医療用医薬品事業』は引き続き継続するような場合で、製薬会社が医療用とOTCの両方を取り扱い、同一のシステムで処理しているような場合は、マスタでの対応が困難となります。

その場合、同じ卸組織・納入先であったとしても、医療用医薬品はそのままで、OTC薬のみ組織改編対応をするということになり、それをマスタで実現しようとすると、製品ごとに納入先を管理することが必要となり、なかなか現実的ではありません。

過去実績を塩漬けにしたいケース

卸に組織改編があって、『特定の納入先への実績については、消滅する組織に残して塩漬けにしたい』というようなケースがあります。

システムとして、その様な要望にどこまで対応するかというのはありますが、対応する場合、マスタで対応するとしたら、卸組織や納入先を月別に管理する必要が生じて、もちろん不可能ではないですが、管理するのはそれなりに負担になりますし、ハードウェアの性能も必要となります。

2019.9.07

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です