(57)【要約】【課題】立場ごとに最適な予算執行内容を知ることができる予算執行管理方法及び予算執行管理プログラムを提供する。【解決手段】予算執行の状態を執行の流れに沿って未使用５０−１、購入依頼起票未承認５０−２、購入依頼承認済未契約５０−３、契約決議起票未承認５０−４、契約決議承認済未受入５０−５、受入検収済未払５０−６、及び支払済５０−７としてフェーズごとに管理し、その前日までの合計値５０、当日のジャーナル５１、及びこれらを合算したリアルタイムの予算執行額５２としてデータベースに保存する。そして担当者の職務に応じて未使用５０−１を購入依頼ベースの予算残額５３−１として表示し、これに購入依頼起票未承認５０−２及び購入依頼承認済未契約５０−３を足したものを契約ベースの予算残額５３−２として表示し、これに契約決議起票未承認５０−４、契約決議承認済未受入５０−５及び受入検収済未払５０−６を足したものを予算残額５３−３として表示する。【選択図】      図６
2004220122.tif 000002
【特許請求の範囲】
【請求項１】
複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の予算執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出することを特徴とする予算執行管理方法。
【請求項２】
算出される前記合計予算残額は、支払済みの購入計画には支払額、契約までの購入計画には契約額、購入依頼のみの購入計画には依頼額を合算対象として、それぞれについて合計予算残額を算出されることを特徴とする請求項１記載の予算執行管理方法。
【請求項３】
起票された購入依頼金額を入力する購入依頼金額入力工程と、該購入依頼金額入力工程により入力された前記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力工程と、
該購入依頼承認済金額入力工程により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力工程と、
該契約決議金額入力工程により入力された前記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力工程と、
該契約決議承認済金額入力工程により入力された前記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力工程と、
該受入検収済金額入力工程により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力工程と、
を含む予算執行管理方法であって、
更に、
前記購入依頼金額入力工程により入力された前記購入依頼金額から前記購入依頼承認済金額入力工程により入力された前記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出工程と、
前記購入依頼承認済金額入力工程により入力された前記承認済金額から前記契約決議金額入力工程により入力された前記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出工程と、
前記契約決議金額入力工程により入力された前記契約決議金額から前記契約決議承認済金額入力工程により入力された前記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出工程と、
前記契約決議承認済金額入力工程により入力された契約決議承認済金額から前記受入検収済金額入力工程により入力された前記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出工程と、
前記受入検収済金額入力工程により入力された前記受入検収済金額から前記支払済金額入力工程により入力された前記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出工程と、
を含み、
更に、
予算額から前記購入依頼起票未承認金額、前記購入依頼承認済未契約金額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、前記受入検収済未払金額、及び前記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出工程と、
前記購入依頼ベースの予算残額、前記前記購入依頼起票未承認金額、及び前記購入依頼承認済未契約金額を合算して契約ベースの予算残額を算出する契約ベース予算残額算出工程と、
前記契約ベース予算残額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、及び前記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出工程と、
前記購入依頼ベース予算残額、前記契約ベース予算残額、又は前記支払ベース予算残額を出力する予算残額出力工程と、
を含むことを特徴とする予算執行管理方法。
【請求項４】
複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の予算執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出する処理をコンピュータに実行させることを特徴とする予算執行管理プログラム。
【請求項５】
起票された購入依頼金額を入力する購入依頼金額入力処理と、該購入依頼金額入力処理により入力された前記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力処理と、
該購入依頼承認済金額入力処理により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力処理と、
該契約決議金額入力処理により入力された前記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力処理と、
該契約決議承認済金額入力処理により入力された前記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力処理と、
該受入検収済金額入力処理により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力処理と、
をコンピュータに実行させる予算執行管理プログラムであって、
更に、
前記購入依頼金額入力処理により入力された前記購入依頼金額から前記購入依頼承認済金額入力処理により入力された前記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出処理と、
前記購入依頼承認済金額入力処理により入力された前記承認済金額から前記契約決議金額入力処理により入力された前記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出処理と、
前記契約決議金額入力処理により入力された前記契約決議金額から前記契約決議承認済金額入力処理により入力された前記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出処理と、
前記契約決議承認済金額入力処理により入力された契約決議承認済金額から前記受入検収済金額入力処理により入力された前記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出処理と、
前記受入検収済金額入力処理により入力された前記受入検収済金額から前記支払済金額入力処理により入力された前記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出処理と、
を前記コンピュータに実行させ、
更に、
予算額から前記購入依頼起票未承認金額、前記購入依頼承認済未契約金額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、前記受入検収済未払金額、及び前記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出処理と、
前記購入依頼ベースの予算残額、前記前記購入依頼起票未承認金額、及び前記購入依頼承認済未契約金額を合算して契約ベースの予算残額を算出する契約ベース予算残額算出処理と、
前記契約ベース予算残額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、及び前記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出処理と、
前記購入依頼ベース予算残額、前記契約ベース予算残額、又は前記支払ベース予算残額を出力する予算残額出力処理と、
を前記コンピュータに実行させることを特徴とする予算執行管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、予算を効率良く執行できる予算執行管理方法及び予算執行管理プログラムに関する。
【０００２】
【従来の技術】
従来、予算は、一般の民間企業であれば、会計年度の上期と下期、あるいは四半期ごとに仕切られて、例えば大きな部署毎、その部署内のプロジェクト毎に、概略の想定される支払い対象が集計されて上部に申告される。その集計された総額がその使用内容とともに容認可能なものであれば、その申告額が容認されて各部署毎の予算として割り当てられるのが一般的である。
【０００３】
そして、そのように一旦割り当てられた予算は、元来が予算そのものが概算によって算出されたものであるから、結果として余剰である場合もあり不足である場合もある。しかし、そのように結果として余剰であったか不足であったかは、実際に予算を使用した後の期末になってみないと分からないのが現状である。
【０００４】
一般の民間企業では、日々の営業活動の状況を示す資料としては営業日報などの充実した資料があるが、予算の執行状況を知る会計資料としては、月ごとに作成される試算表や貸借対照表などがある。しかし、これらの内容は、企業の役員や会計の専門職が見て分かるものであって、予算を使用するに当って一般の社員が見て分かるものではなく見ても内容の判断は困難である。また、通常は一般の社員に見せるべきものではないとされている。
【０００５】
そのような予算の割り当てという点では、省庁や国立の研究所、大学などの官庁会計でもほぼ同様であり、年度ごとに予算が割り当てられる。省庁や国立の研究所、大学などの会計では、これらの予算の執行状況は一般の民間企業とは異なり、従来予算科目に基づいた考えかたによって行なわれていた。
【０００６】
したがって、例えば予算を使用して新たに物品を購入しようとする者が購入依頼の伝票を起こす場合には，予算残額を確認する必要があるが、従来の残額算出の方法は、例えば部署内の予算残高であれば、部署内の細部の予算使用状況とは拘わり無く、総合的に合算された予算残高が提示されるだけである。
【０００７】
例えば、年間の予算額は決まっているが実際の支払いは複数回に分けられる場合がある。例えば、コピー用紙の場合、年間の予算額は決まっていても実際には月ごとに使った分だけ支払いが発生していく。この場合、コピー用紙の予算の残高を月ごとに管理する考え方や認識は官庁会計の中には含まれていない。
【０００８】
図９は、そのような予算執行額の状態を示す図である。同図に示す予算執行額の状態の流れは、右から左に遷移していく状態を示している。同図に示すように、先ず予算額１があり、これを大きく分けて、未使用状態部分２、概算状態部分３、一部概算状態部分４、及び確定状態部分５として分類される。
【０００９】
未使用状態部分２は、その名のごとく未使用の予算額であり、これから使用が可能な予算の残額を示している。概算状態部分３は、購入依頼が起票済みであって未だ承認がされていないもの（購入依頼起票未承認分）、及び購入依頼が承認されていて契約が済んでいないもの（購入依頼承認済未契約分）が含まれる。
【００１０】
また、一部概算状態部分４は、契約決議伝票が起票されていて未だ承認されていないもの（契約決議伝票起票未承認分）、起票された契約決議伝票が承認されていてその契約に基づく物品が未だ納品検収されていないもの（契約決議承認済未受入分）、及び契約した物品の受け入れとその内容を確認する検収が済んでいて支払いが未だ行なわれていないもの（受入検収済未支払分）が含まれる。
【００１１】
そして、確定状態部分５は、その名の通り支払いが行われて予算の使用が確定したもの（支払済分）を示している。
ここで、予算残高という場合、通常は上記の未使用状態部分２の金額と概算状態部分３の金額を合計したものを予算残額６として示されるのが官庁会計の習慣である。
【００１２】
いずれにしても、予算は使用予定金額のことであって、予算そのものが概算によって算出されたものであり、したがって、購入依頼時に申請される金額は、あくまでも概算段階の金額であり、実際に執行される予算金額は購入依頼がなされた物品の契約段階以降に確定される。また、概算契約の場合は、契約段階では金額が確定せずに、支払段階まで金頼確定が持ち越される場合もある。
【００１３】
従来は、予算の残額として予算額と確定した執行額との差額を示していたが、この場合、使途が決定しているものの概算状態にある予算について考慮されていないことになり、利用可能な予算残額を正確には把握できていなかった。
【００１４】
したがって、上記のように予算が余剰となる場合や不足となる場合が起こったときに、もし予算の余剰部門から予算の不足部門に予算をリアルタイムで移動させることが出来れば予算執行の効率が向上するが、現状ではそのような会計システムは一般の企業における会計でも官庁会計でも実現はされていない。
【００１５】
なお、従来、官庁会計に関していえば、例えば予算科目ごとに予算額及び残額を管理するという提案がなされている（例えば、特許文献１参照。）。また、予算科目の最下位レベルで予算残額が足りない場合に上のレベルの残額を参照して，余裕があれば流用可能とするという提案がなされている（例えば、特許文献２参照。）。
【００１６】
【特許文献１】
特開平０５−１０８６５１号公報（要約。図１）
【特許文献２】
特開平０７−０２８９１２号公報（要約。図１）
【００１７】
【発明が解決しようとする課題】
上述したように、予算執行額の状態の流れの中で、予算残高を知ろうとするときに知り得るのは、図９に示す未使用状態部分２の金額と概算状態部分３の金額を合計した予算残額６である。しかし、これは正確な予算残額を示しているとは言えない。
【００１８】
なぜなら、上記の未使用状態部分２の次に示される概算状態部分３の「購入依頼起票未承認分」と「購入依頼承認済未契約分」に示される金額は、購入依頼起票が承認されたとしてもその購入依頼が契約されなければ予算は使用されていないのであるから予算残高として計上されるのはやむを得ない。
【００１９】
しかし、購入依頼起票が承認され、その承済みの購入依頼が契約されれば、実質的には予算は使用されたことになるから、その時点で予算残高は減少する。すなわち未使用２の予算残高はいつでも使用可能な予算残高であるが概算状態部分３の予算残額は常に減少する可能性を含んでいる。つまり未使用状態部分２と概算状態部分３とを合計した金額で示される予算残額６は、すでに購入依頼が起票されている金額を含んでいるので、潜在的にはもっと少なくなる可能性がある。つまり常に金額が減少する可能性を含んでいる。
【００２０】
また、そればかりでなく、概算状態部分３の金額は、購入依頼時に申請された金額であって、あくまでも概算で出された金額であり、実際に予算が執行される金額は契約段階以降に確定される金額である。そして概算契約の場合は契約段階では金額が確定せずに、支払段階まで金額確定が持ち越される場合もある。したがって、その点からみると概算状態部分３の金額は増加（契約時の値上げ）又は減少（契約時の値下げ）の可能性がある。つまり概算契約の金額が確定するときに増減する可能性がある。
【００２１】
このように、従来は、予算の残額として予算額と確定した執行額との差額を示していたが、この場合、使途が決定しているものの概算状態にある予算について考慮していないことになり、実際には、予算残額６で示される予算残高は、正確な予算残額を示しているとは言えないものであり、つまり利用可能な予算残額を正確に把握できていないものであって、従来は、そのように予算残額の正確な把握が困難であったものである。
【００２２】
このように予算を使用しようとする者にとっては利用可能な予算残額を正確に把握できないという不満があったが、他方、支払いを行う立場の者にとっても、今後支払いを行うべき予算執行の状態を正確に知ることが出来ないという不満の残る状況に置かれていた。
【００２３】
図１０（ａ），（ｂ），（ｃ）  は、予算が余剰であった場合（申告した予算の概算が支払確定金額より多い時）や予算が不足であった場合（申告した予算の概算が支払確定金額より少ない時）の従来の会計処理方法を説明する図である。この例では、説明を分かりやすくするために、例えば、年間契約でコピー紙代を契約し、使用した分を月々支払う複数回払いで行うことに取り決めた契約の場合について説明する。
【００２４】
その際、コピー紙の使用枚数が未定の為、全体金額を大目に見積もり，概算金額を出す。その結果、概算金額と支払確定金額に差が生じるが、その差額の処理は契約の終了を待たないと清算することができない。
【００２５】
例として、半年分のコピー紙代１２００円を月々２００円の６回払いで契約した場合、同図（ａ）  に示すように、１月１０日から６月１０日まで各月の支払日である１０日ごとに概算金額欄に示される概算金額より支払確定金額欄に示される金額の方が少ないとき、同図（ａ）  の例では２月は￥１００少なく、３月でも￥１００少なく、５月では￥５０少なく、６月の契約最終日に確定した支払金額は合計￥９５０であって￥２５０の予算の余りが出ている。しかしこの予算余剰残高￥２５０は、６月１０日の契約最終日（つまり全ての支払が終了する日まで）の支払い金額の確定を見るまでは、余剰金（概算予算額が支払い確定金額より少ない場合の余剰金）が開放される（他へ転用される）ことはない。
【００２６】
現実には、同図に示す例では、６月１０日の契約最終日を待つまでもなく、２月で￥１００が余剰であり、３月で￥１００が余剰であり、５月で￥５０が余剰であって、それぞれ、その時点で他へ回すことができるものであるが、従来の予算管理方法では、そのような予算の活用ができず、また予算枠の変動もできなかった。その為、概算金額との差額（余り分計￥２５０）を６月１０日まで他の予算に充当する事ができず、作業の非効率を生じていた。
【００２７】
また、同図（ｂ）  に示すように、同じく半年分のコピー紙代１２００円を月々２００円の６回払いで契約した場合、１月１０日から６月１０日まで各月の支払日である１０日ごとに概算金額欄に示される概算金額より支払確定金額欄に示される金額の方が多いとき、同図（ｂ）  の例では２月に支払い￥６００と概算の予定よりも￥４００多く、逆に３月では支払い￥０であり、４月では再び￥１００多く、５月では又￥１００少なく、そして６月では概算予定通りの￥２００であり、契約最終日に確定した支払金額は合計￥１４００であって￥２００の予算超過であった。
【００２８】
ところで、上記の２月に支払い￥６００の支払超過が発生した時点で、その後の予算使用額が概算通りであるとすると、全体として予算は￥４００の不足となるから、ここで予算の掴み直し（増額）が行われる。
【００２９】
同図（ｃ）  は、その状態を示している。同図（ｃ）  に一点鎖線７で示すグラフは当初の概算予算を示している。そして、実線８で示すグラフは、増額を行われた予算額を示している。この実線８で示すように２月１０日で予算が￥４００増加している。しかし、その後、上記のように３月１０日と５月は１０日で支払いが概算予算よりも減っており、同図（ｃ）  の破線９で示すように、実際に使用された予算総額（確定予算総額）は、増額された予算総額（実線８の６月１０日の時点）よりも減っている。同図（ｂ）  に示すように、契約最終日に確定した実際の不足額は￥２００であったが、２月１０で増額された予算￥４００はそのままであるので実際には￥２００の余剰金が発生している。
【００３０】
この余剰金は、同図（ｂ）  で明らかなように、３月１０日に￥２００余り、４月１０日で￥１００の不足、５月１０日で￥１００余り、つまり現実には、同図に示す例では、６月は１０日の契約最終日を待つまでもなく、３月１０日で￥２００が余剰であり、その時点で他へ回すことができるものでるが、従来の予算管理方法では、それが出来ない。増額した予算はそのまま最終日まで持ち越されることになっている。
【００３１】
このように、複数回払いにおいて、概算金額より確定金額が少ない場合、全ての支払が終わるまで他への予算活用ができない。あるいは、一度予算枠を増やした場合、その後の確定金額が少ない場合でも一旦増額した予算は減らすことができないという予算の効率的使用の点で流動性に欠けるものであった。
【００３２】
このような問題に対して、前述の特許文献１の提案では、利用者は，予算科目ごとに予算額や残額を入力する必要があり、これでは、社員のそれぞれが会計担当者と同様のデータ入力を行うことになって手数が掛かり過ぎて負担が大きいという問題がある。
【００３３】
また、前述の特許文献２の提案では、個々の予算使用対象の現在の状況を分析したり、予算の執行状況を見る例えば予算を直接使用する現場の者、各現場からの予算使用申請に基づいて発注契約を行う者、発注品の受け入れに基づいて支払いを行う者などの立場ごとに、最適な予算執行内容を見ることが出来るようにすることについては何らの考慮もなされていない。
【００３４】
本発明の課題は、上記従来の実情に鑑み、短期間ごと立場ごとに最適な予算執行内容を知ることができる予算執行管理方法及び予算執行管理プログラムを提供することである。
【００３５】
【課題を解決するための手段】
以下に、本発明に係わる予算執行管理方法及び予算執行管理プログラムについてその構成を述べる。
【００３６】
先ず、請求項１記載の発明の予算執行管理方法は、複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の予算執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出するように構成される。
【００３７】
算出される上記合計予算残額は、例えば請求項２記載のように、支払済みの購入計画には支払額、契約までの購入計画には契約額、購入依頼のみの購入計画には依頼額を合算対象として、それぞれについて合計予算残額を算出されるように構成される。
【００３８】
次に、請求項３記載の発明の予算執行管理方法は、起票された購入依頼金額を入力する購入依頼金額入力工程と、該購入依頼金額入力工程により入力された上記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力工程と、該購入依頼承認済金額入力工程により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力工程と、該契約決議金額入力工程により入力された上記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力工程と、該契約決議承認済金額入力工程により入力された上記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力工程と、該受入検収済金額入力工程により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力工程と、を含む予算執行管理方法であって、更に、上記購入依頼金額入力工程により入力された上記購入依頼金額から上記購入依頼承認済金額入力工程により入力された上記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出工程と、上記購入依頼承認済金額入力工程により入力された上記承認済金額から上記契約決議金額入力工程により入力された上記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出工程と、上記契約決議金額入力工程により入力された上記契約決議金額から上記契約決議承認済金額入力工程により入力された上記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出工程と、上記契約決議承認済金額入力工程により入力された契約決議承認済金額から上記受入検収済金額入力工程により入力された上記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出工程と、上記受入検収済金額入力工程により入力された上記受入検収済金額から上記支払済金額入力工程により入力された上記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出工程と、を含み、更に、予算額から上記購入依頼起票未承認金額、上記購入依頼承認済未契約金額、上記契約決議起票未承認金額、上記契約決議承認済未受入金額、上記受入検収済未払金額、及び上記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出工程と、上記購入依頼ベースの予算残額、上記上記購入依頼起票未承認金額、及び上記購入依頼承認済未契約金額を合算して契約ベースの予算残額を算出する契約ベース予算残額算出工程と、上記契約ベース予算残額、上記契約決議起票未承認金額、上記契約決議承認済未受入金額、及び上記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出工程と、上記購入依頼ベース予算残額、上記契約ベース予算残額、又は上記支払ベース予算残額を出力する予算残額出力工程と、を含んで構成される。
【００３９】
更に、請求項４記載の発明の予算執行管理プログラムは、複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の予算執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出する処理をコンピュータに実行させるように構成される。
【００４０】
そして、請求項５記載の発明の予算執行管理プログラムは、起票された購入依頼金額を入力する購入依頼金額入力処理と、該購入依頼金額入力処理により入力された上記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力処理と、該購入依頼承認済金額入力処理により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力処理と、該契約決議金額入力処理により入力された上記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力処理と、該契約決議承認済金額入力処理により入力された上記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力処理と、該受入検収済金額入力処理により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力処理と、をコンピュータに実行させる予算執行管理プログラムであって、更に、上記購入依頼金額入力処理により入力された上記購入依頼金額から上記購入依頼承認済金額入力処理により入力された上記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出処理と、上記購入依頼承認済金額入力処理により入力された上記承認済金額から上記契約決議金額入力処理により入力された上記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出処理と、上記契約決議金額入力処理により入力された上記契約決議金額から上記契約決議承認済金額入力処理により入力された上記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出処理と、上記契約決議承認済金額入力処理により入力された契約決議承認済金額から上記受入検収済金額入力処理により入力された上記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出処理と、上記受入検収済金額入力処理により入力された上記受入検収済金額から上記支払済金額入力処理により入力された上記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出処理と、を上記コンピュータに実行させ、更に、予算額から上記購入依頼起票未承認金額、上記購入依頼承認済未契約金額、上記契約決議起票未承認金額、上記契約決議承認済未受入金額、上記受入検収済未払金額、及び上記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出処理と、上記購入依頼ベースの予算残額、上記上記購入依頼起票未承認金額、及び上記購入依頼承認済未契約金額を合算して契約ベースの予算残額を算出する契約ベース予算残額算出処理と、上記契約ベース予算残額、上記契約決議起票未承認金額、上記契約決議承認済未受入金額、及び上記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出処理と、上記購入依頼ベース予算残額、上記契約ベース予算残額、又は上記支払ベース予算残額を出力する予算残額出力処理と、を上記コンピュータに実行させるように構成される。
【００４１】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
図１は、一実施の形態における予算執行管理を行う予算執行管理サーバを中心とする予算執行管理システムの構成を示すブロック図である。同図に示すように、予算執行管理システム１０は、予算執行管理サーバ（装置）１１と、利用者コンピュータや管理者コンピュータからなる複数の操作者端末１２−ｉ（ｉ＝１，２，・・・、ｎ）と、これら操作者端末１２−ｉと予算執行管理サーバ１１が接続されたネットワーク１３とで構成される。
【００４２】
上記の予算執行管理サーバ１１は、特には図示しないが、ＣＰＵ（ｃｅｎｔｒａｌ−ｐｒｏｃｅｓｓｉｎｇ−ｕｎｉｔ）を備え、このＣＰＵにバスを介して接続されたＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ−ａｃｃｅｓｓ−ｍｅｍｏｒｙ）及び内蔵の大型記憶装置を備えている。ＲＯＭにはＢＩＯＳ（Ｂａｓｉｃ−Ｉｎｐｕｔ／Ｏｕｔｐｕｔ−Ｓｙｓｔｅｍ）が格納されており、大型記憶装置には、予算執行管理サーバ１１でＣＰＵが動作するための予算執行管理サーバ（ソフト）の一部を構成する少なくとも伝票処理プログラム１４、予算管理プログラム１５、及び予算状況出力プログラム１６が格納されている。
【００４３】
これらのプログラムは、ＢＩＯＳの元で動作するＣＰＵによって順次ＲＡＭに呼び出されて後述する予算執行管理の処理が行われる。
また、上記の予算執行管理サーバ１１には、ＣＰＵに上記のバス及び不図示のインターフェースを介して記録媒体としての２台の外部記憶装置１７（１７−１、１７−２）が接続されている。これらの外部記憶装置１７−１及び１７−２は例えば、外付けＨＤ（Ｈａｒｄ−ｄｉｓｋ）、ＦＤ（ｆｌｅｘｉｂｌｅ−ｄｉｓｋ）、ＣＤ−ＲＯＭ／ＲＷ（ｃｏｍｐａｃｔ−ｄｉｓｋ−ＲＯＭ／Ｒｅａｄ−Ｗｒｉｔｅ）、ＭＯ（Ｍａｇｎｅｔ  Ｏｐｔｉｃａｌ  ｄｉｓｋ）、フラッシュメモリ等の携帯可能なデータ及びプログラムの記録媒体である。
【００４４】
なお、操作者端末１２−ｉが予算執行管理サーバ１１から伝票処理プログラム１４、予算管理プログラム１５、又は予算状況出力プログラム１６などをダウンロードするようなときには、ネットワーク１３もプログラム媒体を構成するものと考えることができる。
【００４５】
上記の外部記憶装置１７−１及び１７−２には、上記の伝票処理プログラム１４や予算管理プログラム１５及び予算状況出力プログラム１６によって作成された又はそれらのプログラムと連携して用いられる伝票データのデータベース（ＤＢ）や予算データのデータべース（ＤＢ）が格納されている。
【００４６】
更に、上記の予算執行管理サーバ１１には、ＣＰＵに上記のバス及び不図示のインターフェースを介して入力手段としての入力装置１８や、出力手段としての出力装置１９が接続されている。
【００４７】
入力装置は１８は、キーボード又は表示装置に重ねて配設された感圧型、静電感知型などの透明電極から成る入力操作装置であり、マウス等のポインティングデバイスなども接続されている。
【００４８】
出力装置は、プリンタや表示装置である。表示装置は、ＣＲＴ（ｃｏｔｈｏｄｅ−ｒａｙ−ｔｕｂｅ）、ＬＣＤ（ｌｉｑｕｉｄ−ｃｒｙｓｔａｌ−ｄｉｓｐｌａｙ）又はプラズマディスプレイ（ｐｌａｓｍａ  ｄｉｓｐｌａｙ  ｐａｎｅｌ）などからなる表示装置である。プリンタは、主として伝票類の発行に専用される連続紙使用のラインプリンタや購入依頼書等の通常の書類型の伝票を印刷するページプリンタなどである。
【００４９】
また、上記の操作者端末１２−ｉは、例えばパーソナルコンピュータから成り、本体装置のほかに少なくともマウス、表示装置及びキー入力装置を備えている。
【００５０】
また、ネットワーク１３は、インターネット、イントラネット、又はＬＡＮ（Ｌｏｃａｌ−Ａｒｉａ−Ｎｅｔｗｏｒｋ）等である。
図２（ａ）  は、上記の予算執行管理システムにおける支払確定額が概算金額よりも少ない場合の予算枠計算方法（つまり計算手順）を説明する図表であり、図２（ｂ）  は比較説明のために図１０（ａ）  を再掲した図、図２（ｃ）  は本例の予算執行管理システムの機能を説明する図である。
【００５１】
図２（ａ）  に示す計算手順を示す図表２０は、左から右へ支払日欄２１、計算欄２２、及び差額欄２３からなる。支払日欄２１には、支払日すなわち支払い金額の確定日が示され、計算欄２２には、確定した支払い金額計（累計）と、概算予算枠の残額（未払い月の概算金額の合計）と、これらを足して得られる予算枠とが示され、そして、差額欄２３には、概算金額と実際に支払われた確定金額との差額が示されている。
【００５２】
すなわち、本例において計算欄２２に示される予算枠は、従来のように当初に決定されている予算枠ではなく、支払日に確定した支払い金額の累計と、これから後の未払い月の概算金額の合計とを足したものである。したがって、支払日に確定した支払い金額が概算金額に対して過不足の変動があれば、その分だけ、予算枠が変動する。このように変動する予算枠が支払日毎に算出される。そして、変動の元となった過不足の金額が差額欄２３に記憶される。
【００５３】
図２（ａ）  の例では、１月１０日では、確定金額計として￥２００（１月は最初の月であるので支払った金額と累計額が同額である）、概算金額残すなわち２月１０日〜６月１０日の概算予算の金額合計として￥１０００、これらを足した￥１２００が、１月１０日における予算枠となっている。確定金額と概算金額との差額は「０」である。
【００５４】
次の２月１０日の例では、確定金額計として￥３００（１月の支払確定金額￥２００と２月の支払確定金額￥１００を足したもの）、概算金額残すなわち３月１０日〜６月１０日の概算予算の金額合計として￥８００、これらを足した￥１１００が、２月１０日における予算枠となっている。確定金額と概算金額との差額は＋￥１００であり予算が余った状態である。
【００５５】
以下、同様にして、３月１０日で￥１００余り、５月１０日で￥５０余りとなっている。これは図２（ｂ）  に示す概算金額と支払確定金額との関係から出たもので、図１０（ａ）  で説明した内容と同一のものでもある。
【００５６】
しかし、図１０（ａ）  の従来の場合では６月１０日の契約完了までは余剰予算￥２５０は使用することが出来なかったが、本例では、図２（ａ）  及び同図（ｃ）  に示すように、当初の予算枠２４に対し、支払日に余剰額が算出される毎に差額欄２３に余剰額が記憶されるとともに、２月１０日以後の予算枠２５、３月１０日以後の予算枠２６に示すように、確定金額支払日以後の予算枠は余剰額を差し引いた予算枠となっているので、差額欄２３に記憶された余剰金額は容易に他に転用して使用することができる。
【００５７】
尚、図２（ａ）  及び同図（ｃ）  に示す変動予算枠の推移に示すように、最終の６月１０日の支払確定金額は、ちょうど前月（５月１０日）の支払日で変動して６月に繰り越された予算枠２７内となっていて、差額は「０」であるが、ここで差額が出れば、同様に処理される。いずれにしても、最終支払月では、支払確定金額の合計額が総予算枠となる。
【００５８】
図３（ａ）  は、本例の予算執行管理システムにおける支払確定額が概算金額よりも多い場合の予算枠計算方法（計算手順）を説明する図表であり、図３（ｂ）  は比較説明のために図１０（ｂ）  を再掲した図、図３（ｃ）  は本例の予算執行管理システムの機能を説明する図である。
【００５９】
図３（ａ）  に示す計算手順を示す図表３０は、計算内容すなわち数値のデータが異なるだけで、図２（ａ）  の場合と処理方法は同様である。すなわち図表３０は、左から右へ支払日欄３１、計算欄３２、及び差額欄３３からなる。支払日欄３１には、支払い金額が確定する支払日が示され、計算欄３２には、確定した支払い金額累計と、概算予算枠の残額合計と、これらを足して得られる予算枠とが示され、そして、差額欄３３には、概算金額と実際に支払われた確定金額との差額が示されている。
【００６０】
この場合も、計算欄３２に示される予算枠は、従来のように当初に決定されている予算枠ではなく、支払日に確定した支払い金額の累計と、これから後の未払い月の概算金額の合計とを足したものである。したがって、支払日に確定した支払い金額が概算金額に対して過不足の変動があれば、その分だけ、予算枠が変動し、その変動した予算枠が支払日毎に算出される。そして、変動の元となった過不足の金額が差額欄３３に記憶される。
【００６１】
すなわち、図３（ａ）  の例では、１月１０日の支払日には、確定金額計として￥２００、概算金額残（２月１０日〜６月１０日の概算金額合計）として￥１０００、これらを足して予算枠は￥１２００となる。確定金額と概算金額との差額は「０」である。
【００６２】
これに対して、２月１０日の支払いでは、確定金額計￥８００、概算金額残（３月１０日〜６月１０日の概算金額合計）￥８００、これらを足して２月１０日現在の予算枠は  ￥１６００である。この場合、確定金額計と概算金額計との差額は「−￥４００」であり、その分だけ前月に設定されている予算枠￥１２００に対して予算を超過して支払ったことなる。
【００６３】
この場合、本例では、操作者端末１２−ｉにおいて警告音の報音、又は警告メッセージの報知が行われた後、超過支払分だけ予算枠が拡大される。この予算枠の拡大は、図２（ａ），（ｂ），（ｃ）  で説明したように予算枠が減額された部署の差額欄２３の余剰金額を記憶装置の所定の記憶領域に溜め込んでおき、この余剰金額を転用するようにする。
【００６４】
また、３月１０日では、確定金額計は￥８００で前月と変わらず、つまり支払いの発生が無く、概算金額残（４月１０日〜６月１０日の概算金額合計）は￥６００、それらの合計が３月１０日現在の予算枠￥１４００として計上される。確定金額計と概算金額計との差額は「＋￥２００」であり、その分だけ予算枠は減額されている。
【００６５】
その後、４月１０日では￥１００が不足し、５月１０日では￥１００が余りとなっている。これは図３（ｂ）  に示す概算金額と支払確定金額との関係から出たもので、図１０（ｂ）  で説明した内容と同一のものでもある。
【００６６】
上記の図１０（ｂ）  の従来の場合では、２月は１０日で増額された予算が最終的に余っても、６月１０日の契約完了までは余剰金額￥２００は使用することが出来なかったが、本例では、図３（ａ）  及び同図（ｃ）  に示すように、当初の予算枠３４に対し、２月１０日に増額されて予算枠３５となっても、その後も支払日ごとに過不足が算出される。そして、３月１０日で余り￥２００が算出されると、その￥２００を差額欄３３に記憶するとともに予算枠を上記の増額された予算枠３５から￥２００減額して予算枠３６とする。
【００６７】
また、４月１０日では不足￥１００が生じたため、その分の金額を差額欄３３に記憶するとともに、その分の金額を増額した予算枠３７が設定される。そして、５月１０日の支払で再び余り￥１００が生じたので、その分の金額を差額欄３３に記憶するとともに、その分の金額を減額した予算枠３８が設定される。そして、最終の６月１０日の支払では、確定金額は、ちょうど前月（５月１０日）の支払日で変動して６月に繰り越された予算枠３８内となっていて、差額は「０」である。もちろん、この場合も、ここで差額が出れば、上記同様に処理されて、最終支払月では、支払確定金額の合計額が総予算枠となる。
【００６８】
このように、概算金額より支払確定金額が多い場合は、予算枠を拡大する事ができる。すなわち、この場合も、所定の計算方法による予算枠の金額が確定する毎に、その算出結果の予算枠に応じて当初予算枠を変動させ増減の設定を行うことができる。
【００６９】
また、このように本例によれば、図２（ａ），（ｂ），（ｃ）  に示す支払確定額が概算予算額よりも少ない場合、あるいは図３（ａ），（ｂ），（ｃ）  に示す支払確定額が概算予算額よりも多い場合のいずれにしても、予算枠設定後に、支払日に余りが出たときは、直ちにその余剰金額が判明し且つその後の予算枠が減額されるので、余剰となった金額を他に転用することが容易となる。また、実情に即して予算枠が変動するので予算執行内容がより明確となる。
【００７０】
図４及び図５は、上記の概算予算金額と支払確定金額との関係を、更に説明する図であり、図４は、１回払いの購入依頼の場合の流れを説明する図であり、図５は複数回払いの購入依頼の場合の流れを説明する図である。
【００７１】
先ず、図４により１回払いの購入依頼の場合の流れを説明する。図１に示した外部記憶装置１７−２に格納されている予算データのデータべース（図４の予算ＤＢ４０）には、予算管理プログラム１５によって、Ａプロジェクトの概算予算額￥５００が、Ａプロジェクト概算予算額データ４１として登録されている。
【００７２】
ここで購入希望者から購入依頼伝票４２が発行されたとする。購入依頼伝票４２には、オーダ（購入計画）対象の物品名「Ａ」、購入概算額「￥１００」、及び「１回払い」の支払方法の指定が記載されている。その右方に示すジャーナル（伝票情報）４３−１は、伝票処理プログラム１４によって外部記憶装置１７−１に格納されている伝票データのデータべース上に生成された上記の購入依頼伝票４２が発行されるまでの間のジャーナルデータ（一伝票単位ごとの伝票データ）▲１▼〜▲３▼と、購入依頼伝票４２のジャーナルデータ▲４▼が示されている。そして、ジャーナルデータ▲４▼では上記の依頼伝票４２の分として購入依頼￥１００が計上されている。
【００７３】
このジャーナル４３−１に見られるように、物品名「Ａ」の購入に関しては、ジャーナルデータ▲１▼と▲３▼で、それぞれ￥５０と￥３０の契約が確定している。また、ジャーナルデータ▲２▼では、受入済￥６０が確定している。そして、ジャーナルデータ▲４▼では￥１００が概算額となっている。
【００７４】
つまり、ジャーナルデータ▲４▼で示される購入依頼伝票４２が発行された時点では、予算（￥５００）に対して前日までの予算執行額は￥５０＋￥６０＋￥３０＝￥１４０であり、当日の予算執行額が概算の￥１００、合計の予算執行額は概算含みで￥２４０である。したがって、予算残額は、￥５００（予算）−￥２４０（予算執行額合計）＝￥２６０（予算残額）であった。この金額￥２６０が、予算管理プログラム１５によって外部記憶装置１７−２に格納されている予算データのデータベース（図４の予算ＤＢ４０（４０−１））のＡプロジェクトの予算執行残高４１−１として計上される。
【００７５】
そして、この後、例えば翌日に、上記の依頼伝票４２に基づいて契約書４４が発行される。契約書４４には、オーダ（購入計画）対象の物品名「Ａ」、実際の購入契約額「￥９０」、及び「１回払い」の支払方法の指定が記載されている。その右方に示すジャーナル４３−２は、これも伝票処理プログラム１４によって外部記憶装置１７−１に格納されている伝票データのデータべース上に生成された上記の契約書４４が発行されるまでの間のジャーナルデータ▲１▼〜▲３▼と、契約書４４のジャーナルデータ▲４▼が示されている。そして、ジャーナルデータ▲４▼では上記の契約書４４の分として実際の購入契約額￥９０が計上されている。
【００７６】
このように、購入依頼伝票４２が発行された翌日のジャーナル４３−２では、前日のジャーナルデータ▲１▼で契約済金額￥５０が本日には受入済金額￥５０となっており、前日のジャーナル▲２▼で受入済金額￥６０が本日には支払済金額￥６０となっており、前日のジャーナル▲３▼で契約済金額￥３０が本日もそのまま契約済金額￥３０となって繰り越され、そして前日のジャーナルデータ▲４▼で概算の購入依頼金額￥１００が本日には契約済金額￥９０となっている。この契約済金額￥９０は確定金額であり、本日の予算執行残額は、￥５００（予算）−￥２３０（予算執行額合計）＝￥２７０（予算残額）であって、この金額￥２７０が、予算管理プログラム１５によって、外部記憶装置１７−２に格納されている予算データのデータべース（図４の予算ＤＢ４０（４０−２））のＡプロジェクトの予算執行残高４１−２として計上される。
【００７７】
つまり、前日の概算予算執行残高￥２６０に対して本日の確定予算執行残高￥２７０は、￥１０増しとなっている。この￥１０は確定予算執行後の余剰金額であり、他の予算に転用することができる。
【００７８】
次に、図５により複数回払いの購入依頼の場合の流れを説明する。この例では図１に示した外部記憶装置１７−２に格納されている予算データのデータべース（図５に示す予算ＤＢ４０−３）には、Ａプロジェクトの概算予算額￥６００が、Ａプロジェクト概算予算額データ４１−３として登録されている。
【００７９】
ここで購入希望者から購入依頼伝票４５が発行されたとする。購入依頼伝票４５には、オーダ対象の物品名「Ａ」、購入概算額「￥１４０」、及び「複数回払い」の支払方法指定、そして複数回払いの金額が３回の支払い回数とともに５０円、４０円、及び５０円と記載されている。
【００８０】
その右方に示すジャーナル４３−３は、伝票処理プログラム１４によって外部記憶装置１７−１に格納されている伝票データのデータべース上に生成された上記の購入依頼伝票４５が発行されるまでの間のジャーナルデータ▲１▼〜▲３▼と、購入依頼伝票４５のジャーナルデータ▲４▼が示されている。なお、この場合も、ジャーナルデータ▲１▼〜▲３▼は、図４のジャーナル４３−１のジャーナルデータ▲１▼〜▲３▼と同一である。この例では、ジャーナルデータ▲４▼として、上記の依頼伝票４５の分として支払予定￥１４０が計上されている。なお、同図には参考として支払予定￥１４０の下に上記複数回払いの金額が数値５０、４０、５０として示されている。
【００８１】
このジャーナル４３−３に見られるように、この場合もジャーナルデータ▲１▼〜▲３▼で、それぞれ￥５０、￥６０、￥３０の予算の執行が執行内容別に確定している。そして、伝票処理プログラム１４によって、ジャーナルデータ▲４▼で支払予定￥１４０が概算額として計上されている。
【００８２】
つまり、ジャーナルデータ▲４▼で示される購入依頼伝票４５が発行された時点では、予算（￥６００）に対して前日までの予算執行額は￥５０＋￥６０＋￥３０＝￥１４０であり、当日の予算執行額が概算の￥１４０、合計の予算執行額は概算含みで￥２８０である。したがって、予算残額は、￥６００（予算）−￥２８０（予算執行額合計）＝￥３２０（予算残額）である。この金額￥３２０が、予算管理プログラム１５によって、外部記憶装置１７−２に格納されている予算データのデータべース（図５の予算ＤＢ４０（４０−４））のＡプロジェクトの予算執行残高４１−４として計上される。
【００８３】
そして、この後、例えば翌日に、上記の依頼伝票４５に基づいて支払伝票４６が発行される。支払伝票４６には、オーダ対象の物品名「Ａ」、支払い予定額「１４０」、「複数回払い」の支払方法の指定、及び実際の支払い契約額が３回の支払い回数とともに４０円、４０円、５０円と記載されている。
【００８４】
その右方に示すジャーナル４３−４は、伝票処理プログラム１４によって外部記憶装置１７−１に格納されている伝票データのデータべース上に生成された上記の支払伝票４６が発行されるまでの間のジャーナルデータ▲１▼〜▲３▼と、支払伝票４６に基づくジャーナルデータ▲４▼が示されている。そして、ジャーナルデータ▲４▼では上記の複数回払いの契約に基づいて初回払い分の￥４０が支払済欄に計上され、残り２回分の支払い契約金額￥９０が支払予定欄に計上されている。
【００８５】
このように、購入依頼伝票４５が発行された翌日のジャーナル４３−４では、前日のジャーナルデータ▲１▼で契約済金額￥５０が本日には受入済金額￥５０となっており、前日のジャーナル▲２▼で受入済金額￥６０が本日には支払済金額￥６０となっており、前日のジャーナル▲３▼で契約済金額￥３０が本日もそのまま契約済金額￥３０となって繰り越され、そして前日のジャーナルデータ▲４▼で概算の支払い予定金額￥１４０が本日では支払予定金額￥９０と支払済金額￥４０になっている。支払済金額￥４０は、購入依頼伝票４５では初回の支払い分￥５０に対応する支払い実行額であり、￥１０安くなっている。
【００８６】
上記の支払済金額は確定金額であり、本日の予算執行残額は、￥６００（予算）−￥２７０（予算執行額合計）＝￥３３０（予算残額）であって、この金額￥３３０が、予算管理プログラム１５によって外部記憶装置１７−２に格納されている予算データのデータべース（図５の予算ＤＢ４０（４０−５））のＡプロジェクトの予算執行残高４１−５として計上される。
【００８７】
つまり、前日の概算予算執行残高￥３２０に対して本日の確定予算執行残高￥３３０は、上記の￥１０安く支払った分だけ￥１０増しとなっている。この￥１０は確定予算執行後の余剰金額であり、他の予算に転用することができる。
【００８８】
ところで、上述した図２〜図５の説明では、支払確定金額と概算予算金額との関係から当初の予算枠をリアルタイムで変動させて報知できるようにし、必要に応じて予算が余ったところから予算が不足しているところに短期間内に移動（転用）できるようにする柔軟性のある会計処理方法について説明したが、従来からの会計上の情報は極めて分かりにくいものであったため、せっかく上述したように予算枠を変動させるという柔軟性のある予算体系を採用しても、部署ごと研究プロジェクトごとに係わる予算額、例えば物品（ここでは機器、消耗品、臨時労力などを含めていう）の購入を依頼する者にとって知りたい予算残額と、購入依頼を受けてその購入契約を実行する契約担当者が知りたい予算残額と、契約に基づいて検収した物品への支払いを行う者が知りたい予算残額は、それぞれ内容的に異なるものである。
【００８９】
図６は、本発明の予算執行管理方法及び予算執行管理プログラムの動作を説明する図である。同図は上から下に、先ず前日までの執行額（予算執行額、以下同様）の合計値５０を、図９に示した予算執行額の状態の流れに沿って示し、次に当日のジャーナル５１を上記予算執行額の状態の流れに沿って示し、更に次にリアルタイムな予算執行額５２を同じく上記予算執行額の状態の流れに沿って示し、最後に各部署ごとに応じた予算残高５３（５３−１、５３−２、５３−３）を示している。
【００９０】
ここで、上記の予算執行額の状態の流れに示す「未使用分」５０−１は、会計年度の期首においては、概算購入計画額に対応して承認されて設定された当初予算そのものであり、その後、各担当者によって起票される「購入依頼伝票の未承認分」５０−２という購入計画の最初の実行段階の状態を示す伝票の発行（及びその金額の入力、以下同様）によって「未使用分」５０−１で示される金額（予算残高）は順次減少していく。
【００９１】
また、「購入依頼伝票の未承認分」５０−２は、新規の購入依頼伝票の発行によって金額が増加し、「購入依頼承認済伝票の未契約分」５０−３という購入計画の次の実行段階の状態を示す伝票の発行によって金額が減少する。
【００９２】
これは「契約決議伝票の未承認分」５０−４、「契約決議承認済伝票の未受入分」５０−５、及び「受入検収済伝票の未払分」５０−６についても同様であり、そのものの伝票発行で金額が増加し、購入計画の次の実行段階の状態を示す伝票の発行によって金額が減少する。
【００９３】
そして「支払済伝票分」５０−７は、ひとつの購入計画の実行段階（ある一纏まりの予算執行）の最終段階を示している。ただし、その購入計画の支払い条件が一括払いであれば、その購入計画の終了段階を示し、支払い条件が複数回払いであれば、支払い日ごとの支払い終了を示している。
【００９４】
尚、上記の購入計画の各実行段階の状態を示す伝票の内容は、予算を執行する各段階の状態を示す伝票の内容でもあり、この伝票内容が示す状態（各予算執行段階の状態）を、以下の説明では「フェーズ」という場合もある。
【００９５】
上記の「購入依頼伝票の未承認分」５０−２は、先ず、購入依頼伝票の金額として図１に示す操作者端末１２−ｉの入力装置から、購入依頼伝票が起票され、この起票された購入依頼伝票の購入依頼金額が入力され、この入力がネットワーク１３を介して予算執行管理サーバ１１に入力される。
【００９６】
上記の購入依頼伝票は、起票されたばかりのものであり、まだ承認されたものではないので、予算執行管理サーバ１１では、その金額を「購入依頼伝票の未承認分」５０−２として仕訳して、外部記憶装置１７−１の伝票データのデータベース（ＤＢ）に格納する。
【００９７】
尚、これらの処理は、以下の伝票処理も同様であるが、予算執行管理サーバ１１の伝票処理プログラム１４によって、ネットワーク１３を介し、操作者端末１２−ｉに搭載されている関連プログラムと連携して処理される。
【００９８】
続いて、上記「購入依頼伝票の未承認分」５０−２のうちの全部または一部が承認されると、その承認済金額が、その購入依頼伝票を発行した部署名又はプロジェクト名とともに操作者端末１２−ｉの入力装置から入力される。そして、上記承認された購入依頼伝票の分は、購入依頼が承認されたばかりで未だ契約がなされていないのであるから、予算執行管理サーバ１１によって「購入依頼承認済伝票の未契約分」５０−３となって仕訳されて購入依頼承認済伝票の未契約分のデータベースに移動される。
【００９９】
また、予算執行管理サーバ１１では、上記「購入依頼伝票の未承認分」５０−２の金額から購入依頼承認済金額を減算する処理が行われて、購入依頼未承認残額が算出される。そして、この購入依頼が未だ承認されていない購入依頼未承認残額については、そのまま「購入依頼伝票の未承認分」５０−２の状態で購入依頼伝票の未承認分のデータベース内に残される。
【０１００】
次に、上記のように購入依頼が承認済みとなり「購入依頼承認済伝票の未契約分」５０−３となって仕訳されたものについては、順次、操作者端末１２−ｉの入力装置により契約決議伝票が起票され、ネットワーク１３を介して予算執行管理サーバ１１に入力され、外部記憶装置１７−１の伝票データのデータベースに格納される。
【０１０１】
この起票された契約決議伝票は、起票されたばかりであり未だ承認されていないのであるから、予算執行管理サーバ１１によって「契約決議伝票の未承認分」５０−４として仕訳されて契約決議伝票の未承認分のデータベースに移動される。
【０１０２】
そして、予算執行管理サーバ１１では、上記「購入依頼承認済伝票の未契約分」５０−３の金額から契約決議の金額を減算する処理が行われて、購入依頼承認済未契約分残額が算出される。そして、この購入依頼が承認済で未だ契約決議が行われていない購入依頼承認済未契約分残額については、そのまま「購入依頼承認済伝票の未契約分」５０−３の状態で購入依頼承認済伝票の未契約分のデータベース内に残される。
【０１０３】
続いて、上記起票された契約決議金額のうち契約決議が承認されたものについては、契約決議承認伝票が起票され、その承認された金額が、操作者端末１２−ｉの入力装置により、ネットワーク１３を介して予算執行管理サーバ１１に入力され、外部記憶装置１７−１の伝票データのデータベースに格納される。
【０１０４】
この起票された契約決議承認伝票は、承認済みであることが起票されたばかりであり購入先業者に通知されたばかり又はこれから通知されるものであるから購入対象の物品の納入は行われていない、つまり発注側から見れば未だ受け入れが行われていないものである。したがって、予算執行管理サーバ１１によって「契約決議承認済伝票の未受入分」５０−５として仕訳されて契約決議承認済伝票の未受入分のデータベースに移動される。
【０１０５】
そして、予算執行管理サーバ１１では、上記「契約決議伝票の未承認分」５０−４の金額から契約決議が承認済の金額を減算する処理が行われて、契約決議伝票未承認分残額が算出される。そして、この契約決議が起票されて未だ承認が行われていない契約決議伝票未承認分残額については、そのまま「契約決議伝票の未承認分」５０−４の状態で、契約決議伝票の未承認分のデータベース内に残される。
【０１０６】
次に、上記「契約決議承認済伝票の未受入分」５０−５のうち、物品が納入されて受け入れと、その検収が終了したものについては、受入検収済伝票が発行されて、その受入検収済金額が操作者端末１２−ｉの入力装置により、ネットワーク１３を介して予算執行管理サーバ１１に入力され、外部記憶装置１７−１の伝票データのデータベースに格納される。
【０１０７】
この起票された受入検収済伝票は、受け入れとその検収が済んだばかりでありまだ経理担当者からの代金支払いは行われていないものである。したがって、予算執行管理サーバ１１によって「受入検収済伝票の未払分」５０−６として仕訳されて受入検収済伝票の未払分のデータベースに移動される。
【０１０８】
そして、予算執行管理サーバ１１では、上記「契約決議承認済伝票の未受入分」５０−５の金額から受入検収済の金額を減算する処理が行われて、契約決議承認済伝票未受入分残額が算出される。そして、この契約決議が承認されて未だ受け入れが行われていない契約決議承認済伝票未受入分残額については、そのまま「契約決議承認済伝票の未受入分」５０−５の状態で、契約決議承認済伝票の未受入分のデータベース内に残される。
【０１０９】
そして、上記「受入検収済伝票の未払分」５０−６のうち、支払いが行われる又は行われたものについては、支払い伝票が発行され、その支払い金額が操作者端末１２−ｉの入力装置により、ネットワーク１３を介して予算執行管理サーバ１１に入力され、外部記憶装置１７−１の伝票データのデータベースに格納される。
【０１１０】
この場合、予算執行管理サーバ１１は、その入力された支払金額を「支払済伝票分」５０−７として仕訳して支払済伝票分のデータベースに移動するとともに、上記「受入検収済伝票の未払分」５０−６の金額から支払済の金額を減算する処理を行って、受入検収済伝票未払分残額を算出する。そして、この受入検収済であって未だ支払が行われていない受入検収済伝票未払分残額については、そのまま「受入検収済伝票の未払分」５０−６の状態で、受入検収済伝票の未払分のデータベース内に残しておく。
【０１１１】
このようにして伝票処理プログラム１４により前日までの執行額の合計値が「購入依頼伝票の未承認分」５０−２、「購入依頼承認済伝票の未契約分」５０−３、「契約決議伝票の未承認分」５０−４、「契約決議承認済伝票の未受入分」５０−５、「受入検収済伝票の未払分」５０−６、及び「支払済伝票分」５０−７について、それぞれ累算され、更に、上記「購入依頼伝票の未承認分」５０−２のジャーナルが発生するごとに「未使用分」５０−１の金額が減算されて、これらが前日までの執行額合計値として、予算執行管理サーバ１１の外部記憶装置１７−２の予算データＤＢに、図６に示す前日までの執行額の合計値５０が生成されていく。
【０１１２】
そして、更に、予算管理プログラム１５が、その前日までの執行額の合計値５０に、図６に示すように、当日のジャーナル５１を加算していく。ここでのジャーナル５１は、伝票のフェーズの進行等に合わせて，フェーズごとの執行額の差し引きを記録している。図６に示す例では、当日のジャーナル５１は４つのジャーナルデータ５１−１、５１−２、５１−３及び５１−４を有している。これら４つのジャーナルデータ５１−１、５１−２、５１−３及び５１−４が、それぞれ対応するフェーズの前日までの執行額の合計値５０に加算されて、リアルタイムな予算執行額５２として各フェースごとに算出される。
【０１１３】
このリアルタイムな予算執行額５２は、ジャーナルデータの発生ごとに更新され、当日の最終執務時間において、翌日から見た前日までの執行額の合計値５０として、データベースに保存される。
【０１１４】
また、予算執行管理サーバ１１の予算状況出力プログラム１６は、上記のリアルタイムな予算執行額５２の中のフェーズ「未使用分」５０−１に対応する金額を予算残高５３の中の購入依頼ベースの予算残額５３−１として抽出し、この抽出した金額を必要に応じて自己装置の出力装置１９に出力し、あるいは操作者端末１２−ｉの表示装置に表示出力する。
【０１１５】
また、予算執行管理サーバ１１の予算管理プログラム１５は、上記の購入依頼ベースの予算残額５３−１に、上記リアルタイムな予算執行額５２の中のフェーズ「購入依頼伝票の未承認分」５０−２、及び「購入依頼承認済伝票の未契約分」５０−３に対応する金額を合算し、予算状況出力プログラム１６は、その合算した金額を、予算残高５３の中の契約ベースの予算残額５３−２として、その金額を必要に応じて自己装置の出力装置１９に出力し、あるいは操作者端末１２−ｉの表示装置に表示出力する。
【０１１６】
更に、予算執行管理サーバ１１の予算管理プログラム１５は、上記契約ベースの予算残額５３−２に、上記リアルタイムな予算執行額５２の中のフェーズ「契約決議伝票の未承認分」５０−４、「契約決議承認済伝票の未受入分」５０−５、及び「受入検収済伝票の未払分」５０−６に対応する金額を合算し、予算状況出力プログラム１６は、その合算した金額を、予算残高５３の中の支払ベースの予算残額５３−３として、その金額を必要に応じて自己装置の出力装置１９に出力し、あるいは操作者端末１２−ｉの表示装置に表示出力する。
【０１１７】
このように、本例においては、複数オーダの合計予算残額を算出する際に、各オーダの最新の予算残額の状態を合算対象として合計予算残額を算出している。すなわち、支払済みのオーダは支払額を、契約までのオーダは契約額を、購入依頼のみのオーダは依頼額を、それぞれ合算対象として合計予算残額を算出している。これにより、より確からしい予算残額情報を算出することができる。
【０１１８】
また、このように、リアルタイムでフェーズごとに予算執行額を算出するので、複数回に分割して支払うオーダの場合，１つのオーダであっても、支払いの確定状況に応じて複数の予算残額状態を計上することができる。例えば、コピー用紙用のオーダは、月毎に使用分だけを支払うので、コピー用紙という１つのオーダの中には、過去の月の分として既に支払った金額もあれば、今月以降の分として予算状態のままの金額もある。これを支払済み額は確定金額とし，それ以外は予算金額として計上することができる。
【０１１９】
これにより、図２又は図３で説明したように、１つのオーダの中を複数の状態に分けて管理するので、既に支払った分については，余りがあれば他の予算へ転用することができる。また、上記同様により確からしい予算残額情報を算出することができる。
【０１２０】
また、購入依頼ベース、契約ベース、支払ベースのように職務上の立場や権限に応じて、表示報知して見せる予算残額を変更することができるので、つまり換言すれば、使用可能額として合算する対象を変更することができるので、本システムにより予算を執行する者の権限に応じて適切な予算残額の情報を提供することができるようになる。
【０１２１】
尚、予算執行管理サーバ１１は、ここに取り上げて示す例のように購入依頼ベース、契約ベース、支払ベースの３種類の予算残額の算出・報知だけではなく、必要に応じて各担当ベースごとの予算残額を上記フェーズの金額を適宜に合算することによって出力報知することができる。すなわち、支出業務の各フェーズを基準として、各フェーズごとに予算執行額をリアルタイムで管理し、予算残額をリアルタイムで各フェーズごとに、つまり異なる視点での残額を、示すことが可能である。
【０１２２】
そして、このようにして示される予算残額は、図６において、右にいくほど（購入依頼ベースに近づくほど）余裕が無くて厳しく、左にいくほど（支払いベースに近づくほど）余裕があって緩やかである。
【０１２３】
図７（ａ），（ｂ）  は、図１の予算管理プログラム１５によって上記のように管理される予算管理テーブルのデータ構成の例を具体的に示す図であり、図７（ａ）  は、６月における予算管理テーブルのデータ内容を示す図、同図（ｂ）  は、７月における予算管理テーブルのデータ内容を示す図である。
【０１２４】
図７（ａ），（ｂ）  に示す予算管理テーブル５４（５４−６、５４−７）のデータ構成は、左端列にオーダＡ−００１、Ａ−００２、Ａ−００３、及びＡ−００４（Ａ−００４は図７（ｂ）  のみ）が示されており、これに対応して左から右へ設けられている各例には、予算執行額の状態が、図６に示した予算執行額の状態の流れに従って、購入依頼起票未承認、購入依頼承認済未契約、契約決議起票未承認、契約決議承認済未受入、受入検収済未払、及び支払済として、その金額が示されている。尚、未使用分についてのデータは図示を省略している。
【０１２５】
図７（ａ）  において、オーダＡ−００１とＡ−００２は、一括払いのオーダを示しており、この６月の時点では、オーダＡ−００１は支払済み（￥５００）となっており、オーダＡ−００２は受入検収済みで未払い（￥２５）となっている。また、オーダＡ−００３は、合計で￥１２０の複数回払いのオーダを示しており、この６月の時点では、購入依頼承認済未契約が￥１００、受入検収済未払が￥１０、支払済が￥１０となっている。
【０１２６】
そして、図７（ｂ）  では、新たにオーダＡ−００４が発生しており、購入依頼起票未承認のフェーズとして￥１００が記録されている。先のオーダＡ−００１はそのまま支払済￥５００が確定しており、オーダＡ−００２は６月で受入検収済未払であった￥２５が、７月で支払済となっている。また、オーダＡ−００３は６月で受入検収済未払であった￥１０が、７月では支払済となって支払済金額が￥１０増加しており、更に同じく６月で購入依頼承認済未契約￥１００であったうち、７月では￥１０分が、契約決議起票未承認、契約決議承認済未受入と順に手続きを経て、受入検収済未払￥１０となって記録されている。
【０１２７】
このように、一括払いのオーダの場合も、複数回払いのオーダの場合も、支払いの度ごと、フェーズごとにデータが記録されていくので、前述したように、１つのオーダで複数回に分割して支払う場合であっても、支払いの確定状況に応じて複数の予算残額状態を計上することができる。
【０１２８】
図８（ａ）  〜（ｆ）  は、上記のような予算管理テーブルのデータに基づいて、図１の予算状況出力プログラム１６によって、予算執行管理サーバ１１自身の出力装置１９に出力され、あるいは操作者端末１２−ｉの表示装置に表示出力される表示画面の例を示す図であり、図８（ａ），（ｂ），（ｃ）  は、前月の予算管理テーブルのデータ内容に基づく表示画面の例を示す図、同図（ｄ），（ｅ），（ｆ）  は当月の予算管理テーブルのデータ内容に基づく表示画面の例を示す図である。予算状況出力プログラム１６は、出力の指示入力を行った利用者のＩＤやアクセス権等に応じて、出力内容を変化させる。図８の例では、一番権限の低い購入依頼起票担当者からの出力指示であった場合には同図（ａ），（ｄ）  の表示画面、次に権限のある契約担当者からの指示であった場合には同図（ｂ），（ｅ）  の表示画面、一番権限の高い予算管理者からの指示であった場合には同図（ｃ），（ｆ）  の表示画面というように、利用者の権限に応じて出力する情報の細かさを変化させている。
【０１２９】
図８（ａ）  に示すように、前月の購入依頼起票担当者用の表示画面は、当初予算の１０，０００，０００に対し、購入依頼中予算は６，４５０，０００であり、したがって、新規に購入依頼が可能な予算の残額は上記を差し引いた３，５５０，０００となっている。
【０１３０】
そして、図８（ｄ）  に示すように、当月の購入依頼起票担当者用の表示画面は、当初予算の１０，０００，０００に対し、購入依頼中予算は７，４５０，０００と前月よりも１，０００，０００増加しており、したがって、その分、新規に購入依頼が可能な予算の残額は上記を差し引いた２，５５０，０００となって、前月よりも１，０００，０００減少している。
【０１３１】
これに対して、図８（ｂ）  及び図８（ｅ）  に示す契約担当者用の表示画面では、当初予算、購入依頼中予算、及び残額は、購入依頼起票担当者用の表示画面の場合と変わらないが、これら契約担当者用の表示画面では上記のほかに契約中予算及びその残額が表示されるようになっている。すなわち、前月の契約中予算及びその残額はそれぞれ５，４５０，０００及び４，５５０，０００であり、当月の契約中予算は５，５５０，０００で前月より１００，０００増加し、残額は４，４５０，０００であって、前月より１００，０００減少している。
【０１３２】
このように契約担当者用の表示画面で契約担当者用が見ることが出来る予算残額の範囲は、購入依頼起票担当者が見ることが出来る予算残額のほかに自己の職務に関わる契約分（購入依頼の承認を受けて契約が可能となった分）も含めた予算残額４，５５０，０００（前月）又は４，４５０，０００（当月）として見ることができ、権限に応じて扱える予算フェーズの額、すなわち、契約担当者であれば図６で示す契約ベースの予算額５３−２の範囲を把握することができるので、購入依頼起票担当者の場合よりも裁量の範囲が広くなっている。担当者は、この残額などを参照して、オーダ間の予算割り振りを調整したりすることができる。
【０１３３】
また、これに対して更に図８（ｃ）  及び図８（ｆ）  に示す予算管理者用の表示画面では、当初予算、購入依頼中予算、その残額、契約中予算、及びその残額は、契約担当者用の表示画面の場合と変わらないが、これら予算管理者用の表示画面では上記のほかに支払済み予算及びその残額が表示されるようになっている。すなわち、前月の支払済み予算及びその残額はそれぞれ５，１００，０００及び４，９００，０００であり、当月の支払済予算は５，４５０，０００で前月より３５０，０００増加し、残額は４，５５０，０００であって、前月より３５０，０００減少している。
【０１３４】
このように予算管理者用の表示画面で予算管理者が見ることが出来る予算残額の範囲は、契約担当者が見ることが出来る予算残額よりも更に範囲が広く、自己の職務に関わる支払済みであるか否かの予算全体の状態を見ることができ、契約担当者の場合よりも更に裁量の範囲が広くなっている。
【０１３５】
このように、本例のごとく予算執行状況をフェーズごとに詳細に情報化された表示画面として仔細に見ると、予算管理者の対場から見た場合には、予算の有効再配分を効率よく行うことができるようになり、無駄なく予算を利用して予算執行の効率を向上させることができる。
【０１３６】
以上を総合して、本発明の予算執行管理方法及び予算執行管理プログラムによれば、▲１▼予算残額をリアルタイム且つ多視点で管理して各担当者に正確な予算残額の把握を実現させるので、これにより各担当者は各フェーズにおける予算執行の状態を正確に把握することで無駄なく予算を利用することが可能になる。特に予算残額が減少してくる期末には、最も厳しい基準である購入依頼ベースで残額を把握できる上、各フェーズで金額の確定が起きるごとにリアルタイムな残額を把握することができるため予算の利用効果がより高くなる。
【０１３７】
また、▲２▼多様な集計単位での予算利用状況の把握が可能となり、予算転用の際には高い利便性を発揮することができる。更には、各プロジェクトについている全予算の合計予算残高や、ある予算科目の合計予算残高など、多様な集計単位で予算残額を把握することができるため、予算管理者にとって予算転用の際に高い利便性が得られて予算の利用効果がより高くなる、ということができる。
【０１３８】
このように本発明の予算執行管理方法又は予算執行管理プログラムによれば、予算残額をリアルタイムで且つ立場ごとに異なる多視点からの多様な集計単位で予算利用状況や正確な予算残額を把握して管理できるようになり、予算執行の効率が向上する。
【０１３９】
また、リアルタイムで正確な予算残額を把握できるので、余剰予算の転用の際に高い利便性を発揮することができ、この点からも予算執行の効率が向上する。
【０１４０】
（付記１）複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出することを特徴とする予算執行管理方法。
【０１４１】
（付記２）算出される前記合計予算残額は、支払済みの購入計画には支払額、契約までの購入計画には契約額、購入依頼のみの購入計画には依頼額を合算対象として、それぞれについて合計予算残額を算出されることを特徴とする付記１記載の予算執行管理方法。
【０１４２】
（付記３）起票された購入依頼金額を入力する購入依頼金額入力工程と、
該購入依頼金額入力工程により入力された前記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力工程と、
該購入依頼承認済金額入力工程により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力工程と、
該契約決議金額入力工程により入力された前記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力工程と、
該契約決議承認済金額入力工程により入力された前記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力工程と、
該受入検収済金額入力工程により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力工程と、
を含む予算執行管理方法であって、
更に、
前記購入依頼金額入力工程により入力された前記購入依頼金額から前記購入依頼承認済金額入力工程により入力された前記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出工程と、
前記購入依頼承認済金額入力工程により入力された前記承認済金額から前記契約決議金額入力工程により入力された前記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出工程と、
前記契約決議金額入力工程により入力された前記契約決議金額から前記契約決議承認済金額入力工程により入力された前記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出工程と、
前記契約決議承認済金額入力工程により入力された契約決議承認済金額から前記受入検収済金額入力工程により入力された前記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出工程と、
前記受入検収済金額入力工程により入力された前記受入検収済金額から前記支払済金額入力工程により入力された前記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出工程と、
を含み、
更に、
予算額から前記購入依頼起票未承認金額、前記購入依頼承認済未契約金額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、前記受入検収済未払金額、及び前記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出工程と、
前記購入依頼ベースの予算残額、前記前記購入依頼起票未承認金額、及び前記購入依頼承認済未契約金額の合算して契約ベースの予算残額を算出する契約ベース予算残額算出工程と、
前記契約ベース予算残額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、及び前記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出工程と、
前記購入依頼ベース予算残額、前記契約ベース予算残額、又は前記支払ベース予算残額を出力する予算残額出力工程と、
を含むことを特徴とする予算執行管理方法。
【０１４３】
（付記４）複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出する処理をコンピュータに実行させることを特徴とする予算執行管理プログラム。
【０１４４】
（付記５）算出される前記合計予算残額は、支払済みの購入計画には支払額、契約までの購入計画には契約額、購入依頼のみの購入計画には依頼額を合算対象として、それぞれについて合計予算残額を算出されることを特徴とする付記４記載の予算執行管理プログラム。
【０１４５】
（付記６）起票された購入依頼金額を入力する購入依頼金額入力処理と、
該購入依頼金額入力処理により入力された前記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力処理と、
該購入依頼承認済金額入力処理により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力処理と、
該契約決議金額入力処理により入力された前記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力処理と、
該契約決議承認済金額入力処理により入力された前記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力処理と、
該受入検収済金額入力処理により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力処理と、
をコンピュータに実行させる予算執行管理プログラムであって、
更に、
前記購入依頼金額入力処理により入力された前記購入依頼金額から前記購入依頼承認済金額入力処理により入力された前記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出処理と、
前記購入依頼承認済金額入力処理により入力された前記承認済金額から前記契約決議金額入力処理により入力された前記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出処理と、
前記契約決議金額入力処理により入力された前記契約決議金額から前記契約決議承認済金額入力処理により入力された前記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出処理と、
前記契約決議承認済金額入力処理により入力された契約決議承認済金額から前記受入検収済金額入力処理により入力された前記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出処理と、
前記受入検収済金額入力処理により入力された前記受入検収済金額から前記支払済金額入力処理により入力された前記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出処理と、
を前記コンピュータに実行させ、
更に、
予算額から前記購入依頼起票未承認金額、前記購入依頼承認済未契約金額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、前記受入検収済未払金額、及び前記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出処理と、
前記購入依頼ベースの予算残額、前記前記購入依頼起票未承認金額、及び前記購入依頼承認済未契約金額の合算して契約ベースの予算残額を算出する契約ベース予算残額算出処理と、
前記契約ベース予算残額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、及び前記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出処理と、
前記購入依頼ベース予算残額、前記契約ベース予算残額、又は前記支払ベース予算残額を出力する予算残額出力処理と、
を前記コンピュータに実行させることを特徴とする予算執行管理プログラム。
【０１４６】
（付記７）複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出する手段を有することを特徴とする予算執行管理装置。
【０１４７】
（付記８）起票された購入依頼金額を入力する購入依頼金額入力手段と、
該購入依頼金額入力手段により入力された前記購入依頼金額のうち承認済金額を入力する購入依頼承認済金額入力手段と、
該購入依頼承認済金額入力手段により入力された承認済金額に対応して起票された契約決議金額を入力する契約決議金額入力手段と、
該契約決議金額入力手段により入力された前記契約決議金額のうち契約決議が承認された金額を入力する契約決議承認済金額入力手段と、
該契約決議承認済金額入力手段により入力された前記契約決議承認済金額のうち受入検収済金額を入力する受入検収済金額入力手段と、
該受入検収済金額入力手段により入力された受入検収済金額のうち支払済金額を入力する支払済金額を入力手段と、
を備えた予算執行管理装置であって、
更に、
前記購入依頼金額入力手段により入力された前記購入依頼金額から前記購入依頼承認済金額入力手段により入力された前記承認済金額を減算して購入依頼起票未承認金額を算出する購入依頼起票未承認金額算出手段と、
前記購入依頼承認済金額入力手段により入力された前記承認済金額から前記契約決議金額入力手段により入力された前記契約決議金額を減算して購入依頼承認済未契約金額を算出する購入依頼承認済未契約金額算出手段と、
前記契約決議金額入力手段により入力された前記契約決議金額から前記契約決議承認済金額入力手段により入力された前記契約決議承認済金額を減算して契約決議起票未承認金額を算出する契約決議起票未承認金額算出手段と、
前記契約決議承認済金額入力手段により入力された契約決議承認済金額から前記受入検収済金額入力手段により入力された前記受入検収済金額を減算して契約決議承認済未受入金額を算出する契約決議承認済未受入金額算出手段と、
前記受入検収済金額入力手段により入力された前記受入検収済金額から前記支払済金額入力手段により入力された前記支払済金額を減算して受入検収済未払金額を算出する受入検収済未払金額算出手段と、
を備え、
更に、
予算額から前記購入依頼起票未承認金額、前記購入依頼承認済未契約金額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、前記受入検収済未払金額、及び前記支払済金額を減算して購入依頼ベースの予算残額を算出する購入依頼ベース予算残額算出手段と、
前記購入依頼ベースの予算残額、前記前記購入依頼起票未承認金額、及び前記購入依頼承認済未契約金額の合算して契約ベースの予算残額を算出する契約ベース予算残額算出手段と、
前記契約ベース予算残額、前記契約決議起票未承認金額、前記契約決議承認済未受入金額、及び前記受入検収済未払金額を合算して支払ベースの予算残額を算出する支払ベース予算残額算出手段と、
前記購入依頼ベース予算残額、前記契約ベース予算残額、又は前記支払ベース予算残額を出力する予算残額出力手段と、
を備えたことを特徴とする予算執行管理装置。
【０１４８】
（付記９）複数の購入計画に対応する合計予算残額を算出するに際し各購入計画の執行段階ごとに起票される伝票の種類ごとに対応する最新の予算残額の状態を合算対象として合計予算残額を算出する処理をコンピュータに実行させる予算執行管理プログラムをコンピュータが読み取り可能に記録されたプログラム記録媒体。
【０１４９】
【発明の効果】以上説明したように、本発明の予算執行管理方法又は予算執行管理プログラムによれば、予算の執行状況をリアルタイムあるいは短期間の執行期間内で各職責上の立場ごとに最適な状態で集計して報知できるようにする、つまり、支払済みのオーダは支払額を、契約済みのオーダは契約額を、購入依頼済みのオーダは依頼額を、それぞれ合算対象として予算の残高を計算して報知できるようにするので、立場ごとに自己にとってより確かで必要な予算残額を知ることが出き、リアルタイムで正確な予算残額を把握して予算残額を管理できるので、これにより、予算執行の効率が向上する。
【０１５０】
また、同様に予算残額をリアルタイムで且つ立場ごとに異なる多視点からの多様な集計単位で予算利用状況や正確な予算残額を把握できるので、余剰予算の転用の際には高い利便性を発揮することができ、この点からも予算執行の効率が向上する。
【図面の簡単な説明】
【図１】一実施の形態における予算執行管理を行う予算執行管理サーバを中心とする予算執行管理システムの構成を示すブロック図である。
【図２】（ａ）  は予算執行管理システムにおける支払確定額が概算金額よりも少ない場合の予算枠計算方法を説明する図表、（ｂ）  は比較説明のために図１０（ａ）  を再掲した図、（ｃ）  は本例の予算執行管理システムの機能を説明する図である。
【図３】（ａ）  は予算執行管理システムにおける支払確定額が概算金額よりも多い場合の予算枠計算方法を説明する図表、（ｂ）  は比較説明のために図１０（ｂ）  を再掲した図、（ｃ）  は本例の予算執行管理システムの機能を説明する図である。
【図４】概算予算金額と支払確定金額との関係の流れを１回払いの購入依頼の場合を例にとって説明する図である。
【図５】概算予算金額と支払確定金額との関係の流れを複数回払いの購入依頼の場合を例にとって説明する図である。
【図６】本発明の予算執行管理方法及び予算執行管理プログラムの動作を説明する図である。
【図７】（ａ），（ｂ）  は予算管理プログラムによって管理される予算管理テーブルの例を示す図である。
【図８】（ａ）  〜（ｆ）  は予算管理テーブルのデータに基づいて予算状況出力プログラムによって出力される表示画面の例を示す図である。
【図９】従来の予算執行額の状態を示す図である。
【図１０】（ａ），（ｂ），（ｃ）  は申告した予算概算金額が支払確定金額より多い時や少ない時の従来の会計処理方法を説明する図である。
【符号の説明】
１０  予算執行管理システム
１１  予算執行管理サーバ（装置）
１２−ｉ（ｉ＝１，２，・・・、ｎ）  操作者端末（利用者、管理者コンピュータ）
１３  ネットワーク
１４  伝票処理プログラム
１５  予算管理プログラム
１６  予算状況出力プログラム
１７（１７−１、１７−２）  外部記憶装置
１８    入力装置
１９  出力装置
【図１】
2004220122.tif 000003
【図２】
2004220122.tif 000004
【図３】
2004220122.tif 000005
【図４】
2004220122.tif 000006
【図５】
2004220122.tif 000007
【図６】
2004220122.tif 000008
【図７】
2004220122.tif 000009
【図８】
2004220122.tif 000010
【図９】
2004220122.tif 000011
【図１０】
2004220122.tif 000012