JP5782600B1 - 情報処理装置、プログラム、情報処理システム - Google Patents

Abstract

【課題】事業計画を立てるユーザの負担を低減するための情報をユーザに提供する情報処理装置、プログラム、情報処理システムを提供する。【解決手段】ユーザの指示に応じて、口座への入金または口座からの出金のいずれかである取引に関する取引情報であって、かつ、取引日付と、取引金額と、取引の摘要と、を含む取引情報を取得する取得ステップＳ１００と、取得手段によって取得された取引情報を記憶装置に格納する格納ステップＳ１１２と、ユーザの指示に応じて、記憶装置に格納された取引情報のうち、ユーザによって指定された将来の期間に含まれる取引日付を含む取引情報を参照して、当該将来の期間に行われる予定取引毎に、取引日付と、入金額または出金額と、取引の摘要と、取引が終了した後の口座の残高と、を含む資金試算情報を出力するステップとを備える。【選択図】図１３

Description

本発明は、将来必要になる資金に関する情報を出力する情報処理技術に関する。

一般に、企業経営者は、将来の任意の日（以下「注目日」という）の残高を考慮して、
事業計画を立てる。このとき、注目日の残高だけでなく、注目日より過去に行われた取引
の経緯（つまり、注目日の残高の要因）を考慮することが重要である。

一例として、商品を仕入れる取引（（以下「仕入れ取引」という）が９月９日に行われ
、かつ、借入金を返済する取引（以下「返済取引」という）が９月１０日に行われる例に
ついて説明する。ここで、仕入れ取引後の残高は、返済取引の出金額（つまり、返済額）
より少ない（つまり、仕入れ取引を行った場合、返済取引を行うことができなくなる）も
のとする。
一般に、返済取引は、仕入れ取引よりも重要である。したがって、企業経営者は、返済
取引を行う時点での残高が返済額より少ない場合、当該残高（つまり、注目日である９月
１０日の繰越残高）を増やすような事業計画（例えば、仕入れ取引を中止、または、延期
する計画）を立てる必要がある。そのためには、仕入れ取引および返済取引のそれぞれに
ついて、取引の内容や取引後残高を考慮する必要がある。

従来、会計処理を実行するソフトウェアの中には、ユーザが入力した取引に関する情報
（以下「取引情報」という）を参照して、残高試算表を作成するものがあった（例えば、
特許文献１）。企業経営者は、このようなソフトウェアが作成した残高試算表を用いて、
事業計画を立案していた。

特開２００３−１６７９８５号公報

しかし、特許文献１では、日付毎の残高は示されるが、当該残高の要因は示されない。
したがって、企業経営者は、注目日の残高が少ないことを把握したとしても、当該を増
やすために、注目日以前のどの取引を見直すべきか（つまり、当該残高の要因）を把握す
ることはできない。
そのため、当該要因を把握するために新たな作業が発生する。この作業には、多くの時
間と労力を要する（つまり、企業経営者の負担が大きくなる）。

本発明の目的は、事業計画を立てるユーザの負担を低減するための情報をユーザに提供
するようにした、情報処理装置、プログラム、および、情報処理システムを提供すること
である。

記憶装置にアクセス可能な情報処理装置であって、
ユーザの指示に応じて、口座への入金または口座からの出金のいずれかである取引に関する取引情報であって、かつ、取引日付と、取引金額と、取引の摘要と、を含む取引情報を複数取得する取得手段と、
ユーザの指示に応じて、前記取得手段によって取得された複数の取引情報のうち、ユーザによって指定された複数の指定取引の取引情報に含まれる取引金額の平均値を、各指定取引の取引情報に含まれる取引日付より後であって、かつ、ユーザによって指定された将来の日付に行われる予定取引の取引金額として推定する推定手段と、
前記取得手段によって取得された取引情報と、前記推定手段によって推定された取引金額を含む予定取引の取引情報と、を前記記憶装置に格納する格納手段と、
ユーザの指示に応じて、前記記憶装置に格納された複数の取引情報のうち、ユーザによって指定された将来の期間に含まれる取引日付を含む取引情報を参照して、当該将来の期間に行われる予定取引毎に、取引日付と、入金額または出金額と、取引の摘要と、取引が終了した後の口座の残高と、を含む資金試算情報を出力する第１出力手段と、
を備えた情報処理装置である。

第１の実施形態の情報処理システム１の構成の一例を示す図。 第１の実施形態のクライアント端末１０の構成の一例を示す図。 第１の実施形態のサーバ３０の構成の一例を示す図。 第１の実施形態のユーザデータテーブルのデータ構造の一例を示す図。 第１の実施形態の口座データテーブルのデータ構造の一例を示す図。 第１の実施形態の部門データテーブルのデータ構造の一例を示す図。 第１の実施形態の勘定科目データテーブルのデータ構造の一例を示す図。 第１の実施形態の取引データテーブルのデータ構造の一例を示す図。 第１の実施形態のメインメニュー画面の一例を示す図。 第１の実施形態の口座設定画面の一例を示す図。 第１の実施形態の取引管理画面の一例を示す図。 第１の実施形態の会計伝票画面の一例を示す図。 第１の実施形態の取引情報の登録の処理のフローチャート。 第１の実施形態の資金試算の処理のフローチャート。 第１の実施形態の会計処理のフローチャート。 第２の実施形態の取引管理画面の一例を示す図。 第２の実施形態の取引情報の登録の処理のフローチャート。 第３の実施形態の取引情報の変更の処理のフローチャート。

（１）第１の実施形態
（１−１）情報処理システムの構成（図１）
本実施形態の情報処理システムの構成について説明する。図１は、第１の実施形態の情
報処理システム１の構成の一例を示す図である。

図１に示すように、情報処理システム１は、クライアント端末１０−１〜１０−ｎ（以
下、各クライアント端末１０−１〜１０−ｎに共通して言及するときには、「クライアン
ト端末１０」という）と、サーバ３０とを備える。
クライアント端末１０と、サーバ３０とは、通信網ＮＷ（例えば、インターネット）を
介して、相互に通信可能である。

クライアント端末１０は、ユーザが使用する情報処理装置の一例である。クライアント
端末１０は、例えば、スマートフォン、タブレット端末、パーソナルコンピュータ等であ
る。
サーバ３０は、クライアント端末１０から送信された要求に基づいて、所定の処理を実
行する情報処理装置の一例である。サーバ３０は、例えば、ウェブサーバである。

（１−２）クライアント端末の構成（図２）
クライアント端末１０の構成について説明する。図２は、第１の実施形態のクライアン
ト端末１０の構成の一例を示す図である。

図２に示すように、クライアント端末１０は、ＣＰＵ（Central Processing Unit）１
１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、ス
トレージ１４と、操作入力部１５と、表示部１６と、通信インタフェース１７と、各デバ
イス間で信号を伝送するバス１８とを備える。

ＲＯＭ１２は、情報処理に必要なプログラムおよびデータを記憶する記憶装置である。
ＲＡＭ１３は、情報処理に必要なデータを一時的に記憶する記憶装置である。
ストレージ１４は、ＯＳ（Operating System）のプログラムと、情報処理を実行するア
プリケーション（例えば、ウェブブラウザ）のプログラムと、情報処理を実行することに
よって得られるデータ（つまり、情報処理の実行結果）と、を記憶する記憶装置である。
例えば、ストレージ１４は、フラッシュメモリまたはハードディスクである。

