(57)【要約】【課題】代行回収受託の審査・承認処理の作業負担を軽減でき、代行回収を統括して管理できる代行回収管理方法及び代行回収管理プログラムを提供することを目的とする。【解決手段】コンピュータによって売掛金の請回収を代行して管理する代行回収管理方法であって、演算処理装置が、請求データを取り込むステップ（Ｓ１１）と、請求データが条件に合致するかを判定するステップ（Ｓ１２〜Ｓ１４）と、条件に合致する請求データの代行回収受託に関し、審査・承認処理を省略するステップと、代行回収に関する仕分データを出力するステップ（Ｓ１９）とを有することにより上記課題を解決する。【選択図】図６
2008158896.tif 000002
【特許請求の範囲】
【請求項１】
記憶装置及び演算処理装置を含むコンピュータによって売掛金の請回収を代行して管理する代行回収管理方法であって、
前記演算処理装置が、
請求データを取り込むステップと、
前記請求データが条件に合致するかを判定するステップと、
前記条件に合致する前記請求データの代行回収受託に関し、審査・承認処理を省略するステップと、
代行回収に関する仕分データを出力するステップと
を有することを特徴とする代行回収管理方法。
【請求項２】
前記条件に合致しない前記請求データの代行回収受託に関し、審査・承認処理を実行するステップを更に有することを特徴とする請求項１記載の代行回収管理方法。
【請求項３】
前記請求データが条件に合致するかを判定するステップは、前記請求データの請求先が前記記憶装置に記憶されている代行回収会社テーブルに存在し、承認方法が毎回確認ではなく、且つ初めての確認でないと判定したときに、前記請求データが条件に合致すると判定することを特徴とする請求項１又は２記載の代行回収管理方法。
【請求項４】
記憶装置及び演算処理装置を含むコンピュータに、売掛金の請回収を代行して管理させる代行回収管理プログラムであって、
前記演算処理装置に、
請求データを取り込むステップと、
前記請求データが条件に合致するかを判定するステップと、
前記条件に合致する前記請求データの代行回収受託に関し、審査・承認処理を省略するステップと、
代行回収に関する仕分データを出力するステップと
を実行させる為の代行回収管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、代行回収管理方法及び代行回収管理プログラムに係り、特に売掛金の請回収を代行して管理する代行回収管理方法及び代行回収管理プログラムに関する。
【背景技術】
【０００２】
例えば商品を顧客に販売又はサービスを顧客に提供する場合、販社は信用があると判断した顧客に対して、商品やサービスの代金を即金ではなく、所定期間後に受け取る「掛売り」と呼ばれる代金回収方法を適用することがある。このような代金回収方法は、請求作業や回収確認など、作業負荷が大きかった。したがって、販社の中には代行回収業者に代金回収を依頼して作業負荷の軽減を図るところもあった。
【０００３】
また、販社がグループ会社に属している場合、そのグループ会社の親会社は販社の代行回収業者としての役割を担うこともあった。この場合、親会社は販社から請求データを取得して、請求先の顧客から代金回収を統括的に行っていた。さらに、顧客の本社が顧客の拠点・支店などの代金の請求先となる場合、親会社は顧客の本社から代金回収を統括的に行っていた。
【０００４】
近年、上記のような代行回収の仕組みをコンピュータネットワーク上で実現可能な請求代行回収管理システムが利用されるようになった（例えば特許文献１参照）。
【特許文献１】特開２００３−１２３０２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
例えば親会社が販社の代行回収を行う場合、親会社の担当者は請求データ毎に代行回収受託の審査・承認処理を行わなければならない。通常、代行回収受託の審査・承認処理は代行回収受託のワークフロー（Ｗ／Ｆ）により行われるが、請求データの数が増加するほど作業負担も大きくなるという問題があった。
【０００６】
本発明は、上記の点に鑑みなされたもので、代行回収受託の審査・承認処理の作業負担を軽減でき、代行回収を統括して管理できる代行回収管理方法及び代行回収管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明は、記憶装置及び演算処理装置を含むコンピュータによって売掛金の請回収を代行して管理する代行回収管理方法であって、前記演算処理装置が、請求データを取り込むステップと、前記請求データが条件に合致するかを判定するステップと、前記条件に合致する前記請求データの代行回収受託に関し、審査・承認処理を省略するステップと、代行回収に関する仕分データを出力するステップとを有することを特徴とする。
【０００８】
前記条件に合致しない前記請求データの代行回収受託に関し、審査・承認処理を実行するステップを更に有することを特徴としてもよい。
【０００９】
前記請求データが条件に合致するかを判定するステップは、前記請求データの請求先が前記記憶装置に記憶されている代行回収会社テーブルに存在し、承認方法が毎回確認ではなく、且つ初めての確認でないと判定したときに、前記請求データが条件に合致すると判定することを特徴としてもよい。
【００１０】
なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、代行回収受託の審査・承認処理の作業負担を軽減でき、代行回収を統括して管理できる代行回収管理方法及び代行回収管理プログラムを提供可能である。
【発明を実施するための最良の形態】
【００１２】
次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、以下の実施例では、親会社が子会社である販社から請求データを取得して、顧客の本社から顧客の拠点・支店などの代金の回収を統括的に行う例を説明するが、この例に限るものではない。
【００１３】
図１は本発明による代行回収管理システムの一例の構成図である。図１の代行回収管理システムは、代行回収ＤＢ１，親会社用端末２，販社用端末３，顧客本社用端末４，顧客拠点・支社用端末５，インターネット等のネットワーク６を有する構成である。代行回収ＤＢ１，親会社用端末２，販社用端末３，顧客本社用端末４及び顧客拠点・支社用端末５はネットワーク６を介して接続される。
【００１４】
なお、図１では親会社用端末２，販社用端末３，顧客本社用端末４及び顧客拠点・支社用端末５が１台の例を表しているが、複数台であってもよい。また、代行回収ＤＢ１は複数台に分けて構成してもよい。
【００１５】
親会社用端末２は親会社の担当者が操作するものである。親会社は、代行回収の契約統括窓口会社となる。親会社は顧客本社に対し、一括請求／一括回収を実施する。親会社は販社と同じグループ会社に属する。
【００１６】
販社用端末３は販社の担当者が操作するものである。販社は地域窓口会社となる。販社は顧客拠点・支社に対し、実際に納品・売上を行う。販社は統括販社，エリア販社などに分けることもできる。
【００１７】
顧客本社用端末４は顧客本社の担当者が操作するものである。顧客本社は代金請求／回収先となる。また、顧客拠点・支社用端末５は顧客拠点・支社の担当者が操作するものである。顧客拠点・支社は販社が実際に納品・売上を行う拠点・支社である。
【００１８】
代行回収ＤＢ１は、後述するように、代行回収管理に必要な各種処理の実行、各種情報の記録、及び代行回収受託の審査・承認処理（代行回収受託のワークフロー）の実行を行うものである。代行回収ＤＢ１は、例えば図２に示すようなハードウェア構成により実現される。
【００１９】
図２は代行回収ＤＢの一例のハードウェア構成図である。代行回収ＤＢ１は、それぞれバス１９で相互に接続されている入力装置１１，出力装置１２，ドライブ装置１３，補助記憶装置１４，メモリ装置１５，演算処理装置１６およびインターフェース装置１７を有するように構成される。
【００２０】
入力装置１１はキーボードやマウスなどで構成され、各種信号を入力するために用いられる。出力装置１２はディスプレイ装置などで構成され、各種ウインドウやデータ等を表示するために用いられる。インターフェース装置１７は、モデム，ＬＡＮカードなどで構成されており、ネットワーク６に接続する為に用いられる。
【００２１】
本発明の代行回収管理プログラムは、代行回収ＤＢ１を制御する各種プログラムの少なくとも一部である。代行回収管理プログラムは例えば記録媒体１８の配布やネットワーク６からのダウンロードなどによって提供される。代行回収管理プログラムを記録した記録媒体１８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。
【００２２】
また、代行回収管理プログラムを記録した記録媒体１８がドライブ装置１３にセットされると、代行回収管理プログラムは記録媒体１８からドライブ装置１３を介して補助記憶装置１４にインストールされる。また、ネットワーク６からダウンロードされた代行回収管理プログラムは、インターフェース装置１７を介して補助記憶装置１４にインストールされる。
【００２３】
代行回収ＤＢ１は、インストールされた代行回収管理プログラムを格納すると共に、必要なファイル，データ等を格納する。メモリ装置１５は、起動時に補助記憶装置１４から代行回収管理プログラムを読み出して格納する。そして、演算処理装置１６はメモリ装置１５に格納された代行回収管理プログラムに従って、後述するような各種処理を実現している。
【００２４】
図３は代行回収ＤＢの一実施例の機能構成図である。代行回収ＤＢ１は、請求データ取込み部２１，代行回収会社テーブル管理部２２，メール送信機能部２３，Ｗ／Ｆ部２４，仕訳データ書出し部２５，請求データ３１，代行回収会社テーブル３２，各社担当者テーブル３３，承認者役職設定テーブル３４を含む構成である。
【００２５】
請求データ取込み部２１は、例えば販社用端末３，経理システム（図示せず）等から顧客拠点・支社への請求データ３１を取り込む。代行回収会社テーブル管理部２２は図４に示す代行回収会社テーブル３２を管理する。
【００２６】
図４は代行回収会社テーブルの一例の構成図である。図４の代行回収会社テーブル３２は顧客毎に設けられたレコードから構成される。１レコード（１文書）は顧客毎の情報となる。また、レコードの構造は、親会社を表す「会社」，顧客本社を表す「回収先」，販社を表す「地域窓口会社」，顧客拠点・支社を表す「納入先」，代行回収受託の審査・承認処理（代行回収受託のワークフロー）を表す「承認方法」を項目として含むものである。
【００２７】
項目「承認方法」には、例えば取り込んだ請求データ３１を確認するかどうかの設定がされている。図４では、項目「承認方法」に「毎回確認」又は「２回目以降自動」が設定されている。なお、「毎回確認」は請求データ３１に対し、毎回、代行回収受託のワークフローを実行する為の設定である。「２回目以降自動」は請求データ３１に対し、２回目以降の代行回収受託のワークフローを省略する為の設定である。即ち、項目「承認方法」は代行回収受託のワークフローを実行及び省略する条件を設定したものである。
【００２８】
メール送信機能部２３は、各社担当者テーブル３３を利用し、親会社用端末２，販社用端末３，顧客本社用端末４，顧客拠点・支社用端末５にメール送信を行う。Ｗ／Ｆ部２４は、承認者役職設定テーブル３４を利用し、代行回収受託のワークフローを後述のように実行する。また、仕訳データ書出し部２５は、請求データ，支払データ，回収データを仕訳データとして自動的に書き出す。
【００２９】
次に、本発明の理解を容易とするため、代行回収の契約から売上計上までの手順について説明する。図５は代行回収の契約から売上計上までの手順の一例を示すフローチャートである。
【００３０】
ステップＳ１に進み、親会社と顧客本社とが代行回収に関する契約を結ぶ。ステップＳ２に進み、親会社の担当者は親会社用端末２を操作し、図４に示した代行回収ＤＢ１の代行回収会社テーブル３２に、契約を結んだ顧客のレコードを登録する。また、親会社の担当者は親会社用端末２を操作し、親会社，販社，顧客本社及び顧客拠点・支社の担当者の情報（メールアドレス，電話番号など）を各社担当者テーブル３３に登録する。
【００３１】
ステップＳ３に進み、販社の担当者は顧客拠点・支社から受注があると、ステップＳ４に進み、顧客拠点・支社に対して仕入・納品を行う。ステップＳ５に進み、販社の担当者は売上計上を行う。請求データ３１は、ステップＳ５の売上計上に基づき作成される。
【００３２】
図６は、代行回収管理の手順の一例を示すフローチャートである。例えば代行回収ＤＢ１は所定期間（例えば１日）毎に図６のフローチャートに示す処理を実行する。ステップＳ１１に進み、請求データ読込み部２１は図７のような請求データ３１を読み込む。
【００３３】
図７は請求データの一例の構成図である。請求データは、伝票キー，契約統括窓口会社の会社コード，契約統括窓口会社の部門コード，地域窓口会社の会社コード，地域窓口会社の担当の部門コード，地域窓口会社の担当の担当者社員コード，回収先−お客様  顧客サイトコード，取引日，納入日，発注Ｎｏ，請求書表示，納入先−お客様企業コード，納入先−お客様名，納入先−お客様  顧客サイトコード，納入先−お客様  顧客サイト名，品名，品種コード，数量，金額を項目として含む。
【００３４】
ステップＳ１２に進み、代行回収会社テーブル管理部２２は請求データ３１の契約統括窓口会社の会社コード，地域窓口会社の会社コード，回収先−お客様  顧客サイトコード及び納入先−お客様  顧客サイトコードをキー情報として代行回収会社テーブル３２を検索し、請求データ３１に対応する顧客のレコードが存在するかを判定する。
【００３５】
なお、請求データ３１の契約統括窓口会社の会社コードは代行回収会社テーブル３２の項目「会社」に対応する。請求データ３１の地域窓口会社の会社コードは、代行回収会社テーブル３２の項目「地域窓口会社」に対応する。
【００３６】
請求データ３１の回収先−お客様  顧客サイトコードは、代行回収会社テーブル３２の項目「回収先−顧客サイト」に対応する。また、請求データ３１の納入先−お客様  顧客サイトコードは代行回収会社テーブル３２の項目「納入先−顧客サイト」に対応する。
【００３７】
請求データ３１に対応する顧客のレコードが存在すれば、代行回収会社テーブル管理部２２はステップＳ１３に進む。ステップＳ１３では、代行回収会社テーブル管理部２２が請求データ３１に対応する顧客のレコードの項目「承認方法」を参照し、承認方法が毎回確認かを判定する。
【００３８】
承認方法が毎回確認であれば、Ｗ／Ｆ部２４はステップＳ１５に進む。なお、ステップＳ１２において、請求データ３１に対応する顧客のレコードが存在しないときも、Ｗ／Ｆ部２４はステップＳ１５に進む。
【００３９】
承認方法が２回目以降自動であれば、Ｗ／Ｆ部２４はステップＳ１４に進み、初めての確認（１回目の確認）であるかを判定する。その顧客の請求データ３１の初めての確認であれば、Ｗ／Ｆ部２４はステップＳ１５に進む。
【００４０】
ステップＳ１５ではＷ／Ｆ部２４がメール送信機能部２３に親会社の担当者への確認依頼メールを送信させる。メール送信機能部２３は各社担当者テーブル３２を参照し、親会社の担当者へ確認依頼メールを送信する。ステップＳ１６に進み、親会社の担当者は確認依頼メールを受信する。担当者は請求データ３１を確認する。
【００４１】
ステップＳ１７に進み、親会社の担当者は親会社用端末２を操作し、審査者への審査依頼を要求する。Ｗ／Ｆ部２４は、メール送信機能部２３に審査者への審査依頼メールを送信させる。メール送信機能部２３は、承認者役職設定テーブル３４を参照し、審査者へ審査依頼メールを送信する。審査者は審査依頼メールを受信すると、請求データ３１を審査する。
【００４２】
また、ステップＳ１８に進み、審査者は親会社用端末２を操作し、承認者への承認依頼を要求する。Ｗ／Ｆ部２４は、メール送信機能部２３に承認者への承認依頼メールを送信させる。メール送信機能部２３は、承認者役職設定テーブル３４を参照し、承認者へ承認依頼メールを送信する。承認者は承認依頼メールを受信すると、請求データ３１を承認する。
【００４３】
そして、Ｗ／Ｆ部２４は承認者によって請求データ３１が承認されると、ステップＳ１９に進む。なお、Ｗ／Ｆ部２４はステップＳ１４において、その顧客の請求データ３１の初めての確認でなければ、ステップＳ１９に進む。ステップＳ１９では、請求データ，支払データ，回収データを仕訳データとして自動的に書き出したあと、図６に示す処理を終了する。
【００４４】
図６に示すフローチャートでは、代行回収会社テーブル３２に顧客のレコードが存在するか、認証方法が毎回確認か、初めての確認かの判定結果に応じて、図８に示すように代行回収受託のワークフローの経路を変更している。即ち、図６に示すフローチャートでは代行回収受託のワークフローの経路を変更する条件として、代行回収会社テーブル３２に顧客のレコードが存在するか、認証方法が毎回確認か、初めての確認かの判定結果を利用している。
【００４５】
図８は経路の異なるワークフローを示した説明図である。図８（ａ）のワークフローは図６のステップＳ１５〜Ｓ１８に対応し、代行回収受託のワークフローを実行する例を表している。図８（ｂ）のワークフローは代行回収受託のワークフローを省略する例を表している。
【００４６】
つまり、図６に示すフローチャートでは代行回収会社テーブル３２に顧客のレコードが存在し、認証方法が毎回確認でなく、初めての確認でないことを条件として、代行回収受託のワークフローを省略している。
【００４７】
このように、予め設定してある条件に基づき、代行回収受託のワークフローを人が操作することなく自動的に省略できるようにしたことで、代行回収受託のワークフローの作業負荷を軽減できる。
【００４８】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。なお、本発明による代行回収ＤＢ１は経理システムの一機能としても利用可能である。
【図面の簡単な説明】
【００４９】
【図１】本発明による代行回収管理システムの一例の構成図である。
【図２】代行回収ＤＢの一例のハードウェア構成図である。
【図３】代行回収ＤＢの一実施例の機能構成図である。
【図４】代行回収会社テーブルの一例の構成図である。
【図５】代行回収の契約から売上計上までの手順の一例を示すフローチャートである。
【図６】代行回収管理の手順の一例を示すフローチャートである。
【図７】請求データの一例の構成図である。
【図８】経路の異なるワークフローを示した説明図である。
【符号の説明】
【００５０】
１    代行回収ＤＢ
２    親会社用端末
３    販社用端末
４    顧客本社用端末
５    顧客拠点・支社用端末
６    ネットワーク
１１    入力装置
１２    出力装置
１３    ドライブ装置
１４    補助記憶装置
１５    メモリ装置
１６    演算処理装置
１７    インターフェース装置
１８    記録媒体
１９    バス
２１    請求データ取込み部
２２    代行回収会社テーブル管理部
２３    メール送信機能部
２４    Ｗ／Ｆ部
２５    仕訳データ書出し部
３１    請求データ
３２    代行回収会社テーブル
３３    各社担当者テーブル
３４    承認者役職設定テーブル
【図１】
2008158896.tif 000003
【図２】
2008158896.tif 000004
【図３】
2008158896.tif 000005
【図４】
2008158896.tif 000006
【図５】
2008158896.tif 000007
【図６】
2008158896.tif 000008
【図７】
2008158896.tif 000009
【図８】
2008158896.tif 000010