売掛金の回収に手こずった相手がいますが、よほど記憶力の良い
担当者でなければ、忘れてしまうケースがほとんどです。
ましてや、担当者がやめたら、引き継ぎがされているかどうかと
いう問題があります。

そこで、「ブラックリスト」というバインダーを作り、これまで
の取り立ての経緯を書いたものを作りました。
当社の商品の性格上、あくまでも注文なり、セミナーを受講した
人が請求書をきちんと経理に回したのかの確認をします。

注文データを入力すると、自動的に「ブラックリスト」にMPUの
照合にいきます。
名前と会社名が一致したら、備考欄に「ブラックリストを確認
**************************
してください」という情報がインプットされ、注文データの入力
チェック印刷の時、この情報も印刷されてきます。
その時点で、過去にトラブルのあったお客様かどうかの確認を
します。（同姓同名のケースもあるので、慎重にしています）

基本はそういう人にはDM送付は送らないという手続きを
しています。
過去に何回かこの関門にひっかかったデータもあります。
それは、その人には送らなくても、なんらか情報を入手して
の注文ですね。

今、私の問題はブラックリストに載っているのに、引っかからない
というケースです。

例えば、「ブラックリスト」ではフルネームだったのが、「姓」のみの
申し込みだったとか、あるいは個人が払わないという考えだったのが
会社の経営が思わしくなく、振り込みがされない？のではという
ケースです。この場合は営業担当者が数人いますし、こちらが把握
していない（出来ない）担当者からの注文はチェックをすり抜けて
しまいます。

MPUではなく、MPUの定義表を使えば「ワイルドカードの指定」が
できます。
条件式もいろいろと指定できます。

そこでこの「ブラックリスト」というバインダーの形態を変えて
定義表にすべきかというところで、悩んでいるところです。
（フォーマットが違うのと、固定長なので項目の整理が難しいですね）

元山より

> 今、私の問題はブラックリストに載っているのに、引っかからない
> というケースです。
>
> 例えば、「ブラックリスト」ではフルネームだったのが、「姓」のみの
> 申し込みだったとか、あるいは個人が払わないという考えだったのが
> 会社の経営が思わしくなく、振り込みがされない？のではという
> ケースです。この場合は営業担当者が数人いますし、こちらが把握
> していない（出来ない）担当者からの注文はチェックをすり抜けて
> しまいます。
>
> MPUではなく、MPUの定義表を使えば「ワイルドカードの指定」が
> できます。
> 条件式もいろいろと指定できます。
>
> そこでこの「ブラックリスト」というバインダーの形態を変えて
> 定義表にすべきかというところで、悩んでいるところです。
> （フォーマットが違うのと、固定長なので項目の整理が難しいですね

バインダーを定義表にしないで、そのままでテストしました。
工夫したところは名前の欄です。
会社自体の支払いが問題なところは名前欄のデータを=*といれました。
これでMPUのあるプログラムを動かしたらエラーなく、きちんと
情報が入手されていました。
ということはフルネームの人はフルネームでなく姓のみでアスタリスクのワイルドカードが利くということです。
ということで、もうひとつの問題も解決しました。
備考欄にフルネームの情報をいれておけば、支障なさそうです。

元山より

ごめんなさい。
はやとちりしたようで、どうもＰ間違いしていたようで、
古い定義表だったようです。
だめでしたね。
うーん、くやしい。
やはり定義表に変更しないとだめなのかな？

元山より

>
> やはり定義表に変更しないとだめなのかな？
>

ということで、本日、「ブラックリスト」という普通の（？）
バインダーを定義表＋普通のバインダー兼用という形に修正しました。
かなり変なバインダーです。
番号/使用/条件式/実行式/飛び先/以下あれこれの列がつながります。
これを定義表として指定しても最初の順番があっていれば、尾尻にどん
な列が追加されていようと定義表とみなしてくれているようです。
変形した定義表は使っていましたが、ここまで変形したバインダーは
初めて作成してみたのですが、結果オーライです。

ああ、おどろいた！！

元山より