ＣＰＵ１１は、ストレージ１４に記憶されたプログラムを起動することによって、アプ
リケーションの機能を実現するデバイスである。アプリケーションは、情報処理に必要な
データをＲＡＭ１３に格納し、かつ、格納されたデータを参照して情報処理を実行する。
例えば、ストレージ１４に記憶されたデータを参照する場合、アプリケーションは、スト
レージ１４から当該データを取り出し、かつ、取り出されたデータをＲＡＭ１３に格納す
る。

操作入力部１５は、ユーザの指示を受け付けるデバイスである。アプリケーションは、
操作入力部１５が受け付けたユーザの指示に応じて情報処理を実行する。

表示部１６は、ユーザに情報を提示するデバイスである。アプリケーションは、情報処
理の実行結果を示す画面を表示部１６に表示させる。

通信インタフェース１７は、クライアント端末１０と通信網ＮＷとの間の通信を制御す
るデバイスである。アプリケーションは、通信インタフェース１７を介して、情報処理に
必要なプログラムおよびデータを、他のクライアント端末１０およびサーバ３０との間で
送受信する。

（１−３）サーバの構成（図３）
本実施形態のサーバの構成について説明する。図３は、第１の実施形態のサーバ３０の
構成の一例を示す図である。

図３に示すように、サーバ３０は、ＣＰＵ３１と、ＲＯＭ３２と、ＲＡＭ３３と、スト
レージ３４と、通信インタフェース３５と、各部間で信号を伝送するバス３６とを備える
。

ＲＯＭ３２は、情報処理に必要なプログラムやデータを記憶する記憶装置である。
ＲＡＭ３３は、情報処理に必要なデータを一時的に記憶する記憶装置である。
ストレージ３４は、ＯＳのプログラム、および、情報処理を実行するアプリケーション
のプログラムと、情報処理に必要なデータ（データテーブル）と、を記憶する記憶装置で
ある。例えば、ストレージ３４は、フラッシュメモリまたはハードディスクである。

ＣＰＵ３１は、ストレージ３４に記憶されたプログラムを起動することによって、アプ
リケーションの機能を実現するデバイスである。アプリケーションは、情報処理に必要な
データをＲＡＭ３３に格納し、かつ、格納されたデータを参照して、情報処理を実行する
。例えば、ストレージ３４に記憶されたデータを参照する場合、アプリケーションは、ス
トレージ３４から当該データを取り出し、かつ、取り出されたデータをＲＡＭ３３に格納
する。

通信インタフェース３５は、サーバ３０と通信網ＮＷとの間の通信を制御する。アプリ
ケーションは、通信インタフェース３５を介して、情報処理に必要なプログラムおよびデ
ータを、クライアント端末１０との間で送受信する。

（１−４）データテーブル（図４〜図８）
本実施形態のデータテーブルのデータ構造について説明する。

（１−４−１）ユーザデータテーブル（図４）
本実施形態のユーザデータテーブルのデータ構造について説明する。図４は、第１の実
施形態のユーザデータテーブルのデータ構造の一例を示す図である。
ユーザデータテーブルの各レコード（以下「ユーザデータレコード」という）には、ユ
ーザに関する情報が格納される。

図４に示すように、ユーザデータテーブルは、「ユーザＩＤ」フィールドと、「メール
アドレス」フィールドと、「パスワード」フィールドと、「ユーザ名」フィールドと、を
含む。
「ユーザＩＤ」フィールドには、ユーザ毎に固有のユーザＩＤが格納される。ユーザＩ
Ｄは、ユーザを特定する情報である。ユーザＩＤは、ユーザデータレコードを特定する主
キーとして参照される。
「メールアドレス」フィールドおよび「パスワード」フィールドには、それぞれ、ユー
ザが登録したメールアドレスおよびパスワードを示す文字列が格納される。メールアドレ
スおよびパスワードは、ユーザ認証において参照される情報である。
「ユーザ名」フィールドには、ユーザが登録したユーザ名を示す文字列が格納される。

（１−４−２）口座データテーブル（図５）
本実施形態の口座データテーブルのデータ構造について説明する。図５は、第１の実施
形態の口座データテーブルのデータ構造の一例を示す図である。
口座データテーブルの各レコード（以下「口座データレコード」という）には、ユーザ
が登録した口座（以下「登録口座」という）に関する情報が格納される。口座データテー
ブルは、ユーザＩＤに対応付けられている（つまり、口座データテーブルは、ユーザ毎に
設けられる）。

図５に示すように、口座データレコードは、「口座ＩＤ」フィールドと、「金融機関コ
ード」フィールドと、「支店コード」フィールドと、「口座番号フィールド」と、「口座
名」フィールドと、「残高」フィールドと、を含む。
「口座ＩＤ」フィールドには、登録口座毎に固有の口座ＩＤが格納される。口座ＩＤは
、登録口座を特定する情報である。口座ＩＤは、口座データレコードを特定する主キーと
して参照される。
「金融機関コード」フィールド、「支店コード」フィールド、および、「口座番号」フ
ィールドには、それぞれ、登録口座の金融機関、支店、および、口座番号を示す値が格納
される。
「口座名」フィールドには、登録口座の口座名を示す文字列が格納される。
「残高」フィールドには、登録口座の残高を示す値が格納される。

（１−４−３）部門データテーブル（図６）
本実施形態の部門データテーブルのデータ構造について説明する。図６は、第１の実施
形態の部門データテーブルのデータ構造の一例を示す図である。
部門データテーブルの各レコード（以下「部門データレコード」という）には、ユーザ
が登録した部門に関する情報が格納される。部門データテーブルは、ユーザＩＤに対応付
けられている（つまり、部門データテーブルは、ユーザ毎に設けられる）。

図６に示すように、部門データレコードは、「部門コード」フィールドと、「部門名」
フィールドと、を含む。
「部門コード」フィールドには、部門毎に固有の部門コードが格納される。部門コード
は、ユーザが登録した部門を特定する情報である。部門コードは、部門データレコードを
特定する主キーとして参照される。
「部門名」フィールドには、ユーザが登録した部門名を示す文字列が格納される。

（１−４−４）勘定科目データテーブル（図７）
本実施形態の勘定科目データテーブルのデータ構造について説明する。図７は、第１の
実施形態の勘定科目データテーブルのデータ構造の一例を示す図である。
勘定科目データテーブルの各レコード（以下「勘定科目データレコード」という）には
、ユーザが登録した勘定科目に関する情報が格納される。勘定科目データテーブルは、ユ
ーザＩＤに対応付けられている（つまり、取引データテーブルは、ユーザ毎に設けられる
）。

図７に示すように、勘定科目データレコードは、「勘定科目ＩＤ」フィールドと、「勘
定科目」フィールドと、を含む。
「勘定科目ＩＤ」フィールドには、勘定科目毎に固有の勘定科目ＩＤが格納される。勘
定科目ＩＤは、ユーザが登録した勘定科目を特定する情報である。勘定科目ＩＤは、勘定
科目データレコードを特定する主キーとして参照される。
「勘定科目」フィールドには、ユーザが登録した勘定科目を示す文字列が格納される。

（１−４−５）取引データテーブル（図８）
本実施形態の取引データテーブルのデータ構造について説明する。図８は、第１の実施
形態の取引データテーブルのデータ構造の一例を示す図である。
取引データテーブルの各レコード（以下「取引データレコード」という）には、ユーザ
が登録した取引（過去に行われた取引（以下「終了取引」という）、または、予定取引）
に関する情報（以下「取引情報」という）が格納される。取引データテーブルは、ユーザ
ＩＤに対応付けられている（つまり、取引データテーブルは、ユーザ毎に設けられる）。

図８に示すように、取引データレコードは、「取引ＩＤ」フィールドと、「口座ＩＤ」
フィールドと、「取引種別」フィールドと、「取引日付」フィールドと、「取引金額」フ
ィールドと、「摘要」フィールドと、「部門コード」フィールドと、「勘定科目」フィー
ルドと、「ステータス」フィールドと、「伝票番号」フィールドと、を含む。
「取引ＩＤ」フィールドには、取引毎に固有の取引ＩＤが格納される。取引ＩＤは、ユ
ーザが登録した取引を特定する情報である。取引ＩＤは、取引データレコードを特定する
主キーとして参照される。
「口座ＩＤ」フィールドには、取引に用いられる口座の口座ＩＤ（口座データテーブル
の「口座ＩＤ」フィールドに格納された口座ＩＤのいずれか）が格納される。
「取引種別」フィールドには、取引の種別（入金取引、出金取引、および、振替取引の
いずれか）を示す値が格納される。例えば、「０」は入金取引を示し、「１」は出金取引
を示し、「２」は振替取引を示す。
「取引日付」フィールドには、取引が行われる日付が格納される。
「取引金額」フィールドには、取引金額（口座に入金される金額、または、口座から出
金される金額）が格納される。
「摘要」フィールドには、取引の内容を示す文字列が格納される。
「部門コード」フィールドには、取引に関与する部門の部門コード（部門データテーブ
ルの「部門コード」フィールドに格納された部門コードのいずれか）が格納される。
「ステータス」フィールドには、取引の状況を示す値が格納される。例えば、「０」は
取引が終了しているが、会計伝票の作成が終了していないことを示し、「１」は取引が終
了しており、かつ、会計伝票の作成も終了していることを示し、「２」は取引が終了して
いないことを示している。
「伝票番号」フィールドには、作成された会計伝票の伝票番号を示す値が格納される。
「ステータス」フィールドに「０」または「２」が格納された取引データレコードの「伝
票番号」フィールドには、伝票番号が存在しないことを示す値「Ｎ／Ａ」が格納される。

（１−５）情報処理において表示される画面（図９〜図１２）
本実施形態の情報処理において表示部１６に表示される画面について説明する。

（１−５−１）メインメニュー画面（図９）
本実施形態のメインメニュー画面について説明する。図９は、第１の実施形態のメイン
メニュー画面の一例を示す図である。

メインメニュー画面Ｐ１００は、ログイン認証に成功したときに表示される画面である
。

図９に示すように、メインメニュー画面Ｐ１００は、「口座設定」ボタンＢ１００と、
「取引管理」ボタンＢ１０２と、を含む。
「口座設定」ボタンＢ１００は、ユーザが、口座設定画面Ｐ１１０（図１０）を表示さ
せるときに指定するオブジェクトである。
「取引管理」ボタンＢ１０２は、ユーザが、取引管理画面Ｐ１２０（図１１）を表示さ
せるときに指定するオブジェクトである。

（１−５−２）口座設定画面（図１０）
本実施形態の口座設定画面について説明する。図１０は、第１の実施形態の口座設定画
面の一例を示す図である。

口座設定画面Ｐ１１０は、ユーザが、図９の「口座設定」ボタンＢ１００を指定したと
きに表示される画面である。

図１０に示すように、口座設定画面Ｐ１１０は、「金融機関コード」フォームＦ１１０
と、「支店コード」フォームＦ１１２と、「口座番号」フォーム１２４と、「口座名」フ
ォーム１２６と、「完了」ボタンＢ１１０と、を含む。
ユーザが、「金融機関コード」フォームＦ１１０、「支店コード」フォームＦ１１２、
「口座番号」フォーム１２４、および、「口座名」フォーム１２６に、それぞれ、金融機
関コード、支店コード、口座番号、および、口座名を入力し、次いで、「完了」ボタンＢ
１１０を指定すると、「金融機関コード」フォームＦ１１０、「支店コード」フォームＦ
１１２、「口座番号」フォーム１２４、および、「口座名」フォーム１２６に入力された
情報と、固有の口座ＩＤと、を格納した口座データレコードが口座データテーブルに追加
される。

（１−５−３）取引管理画面Ｐ１２０（図１１）
本実施形態の取引管理画面について説明する。図１１は、第１の実施形態の取引管理画
面の一例を示す図である。

取引管理画面Ｐ１２０は、ユーザが、図９の「取引管理」ボタンＢ１０２を指定したと
きに表示される画面である。

図１１に示すように、取引管理画面Ｐ１２０は、「追加」ボタンＢ１２０と、「期間」
フォームＦ１２０と、「口座」フォームＦ１２２と、領域Ｑ１２０およびＱ１２２と、を
含む。
「追加」ボタンＢ１２０は、ユーザが、新しい取引情報を登録するときに指定するオブ
ジェクトである。
「期間」フォームＦ１２０は、ユーザが、表示させる取引情報に関連する期間を指定す
るためのオブジェクトである。ユーザが「期間」フォームＦ１２０に任意の期間を入力す
ると、取引データレコードのうち、入力された期間内の取引日付を示す値が格納された「
取引日付」フィールドを含む取引データレコードに基づく取引情報（つまり、入力された
期間に行われた取引の取引情報）が領域Ｑ１２２に表示される。
「口座」フォームＦ１２２は、ユーザが、表示させる取引情報に関連する口座を指定す
るためのオブジェクトである。ユーザが「口座」フォームＦ１２２を指定すると、「１．
一括」と、登録口座の口座名「２．経理用」、「３．開発用」…（口座データテーブル（
図５）の「口座名」フィールドに格納された文字列）と、を含むリストが表示される。ユ
ーザが、当該リストの中から「１．一括」を指定すると、取引データレコードのうち、「
取引日付」フィールドに格納された値が「期間」フォームＦ１２０に入力された期間に含
まれる取引データレコードに基づく取引情報（つまり、全ての登録口座に関する取引情報
）が領域Ｑ１２２に表示される。一方、ユーザが、当該リストの中から「１．一括」以外
の文字列（例えば、「２．経理用」）を指定すると、取引データレコードのうち、「取引
日付」フィールドに格納された値が「期間」フォームＦ１２０に入力された期間に含まれ
、かつ、ユーザが指定した文字列に対応する口座ＩＤ（例えば、「A01」）が格納された
「口座ＩＤ」フィールドを含む取引データレコードに基づく取引情報（つまり、ユーザが
指定した口座を用いた取引の取引情報）が領域Ｑ１２２に表示される。

領域Ｑ１２０には、取引管理画面Ｐ１２０を表示している日（つまり、現在）の日付が
表示される。

領域Ｑ１２２には、「口座名」フォームＦ１２２に入力された口座名が示す口座（つま
り、ユーザが指定した口座）を用いた取引であって、かつ、「期間」フォームＦ１２０に
入力された期間に行われた取引の取引情報が表示される。領域Ｑ１２２は、「行番号」欄
と、「取引日付」欄と、「状況」欄と、「摘要」欄と、「入金額」欄と、「出金額」欄と
、「残高」欄と、「勘定科目」欄と、「部門名」欄と、を含む。なお、「勘定科目」欄と
、「部門名」欄とは、省略可能である（つまり、ユーザが取引情報を登録するときに勘定
科目を示す文字列と部門名を示す文字列とを入力しなくても、取引管理画面は表示可能で
ある。
「行番号」欄には、表示される取引情報毎に固有の番号が表示される。ユーザが「行番
号」欄に表示された番号を指定すると、当該行に表示された取引情報に関連する取引が指
定された状態になる。
「取引日付」欄には、取引データテーブルの「取引日付」フィールドに格納された値が
示す取引日付が表示される。
「状況」欄には、取引データテーブルの「ステータス」フィールドに格納された値が示
す取引の状況が表示される。
「摘要」欄には、取引データテーブルの「摘要」フィールドに格納された文字列（つま
り、取引の摘要）が表示される。
「入金額」欄には、「０」が格納された「取引種別」フィールドを含む取引データレコ
ードの「取引金額」フィールドに格納された値（つまり、入金取引の取引金額）が表示さ
れる。
「出金額」欄には、「１」または「２」が格納された「取引種別」フィールドを含む取
引データレコードの「取引金額」フィールドに格納された値（つまり、出金取引または振
替取引の取引金額）が表示される。
「残高」欄には、取引が行われる前の残高（以下「取引前残高」という）と「入金額」
欄に表示された金額との和、または、取引前残高と「出金額」欄に表示された金額との差
（つまり、取引が終了した後の残高（以下「取引後残高」という））が表示される。
「勘定科目」欄には、取引データテーブルの「勘定科目」フィールドに格納された文字
列（つまり、勘定科目）が表示される。
「部門名」欄には、取引データテーブルの「部門名」フィールドに格納された文字列が
表示される。

ユーザが、「追加」ボタンＢ１２０を指定すると、領域Ｑ１２２（例えば、行番号７と
行番号８との間）に新しい行が追加される。次いで、ユーザが、当該行の各欄に情報を入
力すると、入力された情報を格納した取引データレコードが取引データテーブルに追加さ
れる。

上記のように、取引管理画面Ｐ１２０は、各登録口座の資金試算情報や全ての登録口座
の資金資産情報を表示する。

取引管理画面Ｐ１２０の領域Ｑ１２２に表示される資金試算情報によれば、ユーザは、
取引毎に、取引の状況（会計伝票の作成が終了しているか否か）と、摘要（取引の内容）
と、入金額または出金額と、残高と、を容易に把握できる。つまり、ユーザは、予定取引
毎のキャッシュフローと、予定取引後の残高と、を容易に把握できる。
また、取引管理画面Ｐ１２０の領域Ｑ１２２に表示される資金試算情報によれば、ユー
ザは、各登録口座について、または、全ての登録口座について、予定取引毎のキャッシュ
フローと、予定取引後の残高と、を容易に把握できる。

（１−５−４）会計伝票画面Ｐ１３０（図１２）
本実施形態の会計伝票画面について説明する。図１２は、第１の実施形態の会計伝票画
面の一例を示す図である。

会計伝票画面Ｐ１３０は、ユーザが、図１１の「状況」欄を「未確定」から「確定」に
変更したときに表示される画面であって、かつ、「確定」に変更された「状況」欄に対応
する取引（以下「指定取引」という）の会計伝票を表示する画面である。

図１２に示すように、会計伝票画面Ｐ１３０は、領域Ｑ１３０〜Ｑ１３６を含む。

領域Ｑ１３０には、会計伝票画面Ｐ１３０を表示している日（つまり、現在）の日付が
表示される。

領域Ｑ１３２には、会計伝票を特定する伝票番号が表示される。

領域Ｑ１３４には、取引データテーブルの「部門コード」フィールドに格納された部門
コードに対応する部門名（当該部門コードに対応する部門データテーブルの「部門名」フ
ィールドに格納された文字列）が表示される。つまり、領域Ｑ１３４には、指定取引を行
った部門の部門名が表示される。

領域Ｑ１３６には、指定取引の会計項目（相手勘定科目、相手補助科目、金額、消費税
額、摘要、相手税区分）が表示される。

会計伝票画面Ｐ１３０が表示されると、領域Ｑ１３２に表示された伝票番号を示す値が
、指定取引の取引データレコードの「伝票番号」フィールドに格納され、かつ、「ステー
タス」フィールドに取引が終了しており、かつ、会計伝票の作成も終了していることを示
す値「１」が格納される。

（１−６）情報処理のフロー（図１３〜図１５）
本実施形態の情報処理のフローについて説明する。

（１−６−１）取引情報の登録の処理のフロー（図１３）
本実施形態の取引情報の登録の処理について説明する。図１３は、第１の実施形態の取
引情報の登録の処理のフローチャートである。

はじめに、取引情報の登録の要求の受付（Ｓ１００）が実行される。
取引情報の登録の要求は、取引に用いられた口座の口座名と、取引日付と、入金額また
は出金額と、摘要と、取引を行った部門の部門名と、を示す情報を含む。
例えば、ユーザが、操作入力部１５を操作して、図１１の「追加」ボタンＢ１２０を指
定すると、領域Ｑ１２２に新しい行が表示される。次いで、ユーザが、当該新しい行の「
取引日付」欄と、「摘要」欄と、「入金額」欄または「出金額」欄と、「部門名」欄と、
に情報を入力すると、サーバ３０は、ウェブブラウザから、当該欄に入力された情報を含
む要求（取引情報の登録の要求）を受け付ける。

次に、口座ＩＤの特定（Ｓ１０２）が実行される。
例えば、サーバ３０は、取引情報の登録の要求に含まれる口座名を示す情報に対応する
口座ＩＤを口座データテーブル（図５）から取り出す。取り出された口座ＩＤは、登録す
る取引情報に含める口座ＩＤとして特定される。

次に、取引種別の特定（Ｓ１０４）が実行される。
例えば、取引情報の登録の要求が入金額を示す情報を含む（例えば、ユーザが図１１の
領域Ｑ１２２の「入金額」欄に情報を入力した）場合、サーバ３０は、取引種別が入金取
引である、と特定する。
また、取引情報の登録の要求が出金額を示す情報を含み、かつ、振替口座への振替であ
ることを示す摘要を含まない（例えば、ユーザが「出金額」欄に情報を入力し、かつ、「
摘要」欄に取引に用いられた口座からの出金であることを示す文字列を入力した）場合、
サーバ３０は、取引種別が出金取引である、と特定する。
また、取引情報の登録の要求が出金額を示す情報と、取引に用いられた口座以外の口座
への振替であることを示す摘要と、を含む場合、（例えば、ユーザが「出金額」欄に情報
を入力し、かつ、「摘要」欄に取引に用いられた口座以外の口座（以下「振替先口座」と
いう）への振替であることを示す文字列（一例として、「振替」という文字列、および、
振替先口座の口座番号）を入力した）場合、サーバ３０は、取引種別が振替取引である、
と特定する。

次に、部門コードの特定（Ｓ１０６）が実行される。
例えば、サーバ３０は、取引情報の登録の要求に含まれる部門名を示す情報に対応する
部門コードを部門データテーブル（図６）から取り出す。
なお、部門コードの特定（Ｓ１０６）は、省略可能である。

次に、勘定科目コードの特定（Ｓ１０８）が実行される。
例えば、サーバ３０は、取引情報の登録の要求に含まれる勘定科目を示す情報に対応す
る勘定科目コードを勘定科目データテーブル（図７）から取り出す。
なお、勘定科目コードの特定（Ｓ１０８）は、省略可能である。

次に、取引データレコードの作成（Ｓ１１０）が実行される。
例えば、サーバ３０は、新たな取引ＩＤ（取引データテーブルに格納されていない取引
ＩＤ）を「取引ＩＤ」フィールドに格納し、Ｓ１０２において特定された口座ＩＤを「口
座ＩＤ」フィールドに格納し、Ｓ１０４において特定された取引種別を示す値を「取引種
別」フィールドに格納し、Ｓ１００において受け付けられた取引情報の登録の要求に含ま
れる値または文字列を「取引日付」フィールド、「取引金額」フィールド、および、「摘
要」フィールドに格納し、Ｓ１０６において特定された部門コードを「部門コード」フィ
ールドに格納し、取引についての会計伝票の作成が終了していないことを示す値「０」を
「ステータス」フィールドに格納し、「伝票番号」フィールドに値「Ｎ／Ａ」を格納する
。これにより、新たな取引データレコードが作成される。

次に、取引データテーブルの更新（Ｓ１１２）が実行される。
例えば、サーバ３０は、Ｓ１１０において作成された取引データレコードを取引データ
テーブルに格納する。これにより、取引データテーブルが更新される。

以上より、ユーザが入力した情報を含む取引情報が登録される。

（１−６−２）資金試算の処理のフロー（図１４）
本実施形態の資金試算の処理について説明する。図１４は、第１の実施形態の資金試算
の処理のフローチャートである。

はじめに、資金試算の要求の受付（Ｓ１２０）が実行される。
例えば、ユーザが、操作入力部１５を操作して、図１１の「期間」フォームＦ１２０に
任意の期間を示す情報を入力し、かつ、「口座」フォームＦ１２２の任意の口座を指定す
ると、サーバ３０は、ウェブブラウザから、「期間」フォームＦ１２０に入力された情報
と、「口座」フォームＦ１２２に入力された情報と、を含む要求（資金試算の要求）を受
け付ける。
以下、「口座」フォームＦ１２２で「１．一括」が指定された例について説明する。

次に、取引データレコードの取出（Ｓ１２２）が実行される。
例えば、サーバ３０は、取引データテーブル（図８）に含まれる取引データレコードの
うち、「期間」フォームＦ１２０に入力された期間と、「口座」フォームＦ１２２で指定
された口座（例えば、「１．一括」と、に対応する取引データレコード（つまり、「期間
」フォームＦ１２０に入力された期間に行われた全ての取引の取引情報）を取り出す。

次に、繰越残高の計算（Ｓ１２４）が実行される。
例えば、サーバ３０は、口座データテーブル（図５）に含まれる全ての口座データレコ
ードの「残高」フィールドに格納された値の合計値を計算する。この合計値は、「期間」
フォームＦ１２０に入力された期間の初日の時点（当該期間の最初の取引が行われる前の
時点）での残高（以下「繰越残高」という）である。

次に、取引後残高の計算（Ｓ１２６）が実行される。
例えば、サーバ３０は、Ｓ１２２において取り出された取引データレコード毎に、「取
引金額」フィールドに格納された値と、当該取引データレコードに関連する取引が行われ
る前の残高と、を参照して、取引後残高を計算する。
より具体的には、Ｓ１２２において取り出された取引データレコードの「取引種別」フ
ィールドに入金取引であることを示す値「０」が格納されている場合、サーバ３０は、当
該取引データレコードに関連する取引が行われる前の残高（当該取引データレコードに関
連する取引が「期間」フォームＦ１２０に入力された期間の最初に行われる取引である場
合には、Ｓ１２４において計算された繰越残高、それ以外の場合には、当該取引データレ
コードに関連する取引の直前に行われる取引が終了した後の残高）に、「取引金額」フィ
ールドに格納されている値を加算する。これにより、取引後残高が計算される。
一方、Ｓ１２２において取り出された取引データレコードの「取引種別」フィールドに
出金取引であることを示す値「１」または振替取引であることを示す値「２」が格納され
ている場合、サーバ３０は、当該取引データレコードに関連する取引が行われる前の残高
から、「取引金額」フィールドに格納されている値を減算する。これにより、取引後残高
が計算される。

次に、小計の計算（Ｓ１２８）が実行される。
例えば、サーバ３０は、取引日付毎に、Ｓ１２２において取り出された取引データレコ
ードの「入金額」フィールドに格納された値の合計と、「出金額」フィールドに格納され
た値の合計と、を計算する。これにより、小計が計算される。
なお、小計の計算（Ｓ１２８）は省略可能である。

次に、合計の計算（Ｓ１３０）が実行される。
例えば、サーバ３０は、Ｓ１２８において計算された入金額の小計の合計と、出金額の
小計の合計と、を計算する。
なお、合計の計算（Ｓ１３０）は省略可能である。

次に、資金試算情報の出力（Ｓ１３２）が実行される。
例えば、サーバ３０は、Ｓ１２２において取り出された取引データレコードと、Ｓ１２
４〜Ｓ１３０の計算結果と、を参照して、取引管理画面Ｐ１２０（図１１）のＨＴＭＬデ
ータを生成し、かつ、生成されたＨＴＭＬデータをウェブブラウザに送信する。次いで、
ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータを参照して、取引管理画面
Ｐ１２０を表示部１６に表示する。これにより、ユーザは、指定した期間に行われる予定
取引毎のキャッシュフロー（予定取引が行われる日付、予定取引の内容、予定取引におい
て取り扱われる金額）と、予定取引後の残高と、を知ることができる。また、ユーザは、
指定した将来の期間に含まれる日付毎に、入金額の小計と、出金額の小計と、残高と、を
知ることができる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータをプリン
タ（図示せず）に送信する。これにより、ユーザは、取引管理画面Ｐ１２０のハードコピ
ーを得ることができる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータをメール
サーバ（図示せず）に送信する。これにより、ユーザは、資金試算情報を他のユーザと共
有できる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータを汎用フ
ォーマット（例えば、ＣＳＶフォーマット、テキストフォーマットなど）のデータに変換
し、かつ、変換されたデータをストレージ１４に保存してもよい。これにより、ユーザは
、汎用フォーマットをサポートするアプリケーション（例えば、会計処理を実行するソフ
トウェア、商品の在庫管理の処理を実行するソフトウェアなど）において、資金試算情報
を利用できる。

（１−６−３）会計処理のフロー（図１５）
本実施形態の会計処理について説明する。図１５は、第１の実施形態の会計処理のフロ
ーチャートである。

はじめに、会計処理の要求の受付（Ｓ１４０）が実行される。
会計処理の要求は、取引データテーブルの「取引ＩＤ」フィールドに格納された取引Ｉ
Ｄのいずれかを含む。
例えば、ユーザが、操作入力部１５を操作して、取引管理画面Ｐ１２０（図１１）の領
域Ｑ１２２に表示された取引のうち、「状況」欄に「未確定」が表示された取引に対して
、「状況」欄の表示を「未確定」から「確定」に変更すると、サーバ３０は、ウェブブラ
ウザから、「状況」欄の表示が変更された取引を特定する取引ＩＤを含む会計処理の要求
を受け付ける。

次に、取引データレコードの取出（Ｓ１４２）が実行される。
例えば、サーバ３０は、取引データテーブル（図８）に含まれる取引データレコードの
うち、Ｓ１４０において受け付けられた会計処理の要求に含まれる取引ＩＤが格納された
「取引ＩＤフィールド」を含む取引データレコード（つまり、ユーザが指定した取引の取
引情報）を取り出す。

次に、会計伝票の出力（Ｓ１４４）が実行される。
例えば、サーバ３０は、Ｓ１４２において取り出された取引データレコードを参照して
、会計伝票画面Ｐ１３０（図１２）のＨＴＭＬデータを生成し、かつ、生成されたＨＴＭ
Ｌデータをウェブブラウザに送信する。ウェブブラウザは、サーバ３０から送信されたＨ
ＴＭＬデータを参照して、会計伝票画面Ｐ１３０を表示部１６に表示する。これにより、
ユーザは、会計伝票の内容を確認できる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータをプリン
タに送信する。これにより、ユーザは、会計伝票画面Ｐ１３０のハードコピーを得ること
ができる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータをメール
サーバに送信する。これにより、ユーザは、会計伝票を他のユーザと共有できる。
別の例として、ウェブブラウザは、サーバ３０から送信されたＨＴＭＬデータを汎用フ
ォーマット（例えば、ＣＳＶフォーマット、テキストフォーマット等）のデータに変換し
、かつ、変換されたデータをストレージ１４に保存してもよい。これにより、ユーザは、
汎用フォーマットをサポートするアプリケーション（例えば、会計処理を実行するソフト
ウェア、商品の在庫管理の処理を実行するソフトウェアなど）において、会計伝票の情報
を利用できる。

次に、取引データレコードの更新（Ｓ１４６）が実行される。
例えば、サーバ３０は、Ｓ１４２において取り出された取引データレコードの「ステー
タス」フィールドに、取引が終了しており、かつ、会計伝票の作成も終了していることを
示す値「１」を格納する。これにより、取引データレコードが更新される。

次に、取引データテーブルの更新（Ｓ１４８）が実行される。
例えば、サーバ３０は、Ｓ１４６において更新された取引データレコードを取引データ
テーブルに格納する。これにより、取引データテーブルが更新される。

以上より、ユーザは、登録した取引情報に基づく会計伝票を容易に得ることができる。

（１−７）第１の実施形態の変形例
第１の実施形態の変形例について説明する。

（１−７−１）第１の実施形態の変形例１
上記実施形態では、取引情報の登録の処理（図１３）において、ユーザが入力した情報
に基づいて、取引情報を登録する例について説明したが、本発明の範囲はこれに限られな
い。本実施形態では、ユーザが情報を入力する代わりに、任意のソフトウェアによって作
成されたデータ（例えば、給与を計算するソフトウェアによって作成されたデータ、商品
の受注を管理するソフトウェアによって作成されたデータ、経費を管理するソフトウェア
によって作成されたデータ、会計処理を行うソフトウェアによって作成されたデータ、銀
行が提供するオンラインバンクで管理されているデータなど）をインポートしてもよい。
この場合、サーバ３０は、任意のソフトウェアによって作成されたデータのフォーマット
を取引データテーブル（図８）のフォーマットに変換することにより、取引データテーブ
ルに取引データレコードを格納する。
これにより、取引情報を登録するときのユーザの負担を低減でき、かつ、これらのソフ
トウェアを利用するユーザの利便性を向上させることができる。

（１−７−２）第１の実施形態の変形例２
上記実施形態では、取引情報の登録の処理（図１３）において、ユーザが入力した情報
に基づいて、勘定科目コードを特定する例について説明したが、本発明の範囲はこれに限
られない。本実施形態では、ユーザが勘定科目を示す情報を入力しなかった場合、サーバ
３０は、摘要と勘定科目との対応関係を示す辞書データ（図示せず）を参照して、勘定科
目を示すコードを特定してもよい。
これにより、ユーザは、勘定科目を意識することなく、取引情報を登録できる。つまり
、勘定科目に関する知識を有していないユーザであっても、取引情報を登録できる。

（１−８）第１の実施形態のまとめ
本実施形態によれば、記憶装置にアクセス可能な情報処理装置であって、ユーザの指示
に応じて、口座への入金または口座からの出金のいずれかである取引に関する取引情報で
あって、かつ、取引日付と、取引金額と、取引の摘要と、を含む取引情報を取得する取得
手段と、前記取得手段によって取得された取引情報を前記記憶装置に格納する格納手段と
、ユーザの指示に応じて、前記記憶装置に格納された取引情報のうち、ユーザによって指
定された将来の期間に含まれる取引日付を含む取引情報を参照して、当該将来の期間に行
われる予定取引毎に、取引日付と、入金額または出金額と、取引の摘要と、取引が終了し
た後の口座の残高と、を含む資金試算情報を出力する第１出力手段と、を備えた情報処理
装置が提供される。
これにより、ユーザが取引情報（少なくとも、取引日付と、取引金額と、取引の摘要と
、を含む情報）を情報処理装置に与えると、取引毎の取引日付と、入金額または出金額と
、取引の摘要と、取引後残高と、を含む資金試算情報が提供される。ユーザは、この資金
試算情報を通じて取引毎のキャッシュフローと、取引後残高と、を把握した上で、事業計
画を立てることができる。例えば、ユーザが任意の注目日の残高が不足していると考えた
場合、注目日以前に行われる取引のうち、注目日に行われる取引（例えば、返済取引）よ
り重要度が低い取引（例えば、仕入れ取引）を中止、または、延期するような事業計画を
立てることができる。したがって、事業計画を立てるときのユーザの負担を低減できる。

また、本実施形態によれば、前記第１出力手段は、ユーザによって指定された将来の期
間に含まれる日付毎に、入金額の合計と、出金額の合計と、全ての取引が終了した後の口
座の残高と、をさらに含む資金試算情報を出力する、情報処理装置が提供される。
これにより、ユーザが取引情報を与えると、ユーザが指定した将来の期間に含まれる日
付毎の入金額の合計と、出金額の合計と、口座の残高と、を含む資金試算情報が提供され
る。ユーザは、この資金試算情報を通じて将来における日々のキャッシュフローを把握し
た上で、事業計画を立てることができる。したがって、事業計画を立てるときのユーザの
負担をさらに低減できる。

また、本実施形態によれば、ユーザの指示に応じて、前記記憶装置に格納された取引情
報のうち、ユーザによって指定された取引である指定取引の取引情報を参照して、当該指
定取引の会計伝票を出力する第２出力手段をさらに備えた、情報処理装置が提供される。
ユーザの指示に応じて、前記記憶装置に格納された取引情報のうち、ユーザによって指
定された取引である指定取引の取引情報を参照して、当該取引情報に含まれる取引日付よ
り後であって、かつ、ユーザによって指定された将来の日付に行われる予定取引の取引金
額を推定する推定手段をさらに備え、前記格納手段は、前記予定取引に関する取引情報で
あって、かつ、ユーザによって指定された将来の日付と、前記推定手段によって推定され
た取引金額と、を含む取引情報を前記記憶装置に格納する。
これにより、ユーザが指定した取引の会計伝票が提供される。ユーザは、この会計伝票
を用いて、所定の作業（例えば、経理作業など）を行うことができる。したがって、経理
作業におけるユーザの負担を低減できる。

（２）第２の実施形態
上述の第１の実施形態では、ユーザが入力した情報に基づく取引金額を新たに登録する
取引情報に含める例について説明した。これに対して、本実施形態では、既存の取引情報
に含まれる取引金額に基づいて推定された取引金額を新たに登録する取引情報に含める例
について説明する。
なお、上述の実施形態と同様の説明は適宜省略する。

（２−１）情報処理において表示される取引管理画面（図１６）
本実施形態の取引管理画面について説明する。図１６は、第２の実施形態の取引管理画
面の一例を示す図である。

図１６に示すように、取引管理画面Ｐ２２０は、第１の実施形態の取引管理画面Ｐ１
２０（図１１）と同様の要素に加えて、「コピー」ボタンＢ２２０を含む。
「コピー」ボタンＢ２２０は、ユーザが、新たな取引の取引金額の推定の要求を行うと
きに指定するオブジェクトである。

ユーザが「行番号」欄に番号が表示された少なくとも１つの行を指定し、次いで「コピ
ー」ボタンＢ２２０を指定すると、指定された行の「取引日付」欄に表示された日付に関
連する日付（例えば、「取引日付」欄に表示された日付の１ヶ月後の日付）と、指定され
た行の「摘要」欄に表示された摘要に関連する摘要（例えば、「摘要」欄に表示された情
報の全部または一部が共通する摘要）と、指定された行の「入金額」欄または「出金額」
欄に表示された金額に基づいて推定された金額と、指定された行の「勘定科目」欄および
「部門名」欄に表示された勘定科目および部門名とそれぞれ同一の勘定科目および部門名
と、を含む取引情報が新たに登録される。

（２−２）取引情報の登録の処理のフロー（図１７）
本実施形態の取引情報の登録の処理について説明する。図１７は、第２の実施形態の取
引情報の登録の処理のフローチャートである。

はじめに、取引情報の登録の要求および取引金額の推定の要求の受付（Ｓ２００）が実
行される。
例えば、ユーザが、操作入力部１５を操作して、図１６の領域Ｑ１２２の任意の行（例
えば、行番号「６」の行）と、「コピー」ボタンＢ２２０と、を指定すると、領域Ｑ１２
２に新しい行が追加される。当該新しい行には、ユーザが指定した行（例えば、行番号「
６」の行）に表示された情報に関連する情報が表示される。サーバ３０は、ウェブブラウ
ザから、当該新しい行に表示された情報を含む要求（取引情報の登録の要求）と、取引金
額の推定の要求と、を受け付ける。取引金額の推定の要求は、ユーザが指定した行に関連
する取引（以下「指定取引」という）の取引ＩＤを含む。

次に、取引データレコードの取出（Ｓ２０２）が実行される。
一例として、サーバ３０は、Ｓ２００において受け付けられた取引金額の推定の要求に
含まれる取引ＩＤが格納された「取引ＩＤ」フィールドを含む取引データレコード（つま
り、指定取引の取引情報）を取引データテーブル（図８）から取り出す。
さらに、別の例として、サーバ３０は、Ｓ２００において受け付けられた取引金額の推
定の要求に含まれる取引ＩＤが格納された「取引ＩＤ」フィールドを含む取引データレコ
ード（つまり、指定取引の取引情報）と、当該取引データレコードの「摘要」フィールド
に格納された文字列と少なくとも一部が共通する文字列が格納された「摘要」フィールド
を含む取引データレコード（つまり、指定取引に関連する取引（以下「関連取引」という
）の取引情報）と、を取引データテーブルから取り出す。換言すると、「関連取引」とは
、取引の内容（例えば、入金元、出金元、目的など）が指定取引と同様である（同一、ま
たは、類似の）取引のことである。

次に、取引金額の推定（Ｓ２０４）が実行される。
一例として、Ｓ２０２において取り出された取引データレコードが１つである場合、サ
ーバ３０は、Ｓ２０２において取り出された取引データレコードの「取引金額」フィール
ドに格納された値と同一の値を、新たに登録する取引情報に含める取引金額として推定す
る。
別の例として、Ｓ２０２において取り出された取引データレコードが複数である場合、
サーバ３０は、Ｓ２０２において取り出された取引データレコードの「取引金額」フィー
ルドに格納された値の平均値を、新たに登録する取引情報に含める取引金額として推定す
る。
別の例として、Ｓ２０２において取り出された取引データレコードが複数である場合、
サーバ３０は、Ｓ２０２において取り出された取引データレコードのうち、所定期間（例
えば、過去１年間）に含まれる値が格納された「取引日付」フィールドを含む取引データ
レコードの「取引金額」フィールドに格納された値の平均値を、新たに登録する取引情報
に含める取引金額として推定する。

次に、第１の実施形態（図１３）と同様に、口座ＩＤの特定（Ｓ１０２）〜勘定科目コ
ードの特定（Ｓ１０８）が実行される。

次に、取引データレコードの作成（Ｓ２０６）が実行される。
例えば、サーバ３０は、第１の実施形態（図１３）と同様に、「取引ＩＤ」フィールド
と、「口座ＩＤ」フィールドと、「取引種別」フィールドと、「取引日付」フィールドと
、「摘要」フィールドと、「部門コード」フィールドと、「ステータス」フィールドと、
に値、文字列、または、コードを格納し、かつ、Ｓ２０４において推定された取引金額を
示す値を「取引金額」フィールドに格納する。これにより、新たな取引データレコードが
作成される。

次に、第１の実施形態（図１３）と同様に、取引データテーブルの更新（Ｓ１１０）が
実行される。

以上より、指定取引の取引金額に基づいて推定された取引金額を含む取引情報（指定取
引に関連する関連取引の取引情報）が登録される。

（２−３）第２の実施形態のまとめ
本実施形態によれば、ユーザの指示に応じて、前記記憶装置に格納された取引情報のう
ち、ユーザによって指定された取引である指定取引の取引情報を参照して、当該取引情報
に含まれる取引日付より後であって、かつ、ユーザによって指定された将来の日付に行わ
れる予定取引の取引金額を推定する推定手段をさらに備え、前記格納手段は、前記予定取
引に関する取引情報であって、かつ、ユーザによって指定された将来の日付と、前記推定
手段によって推定された取引金額と、を含む取引情報を前記記憶装置に格納する、情報処
理装置が提供される。
これにより、ユーザが新たな取引情報を登録する際に、取引金額を入力しなくても、ユ
ーザが指定した取引の取引金額に基づいて推定された取引金額を含む取引情報が登録され
る。したがって、取引情報を登録するときのユーザの負担を低減でき、かつ、より正確な
取引金額を取引情報に含めることができる。

（３）第３の実施形態
上述の実施形態では、新たな取引情報を登録する例について説明した。これに対して、
本実施形態では、ユーザが既存の取引情報に含まれる取引金額を編集した場合、当該取引
情報とは異なる既存の取引情報に含まれる取引金額が自動的に編集される例について説明
する。
なお、上述の実施形態と同様の説明は適宜省略する。

（３−１）取引情報の変更の処理のフロー（図１８）
本実施形態の取引情報の変更の処理について説明する。図１８は、第３の実施形態の取
引情報の変更の処理のフローチャートである。

はじめに、取引情報の変更の要求の受付（Ｓ３００）が実行される。
例えば、ユーザが、操作入力部１５を操作して、図１１の領域Ｑ１２２の任意の行の「
入金額」欄もしくは「出金額」欄、または、図１２の領域Ｑ１３６の「金額」欄に表示さ
れた情報を編集すると、サーバ３０は、ウェブブラウザから、当該行に表示された取引情
報（指定取引の取引情報）に含まれる取引ＩＤと、編集された情報（つまり、編集後の取
引金額）と、を含む要求（取引情報の変更の要求）を受け付ける。

次に、指定取引および関連取引の取引データレコードの取出（Ｓ３０２）が実行される
。
例えば、サーバ３０は、Ｓ３００において受け付けられた取引情報の変更の要求に含ま
れる取引ＩＤを含む取引データレコード（指定取引の取引情報）と、当該取引データレコ
ードの「摘要」フィールドに記録された文字列の少なくとも一部を含む「摘要」フィール
ドを含む取引データレコード（関連取引の取引情報）と、を取引データテーブル（図８）
から取り出す。取り出される関連取引の取引データレコードは、１つであってもよいし、
複数であってもよい。

次に、指定取引の取引データレコードの更新（Ｓ３０４）が実行される。
例えば、サーバ３０は、Ｓ３００において受け付けられた取引情報の変更の要求に含ま
れる取引金額（つまり、ユーザによって編集された指定取引の取引金額）を示す値を、Ｓ
３０２において取り出された指定取引の取引データレコードの「取引金額」フィールドに
格納する。これにより、指定取引の取引データレコードが更新される。

次に、取引金額の推定（Ｓ３０６）が実行される。
例えば、サーバ３０は、Ｓ３０４において「取引金額」フィールドに格納された値と、
Ｓ３０２において取り出された関連取引の取引データレコードのうち、指定取引の取引デ
ータレコードの「取引日付」フィールドに格納された値より小さい値が格納された「取引
日付フィールド」を含む取引データレコードの「取引金額」フィールドに格納された値と
、の平均値（つまり、編集後の指定取引の取引金額と、指定取引より前に行われた関連取
引の取引金額と、の平均値）を、指定取引より後に行われた関連取引の取引金額として推
定する。

次に、関連取引の取引データレコードの更新（Ｓ３０８）が実行される。
例えば、サーバ３０は、Ｓ３０６において推定された取引金額を示す値を、Ｓ３０２に
おいて取り出された関連取引の取引データレコードのうち、指定取引の取引データレコー
ドの「取引日付」フィールドに格納された値以上の値が格納された「取引日付」フィール
ドを含む取引データレコード（つまり、指定取引以降に行われた関連取引の取引情報）の
「取引金額」フィールドに格納する。これにより、指定取引以降に行われた関連取引の取
引データレコードが更新される。

次に、取引データテーブルの更新（Ｓ３１０）が実行される。
例えば、サーバ３０は、Ｓ３０４において更新された指定取引の取引データレコードと
、Ｓ３０８において更新された関連取引の取引データレコードとを、取引データテーブル
に格納する。これにより、取引データテーブルが更新される。

以上より、ユーザが指定取引の取引金額を編集すると、指定取引以降に行われた関連取
引の取引金額が自動的に編集される。

（３−２）第３の実施形態のまとめ
本実施形態によれば、ユーザの指示に応じて、前記記憶装置に格納された取引情報のう
ち、前記指定取引の取引情報に含まれる取引金額を変更する変更手段をさらに備え、前記
推定手段は、前記変更手段によって変更された取引金額に基づいて、前記予定取引の取引
金額を推定し、前記変更手段は、さらに、前記推定手段によって推定された取引金額に基
づいて、前記記憶装置に格納された取引情報のうち、前記指定取引の取引情報に含まれる
取引日付より後の取引日付を含む取引情報に含まれる取引金額を変更する、情報処理装置
が提供される。
これにより、ユーザが登録済みの取引情報に含まれる取引金額を編集すると、当該取引
情報に関連する取引に類似する取引の取引情報に含まれる取引金額も自動的に編集される
。したがって、ユーザは、互いに関連する複数の取引の取引金額を編集するときのユーザ
の負担が低減できる。

（４）その他の変形例
上述の実施形態では、クライアント端末１０にインストールされたウェブブラウザと、
サーバ３０とによって、本実施形態の情報処理が実現される例について説明したが、本発
明の範囲はこれに限られるものではない。
例えば、本実施形態の情報処理は、クライアント端末１０にインストールされた専用ア
プリケーション（ウェブブラウザ以外のアプリケーション）と、サーバ３０が提供する専
用サービスとによって実現されてもよいし、当該専用アプリケーションのみによって（つ
まり、専用アプリケーションとサーバ３０との間の通信なしに）実現されてもよい。

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に
限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々
の改良や変更が可能である。また、上記の実施形態および変形例は、組合せ可能である。

１ ：情報処理システム
１０ ：クライアント端末
１１ ：ＣＰＵ
１２ ：ＲＯＭ
１３ ：ＲＡＭ
１４ ：ストレージ
１５ ：操作入力部
１６ ：表示部
１７ ：通信インタフェース
１８ ：バス
３０ ：サーバ
３１ ：ＣＰＵ
３２ ：ＲＯＭ
３３ ：ＲＡＭ
３４ ：ストレージ
３５ ：通信インタフェース
３６ ：バス
ＮＷ ：通信網

Claims (5)

1. 記憶装置にアクセス可能な情報処理装置であって、
   ユーザの指示に応じて、口座への入金または口座からの出金のいずれかである取引に関する取引情報であって、かつ、取引日付と、取引金額と、取引の摘要と、を含む取引情報を複数取得する取得手段と、
   ユーザの指示に応じて、前記取得手段によって取得された複数の取引情報のうち、ユーザによって指定された複数の指定取引の取引情報に含まれる取引金額の平均値を、各指定取引の取引情報に含まれる取引日付より後の日付のうちユーザによって指定された将来の日付に行われる取引であって、かつ、前記指定取引の摘要に関連する摘要を含む取引である予定取引の取引金額として推定する推定手段と、
   前記取得手段によって取得された取引情報と、前記推定手段によって推定された取引金額を含む予定取引の取引情報と、を前記記憶装置に格納する格納手段と、
   ユーザの指示に応じて、前記記憶装置に格納された複数の取引情報のうち、ユーザによって指定された将来の期間に含まれる取引日付を含む取引情報を参照して、当該将来の期間に行われる予定取引毎に、取引日付と、入金額または出金額と、取引の摘要と、取引が終了した後の口座の残高と、を含む資金試算情報を出力する第１出力手段と、
   を備えた情報処理装置。
2. 記憶装置にアクセス可能な情報処理装置であって、
   ユーザの指示に応じて、口座への入金または口座からの出金のいずれかである取引に関する取引情報であって、かつ、取引日付と、取引金額と、取引の摘要と、を含む取引情報を複数取得する取得手段と、
   ユーザの指示に応じて、前記取得手段によって取得された複数の取引情報のうち、ユーザによって指定された複数の指定取引の取引情報に含まれる取引金額の平均値を、各指定取引の取引情報に含まれる取引日付より後であって、かつ、ユーザによって指定された将来の日付に行われる予定取引の取引金額として推定する推定手段と、
   前記取得手段によって取得された取引情報と、前記推定手段によって推定された取引金額を含む予定取引の取引情報と、を前記記憶装置に格納する格納手段と、
   ユーザの指示に応じて、前記記憶装置に格納された複数の取引情報のうち、ユーザによって指定された将来の期間に含まれる取引日付を含む取引情報を参照して、当該将来の期間に行われる予定取引毎に、取引日付と、入金額または出金額と、取引の摘要と、取引が終了した後の口座の残高と、を含む資金試算情報を出力する第１出力手段と、
   ユーザの指示に応じて、前記記憶装置に格納された複数の取引情報のうち、ユーザによって指定された指定取引の取引情報に含まれる取引金額を変更する変更手段と、を備え、
   前記推定手段は、前記変更手段によって変更された取引金額に基づいて、前記予定取引の取引金額を推定し、
   前記変更手段は、さらに、前記推定手段によって推定された取引金額に基づいて、前記記憶装置に格納された取引情報のうち、前記指定取引より後に行われる予定取引の取引金額を変更する、
   情報処理装置。
3. 前記推定手段は、前記指定取引の取引情報のうち、所定期間に含まれる取引日付を含む取引情報に含まれる取引金額の平均値を、前記予定取引の取引金額として推定する、
   請求項１または２に記載の情報処理装置。
4. コンピュータを、請求項１〜３のいずれかに記載の情報処理装置の各手段として機能させるプログラム。
5. 記憶装置と、前記記憶装置にアクセス可能なサーバと、前記サーバおよび前記記憶装置にアクセス可能なクライアント端末と、を備える情報処理システムであって、
   請求項１〜３のいずれかに記載の情報処理装置の各手段が、それぞれ、前記クライアント端末および前記サーバのいずれかに設けられた、情報処理システム。

Images