(58)【調査した分野】(Int.Cl.,DB名)
会計事務所の端末(以下、会計事務所端末)と、複数の顧問先の端末(以下、顧問先端末)がネットワークで接続された構成において、複数の顧問先からの様々なアプリケーション(以下、アプリ)用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができるシステムであって、
顧問先端末は、様々なアプリ用データと、前記アプリ用データに関するイベントログ情報とを送受信することが可能なデータ送受信手段を備え、
会計事務所端末は、
複数の前記顧問先端末により前記データ送受信手段から送信された前記アプリ用データと前記イベントログ情報とを受信するデータ受信手段と、
前記データ受信手段により受信した受信データの状況を、受信した前記イベントログ情報を記憶したイベントログ記録部と、データ形式ごとに作業手順を記憶した業務進行テーブルとに基づいて判断するデータ状況判断手段と、
前記データ状況判断手段により判断されたデータ状況に応じ、重要度を、重要度テーブルを参照して判定し、または、処理優先度を、処理期限管理テーブルを参照して判定するデータ重要度判定手段と、
前記受信データの受信時に、前記受信データを分別して得た前記顧問先端末のアプリ情報と、前記会計事務所端末のアプリ情報とを比較することで、異常を判断するデータ異常判断手段と、
前記受信データの内容を表示、または編集、またはチェックするための1ないし複数のアプリを、前記イベントログ記録部を参照して選択し、起動させるアプリ起動手段と、
前記受信データを取り込むアプリを、前記イベントログ記録部を参照して選択して起動し、前記受信データを取り込むデータ取込手段と、
前記アプリ用データに関するイベントが発生する度に、その履歴と、前記業務進行テーブルを参照して得られる一連の業務処理内での進捗状況とを、前記イベントログ記録部に記録するイベントログ記録手段と、
前記データ受信手段によりデータを受信したことを通知するデータ受信通知手段と、
複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち1以上と、受信データとを一括表示する受信データ一括表示手段と、
データ形式をシンボル化して表示し、前記データ形式に対応する処理を実行する操作機能を付加したシンボル表示手段と、
前記データ状況判断手段で判断された状況を表示するデータ状況表示手段と、
前記データ重要度判定手段により判定された重要度、または処理優先度を表示するデータ重要度表示手段と、
前記データ異常判断手段で異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示手段と、
前記アプリ起動手段による前記1ないし複数のアプリを起動させるためのボタンを表示するアプリ開始ボタン表示手段と、
前記データ取込手段による取り込みを開始するためのボタンを表示する取込開始ボタン表示手段と、
前記データ異常判断手段により、異常があると判断された前記受信データの内容を確認するためのアプリを起動させるボタンを表示する異常データ確認開始ボタン表示手段と、
前記イベントログ記録手段により、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化する進捗状況表示手段と、
を備える、会計処理システム。
複数の顧問先端末に対してネットワークで接続された構成において、複数の顧問先からの様々なアプリ用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができる会計処理装置であって、
複数の前記顧問先端末により様々なアプリ用データと前記アプリ用データに関するイベントログ情報とを受信するデータ受信手段と、
前記データ受信手段により受信した受信データの状況を、受信した前記イベントログ情報を記憶したイベントログ記録部と、データ形式ごとに作業手順を記憶した業務進行テーブルとに基づいて判断するデータ状況判断手段と、
前記データ状況判断手段により判断されたデータ状況に応じ、重要度を、重要度テーブルを参照して判定し、または、処理優先度を、処理期限管理テーブルを参照して判定するデータ重要度判定手段と、
前記受信データの受信時に、前記受信データを分別して得た前記顧問先端末のアプリ情報と、前記会計処理装置のアプリ情報とを比較することで、異常を判断するデータ異常判断手段と、
前記受信データの内容を表示、または編集、またはチェックするための1ないし複数のアプリを、前記イベントログ記録部を参照して選択し、起動させるアプリ起動手段と、
前記受信データを取り込むアプリを、前記イベントログ記録部を参照して選択して起動し、前記受信データを取り込むデータ取込手段と、
前記アプリ用データに関するイベントが発生する度に、その履歴と、前記業務進行テーブルを参照して得られる一連の業務処理内での進捗状況とを、前記イベントログ記録部に記録するイベントログ記録手段と、
前記データ受信手段によりデータを受信したことを通知するデータ受信通知手段と、
複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち1以上と、受信データとを、表示部に一括表示する受信データ一括表示手段と、
データ形式をシンボル化して前記表示部に表示し、前記データ形式に対応する処理を実行する操作機能を付加したシンボル表示手段と、
前記データ状況判断手段で判断された状況を前記表示部に表示するデータ状況表示手段と、
前記データ重要度判定手段により判定された重要度、または処理優先度を、前記表示部に表示するデータ重要度表示手段と、
前記データ異常判断手段で異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示手段と、
前記アプリ起動手段による前記1ないし複数のアプリを起動させるためのボタンを、前記表示部に表示するアプリ開始ボタン表示手段と、
前記データ取込手段による取り込みを開始するためのボタンを、前記表示部に表示する取込開始ボタン表示手段と、
前記データ異常判断手段により、異常があると判断された前記受信データの内容を確認するためのアプリを起動させるボタンを、前記表示部に表示する異常データ確認開始ボタン表示手段と、
前記イベントログ記録手段により、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化して、前記表示部に表示する進捗状況表示手段と、
を備える、会計処理装置。
会計事務所の端末(以下、会計事務所端末)と、複数の顧問先の端末(以下、顧問先端末)がネットワークで接続された構成において、複数の顧問先からの様々なアプリケーション(以下、アプリ)用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができる方法であって、
顧問先端末が、様々なアプリ用データと、前記アプリ用データに関するイベントログ情報とを送受信することが可能なデータ送受信ステップを含み、
会計事務所端末が、
複数の前記顧問先端末により前記データ送受信ステップから送信された前記アプリ用データと前記イベントログ情報とを受信するデータ受信ステップと、
前記データ受信ステップにより受信した受信データの状況を、受信した前記イベントログ情報を記憶したイベントログ記録部と、データ形式ごとに作業手順を記憶した業務進行テーブルとに基づいて判断するデータ状況判断ステップと、
前記データ状況判断ステップにより判断されたデータ状況に応じ、重要度を、重要度テーブルを参照して判定し、または、処理優先度を、処理期限管理テーブルを参照して判定するデータ重要度判定ステップと、
前記受信データの受信時に、前記受信データを分別して得た前記顧問先端末のアプリ情報と、前記会計事務所端末のアプリ情報とを比較することで、異常を判断するデータ異常判断ステップと、
前記受信データの内容を表示、または編集、またはチェックするための1ないし複数のアプリを、前記イベントログ記録部を参照して選択し、起動させるアプリ起動ステップと、
前記受信データを取り込むアプリを、前記イベントログ記録部を参照して選択して起動し、前記受信データを取り込むデータ取込ステップと、
前記アプリ用データに関するイベントが発生する度に、その履歴と、前記業務進行テーブルを参照して得られる一連の業務処理内での進捗状況とを、前記イベントログ記録部に記録するイベントログ記録ステップと、
前記データ受信ステップによりデータを受信したことを通知するデータ受信通知ステップと、
複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち1以上と、受信データとを一括表示する受信データ一括表示ステップと、
データ形式をシンボル化して表示し、前記データ形式に対応する処理を実行する操作機能を付加したシンボル表示ステップと、
前記データ状況判断ステップで判断された状況を表示するデータ状況表示ステップと、
前記データ重要度判定ステップにより判定された重要度、または処理優先度を表示するデータ重要度表示ステップと、
前記データ異常判断ステップで異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示ステップと、
前記アプリ起動ステップによる前記1ないし複数のアプリを起動させるためのボタンを表示するアプリ開始ボタン表示ステップと、
前記データ取込ステップによる取り込みを開始するためのボタンを表示する取込開始ボタン表示ステップと、
前記データ異常判断ステップにより、異常があると判断された前記受信データの内容を確認するためのアプリを起動させるボタンを表示する異常データ確認開始ボタン表示ステップと、
前記イベントログ記録ステップにより、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化する進捗状況表示ステップと、
を含む、会計処理方法。
【背景技術】
【0002】
昨今の会計事務所は、主に記帳を受託する事務所や主に監査を得意とする事務所など、事務所毎の業務処理に対して様々な特色を持つことが多いが、その中で基本的な業務として、「顧問先への経理指導、記帳・自計化指導」→「データ受取」→「会計処理」→「決算税務・電子申告」→「顧問先への資料提出」という一連の順番・流れ・状況の把握をする、ワークフローや業務フローとも呼ばれる業務処理において、精度、早さの要求は、今もなお顧問先への対応において、求められている。
【0003】
この、顧問先から会計事務所、そして顧問先へと返るの一連の業務処理に対し、自動化や省力化を導入することで緊密な連携となり、双方にまたがる一連の処理を、スムーズかつシームレスに実現するものである。
【0004】
会計事務所では、顧問先を1〜N社のサポートをしている。
昨今の技術進歩により、顧問先内の業務システムは、多種多様になっているなか、会計事務所では、所内で担当者を割り当てながら、各顧問先へのサポートをしている。
また、会計事務所では、その顧問先に対する進捗を確認しながら、会計事務所のアドバンテージを出せるように、過去の傾向、記帳アプリケーションソフトウェア(以下、アプリ)の操作、仕訳科目の出現頻度、仕訳後の状況を見ながら、日頃から顧問先の自計化を推進・教育・アドバイスなどをしている。
【0005】
その中で、会計事務所では、様々なデータ形式のデータ(領収書等、カード明細、銀行カード情報等や、顧問先で入力した仕訳情報、帳簿情報等)を受信し、仕訳が正常であることを確認し、決算情報としてまとめ、監査し、作成した財務帳表等を顧問先に報告確認し、電子申告を行うような、一連の対応をしている。
【0006】
財務帳表等の作成の過程では、顧問先毎に統一したメッセージを用意して、顧問先に提出する際のメッセージを添えることで、簡単に更なるアドバイスができるような効率的な手法を含めた、統合管理システムの改良も進められてる。
【0007】
従来、会計事務所では、複数の顧問先から、様々なベンダのアプリで作成されたデータが送られてくるが、データが送られてきたかどうかを確認する方法として、送られてきたデータに適したアプリを起動して確認する方法や、メッセージやデータの送受信管理システムを使用する方法がある。
【0008】
また、送られてきたデータに異常がないかを確認する方法として、データを編集用アプリで開いて目視でチェックする方法や、チェック用アプリを利用して自動チェックする方法がある。ただし、データをチェックするためのチェック用アプリは1つとは限らず、複数のチェック用アプリを利用して1つのデータをチェックしなければならない場合もある。
【0009】
送られてきたデータは、どのような処理を望んだものか、依頼内容のメッセージと共に送られてくるものがある一方、定期的な報告のためや、アプリ内でのデータの送信やり取りのため等の理由で、依頼内容のメッセージがないものもある。依頼内容のメッセージがないデータに対しては、依頼内容を、送信元の顧問先に電話等で聞いたり、会計事務所内で作業履歴を確認することで推測したり、アプリ内のワークフロー管理機能で把握したりすることで対応している。
【0010】
このように会計事務所では、複数の顧問先の様々なベンダのアプリのデータを、受信したかを様々な方法でキャッチアップし、データが正しいものかを色々な方法で確認し、作業順番を重要度・優先度で判断しながら割り振り、データの取り込みを進捗確認しながら行い、仕訳等の実際の作業をデータ毎の専用アプリで行うなどの一連の作業を、作業履歴を残しながら顧問先毎に対応している。また、一連の作業を可能とするために、複数の顧問先が送信するデータを取り扱うための様々なベンダのアプリの管理(インストール、バージョンアップ等)や、メンテナンスも行っている。
【0011】
そのため、受信データの管理を簡易化する方法や、データを受信してから迅速に対応する方法、複数の顧問先から同時に依頼があった際に効率良く処理する方法、対応するための様々な操作を簡易化する方法、作業の履歴を効率よく行う方法が重要になっていた。また、様々なベンダのアプリ管理も重要になっていた。
【0012】
もう一方の見方として、会計事務所に関して、設立当初は顧問先が少ないながらも、主に記帳代行を受託する会計事務所や、主に監査を得意とする会計事務所、主に相続対応を得意とする会計事務所など、様々な特色を持たせて顧問先の数を増やし、会計事務所の所員(以下、作業員)も増員していく成長過程で、日々の業務を遂行しながら、日頃から顧問先の自計化を推進・教育・アドバイスなどをしている状況がある。
【0013】
日々の業務では、顧問先から伝票(紙ベース)をそのまま受領したり、多種多様の業務システム、様々なベンダのアプリケーションソフトウェア(以下、アプリ)を持つ顧問先の、それらアプリや業務システムなどで生成された様々な形式のデータ(領収書、カード明細、銀行カード情報、顧問先で入力した仕訳情報、帳簿情報、顧問先情報等)を、メーラーやクラウドストレージ、アプリ独自の送受信機能を使うなどで、インターネットで受信、またはUSBメモリ等のメディアを用いて受領するなどの体制を整えたり、受領したデータに不備がないかを確認したりしながら、会計事務所内の会計アプリへ入力して(取り込んで)仕訳作業をするために、過去の状況における傾向や、仕訳科目の出現頻度などを見たり、記帳アプリの記帳支援機能を活用したり、会計事務所内の作業員同士の情報共有や顧問先から付加情報を聞き出したり、仕訳した会計データが正しいことをチェック専用アプリでチェックをしたりして、最終的には、記帳代行や仕訳、決算財務帳表作成なども含んだ基本的な業務である、「顧問先への経理指導、記帳・自計化指導」→「データ受取」→「会計処理」→「決算税務・電子申告」→「顧問先への資料提出」という順番、流れ、ワークフローや業務フローとも呼ばれる一連の業務を、状況を把握しながら、各対応アプリを個別に起動して確認する手間、組み合わせの問題、整合性の問題、操作性の問題もある。
【0014】
これら日々の業務は、複数の顧問先に対して行う業務であって、効率良く作業を進めるためには、顧問先毎に進捗管理と合わせて、全ての顧問先の進捗状況を管理する必要もあり、会計処理という実務の他に係る業務が多岐に渡る。
例えば、顧問先からデータとして証憑を受信する際の業務フローは、データが送られてきたかどうかを確認、チェック用アプリを利用してデータに異常がないか、不足情報がないかを確認、データを編集用アプリで開いて目視で間違いがないか、不足情報がないかを確認、データの間違い修正、不足情報(仕訳、勘定科目等)の追記等を行い、データを保存する、という流れに沿って対応する。
【0015】
データが送られてきたことを認識するには、主にアプリを起動してデータの有無を確認して認識しているが、顧問先からの電話やメール等の連絡を受けて気付く、または問い合わせて認識するなど、多くは人手に頼った方法で認識していた。 最近では、バックグラウンドで動作するシステムまたはアプリが、画面上に受信したことを表示させたりするが、対応するデータしか表示できなかったり、短時間の表示だったりと利便性は低い。
【0016】
何のデータなのか、どのような処理を望んだデータなのかを把握した後、そのデータに適したアプリ(編集用アプリ、チェック用アプリ、取り込み用アプリなど)を、複数の業務アプリから自己判断で選んでアプリを起動していた。
【0017】
記帳関連データであれば記帳関連アプリ等へ、監査関連データであれば会計アプリ等へ、汎用アプリで作成された会計データであれば、汎用アプリで変換してから会計アプリ等へ、メーカー独自の会計アプリ(システム)のデータであれば、必要に応じて変換してから会計アプリ等へ、証憑画像であれば、OCR解析アプリ等から証憑関連アプリへと取り込んでいた。以上から分かる通り、顧問先から受信するデータを取り込む入口がバラバラで煩雑であった。
【0018】
受信したデータのチェックにチェック用アプリを使用したりするが、使用するチェック用アプリは1つとは限らず、データによっては複数のチェック用アプリを利用し、最初はチェック用アプリA、次はチェック用アプリB・・・など、順番通りにアプリを起動してチェックすることで、やっと1つのデータのチェックを終えることができるものもあった。
【0019】
前述の「適したアプリ」に関して補足すると、財務の業務は財務アプリ系(または財務システム、更に会計データ入力や帳表作成などの詳細な分類をアプリ化しているものもある)で、税務の業務は税務アプリ系(または税務システム、更に法人税申告や電子申告作成などの詳細な分類をアプリ化しているものもある)でと、それぞれの業務毎に独立したアプリを起動し、必要に応じて顧客ファイル管理アプリ(またはシステム)、業務進捗管理アプリ(またはシステム)、スケジュール管理アプリ(またはシステム)などで作業を行っていた。
【0020】
このように会計事務所では、複数の顧問先の様々なベンダのアプリで生成されたデータを、様々な方法で受信したことをキャッチアップ(認識)し、色々な方法でデータにエラーや不備がないことを確認し、重要度・優先度で作業順番を判断しながら、作業員に業務を割り振り(分担し)、データの取り込みの進捗確認をしながら、データ毎に適したアプリを起動させて、仕訳などの実際の作業を、顧問先毎に作業履歴を残しながら対応している。 また、このような作業を行うために、会計事務所内の環境を、顧問先が使用している様々なベンダのアプリに合わせている(アプリのインストール、バージョンアップなどのメンテナンスをしている)。
【0021】
一方、顧問先からは、顧問先サービスに対しての対応の正確さや早さの要求があるため、受信データの管理を簡易化する方法や、データを受信してから迅速に対応する方法、複数の顧問先から同時に依頼があった際に効率良く処理する方法、対応するための様々な操作を簡易化する方法、作業の履歴を効率よく行う方法、顧問先のサポート効率化が重要になっている。また、様々なベンダのアプリ管理も重要になっている。
【0022】
そして、顧客満足度アップや、他の会計事務所との比較でアドバンテージを出すことは、今もなお会計事務所における課題でもある。
会計事務所の人手不足、職員の退職による作業員のスキルによる作業ばらつきなど、課題も多い。
【0023】
それらの課題に対して、メッセージやデータの送受信管理システムを使用する方法や、顧問先毎に統一したメッセージを用意して、顧問先に提出する際のメッセージを添えることで、簡単に更なるアドバイスができるような効率的な手法を含めた、統合管理システムの改良などの技術を発展させてきた。
【0024】
しかし、今もなお、顧問先データの取り込みの入り口がバラバラであることや、アプリを起動するまでデータの受信が分からないことから、色々なアプリベンダを使い分けしている会計事務所の日常作業の中で、顧問先からのデータ受信に気付くのが遅れることがあり、人手に頼った確認方法は、非効率的である状況は変わらない。
【0025】
そのような問題を解決するために、受信データの管理を簡易化する方法として、アプリのデータを顧問先毎、年度毎、業務種別毎に管理する技術が開示されている(例えば、特許文献1参照)。
しかし、この技術では、顧問先毎に管理するため、その日に受信した複数の顧問先のデータを一括表示することができず、その日の業務量を見積もることや、複数の顧問先からの受信データを全て見並べて優先度をつけることができない課題がある。
【0026】
また、一連の作業に融通を持たすやり方を簡易的に管理する方法として、作業者がリストから選択することで、適切なワークフローでの作業が実施でき、かつその作業履歴を管理できる技術が開示されている(例えば、特許文献2参照)。
しかし、この技術では、作業者が作業に対して適切なワークフローを知っていることが前提のため、ワークフローの選択肢の数の多さ、複雑さと、作業者の熟練度によっては、リストから選択することが難しくなるという課題がある。
【0027】
また、ERP(Enterprise Resource Planning)パッケージという、例えば、代表的な承認ワークフローや決裁ワークフローなどを統合的に管理するシステムもあるが、その環境を維持したまま、EC(Electronic Commerce)メディアが提供するサービスを利用する技術が公開されている(例えば、特許文献3参照)。
しかし、この技術では、ERPパッケージ内での、1つのワークフローの管理に留まっているため、顧問先から受信したデータ毎に発生する、複数のワークフローに対応することができないという課題もある。
【0028】
さらに、様々なベンダのアプリの管理を容易にする方法として、指定日時に確実にアプリを稼働させる記述が開示されている(例えば、特許文献4参照)。
しかし、この技術では、作業者が起動するアプリを指定しなければならないため、受信したデータ形式に対応する様々なアプリを管理するには、作業者の管理システムがどのアプリのどのバージョンに対応しているかという知識が必要であり、容易に管理できないという課題もある。
【発明を実施するための形態】
【0048】
以下、本発明を実施するための形態について、図を参照しながら説明する。なお、これは、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。
以下、説明する実施例1〜6において、
図1−1の端末装置10、
図2−1の顧問先端末1(101)は、それぞれ記載が異なるが、同一の顧問先の端末装置のことを指し、
図1−1のサーバー装置20、
図2−1のサーバー装置2(201)は、それぞれ記載が異なるが、同一の会計事務所のサーバー装置のことを指し、
図1−1の端末装置21、
図2−1の会計事務所端末3(401)は、それぞれ記載が異なるが、同一の会計事務所の端末装置のことを指す。
【0049】
(実施例1)
以下に実施例1を記載するが、この実施例1によって本発明は限定されるものではない。
[全体構成]
図1−1は、本発明の実施例になるシステム全体の構成図である。
【0050】
図1−1に示すシステム構成は1例であり、図中の会計事務所のサーバー装置20は、サーバー装置20の機能を端末装置21と統合した端末装置に置き換えてもよい。
図2−1は、上記本発明のシステム全体における機能を示すブロック図である。
また、
図2−1は、会計事務所の会計事務所端末3と、複数の顧問先(例えば、顧問先A、顧問先B、・・・顧問先N)の内、一例として1つの顧問先のとした顧問先端末1と、会計事務所と顧問先の間で行われるデータのやり取りで中継されるサーバー装置2がネットワークで接続されたネットワークシステムの実施例でもある。
【0051】
図1−1では、顧問先−会計事務所間のシステムとして示しているが、企業の本社等が各部門や各支店(の従業員)等を対象に財務管理を行う場合には、顧問先−会計事務所を支店−本社間のシステムとしてもよい。
【0052】
図1−1の会計事務所の端末装置21は1台あるように記載しているが、複数台あってもよい。
図1−1の顧問先の端末装置10は、顧問先毎に1台あるように記載しているが、顧問先毎に複数台あってもよい。
また、会計事務所の端末装置21や顧問先の端末装置10は、デスクトップ型PCやノート型PCに限らず、スマートフォンやタブレット等の携帯端末でもよいし、実体が仮想化された仮想マシンでもよいし、必ずしも会計事務所内に設けられる必要はなく、外出先や自宅勤務の職員の端末装置や外注先の職員の端末装置でもよいし、端末装置が存在する場所を含め、その記載に限定されるものではない。
【0053】
図2−1のサーバー装置2は、
図1−1ではサーバー装置20として1台で示しているが、複数台であってもよい。また、
図2−1のサーバー装置2は、複数台を各地に点させてもよいし、業務委託等のサービスを行っている企業内に存在させてもよいし、クラウドサービスのようにデータセンターに存在させてもよいし、その記載に限定されるものではない。
【0054】
[システム構成:データの流れ]
図1−2は、本実施形態に係る会計処理システムのデータの流れを示す図である。
図1−2に示すシステム構成上のデータの流れは、顧問先が会計事務所に対し、様々なデータを1つのアプリで送信し、会計事務所内で取り込まれ、監査、財務帳表の作成を行い、電子申告や顧問先への帳表提出などの一連の流れを記したものである。
【0055】
図2−2は、上記本発明によって財務、税務業務を一体処理するメニューを示す図である。
図2−2に示すデータ連携は、受信したデータを財務処理業務501ないし税務処理業務502へ自由に行き来できるデータ連携を示すものであり、
図1−2の会計事務所内の処理(財務帳表作成の前後)の監査処理253や電子申告255に係るものである。
【0056】
[顧問先端末、会計事務所端末、サーバー装置のハードウェア]
図2−1は、本実施形態に係る装置の機能を示すのブロック図である。
図2−1に示す顧問先端末1、会計事務所端末3、サーバー装置2は、入力部、画像取込部、出力部(表示、印字)、通信部、制御部、記憶部の6つの機能を備える。これら6つの機能は、一般的なコンピュータの機能のため、詳細な説明は省略する。ただし、サーバー装置2に限っては、会計事務所端末3等から通信部を介して、サーバー装置2を操作する機能を備えた場合は、表示部を備えなくてもよい。
【0057】
[顧問先端末:顧問先]
図2−1の顧問先端末1には、様々なアプリがインストールされており、様々なアプリによって、様々なデータ形式のデータが生成される。
【0058】
従来は、顧問先(データを送る方)しか、データ形式、データ状況などを知らず、会計事務所は、顧問先とのメールやメッセージ、口頭などでの伝達によって、その情報を知ったあとでないと、作業が開始できないという状況だった。
【0059】
本実施例では、顧問先端末1でデータを生成した際、
図3−2のイベントログテーブルには、データを作成した目的が明確な場合はその目的をデータ状況、データ形式として記録されるほか、
図3−1のアプリ情報テーブルの情報を元に、どのアプリのどのバージョンで作成したものか等の情報も記録される。その他、顧問先がデータを送る際に、データ形式を指定するようにしてもよい。
イベントログテーブル(
図3−2)は、顧問先側(顧問先端末1)の他、会計事務所側(サーバー装置2)に存在する。 イベントログテーブルの項目は共通であるが、顧問先側のみ、または会計事務所側のみで記録される項目もある。
【0060】
イベントログ情報を効果として、会計事務所でデータをチェックする際のチェック専用アプリはなにか、なんの作業から開始すればよいか、データを取り込む際のアプリはなにかなど、が分かることに加え、データのチェックや取り込みの作業を自動化してもよい。
【0061】
例えば、顧問先が会計事務所に対してA銀行の入出金CSVファイルと指定して送信することで、会計事務所は、CSVファイルを選ぶだけで、A銀行の取込設定を利用して、銀行明細データの取り込みが実行され、さらに口座名義情報含めて、科目や補助も決定し、自動入力できるようにしてもよい。
また、同じCSVのデータ形式でも、A社の仕訳CSVであれば、会計データの取り込みをA社の設定で実行でき、資産データ一覧のデータ形式であれば、減価償却アプリへの取り込みが実行できる。
【0062】
顧問先の顧問先端末1(
図2−1)からサーバー装置2(
図2−1)又は会計事務所の会計事務所端末3(
図2−1)へ、データを送信する際、顧問先では、汎用性を持ったメーラーや、送信するデータ専用のアプリが持つデータ送受信機能等で送信することができる。
【0063】
本実施例では、
図1−2のように顧問先から会計事務所へ、送受信するための専用アプリを介して送信する。 送信されるデータは、顧問先にて様々なアプリで生成されたデータと、そのデータに関するイベントログ情報を一緒に送信する。 データに関するイベントログ情報とは、データの更新日時とイベントログテーブル(
図3−2)の日時情報とを照合して合致した情報である。
【0064】
[サーバー装置:会計事務所]
顧問先が会計事務所に送信したデータは、サーバー装置2(
図2−1)が受信する。本実施例では、受信はサーバー装置2(
図2−1)が行うものとして説明するが、会計事務所端末3(
図2−1)で受信してもよいし、その記載に限定されるものではない。
【0065】
サーバー装置2(
図2−1)は、顧問先から送信されたデータ(イベントログ情報を含む)を受信すると、顧問先にて様々なアプリで生成されたデータは、記憶部(
図2−1の203)にあるデータ記録部216へ記録し、受信したイベントログ情報(顧問先でデータを生成したときのアプリ名とアプリバージョン、データ形式など)は、会計事務所が受信した日時や受信したこと(データ状況)、受信データの名称、受信データの保存先、顧問先情報(商号コードや担当者等)等と共に記憶部(
図2−1の203)にあるイベントログ記録部218のイベントログテーブル(
図3−2)へ記録する。
【0066】
また、サーバー装置2(
図2−1)は、データを受信すると、受信したデータに問題ないかを自動でチェックする。具体的には、受信したデータのデータ形式に適した1以上のデータチェック専用アプリを作業員の操作なしで実行し、データが正常に読めるか、データをアプリに取り込む際に不足している箇所がないか、データ内の値に整合性が取れていない部分があるか(例えば、取引の税率が適切に軽減税率となっているかなどの会計処理の観点を含む)、取込済のデータと重複していないかなどの不備や異常を判定し、データに異常があった場合、受信データの記録と共に、軽度エラーや重度エラー等のエラー情報をイベントログテーブル(
図3−2)に記録する。
【0067】
また、データの不備など以外に、役員報酬が発生している月なのか、消耗品費だが10万円以上の取引がないかなど、取り扱いに対する注意が必要なデータを自動で判別し、警告してもよい。
【0068】
なお、データ内の値に整合性が取れていない部分があるかの判定項目に関しては、様々なチェック項目が考えられるが、本発明の本質とは異なるため、詳細な説明は省略する。
【0069】
また、サーバー装置2(
図2−1)は、データを受信すると、受信したデータの状況を判断する。
具体的には、受信したデータのイベントログ情報にデータ状況がある場合はその情報から、ない場合は、受信したデータと同じデータ形式の履歴のうち直近のデータ状況を、イベントログテーブル(
図3−2)から検出し、業務進行テーブル(
図3−3)に基づき、次のステップをデータ状況として判断する。
【0070】
業務進行テーブル(
図3−3)とは、記憶部(
図2−1の203)に存在する業務進行記録部219(
図2−1)に保存されており、データ形式ごとに行われる作業手順をテーブルにしたもので、例えば、データ形式が「伝票」の場合、「依頼受信→データ組込み→データ確認→修正確認→修正データ受信→データ確認済→監査→月次報告書作成→月次報告承認待ち→月次報告→報告完了」というステップ(
図3−3に図示せず)を記録しているものである。
業務進行テーブル(
図3−3)は、会計処理システムに既定値として持っているほか、作業員がテーブルを修正することや、新たなステップを追加することなどもできる。
【0071】
また、サーバー装置2(
図2−1)は、データを受信すると、受信したことを会計事務所端末3(
図2−1)(の作業員)に通知する。具体的には、サーバー装置2(
図2−1)から会計事務所端末3(
図2−1)に対し、いつ、どの顧問先から、何のデータが届いたか等の簡易情報を含んだパケットを送信する。
【0072】
[会計事務所端末:会計事務所]
会計事務所端末3(
図2−1)は、サーバー装置2(
図2−1)からデータを受信したという情報を通知するためのパケットを受信すると、アプリを立ち上げることなく、すぐに通知(画面に表示)する。
【0073】
作業員は、本発明である会計処理システムの管理コンソールを起動する。この管理コンソールでは、画面に、新規に受信したデータの他、まだアプリに取り込んでいない過去に受信したデータや送信したデータが一覧で表示される。 具体的には、送受信日時、顧問先名、データ名称、ファイルの種類を示すアイコン、データの簡易チェックでエラーした際のエラーアイコン、データの進捗状況、などを少なくとも1つを含むデータに関する情報を、サーバー装置2(
図2−1)から取得して一覧表示される。
【0074】
サーバー装置2(
図2−1)から様々な情報を取得する際に、会計事務所端末3(
図2−1)からサーバー装置2(
図2−1)に対し要求をするが、サーバー装置2(
図2−1)が、その情報を取り扱える作業者なのかを、会計事務所端末3(
図2−1)の名前情報や会計事務所端末3(
図2−1)にログインしたユーザー情報から判断して、取り扱える権限を持つ作業者(の会計事務所端末3(
図2−1))にのみ、データの要求に応じて様々な情報を会計事務所端末3(
図2−1)に送信する(アクセス権を与える)セキュリティ管理機能を、本発明に入れるか、別のシステムで用意するかして、様々な情報を、複雑なセキュリティ設定を行うことなく運用でき、機密保持も万全に利用できるようにしてもよい。
【0075】
また、上記セキュリティ管理機能のアクセス権において、作業員毎ではなく、複数の作業員を1グループとして、そのグループに対してアクセス権を与えたり、使用する会計事務所端末3(
図2−1)に対して(会計事務所端末3(
図2−1)にログイン出来るユーザーに対して)アクセス権を与えたりしてもよい。 なお、新たにグループへ追加された作業員も同グループのアクセス権を引き継げるようにしてもよい。
【0076】
データに関する情報には、その他に、顧問先の管理番号、顧問先の決算年月日、顧問先内の担当者、会計事務所内の担当者、顧問先の業種など、もあってもよい。
エラーアイコンの表示は、エラーの重症度、緊急対応度などにより、色分けや点滅などのアニメーションで視覚的効果を付してもよい。
なお、ファイルの種類を示すアイコンや、データの簡易チェックでエラーした際のエラーアイコンのアイコンは、作業員への通知手段の一例とした記載したものであり、アイコンに限定するものではなく、ポップアップ通知やエラー音通知、音声通知などの通知であってもよい。
【0077】
なお、この一覧表示は、条件を付することができる。例えば、管理コンソール内にプルダウンメニューを用意し、そのプルダウンメニューで一覧表示の条件を選択することで、条件に合致したデータのみを、すぐに表示できる。また、表示設定ボタン、およびその表示設定ボタンを押下することで別途表示される表示設定画面を用意して、一覧表示の詳細条件(商号コードの指定、対象期間、受信データのみ、送信データのみ、組込み済みデータを含めた全送受信データなど)を指定したり、データに関する情報の要素を取捨選択したりして、表示する情報を細かく設定することができる。
【0078】
管理コンソールでは、一覧表示されたデータの1つを選択して、そのデータの詳細情報を表示すると共に、そのデータを受信した後の作業を行う為の操作ボタンを用意する。具体的には、受信したデータを編集するための操作ボタンを1つ、受信したデータを取り込むための操作ボタンを1つ、受信したデータが簡易チェックでエラーした場合は、そのデータに適したチェック用アプリを1ないし複数起動させるための操作ボタンを1つ用意する。
【0079】
従来、作業員は、受信データに対して、そのデータに適した編集用アプリ、チェック用アプリ、取り込み用アプリを、複数の業務アプリから選択して起動していたが、本発明では、選択する手間を省くため、1つのボタン操作で作業に適したアプリを選択することができるように改良した。
【0080】
図2−2は、財務、税務業務を一体処理する統合メニューの機能を説明する図である。
本発明で、1つのボタンで作業を開始すると、その先の取り込みから監査、帳表作成、決算・申告処理、電子申告まで、会計事務所における一連の実務を、財務・税務のデータ連携や連動により、財務と税務の一体処理を可能とする。関連するアプリないしシステムを自由に行き来できることで、突き付けが必要なデータの参照・確認なども手際よく行え、会計事務所の実務を総合的に効率することができる。
【0081】
その他、データの詳細情報を表示する際に、別の管理システムへ切り替えるための操作ボタンを用意してもよい。具体的には、本発明である会計処理システムは、データを一元管理するシステムであるため、複数の顧問先のデータを一元的に表示できる一方、顧問先毎の管理においては、情報が多いことから、顧問先毎に管理できるシステムを使用した方が便利な時もあり、そのシステムへの切り替えをスムーズに行うために、プルダウンメニューで複数ある会計処理システムを選択した後、1つの操作ボタンを押下することで、管理システムの切り替えを行う。
【0082】
会計処理システムを切り替える方法として記載したプルダウンメニューは、プルダウンメニューに限定するものではなく、スワイプ等のジェスチャー操作やキーボードのファンクションキーの割り当てによる入力、音声入力などでもよいし、その記載に限定されるものではない。
【0083】
(実施例2)
以下に実施例2を記載するが、この実施例2によって本発明は限定されるものではない。
(1) データを送る方(顧問先)で、データの種類を指定して送ることで、データを取り込む方(会計事務所)で取り込みの機能や種類等を指定しなくてすむようにしてもよい。
従来は送る方しか知らない情報を、メール本文や口頭などで伝達し、その情報を元に事務所の担当が処理システムを選択していた。例えば、顧問先が「A銀行」の「入出金CSV」と指定してデータを会計事務所へ送信することで、会計事務所側はその受信したデータを選び、作業を開始すると、起動A銀行の取込設定がされた状態で銀行明細取込アプリが起動できる。口座名義もあれば科目や補助も決定ができる。同様に、同じCSVでも、「A社」の「仕訳CSV」と指定して送信した場合は、他社会計データ取込アプリをA社の設定でアプリが起動でき、「資産データの一覧」と指定して送信した場合は、減価償却システムが起動(取込)できる。
【0084】
(2)イベントログ情報を元に、顧問先毎にデータ状況を表示・管理してもよい。
例えば、顧問先単位の情報として、データが来ている状況や、会計データにエラーがある状況、電子申告データを作成済みの状況などを表示させることで、顧問先のデータ管理を容易にすることができる。
【0085】
(3)会計事務所で今まさに処理しようとしている機能と、データの状況とを突きあわせ、現在のワークフローの段階において、重要となる情報を強調して表示、または絞って表示してもよい。
例えば、会計データを入力する時であれば、顧問先からのデータ受信の情報(値など)を会計データのエラー箇所より優先させて強調表示するようにしてもよい。
また例えば、個々の申告書データにエラーがある場合には、複数の申告書間に対するエラーチェックの結果表示はまだ省略し、それぞれの申告書に対するエラーのみを表示するようにしてもよい。
また例えば、電子申告データを作成しようとした場合には、各種エラー結果を強調表示するようにしてもよい。
【0086】
(4)データ状況の変更をきっかけに各種処理を自動実行してもよい。
例えば、顧問先からの受信データがなくなったら(全ての受信データを会計データDBに取り込みができたら)、会計データの自動チェックするようにしてもよい。
また例えば、電子申告をするための申告書の全てのデータにエラーがなくなったら、電子申告用のデータを自動作成するようにしてもよいし、顧問先へ署名を頂くための連絡をするように促すようにしてもよい。
【0087】
(実施例3)
以下に実施例3を記載するが、この実施例3によって本発明は限定されるものではない。
【0088】
[全体構成]
図1−1は、本実施形態に係る会計処理全体のシステム構成を示す図である。
図1−1に示すシステム構成は、会計事務所の会計事務所端末(端末装置21)と、複数の顧問先の顧問先端末(端末装置10)と、会計事務所と顧問先の間で行われるデータのやり取りで中継されるサーバー装置20がネットワーク(300、301)で接続されたネットワークシステム例である。
【0089】
サーバー装置20(
図1−1)は、サーバー装置20の機能を統合した端末装置(端末装置21(
図1−1)と同じハードウェア)に置き換えてもよいし、別途用意された装置上に仮想化されたサーバーでもよいし、サーバー装置20を経由せずに顧問先の端末装置10(
図1−1)から直接、会計事務所のサーバー装置20の機能を統合した端末装置21(
図1−1)に接続されたネットワークシステムでもよい。
サーバー装置20の台数において、
図1−1ではサーバー装置20として1台ずつで示しているが、複数台であってもよい。
サーバー装置20の設置場所は、会計事務所内に設置することに限らず、複数台を1ヶ所に設置せずに各地に点在させてもよいし、業務委託等のサービスを行っている企業内に存在してもよいし、クラウドサービスのようにデータセンターに存在してもよく、この記載に限定されるものではない。
端末装置(10,21)は、デスクトップ型PCやノート型PCに限らず、スマートフォンやタブレット等の携帯端末でもよいし、実体が仮想化された仮想マシンでもよい。
端末装置(10,21)の台数において、
図1−1では顧問先の端末装置10および会計事務所の端末装置21をそれぞれ1台ずつで示しているが、それぞれに複数台であってもよい。
端末装置(10,21)の設置位置において、必ずしも顧問先内や会計事務所内に設けられる必要はなく、外出先や自宅勤務の職員の端末装置、外注先の職員の端末装置でもよく、端末装置が存在する場所を含め、この記載に限定されるものではない。
また、
図1−1では、顧問先−会計事務所間のシステムとして示しているが、企業の本社等が各支部や各支店、各支社(の従業員)等を対象に財務管理を行う場合には、支社等−本社間のシステムとしてもよい。
【0090】
[システム構成:データの流れ]
図1−2は、本実施形態に係る会計処理システムのデータの流れを示す図であり、本発明は、このデータの流れをスムーズに処理できるように、顧問先と会計事務所との関係強化、および業務負担の軽減、そして会計事務所におけるワークフローの確立を支援、実現するシステム(装置)である。
図1−2に示すシステム構成上のデータの流れは、顧問先100は会計事務所200に対して、他社データCSV152(他社アプリで作成された汎用データでTEXT形式やXML形式、CSV形式など)や領収書等153、通帳/カード明細154、銀行カード/クレジットカード155、顧問先による記帳データ157、その他156の様々な種類のデータを様々な顧問先アプリケーション150からあらゆる情報の受け渡し方法で、インターネット300(通信回線)を介して送信(350)する。会計事務所では、データ受領の統一された会計事務所の入り口である会計事務所アプリケーション250によって受信し、端末251によってデータが取り込まれ252、財務システムなどのデータチェック機能の活用256をしながら、監査253、財務帳表作成254を行い、関連資料を自動収集して電子申告255をしたり、様々な形式の資料(決算報告書や帳表等)を一つの操作で出力・一括印刷(出力指示の統一)したり、顧問先100(または端末151)へメールや転送ツールなどで帳表を提出し(257、351、352)、顧問先100で仕訳や元帳の表示158をして正しい帳簿の参照確認をするなどの一連の業務の流れを記したものである。 この会計事務所内のデータの流れは、本発明である会計処理システム(
図1−2の200の中の統合メニューの機能(ポータルサイト))の支援によって、シームレスな一筆書きのワークフローを実現する。
なお、顧問先100と会計事務所200との間のデータのやり取りおいて、インターネットを介す方法以外に、USBメモリ等のメディアによるやり取りや、顧問先の端末151と会計事務所の端末251とが無線や有線などで直接接続して行うデータのやり取り、請求書やレシート等の紙媒体で受理するやり取りなどもあるが、この記載に限定されるのもではない。
【0091】
そこで実施例の詳細を説明する前に、
アプリ毎にアプリ起動時にデータの有無を確認し、取込処理を実行するものであったものを、
本発明の実施例のポイントとして、
図5−2の表示画面において、
1.アプリ起動しなくてもデータの有無を
図5−2で確認可能となり、データの状態(金額相違や未決定勘定科目データチェックやバランスチェックや入力漏れ等の各種チェック結果、エラー状態
や
図5−1で確認できる、顧問先からのデータ受信、監査依頼や監査状況)等の情報(通知)を表示(データを選択した場合は連動して該当アプリを起動)、
2.選択したデータや重要度を加味して、必要な情報が把握しやすいような表示
3.
図5−2において、アプリ起動前にデータの状態を確認してデータの取り込み、データのエラーの確認、再チェックやエラー内容(読み取れない画像データがある等)の確認や通知等を行う
4.
図5−2において、通知履歴の管理(履歴の一覧表示等)
5.
図5−1において、対象データと関連するデータ(財務と税務と画像)の対応関係をわかりやすく表示(電子申告システムや法人申告統合システム等)
6.
図5−2において、ユーザーが行ったオペレーション(ジョブ記録)と顧問先からの受信データとチェック結果を関連付けたデータ管理
7.
図5−1、
図5−2において、対象データと関連するデータを資料の用途に応じた一括管理及び出力(印刷、電子帳表、データ出力、顧問先へデータ送信)設定
8.受信した画像データを仕訳データに変換
9.
図2−2において対象データと電子申告に関する情報(処理年、納税先、署名や納税者等)を関連付けて一括管理
10.対象データと使用アプリを管理(ロックして他のアプリからは編集不可)
することが可能になる。
【0092】
[顧問先端末、会計事務所端末、サーバー装置のハードウェア構成]
図2−1は、本実施形態に係る装置の機能を示すブロック図である。
図2−1に示す顧問先端末1、サーバー装置2、会計事務所端末3は、コンピューターシステムの制御部(102,202,402)、入力部(104、204、404)、出力部(106、206、406)、記憶部(103,203,403)、画像取込部(105、205、405)から構成され、本実施形態に係る顧問先と会計事務所のデータ等の処理を、通信部(107,207,407)を通してやり取りを行うためのブロック図例である。
なお、サーバー装置2と会計事務所端末3とを統合した装置と顧問先端末1とが直接接続される構成であってもよい。
【0093】
[顧問先]
図2−1の101は顧問先を示す。
顧問先端末1では、証憑データを処理するためや、記帳入力(帳簿入力)を行うため、決算するためなどの会計データが、様々なアプリを利用して様々なデータ形式で生成され、データ記録部111に記録されると共に、管理番号の会計データIDを生成し、会計データに関するイベントログ情報(例えば、データ形式やデータ状況(例えば、会計事務所送信前など)、顧問先名、顧問先担当者名など)と、アプリケーション情報管理記録部112に記録されているアプリケーション情報テーブル(
図3−1)から取得した会計データを生成したアプリに関する情報(例えば、アプリ名、バージョン、リリース日など)を、会計データID(図示せず)に紐付けてイベントログ記録部113のイベントログテーブル(
図3−2)へ記録する。
なお、アプリケーション情報管理記録部112に記録されているアプリケーション情報テーブル(
図3−1)は、アプリのインストール時、バージョンアップ時、アンインストール時などのイベントや、手動要求/遠隔操作要求/曜日指定等による定期的な要求などのアプリ情報を意図的に記録するための要求(メンテナンスなどを考慮した要求)をきっかけに、管理番号のアプリID(図示せず)を基準としたテーブルへ、アプリ名、アプリバージョン、ファイル拡張子、データ形式、ファイル名に含まれる識別文字列、リリース日(図示せず)、ベンダ名(図示せず)、インストール日(図示せず)、バージョンアップ日(図示せず)などの情報が記録される。
顧問先が会計事務所へデータを送信する際、顧問先端末1(
図2−1)は、データ送受信部110によって、データ記録部111から会計データを取得すると共に、イベントログ記録部113から会計データに付随する会計データIDを検索キーとして、直近のイベントログ情報(会計データ生成時のアプリ情報を含む)を取得し、それらを合わせて、通信部107へ引き渡し、会計事務所へ送信する。
このイベントログ情報を合わせて送信することにより、従来、会計事務所の作業者が、顧問先から受信した会計データを処理する前に行っていた、顧問先とのメールや電話(口頭)などで会計データに関する情報を入手する作業が不要となり、かつ本システムで会計データの処理の開始をスムーズに支援することができるようになる。 さらには、会計データに対するチェックや取り込みの作業を自動化することも可能となる。
イベントログテーブル(
図3−2)のうち、直近のイベントログ情報と送信する考えは、イベントログを記録し続けると、イベントログテーブルのデータサイズが大きくなってしまうため、送信データも肥大化することを考慮したもので、具体的には、例えば、会計データIDで検索した結果に対し、さらに送信する会計データの更新日時とイベントログテーブルの日時情報とを照合して、合致した情報のみを、イベントログ情報としてデータと一緒に送信する手法もある。
このイベントログは、
図5−2の527の履歴で確認できる。
会計データのイベントログ情報を使わずに、例えば、顧問先が会計事務所に対してデータを送信する際に、顧問先アプリケーション(
図1−2の150)上で、「A銀行」の「入出金」の「CSV(ファイル)」と指定して送信する方法でもよい。 その方法によって、会計事務所側でデータを受信した際に、受信した会計データを選ぶだけで、A銀行の取込設定が自動選択され、銀行明細データの取り込みがスムーズに実行でき、さらに口座名義情報を含めて、科目や補助も自動で判断し、自動入力することも可能となる。
また、同じ「CSV」のデータ形式でも、A社製の会計データ入力アプリで作成された会計データであれば、会計事務所側で会計データの取り込みを自動でA社の設定で実行することも可能となる。
その他、同じ「CSV」のデータ形式でも、資産データ入力アプリで作成された会計データであれば、会計事務所側で減価償却アプリへの自動取り込みなどをすることも可能となる。
【0094】
[会計事務所]
図2−1の201ないし401は、会計事務所を示す。
顧問先端末1から会計事務所へ、サーバー装置2が、通信部207を介してデータ送受信部210でデータを受信する。
なお、サーバー装置2の制御部202および記憶部203の機能を、会計事務所端末3に統合させることで、サーバー装置2を利用せずに、会計事務所端末3が直接、顧問先端末1から送信されたデータを受信することも可能である。 以降の説明ではサーバー装置2を用いた説明をするが、前述と同様に、サーバー装置2の機能を会計事務所端末3に持たせ、サーバー装置2を介さない構成としてもよい。
【0095】
受信したデータ内の会計データは、今まで受信した会計データの追番(管理番号)である会計データIDとともに記憶部(
図2−1の203)のデータ記録部216へ、受信したデータ内のイベントログ情報(会計データのアプリ情報を含む)は、会計データIDと紐付けて記憶部(
図2−1の203)のイベントログ記録部218のイベントログテーブル(
図3−2)へ記録される。さらに、イベントログ情報として、受信日時、受信したこと、受信データの名称、受信データの保存先、受信データの数、受信データ形式、どんなデータ(決算書作成依頼や監査依頼など)を受信したか、何のために送信されたのか、相手先情報(商号コードや担当者等)、会計事務所の作業員に受信したことを知らせる通知を出したか等の履歴も記録される。
【0096】
そして、データ受信認識部211(
図2−1)が、会計データを受信したことを認識すると、データ受信通知部215が、通信部(207、407)を介して、会計事務所端末3に会計データを受信した旨の通知を行い、会計事務所端末3では、データ新着表示部410が出力部406の画面やスピーカー(図示せず)等で、作業員へ迅速に会計データを受信したことを通知する。
【0097】
データが受信されたことを認識した作業員(会計事務所)は、会計事務所端末3(
図2−1)より、本システムの統合画面(詳細表示)(
図5−2)を起動させて、受信した会計データの確認や次の作業などを行う。
本システムである統合画面(詳細表示)(
図5−2の520)には、新着の会計データと既に受信済みの会計データの両方に対して、表示条件に合致した会計データとその会計データに関する様々な情報とを合わせて、受信データ一括表示部411(
図2−1)が出力部406(画面)(
図2−1)に表示する(
図5−2の526)。 その他、データアイコン表示部415(
図2−1)よりアイコンでデータ形式(データの種類)や状況の情報(
図5−2の526)、データ状況表示部414(
図2−1)より会計データの状況(ファイル)の情報(
図5−2の523)、会計データを受信した時などをきっかけに動作するデータ異常判断部212(
図2−1)より会計データに異常があった場合に、異常データ確認開始ボタン表示部417(
図2−1)次の操作(作業)のボタン(エラー通知524)、データ編集ボタン表示部420(
図2−1)とデータ編集部421(
図2−1)より、データを編集するためのアプリを起動するボタン(処理525)、取込開始ボタン表示部418(
図2−1)とデータ取り込み部419(
図2−1)よりデータを会計データDB(
図2−1に図示せず)への取り込みを操作するボタン(データ取込528)という、情報の表示と次の操作を開始する手段の提供をする。 さらに、会計データのファイル種類521、会計データの顧問先情報522、受信データなどの履歴を見るための手段(履歴(ボタン)527)を、統合画面(詳細表示)520で提供する。
この統合画面(詳細表示)520の画面操作を終了するためのキャンセル(ボタン)529もあり、押下されると、次に統合画面(データ一覧表示)(
図5−1の510)が表示される。
【0098】
統合画面(データ一覧表示)510内には、データ異常判断部212(
図2−1)より会計データに異常があったと判断されたデータに対する通知(視覚効果)や、データ重要度表示部413(
図2−1)より会計データがどれだけ重要なものであるかの通知(視覚効果)を、受信データ一括表示部(
図5−1の514)で表示する。 また、メイン画面選択416(
図2−1)より本システムと連動した様々なシステムへの切替選択手段(
図5−1や
図5−2に図示せず)を提供する。 統合画面(データ一覧表示)510には、その他の表示、操作ボタンがあるが、後で説明する。
以上、ブロック図(
図2−1)のブロックにより、上述した統合画面(510、520)で受信した会計データに対する状況・情報を容易に把握でき、そして次の作業へのスムーズな開始を支援するための操作が提供できる。
【0099】
図2−2は、受信した会計データ(決算データ)に対して、申告書類を作成する(電子申告507)までのアプローチの業務概要を示す。
具体的には、財務アプリまたはシステム(財務501)や税務アプリまたはシステム(税務502)を必要に応じて切り替えながら、資料作成(監査/帳表作成503、申告書作成504)やチェックを行い、電子申告に必要な資料を、財務501および税務502のそれぞれから収集(データ収集(505、506))し、電子申告形式データ作成508を行い、電子申告517を行う流れである。
本システムでは、財務501と税務502を自由に行き来できているかのように切り替えをスムーズに行えるような操作性を提供し、また、財務501においては、顧問先データの活用によりデータ入力なしに監査/帳表作成およびデータ収集ができ、税務502においては、関連データの連動で速やかに申告書作成およびデータ収集ができ、最終的に電子申告を手際よく申請することができることから、一連の処理を効率よく実行500できる。 このような本システムの支援によって、会計事務所が顧問先に対して、新サービスを創出したり、顧客開拓に投資したりできるような余力の創出509ができること(効果)を、
図2−2で概要的に示す。
【0100】
図3−1は、アプリケーション情報テーブルであり、アプリケーション情報管理記録部(112、217)(
図2−1)に記録される。 前述の通り、会計データを生成した時に、どのアプリで生成したかなどの情報を記録するためのテーブルであり、顧問先−会計事務所間で会計データをやり取りする際に付加し、相互の連携を潤滑にする。 具体的には、アプリ毎に管理番号であるアプリID(図示せず)を割り振り、アプリIDをキーとして、アプリ名、アプリVer、ファイル拡張子、データ形式、ファイル名に含まれる識別文字列、自端末への対応、非対応理由、非対応時の通知、商号コード(顧問先を特定するための情報)などの項目が記録される。 なお、項目「データ形式」については、アプリケーション情報テーブル(
図3−1)の他、後述するイベントログテーブル(
図3−2)と業務進行テーブル(
図3−3)にも共通する項目である。 この項目「データ形式」は、データをどのアプリで編集・チェック・取り込みをするかを判断するための要素の一つであり、項目の値として、アプリ特有のファイル拡張子や該当アプリ名などが記録される。
【0101】
図3−2は、イベントログテーブルであり、イベントログ記録部(113、218)(
図2−1)に記録される。
イベントログとは、会計データに対して操作(オペレーション)を行った際に、イベントが発生した事項で、その操作履歴や結果、会計データに関する付加情報などを記録する。
例えば、データをいつ、だれが(顧問先担当者や会計事務所作業員)、どこで(顧問先名や会計事務所名)、どのアプリで、何をしたか(開いた、データ一部を保存した、追記した、一部を削除した、エラーチェックを実施してエラーを検出したなど)、更に人の手を介さずバックグラウンドで自動チェックした際にエラーを検出した結果など、データに対する変化や操作、結果などを記録したものである。
会計データに対する次の作業をシステムが支援したり、業務進捗を把握したり、いつ・誰が・どのように編集を行ったかなどの5W1Hに基づいた作業履歴を後から確認したりを可能にする。
具体的には、顧問先からのデータ受信時、顧問先へのデータ送信時、会計事務所内での受信データの取込時、「会計データ入力、次期繰越、会計ファイル編集、仕訳データ合併、残データ合併、業種区分変更、決算年月日変更、財務ファイル管理、公開データ管理、在宅入力の会計ファイル変換、OCR 連携システムなど」での会計ファイル登録時、期首残高のバランスエラー、月別開始残高のバランスエラー、科目未決定勘定の使用、諸口バランスエラーなどの各種エラーをチェックするための法人税申告書などの申告書作成アプリ終了時に行うチェック実行時、チェックリストに基づいた法人申告、減価償却、勘定科目内訳などのチェックアプリでの金額相違チェック実行時、電子申告、事業概況説明などの形式チェック実行時、アプリ終了時に、会計データや電子申告データ形式などの自動チェックが実行された時などに、イベントログテーブル(
図3−2)に対して、いつ(年月日、時刻)、だれが(自社情報2=作業員など)、どの端末で(自社情報1=端末名)、だれの何のデータを(相手先情報1=顧問先名、相手先情報2=顧問先担当者名、データ名称、データ状況など)、どのアプリでまたはどのシステムで(データ形式)、結果などのどうしたか(イベント内容)などを記録する。
例えば、データを受信した際は、受信した会計データ毎に管理番号である会計データID(図示せず)を割り振り、会計データIDをキーとして、イベントが発生した年月日、時刻、イベント内容、追加情報1〜N(例えば、顧問先Aや顧問先Cなどの顧問先情報や、チェッカー1 Ver.1.3などの使用アプリ情報、などの関連情報)、データ名称、データ保存先(例えば、絶対パスや相対パス、どのサーバーなど)、データ形式(例えば、会計データ、帳表、電子申告などのどのようなデータなのかを把握するための情報)、データ状況(例えば、新規受信(図示せず)、保存済み、送信済み、送信取消、編集中(図示せず)、未取込(図示せず)、修正依頼中(図示せず)などの会計データの進捗情報)、相手先情報1〜N(例えば、顧問先Aや顧問先Cなどの顧問先情報、XさんやYさんなどの顧問先担当者情報、顧問先が送信する際に付加したアプリ名やアプリバージョンなどのアプリ情報(図示せず)、などの送信元や受信データに関する情報)、自社情報1〜N(例えば、マシン1やマシン3などの作業PC情報、AさんやCさんなどの作業者名、AグループやCグループなどの作業グループ名(図示せず)、などの会計事務所内で会計データを取り扱う際に関連する情報)の項目が記録される。イベントログテーブル(
図3−2)のデータ形式の値について、前述したアプリケーション情報テーブル(
図3−1)と後述する業務進行テーブル(
図3−3)の項目の値として記載されている内容とは異なるが、イベントログテーブル(
図3−2)も含め、3つの図(テーブル)のデータ形式の記載内容は共通する。
なお、イベントログテーブルに記録される項目に関して、この記載に限定されるものではない。
【0102】
図3−3は、業務進行テーブルであり、業務進行記録部219(
図2−1)に記録される。 単純な操作で次の作業に移れるように支援するための情報であり、様々な業務におけるフローをまとめたテーブルである。
具体的には、業務の種類毎に管理番号である業務フローIDを割り振り、業務フローIDをキーとして、データ形式、ステップ1〜N(例えば、依頼受信、データ確認、データ取込、帳表作成・監査、申告書作成、電子申告所準備、提出、などの項目が記録される。 業務進行テーブル(
図3−3)のデータ形式の値について、前述したアプリケーション情報テーブル(
図3−1)とイベントログテーブル(
図3−2)の項目の値として記載されている内容とは異なるが、業務進行テーブル(
図3−3)も含め、3つの図(テーブル)のデータ形式の記載内容は共通する。 業務進行テーブル(
図3−3)のステップ1〜Nの値について、前述したイベントログテーブル(
図3−2)のデータ状況の値と共通する。
【0103】
図5−1(統合画面(データ一覧表示))、
図5−2(統合画面(詳細表示))は、実際の操作画面の表示例であるが、その記載に限定されるものではない。
図6は、本システムのフローチャートである。 会計事務所が顧問先からデータを受信してからの具体的な作業の流れに沿って、
図6(S6−1の開始から)、
図5−1、
図5−2について、より詳細に説明する。
【0104】
[サーバー装置]
顧問先端末1(
図2−1)から会計事務所に送信されたデータは、サーバー装置2(
図2−1)が会計事務所アプリケーション(
図1−2の250)で受信する(
図6のS6−2)。
会計事務所が受信するデータは、例えば、電子化されたレシートデータ、通帳データ、入出金明細データ、記帳データ、監査データ、会計データ(密な連動可能)、会計データ(連動が可能または連動できない他社データ)などがあげられるあるが、これらの記載に限定されるものではない。
顧問先から会計事務所へ送信されるデータは、顧問先毎に種類、形式などが異なる。 本システムに連動する顧問先アプリケーション(
図1−2の150)を使用せず、汎用性を持ったメーラーや、送信するデータの専用アプリによるデータ送受信機能等で送信することもある。 その場合、会計事務所側では、顧問先と同一または互換性を持つアプリでデータを受信する必要があるが、本システムである会計事務所アプリ(
図1−2の250)では、顧問先と同一または互換性を持つアプリと連動し、会計事務所アプリ(
図1−2の250)が受信する。
なお、サーバー装置2(
図2−1)と会計事務所端末3とを統合してもよく、その装置が顧問先端末1からデータを受信してもよい。
【0105】
サーバー装置2(
図2−1)が受信したデータは、受信した順に管理番号の会計データIDが割り振られ、一括管理され(
図6のS6−3)、記憶部203(
図2−1)のデータ記録部216やイベントログ記録部218などへ記録される(
図6のS6−4)。
【0106】
ここで、顧問先からデータを受信したことを、会計事務所の職員(先生や作業員)に対し、使用端末装置(会計事務所端末3)に対し、いつ、どの顧問先から、何のデータが届いたか等の簡易情報を、即時通知してもよい(
図6に図示せず)。 なお、通知方法は、ポップアップやトースト通知等で画面にしたり、音や音声で通知したり、通信機能を使って別のモバイルデバイスへメール等で通知するなどの方法があるが、これに限らない。
【0107】
また、受信したデータのアプリ名やデータ形式などの情報を元に、自動でデータの分析、チェックをしてもよい(
図6のS6−5)。
具体的には、データの分析として、データの種類(分類)は何か(電子化されたレシートデータ、通帳データ、入出金明細データ、記帳データ、監査データ、会計データ(密な連動可能)、会計データ(連動が可能または連動できない他社データなど))、会計データの状態(作業内容)(新規受信、修正依頼中など)、重要度(優先度)の割り振り(詳細は後述)などを認識して、その分析結果をイベントログテーブルに記録(
図6のS6−4)してもよいし、さらにそれらの情報を履歴(
図5−2の527)で確認できるようにしてもよい。
また、データのチェックとして、受信したデータのデータ形式に適した1以上のデータチェック専用アプリを、作業員の操作なしで自動実行し、データが正常に読めるか、データをアプリに取り込む際に不足している情報や不備がないか、データ内の値に整合性が取れていない部分があるか(例えば、取引の税率が適切に軽減税率となっているかなどの会計処理の観点を含む)、取り込み済みのデータと重複していないか、AIなどによる解析で、過去の摘要の傾向から軽減税率適用の可能性がある取引に対して、標準税率しか入力されていないかなどの適用税率のチェックなどの異常がないかなどを、自動チェックして、もしデータに異常があった場合は軽度エラーや重度エラー等のエラー情報を含め、チェック結果をイベントログテーブルに記録(
図6のS6−4)してもよいし、さらにそれらの情報を履歴(
図5−2の527)で確認できるようにしてもよい。なお、データ内の値に整合性が取れていない部分があるかなどの判定手法に関しては、様々な手法があるが、本発明の本質とは異なるため、詳細な説明は省略する。
また、データを取り扱うことができるかどうかのチェックとして、データを受信した際に、データ送受信部(
図2−1の210)で分別したアプリ情報(データ生成時のアプリ名、アプリバージョンなど)をアプリケーション情報管理記録部(
図2−1の217)に記録するが、そのアプリ情報と、会計事務所側のアプリ情報(取り扱うことができるシステム/アプリ)(記録先、記録部は図示せず)とをデータ異常判断部(
図2−1の212)で比較してもよい。さらにデータ異常判断部212は、その結果をアプリケーション情報テーブル(
図3−1)ないしイベントログテーブル(
図3−2)に記録し、会計事務所側にアプリが存在しない場合(アプリ非互換)や、アプリは存在するが受信データ生成時のアプリバージョンの方が会計事務所側よりも新しい場合(旧バージョン)など、会計事務所側でデータを取り扱うことができない場合(非対応の場合)に、エラーとしてイベントログ記録部(
図2−1の218)のイベントログテーブル(
図3−2)へ、自端末への対応として「非対応」、非対応理由として例えば「旧バージョン」などと記録すると共に、会計事務所端末3(
図2−1の401)へ通信部(
図2−1の207、407)を介して通知し、データ異常表示部(
図2−1の412)より、会計事務所の作業員などに対して警告表示してもよい。
なお、データ受信時に自動でデータの分析やチェックをする場合は、機械的な判断となるため、どうしても単純なデータ分析、チェックしかできない。 しかし、自動分析・チェックでエラーを検出した場合に、即時、別手法で画面にエラー通知し、作業員がすぐに気付き、顧問先へ問い合わせるなどの迅速な対応ができるようにしてもよい。
【0108】
会計事務所の職員(先生や作業員)は、データ受信通知を受け(または知らずとも通常業務として)、本発明である会計処理システム(ポータルサイト)を手動で起動し、統合画面(詳細表示)(
図5−2の520)が表示される(
図6のS6−7およびS6−6)。
この統合画面(詳細表示)520には、受信したデータの、業務フロー上のどこまで進んでいるかなどの情報を含むイベントログ情報を元に、まだ会計データDBに取り込んでいない受信したデータのファイル名、受信日時などを一覧表示526する他、一覧表示されたデータを選択することでそのデータの顧問先情報522(例えば、商号コード、商号名、決算年月日、顧問先会社の担当者名、住所、どのような案件なのか、最初にデータを受信した日付などの情報)、ファイルの種類521(データ形式)、ファイルの状況523、次の作業を支援するための操作ボタンである処理525(作業関連の操作ボタン)、データ取込528(作業関連の操作ボタン)、エラー通知524(作業関連の操作ボタン)、一覧表示されたデータに関する履歴を表示するための履歴527(操作ボタン)、総合画面(詳細表示)520を終了させるためのキャンセル529(操作ボタン)を表示する(
図6のS6−7およびS6−6)。また、エラーチェック等でエラーを検出したデータや期限間近なデータなど、注意すべきデータが存在する場合は、警告の表示を表示する(図示せず)。以上より、注目させたい会計データDBなどのデータ一覧や状況などの情報と、次の作業の入り口を集約した操作ボタンを1つの画面(
図6のS6−7およびS6−6)で提供し、円滑な業務進行を支援する。
商号名は顧問先の企業名であり、商号コードは、会計事務所が顧問先を管理するために任意につける管理番号である。
【0109】
なお、顧問先情報522の表示に関しては、本会計処理システムと連携している顧客管理システムなどから情報を取得して、より詳細な顧問先情報を表示してもよい。
【0110】
この画面の他に、注意すべきデータの認知性を向上させるために、警告表示があるデータのみを一括表示する画面を別に用意してもよい(図示せず)。 この時、会計データDBへ取り込んでいないという条件をなくして一括表示するようにしてもよい。
【0111】
この統合画面(詳細表示)520では、何通りもあるデータ処理の作業を、3つの作業(チェック 、編集、取込)に分類分けし、それぞれの分類(作業)に対して、開始するための操作ボタンを、処理ボタン525、エラー通知ボタン524、データ取込ボタン528と、1つずつ用意している。 その操作ボタンを作業の入り口として、操作対象のデータに対して、顧問先が送信する際に付加したデータの種類や状況などのデータに関するイベントログ情報を元に、データ処理に最適な1ないし複数のアプリを自動選択して起動するため、複雑な業務フローの入り口が簡素化され、作業者の知識レベル、熟練度等に関係なく、スムーズな作業開始を支援することができる。
具体的には、一覧表示された受信データ526の内、1つのデータ(例えば、伝票1のデータ形式のデータ)を選択し、操作ボタン(処理525・エラー通知524・取込528)を押下すると、データ状況判断部213(
図2−1)が、選択されたデータの会計データIDより、イベントログテーブル(
図3−2)のデータ形式とデータ状況の情報を取得する。 取得した情報のうち、データ形式を業務進行テーブルのキーとして照合して、データの業務フローを特定し、その業務フロー内のステップとデータ状況とが合致したステップを検出する(例えば、業務フローID1のステップ4:帳表作成)。 そして、その次のステップに記載された値(例えば、申告書作成)をキーとして、アプリケーション情報テーブル(
図3−1)に記録されている起動トリガ(項目)(
図3−1に図示せず)と合致したアプリケーションを起動すると共に、イベントログテーブル(
図3−2)に、会計データIDをキーとして、アプリの起動トリガとなったキー(この場合、申告書作成)をデータ状況に記録する。 このようにすることで、操作ボタンを押下する度に、そのデータの作業を行う上で適切なアプリが起動される。
処理ボタン525、エラー通知ボタン524、データ取込ボタン528に対応するアプリの一例として、会計データ入力アプリ、事業概況説明書アプリ、減価償却アプリ、勘定科目内訳書アプリ、法人税申告書アプリなどがあるが、これらの記載に限定されるものではない。
【0112】
操作ボタンの動作の具体例を挙げると、処理ボタン525をクリックすると、そのデータの業務フローに適したアプリ(例えば会計データ入力)が起動し、確認および編集をおこない、アプリにデータを取り込こみ、再び処理ボタン525が表示された画面に戻り、同じ処理ボタン525をクリックすると、次の業務に進められるデータになっているため、そのデータの業務フローに適したアプリ(例えば法人税申告書)が起動し、編集するといった流れで作業が進む。
また別の例を挙げると、処理ボタン525をクリックすると、そのデータの業務フローに適した複数のアプリ(例えば会計データ入力と法人税申告書)が同時に起動し、突き合わせチェックができる流れで作業が進む。
また別の例を挙げると、エラーが検出された受信データの場合、エラー通知ボタン524をクリックすると、そのデータに適したチェックアプリ(例えば法人税申告チェック)が起動し、人目でチェックできる流れで作業が進む。
また別の例を挙げると、受信したデータに適したチェックアプリを起動するかどうかを決定するチェックボックスにチェックを入れた状態で、処理ボタン525をクリックすると、そのデータの業務フローに適したアプリ(例えば法人税申告書)とチェックアプリ(例えば法人税申告チェック)が同時に起動し、編集(修正)とチェックを並列処理して効率的に作業が進む。
また別の例を挙げると、受信したデータを、データ取込ボタン528で、直接取り込む流れでも作業が進む。
【0113】
実際の作業の順番を一例で上げ、全体のフローチャート(
図6)の説明に戻り、S6−8以降を説明するが、作業の順番はこの記載に限定されるものではない。
【0114】
まずは、会計データDBへ取り込む前に、受信したデータに不備がないかチェックしていないので、チェック対象データを選択した後、作業員がエラー通知ボタン524を押下する。
操作受付のステップS6−8は、データチェック作業(アプリ起動)のステップS6−11に移り、チェックするために適したチェック用アプリ(例えば、会計ファイルのチェック、法人申告チェック、電子申告形式チェック、法人税申告書のチェック)を1ないし複数起動させる。
従来は、データの種類やデータの状況によって、使用するチェック用アプリの種類が異なり、また複数のチェック用アプリを使用してチェックする場合などもあり、それらを自ら判断し、手動で起動していたが、本統合画面ではエラー通知ボタン524(1種類のみ)を押下するという単純操作だけで、チェック対象データに関する情報(例えば、現状のデータの状況(新着)とデータ形式(CSV形式)など)を、会計データIDをキーとして、イベントログ記録部(
図2−1の218)に記録されているイベントログテーブル(
図3−2)より取得し、チェック対象データをチェックするために必要なアプリを起動させる。
作業員は、起動したアプリでチェック対象データのチェックを終えると、統合画面(詳細表示)520へ画面が戻り、再び操作受付のステップS6−8に戻る。
【0115】
なお、エラー通知ボタン524は、別作業でデータチェックをして、エラーのまま処理を終えたデータが存在した場合に表示するようにしてもよいし、データを受信した際に、自動でデータチェックをするようにした場合、目視確認が必要なエラーがあるデータが存在した場合に表示するようにしてもよい。
エラー通知ボタン524を押下することで、エラーがあるデータのみを一覧表示し(図示せず)、その中から選択されたデータのエラーの詳細を確認することができたり(図示せず)、修正することができたりしてもよい。
エラーに関して、会計処理または税務処理に必要な項目に異常があるデータをエラーとするが、そのエラーの一例として、会計データ関連(会計データ入力)では、バランスエラー(期首残高)、バランスエラー(開始残高:xx月)、諸口のバランスエラー(XX月)、科目未決定勘定エラー(XX月)などがあり、事業概況説明書関連では、電子申告データ形式チェックのエラーなどがあり、減価償却関連では、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあり、勘定科目内訳書関連では、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあり、法人税申告書関連では、確認が必要な別表や項目エラー、未選択の帳表エラー、未入力の帳表エラー、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあるが、これらの記載に限定されるものではない。
【0116】
データをチェックした結果、データに修正する必要があることがわかった作業員は、編集対象データを選択した後、処理ボタン525を押下する。
操作受付のステップS6−8は、データ編集作業(アプリ起動)のステップS6−9に移り、記憶部203のイベントログ記録部218にある、データを受信した際に取得したイベントログ情報(顧問先、業務フローの進捗、依頼内容、データ(ファイル)の種類、データを受信した際の自動チェックなど)を元に、編集対象データを編集するために適したアプリ(例えば、会計データ入力アプリ、法人申告アプリ、電子申告アプリ、法人税申告書アプリ、表計算アプリ、その他各種エラーチェック用アプリなど)を1ないし複数起動させる。 複数のアプリを起動する場合とは、異なるアプリでの編集画面を突き合わせてチェックしながら入力すると効率がよい場合や、編集用アプリとチェック用アプリと並行しながら編集を進めると効率がよい場合をなどである。 前述したエラー通知ボタンと同様に、従来は煩雑な自己判断、手動アプリ起動を必要としていたが、編集対象データに関する情報をイベントログテーブルより取得することで、自動でデータ編集作業に必要なアプリを起動させる。
作業員は、起動したアプリで編集対象データの編集を終えると、統合画面(詳細表示)520へ画面が戻り、再び操作受付のステップS6−8に戻る。
【0117】
データの修正を終え、エラーや不足のないデータとなったため、作業員は、会計データDBなどへデータを取り込むため、取込対象データを選択した後、データ取込ボタン528を押下する。
操作受付のステップS6−8は、データ取込作業(アプリ起動)のステップS6−10に移り、取込対象データを会計データDBなどへ取り込むために適したアプリ(例えば、会計データ入力アプリ、法人申告アプリ、電子申告アプリ、法人税申告書アプリなど)を起動させる。 前述したエラー通知ボタンと同様に、従来は煩雑な自己判断、手動アプリ起動を必要としていたが、取込対象データに関する情報をイベントログテーブルより取得することで、自動でデータ取込作業に適したアプリを起動させる。取り込むデータの一例として、画像化と共にデータ化した伝票(レシート)や通帳、自計化した顧問先で入力された入出金明細データや記帳データ、監査依頼と監査依頼に必要な資料、他のベンダのアプリで生成された会計データなどがある。
作業員は、起動したアプリで取込対象データの取り込みを終えると、統合画面(詳細表示)520へ画面が戻り、再び操作受付のステップS6−8に戻る。
【0118】
作業員は、必要に応じて、統合画面(詳細表示)520から、ボタンやプルダウンメニュー(
図5−2に図示せず)などによって、別の管理ソフト(管理システム)を起動したり、または切り替えられたり(統合画面を終了させて起動したり)できるようにしてもよい。
これは、熟練した作業員が、更に効率を上げるために、別の管理ソフトを起動する際に用いられる。
具体的には、本発明である会計処理システムは、データを一元管理するシステムであるため、複数の顧問先のデータを一元的に表示できる一方、顧問先毎の管理においては、情報が多いことから、顧客情報管理システム(Client File Manager)などの顧問先毎に管理できるシステムを使用した方が便利な時もあり、そのようなシステムへの切り替えをスムーズに行うための支援機能を提供する。
関連する別の管理ソフトとして、例えば、財務システム、税務システム、法人申告システムなどがあり、それらを連動・連携させて、管理ソフトの切り替えを行う。 さらにその連動・連携を活用し、業務フローを段階的に進めていく中で、その都度必要な書類を一括印刷する機能や、1つのデータを編集することでその他の書面(例えば税務代理書面など)も反映される機能、申告する際に必要な資料を収集して申告(例えば電子申告)をする機能を連動させてもよい。
作業員は、管理ソフトを切り替えるか起動するかを選択(
図5−2に図示せず)し、プルダウンメニューなどで管理ソフトを選択する。
操作受付のステップS6−8は、別管理ソフト(管理ソフト起動)のステップS6−12に移り、プルダウンメニューなどで選択された別管理ソフトを起動する。 そして、管理ソフトを起動するだけ(統合画面(詳細表示)を終了しない場合)であれば、ステップS6−13の「終了しない」に進み、再び操作受付のステップS6−8に戻る。 管理ソフトを切り替える場合(統合画面(詳細表示)を終了する場合)は、ステップS6−13の「終了する」に進み、統合画面(詳細表示)を終了させる(S6−14)。
なお、管理ソフトの切り替え方法は、前述したプルダウンメニューに限定するものではなく、スワイプ等のジェスチャー操作やキーボードのファンクションキーの割り当てによる入力、音声入力などでもよいし、その記載に限定されるものではない。
なお、本システムにおいて、データの取り込みからデータのチェック、財務帳表の作成、電子申告までの一連の作業をスムーズに進められるように、管理ソフト(統合システム(例えば法人申告統合システムなど))の関連するアプリなど(例えば電子申告、個人申告、相続税等など)の機能を、さらに連携・連動させるような形で追加・拡張することができる。 この連携させる手法は、様々な手法があるが、本発明の本質とは異なるため、詳細な説明は省略する。
【0119】
その他、作業員が、統合画面(詳細表示)520を終了させたい場合、キャンセルボタン529を押下する。 操作受付のステップS6−8は、キャンセル(画面表示終了)のステップS6−15に移り、統合画面(詳細表示)520を終了させる(S6−14)。
統合画面(詳細表示)520を終了させると、統合画面(データ一覧表示)(
図5−1の510)が表示されるようにしてもよい。
【0120】
以上の実際の作業の中で、どのようなアプリケーションで、データをどのように処理し、どのようなエラーがあったか、データのチェック結果、取り込み、入力、修正、監査結果、資料作成、顧問先への連絡などの5W1Hなどの条件を含む作業履歴情報を、ジョブ実行記録として、本会計処理システムでは、イベントログ記録部218(
図2−1)のイベントログテーブル(
図3−2)へ記録している。 このように、イベントログテーブル(
図3−2)に記録することで、例えば、顧問先データ、監査依頼、アプリ起動記録、アプリ起動中操作記録、データ受信、チェック結果、チェック結果の通知、データ確認画面、共通のデータ選択画面、各アプリ(会計、法人申告、電子申告形式、法人税申告書等)のチェックなどのジョブ実行履歴で、統合画面(詳細表示)(
図5−2の520)で表示し切れなかった有効な情報や、さらに過去のデータの受信または送信の履歴を、履歴ボタン(
図5−2の527)(
図6には図示せず)で表示することができるが、別の画面に表示してもよい。
また、業務進行テーブル(
図3−3)を参照することで、一連の業務フローにおいて、データに対してどこまで業務が進んだか、という進捗状況も把握することができる。
【0121】
以上、実際の作業の順番の一例から分かる通り、本統合画面(詳細表示)520によって、日常作業の中で、作業員が、データ受信やデータエラーなどに素早く気が付き、、チェック漏れを減少させる支援ができ、かつデータの取り込みやエラー確認の作業を開始する際の操作を単純化・統一化することで、会計事務所の業務負担の軽減と、円滑なワークフローの確立を実現するための支援ができる。
【0122】
統合画面(詳細表示)520では、まだ会計データDBに取り込んでいないデータが表示対象であったのに対し、統合画面(データ一覧表示)510では、会計データDBに取り込み済みのデータを含め、まだアプリに取り込んでいない過去に受信したデータや、顧問先へ送信(返信)したデータなどを一覧で表示する(514)。
統合画面(データ一覧表示)510では、条件1(512)、条件2(513)、表示条件515によって設定された各表示条件に合致したデータを、一括表示(514)しており、その表示中のデータの一つを選択した際にその会社名511を表示するとともに、その会計データの作業を開始するための確定ボタン518や、その会社名511のやり取り履歴を表示するための会社履歴ボタン517を表示する。その他、統合画面(データ一覧表示)510に対する様々な設定をするための設定ボタン516や統合画面(データ一覧表示)510を終了させるためのキャンセルボタン519も表示する。
なお、確定ボタン518や、会社履歴ボタン517は、一括表示(514)されたデータを選択しないと効果を奏しないため、データが選択されていない場合は、操作無効なグレーアウト表示にして、データが選択された場合に、操作有効な表示に変わるような表示にしてもよい。
【0123】
会社名511は、顧問先名(会社名)を表示するが、その他、顧問先の管理番号、顧問先の決算年月日、顧問先内の担当者、会計事務所内の作業員、顧問先の業種などがあってもよい。それらの情報は、データのイベントログ(
図3−2)に記録されていてもよいし、顧客管理システムなどの別のシステムに記録されていて、連携・連動させて、情報を取得するようにしてもよい。
条件1(512)、条件2(513)は、一覧表示514の表示条件を指定するプルダウンメニューであるが、ラジオボタンなどの入力方法でもよいし、この記載に限定されるものではない。 ここでは、表示条件を簡単に設定できるインターフェースで、素早く条件に合致したデータのみを、一覧表示することができる。
表示設定ボタン515は、押下することで表示設定画面が別表示され、一覧表示514の詳細条件(商号コードの指定、対象期間、受信データのみ、送信データのみ、組込み済みデータを含めた全送受信データ、記帳や監査等の依頼内容別など)を指定したり、データに関する情報の要素を取捨選択したりして、表示する情報を細かく設定することができる。また、データを一覧表示する上で、新着情報やデータの種類、受信したデータの状況に応じた重要度、受信したデータを業務フローに沿って処理した後の重要度、処理期限までの残り日数による処理優先度、エラーがあるデータなどを、文字の色や太さ、アイコンなどで区別したり、点滅などのアニメーションで視覚的効果を付したり、表示する情報を絞ったり(表示を省略したり)、折り畳み表示(例えば、バーが表示されているところをクリックすると内容が表示され、再度バーをクリックすると内容がバーに折りたたまれるような表示の仕方)をするなどして、必要な情報が把握しやすいように表示をすることもできる。
例えば、会計データを入力する場合には、顧問先からのデータ受信の方を会計データのエラーより優先させて表示させることや、個々の申告書データにエラーがある場合には、申告書間のエラーチェックの結果をまだ表示させない(まだ省略する)ことやか、電子申告データを作成する場合には、各種エラー結果を強調することで、重要度に応じた表示をしてもよい。
なお、アイコン(新着情報アイコン、データ形式(種類)別アイコン、重要度別アイコン、処理優先度別アイコン、エラーアイコンなど)に操作ボタンの機能を付して、押下することで
図5−2の処理ボタン525、エラー通知ボタン524、データ取込ボタン528と同様の動作となるようにしてもよいし、その他の操作となるように動作してもよい。なお、この記載に限定されるものではない。
【0124】
この重要度は、データ記録部216に記録されている重要度設定テーブル(図示せず)によって定めており、データに紐づけられたイベントログテーブル(
図3−2)に記録されている値(例えば、イベント内容、追加情報1、追加情報2、データ形式、自社情報2の値)に対して、それぞれに重要度の指数を割り振っている。 このデータ毎に割り振られる重要度の指数化は、データ重要度判定部214(
図2−1)によって、データに対する操作が行われてイベントログテーブル(
図3−2)に記録される際に都度実行される。
例えば、イベント内容の例えば、データ受信に3、帳表作成アプリ起動に1、帳表作成アプリ終了に2、簡易チェックに1、簡易チェックエラー検出に5など)、追加情報1の例えば、データの所有先を特定する情報に関する顧問先Aに10、顧問先Bに5など)、追加情報2の例えば、データの自身の異常状況に関する情報である受信OKに1、受信NGに10、軽度エラーに15、重度エラーに20、正常終了に1、異常終了に30など)、データ形式の例えば、会計データに10、帳表に5、電子申告に20、PDFに1、CSV(他ベンダ)に3、CSV(銀行明細)に2など)、自社情報2の例えば、作業員名であるAさんに5、Bさんに2など)、と指数を割り振る。更に項目に対する重要度レベルを、例えば、イベント内容に5、追加情報1に3、追加情報2に10、データ形式に1、追加情報2に1と割り振る。そして、最終的にデータの重要度の数値化を、例えば、データに関するすべての数値をイベント内容がデータ受信で5×3、追加情報1が顧問先Aで3×10、追加情報2が受信OKで1×10、データ形式が会計データで1×10、自社情報2がBさんで1×2とすると、そしてそれら重要度の指数は、その数値の合計、5×3+3×10+1×10+1×10+1×2=67となる。この算出された重要度指数を元に、その他のデータと比較し、重要度の順番を決めていく。この重要度指数は、会計データDBへ記録してもよい。この重要度の数値化する手法や重要度の比較手法などは、その記載に限定されるものではない。
【0125】
処理優先度は、会計データ(会計データID)に対して、顧問先から処理期限の要求がある場合はその日時を、顧問先から処理期限の要求がない場合は、後述する実施例4のスケジュール概念に基づく作業完了日時(予定日時)を、紐付けて、データ記録部216に記録される処理期限管理テーブル(図示せず)に記録されており、その他のデータと処理期限までの残り日数の少なさで比較して、少ない方から順に優先度を割り振ることができる。この手法は、その記載に限定されるものではない。
【0126】
サーバー装置2から様々な情報を取得し、会計事務所端末3で統合画面(データ一覧表示)510や統合画面(詳細表示)520で情報を表示する際に、アクセス権で制御を掛けることもできる。具体的には、サーバー装置2が、取得しようとしている情報を取り扱うことができる作業員なのかを、会計事務所端末3の名前情報や、会計事務所端末3にログインしたユーザー情報などから判断して、取り扱うことを許可された作業員(または会計事務所端末3)にのみ、データの取り扱いを許可(送信、展開)する。このような(アクセス権を与える)セキュリティ管理機能は、本発明に入れるほか、別のシステムで用意して連動することで、様々な情報を、複雑なセキュリティ設定を行うことなく運用でき、機密保持も万全に利用できる。
また、上記セキュリティ管理機能において、作業員毎ではなく、複数の作業員を1グループとして、そのグループに対してアクセス権を与えたり、使用する1ないし複数の会計事務所端末3に対して(会計事務所端末3にログイン出来るユーザーに対して)アクセス権を与えたりすることができる。 なお、新たにグループへ追加された作業員も同グループのアクセス権を引き継ぐこともできる。
【0127】
設定516(ボタン)(
図5−1)は、押下することで統合画面(データ一覧表示)510とは異なる画面が表示され、統合画面(データ一覧表示)510ないし統合画面(詳細表示)(
図5−2の520)の表示上のカスタマイズ設定をすることができる。 例えば、エラーアイコンの色変更や、特定の顧問先の受信通知に関しての表示有無や、色や文字の太さによる強調表示などを行えるが、これ以上の説明は、本発明の本質とは異なるため、省略する。
会社履歴ボタン517は、会社履歴等顧問先等の対応も含めた履歴が確認できる。
一覧表示(514)されたデータの中から選択された「受信データの送信元の会社」に関する、過去の受信または送信データ、作業履歴などを別画面にて表示するが、これ以上の説明は、本発明の本質とは異なるため、省略する。
確定(ボタン)518は、一覧表示514の中から選択したデータの次の作業への入口(作業を開始する操作ボタン)であるが、統合画面(詳細表示)520を表示させてもよい。
【0128】
その他、前述した統合画面(詳細表示)520で管理ソフトを切り替えられる機能(
図6のS6−12)(
図5−2に図示せず)を、統合画面(データ一覧表示)510にあってもよい(
図5−1に図示せず)。
【0129】
以上の2つの統合画面(
図5−1、
図5−2)の作業開始ボタン(518、525、524)や管理ソフトの切り替え(図示せず)により、財務系アプリや税務系アプリの間をまたがって作業ができ、この関係が
図2−2となる。
【0130】
図2−2は、申告書類を作成するまでのアプローチに必要な「財務501」や「税務502」、「電子申告507」をブロックとし、資料作成(503、504、508)やチェック、データ収集(505、506)などの作業が、財務と税務との間で相互に行き来する業務の関係を示す図である。
具体的には、電子申告業務の過程で、税務関連である法人税申告書、減価償却、内訳書のデータと、財務関連である会計データとを照合することで、金額の不一致等を突き合わせチェックが容易にできることや、必要に応じて修正する場合に、財務側や税務側のアプリを起動してデータの修正をすること、財務関連や税務関連の双方で必要なデータや資料等を収集することなどの、一連の処理を効率よく実行500することができると、余力の創出509が可能となることを示す図である。
実際、会計事務所は、顧問先から受信した会計データから、財務関連の資料(例えば、監査報告や財務帳表など)や、税務関連の資料(例えば各種申告書など)を作成し、電子申告に必要な資料を用意する。 財務関連や税務関連の資料を作成する際は、それぞれの分野に様々なアプリがある。 財務システムまたは財務アプリと、税務システムまたは税務アプリは、別ベンダのもので構成されることが多く、そのため財務と税務の連携・連動ができないことがよくある。 実際の資料用意作業では、財務関連のアプリ同士を切り替えたり、税務関連のアプリ同士を切り替えたりするが、財務関連のアプリと税務関連のアプリを互いに切り替えたりすることも少なくない。
このような場面では、その都度、作業に適切なアプリを起動させる必要があるが、それにはそれなりの手間が掛かる。
本発明では、財務・税務のデータやアプリ、システムの連携・連動により、顧問先から受信した会計データを処理する実作業上で、財務と税務の切り替えを意識することなく自在に行き来でき、垣根を超えた突き付けチェックなども手際よく行え、また必要に応じて遡って作業し直すことも単純操作ででき、あたかも監査、帳表作成、決算・申告処理、電子申告までの会計事務所における一連の実務を、流れ作業のように処理できるように支援する会計処理システムを提供しており、電子申告に必要なデータを自動収集することができ、また手際よく申告手続きまででき、会計事務所の実務効率の総合的な向上により創出された余力を、新サービスや顧客開拓などへ注力することができる。
「財務と税務を自由に行き来」という表現に関してさらに説明すると、例えば法人申告統合システムのことを指しており、本発明の統合メニューから該当アプリ(法人申告統合システム)を起動できるため、従来、会計データ入力を行った後、法人申告統合システムを起動するために、会計データ入力のアプリを閉じ、法人申告統合システムを起動し、該当顧問先を選択肢、該当データを選択することで、やっと法人申告の編集が行えたという煩わしい手順が不要となり、「財務と税務を自由に行き来」できるような感覚で、仕訳入力〜申告書作成〜チェック〜電子申告までの作業を一筆書きのように行うことが出来るということを表現している。
【0131】
(実施例4)
以下に実施例4を記載するが、この実施例4によって本発明は限定されるものではない。
受信したデータを処理(作業など)した後に、次の業務フローが人手を介さずとも機械的に処理できる場合、データを処理した後の状態変化をきっかけに、会計処理システムが次の業務フローに沿って、自動で処理を実行してもよい。
例えば、顧問先からの受信データを取り込んだ後、会計処理システムが会計データのチェックを自動で実行したり、ある顧問先の申告書を全て作成し、チェックし終わった後、会計処理システムが電子申告用のデータを自動生成したり、作成した資料のチェックが終わった後、会計事務所内の権限を持つ上司(先生)に承認を促したり、顧問先へ提出する資料に提出の許可が得られたら、自動で顧問先に資料を提出したりしてもよい。
【0132】
(実施例5)
以下に実施例5を記載するが、この実施例5によって本発明は限定されるものではない。
本発明では、階層管理可能なカレンダーを提示、提供することができる。
【0133】
この階層管理可能なカレンダーは、イベントログテーブル(
図3−2)の情報を元に、カレンダーの表記をベースにして、スケジュール状況をビジュアル(視覚的)にまとめて、閲覧制限をかけて情報提供するもので、ユーザーが容易にスケジュールを把握できる様に、また作業漏れを無くす様に支援しながらも、限定したスケジュール閲覧によって情報漏れを抑えることができる機能である。なお、スケジュールの表記方法には、カレンダー表記の他、タイムスケジュール表記やグラフ表記、表による表記などでもよく、その表記は限定されない。同様に、階層管理可能なカレンダーや表形式などのそのフォーマットも制限されない。
【0134】
階層管理とは、会計事務所内(先生、マネージャー、作業者など)の人員の責任レベルの度合いや担当割当などによる階層と同様に、情報の閲覧も階層的に許可/禁止を管理することである。
例えば、会計事務所の先生は全ての情報を閲覧できるが、作業員は担当顧問先しか閲覧ができない、数の作業員を1つにまとめたグループに対して閲覧を許可するなどの、人に対する閲覧制限の階層管理の方法がある。
また、人に対してではなく、装置に対して閲覧制限することもできる。 例えば、作業端末装置(例えば、会計事務所端末3(
図2−1の401))の個体情報(IPアドレスやMACアドレスなど)を元に、特定の作業端末装置に対する閲覧制限や、複数の作業端末装置をグループにまとめて閲覧制限する、装置に対する閲覧制限の階層管理の方法もある。
また、例えば、過去の担当顧問先情報は、担当期間の情報のみに限定して閲覧の許可を与える階層管理の方法もある。
また、例えば、AからCまで、3つの会計事務所で構成された税理士法人に対しても、A会計事務所内のみ閲覧許可、BとCのみ閲覧許可など、事務所単位での階層管理の方法もある。
また、例えば、顧問先にも同様に階層管理可能なカレンダーを提供することも可能で、顧問先の社長は全て閲覧許可、顧問先担当者は処理を行ったデータに関連するスケジュールのみ閲覧許可、顧問先の本社(本店)は全て閲覧許可、支社(支店)は閲覧禁止など、人単位や組織単位での階層管理の方法もある。
なお、例に挙げた階層管理の方法に、その方法は制限されない。
【0135】
階層管理可能なカレンダーの具体的な実施例として、
図2−1のサーバー装置2では、本システムと連動した顧問先管理システムで、データ記録部216から顧問先の情報(顧問先ID、顧問先名、顧問先担当者、顧問先独自の休日、決算日など)を取得し、イベントログ記録部218からその顧問先に関する情報(データ受信日、データ形式)を取得し、取得したデータ形式と、業務進行テーブル(
図3−3)のデータ形式とを照合する。
【0136】
図3−3の業務進行テーブルは、データ記録部216に記録されており、そのテーブルに記録されているのは、様々な業務フローに関する情報である。 具体的には、データ形式毎に業務フローIDを割り振り、業務フローID毎に業務フローのステップ(工程)と、ステップ毎の工数が記録されている。
ステップには、例えば、ステップ1に依頼受信(データ受信)、ステップ2にデータ確認という、ステップ毎に作業概要が紐付けられた形で記録されており、作業概要はその他にも、データ取込、帳表作成、監査、申告書作成、電子申告準備、提出、申請などが記録されているが、これに限定されない。
ステップ毎の工数には、ステップに紐づけてそのステップにかかる工数が時間単位の数値で記録されているが、これに限定されない。
【0137】
このテーブルは、基本的には事前に用意されているものだが、新たな業務フローをユーザーが追加設定することや、ベンダが定義ファイルを提供してそれを取り込むことで追加設定することも可能であり、自由に追加、削除することができる。 また、業務フロー毎のステップの変更、ステップ毎の工数の変更も、ユーザーによって修正ができる。 さらに、ステップ毎の工数の変更に関しては、実際に作業員が作業を行った際にその履歴がイベントログ記録部218に記録されるが、その情報を元に、ステップ毎の工数を、同業務進行テーブル内に複数回分記録し、平均化したものを新たなステップ毎の工数として更新することもできる。
【0138】
取得したデータ形式と、業務進行テーブル(
図3−3)のデータ形式とを照合して得られた業務フローID(業務フロー)を元に、業務進行テーブルのステップ1を、データ受信日として起点とし、ステップ2から業務フローの最終ステップXまで、それぞれに割り当てられた工数(業務進行テーブル(
図3−3)に存在)を、それぞれの間隔(期間)として、データ記録部216にある、スケジュールDBに記録される。
【0139】
スケジュールDBに記録される情報は、顧問先の情報、会計事務所の情報、日付と関連付けられた業務フロー、カレンダー情報などがあるが、それらに限定されない。
具体的にスケジュールDBに記録される情報の例として、顧問先の情報には、顧問先管理システムから取得した、顧問先ID、顧問先名、顧問先担当者、顧問先独自の休日、決算日などがあり、会計事務所の情報には、顧問先管理システムから取得した、顧問先担当責任者、顧問先担当作業者のほか、本システム(イベントログ記録部218)から取得した、業務処理を完了させた作業員名、業務処理を完了させたステップ数、業務処理を完了させた日付や、本システム(設定管理テーブル群)から取得した階層管理レベル数、日付と関連付けられた業務フローには、業務進行テーブル(
図3−3)から取得した、ステップ(業務概要)、ステップ数、ステップ数に対する工数、業務フローカレンダー情報には、既にスケジュールDBに記録されているほか、インターネット経由で更新された日付情報である、年月日、曜日、日本の祝日、が記録されているが、これらに限定されない。
【0140】
本システムの設定管理テーブル群は、データ記録部216に記録されており、会計事務所内の先生および従業員全て(以下、所員)に対する所員ID、氏名、閲覧権限レベルの所員テーブルと、所員IDに対して、担当顧問先IDと担当期間(担当開始日と担当終了日)の組合わせと紐付けた顧問先担当テーブルと、所員IDに対して、顧問先ID毎の閲覧許可/禁止フラグをまとめた顧問先別閲覧管理テーブルとを含む、複数のテーブルをまとめたものであり、その他、本システムの表示設定や条件設定などのテーブルも含まれるが、それらテーブルは、本システムではなく、連動する別のシステム(例えば、所員管理システムなど)にテーブルを持ってもよいし、これらに限定されない。
【0141】
以上に述べた様々な情報をスケジュールDBより取得し、顧問先用のスケジュールを階層管理可能なカレンダーに、データ受信日から作業終了までに必要な日数分の営業日を帯状に塗布させて、途中の作業概要も帯上に示したもの顧問先端末1(
図2−1)や会計事務所端末3(
図2−1)に通信部207(
図2−1)を介して提供し、出力部(
図2−1の106ないし406)で表示することで、受信したデータに関するスケジュール兼業務フローが可視化できる。
【0142】
その表示のフォーマットは、月単位の表示方法もあるが、その他、週単位、3日単位、1日単位と拡大表示する方法もあり、4半期単位、半年単位、1年単位と縮小表示する方法もあるが、これらに限定されない。
【0143】
表示方法には、その他に、ある条件下において、順番を並べ替える(ソートする)表示方法もある。
例えば、1日単位での表示の中に、複数の顧問先のスケジュールがある場合、各顧問先の決算日の近い順に表示させることや、会計事務所内の担当者名の五十音順にその担当顧問先を順に表示させること、データにエラーや不備があると認識した日時順に表示させること、など様々な並べ替えができるが、これらに限定されない。
【0144】
スケジュールの表示内容は、例えば、5W1Hに基づき、いつ、どこで、誰が、いくらで、何を、どうするなどの基本情報が表示される他、セキュリティレベル(どのレベルの人まで閲覧できるか)なども表示できるが、この例えによって表示できる内容は限定されない。
そして、本システム等を活用して、データに対する作業を実施したら、階層管理可能なカレンダーに、だれが、どのくらいの期間、どのデータを、どこまで作業したかなどを反映させ、作業進捗の可視化ができるが、この例えによって可視化できる内容は限定されない。
【0145】
この階層管理可能なカレンダーに付加されたスケジュール情報の閲覧は、例えば、会計事務所の他、該当する顧問先へ、そのままのカレンダー形式や表形式などで閲覧できるようにしてもよいし、更に整理または絞った情報を表現してもよいが、この例えによって顧問先が閲覧可能な情報量は限定されない。
【0146】
このカレンダーや表形式は閲覧の他、スケジュールの期限をアラート(表示、音、スマホ転送など)で、会計事務所内にお知らせしてもよい。このアラートも階層管理と連動させ、権限を持つ人にのみ、アラート通知させてもよい。
【0147】
さらに、そのカレンダーで可視化された業務フローまたは作業進捗から、次の作業のために必要なアプリを起動させてもよい。業務フローや作業進捗は、円グラフや日めくりなど、様々な可視化方法があるので、ここでは言及しない。
【0148】
(実施例6)
以下に実施例6を記載するが、この実施例6によって本発明は限定されるものではない。
以下の実施例6で記載されている業務処理手順は、作業手順と同一の意味を持つものであり、会計事務所の作業手順通りに円滑に進める支援をしているため、業務処理手順を実行(作業手順実行)する会計処理装置であって、具体的に作業手順実行装置や作業手順実行支援装置として読み替えることも可能である。
会計事務所端末3は制御部402と記憶部403と入力部404と出力部406と通信部407から構成される。実施例6は会計事務所端末3で説明して説明しているが、制御部と記憶部についてはサーバー装置2(制御部202と記憶部203)で行ってもよい。
【0149】
アプリケーション情報テーブル(
図3−1)は担当者が業務で使用するアプリケーション(以下アプリとする)とアプリで使用するデータを管理するテーブルであり、「処理ステップ」(図示せず)と「アプリ名」と「データ形式」と「必要データ」の項目からなる。「処理ステップ」は後述する業務進行テーブルのステップ(例えば、「データ取込」、「帳表作成」、「申告書作成」、「電子申告準備」等)に対応し、業務処理の処理手順と使用するアプリを対応付けている。「アプリ名」は業務で用いるアプリ名(例えば、会計データ入力、法人税申告書作成、減価償却入力、事業概況説明書作成、勘定科目内訳書作成、決算報告書作成、相続税申告書作成、電子申告システム等)を示し、「データ形式」はアプリが使用するデータの形式(例えば、会計データ、法人税申告書データ、減価償却データ、事業概況説明書データ、勘定科目内訳書データ、帳表データ、申告データ等)である。「必要データ」はアプリがデータ取込可能なデータの形式である。
【0150】
業務進行テーブル(
図3−3)は担当者の業務進捗を管理するテーブルであり、「業務フローID」と「担当者名(図示せず)」と「顧問先名(図示せず)」と「データ形式」と「ステップ1」から「ステップN」までの項目からなる。「業務フローID」は担当者が行う業務を識別するもので、「担当者名」は業務処理を行なう担当者の名前を示す。「顧問先名」は担当者が業務処理を行なう対象である顧問先の名前を示す。「データ形式」は顧問先から受信するデータの形式(例えば会計データや画像データ等)を示す。「ステップ1」から「ステップN」は担当者の業務処理の処理手順を示す。
【0151】
ここで担当者Aが業務の流れの例として電子申告処理について
図4に基づき説明する。
管理テーブルとしてアプリケーション情報テーブル(
図3−1)と業務進行テーブル(
図3−3)と後述するイベントログテーブル(
図3−2)の3つのテーブルからなり、記憶部403に記憶される。
【0152】
図4のS1において担当者が会計事務所端末3で電子申告処理を行なう顧問先Bを選択すると、会計事務所端末3の制御部402が業務進行テーブルの項目「業務フローID」に電子申告業務を示す値「3」を、項目「担当者名」に「A」の値を、項目「顧問先名」に「B」の値を、項目「ステップ1」から「ステップ8」に電子申告処理に必要な処理手順(項目「ステップ1」から順に「依頼受信」、「データ確認」、「データ取j込」、「帳表作成」、「申告書作成」、「電子申告準備」、「署名付与」、「提出」の値)を設定する。制御部402は、業務進行テーブルの項目「ステップ1」の値である「依頼受信」を読み出し、顧問先から電子申告の依頼が来ているかをチェックする。
【0153】
電子メール等で電子申告の依頼を受信していることを確認できたら、電子申告依頼の受信済の通知を表示する。担当者は表示された通知を確認したら(S4−6)、確認ボタン(図示せず)を押すことで依頼受信処理が終了する。
【0154】
制御部402は、業務進行テーブルの項目「ステップ2」の値「データ確認」を読み出し、後述する基本情報(図示せず)を生成して表示する。基本情報は電子申告に必要な情報であり、「納税者」、「組織情報」、「決算日」、「税目」、「納税先」、「税理士名」の項目からなる。
【0155】
具体的には制御部402が顧問先情報(図示せず)から顧問先Bの組織情報(法人か個人か)と決算日と納税先(税務署名)を読み出し、基本情報の項目「納税者(納税者の名前)」に「B」を、項目「組織情報」に「法人」を、「決算日」に「○○年3月31日」を、「税目(申告する税対象)」に「法人税」を、「納税先」に「D税務署(URLも含む)」を、「税理士名」に「S」を設定して、基本情報を生成する。
【0156】
制御部402は生成した基本情報に不足(例えば、情報未記入等)や間違い(例えば、顧問先の住所と対応する税務署名が一致しない等)等のエラーがないかチェックし、エラーがなければそのまま表示し、エラーがあればその部分を強調表示等の担当者にわかりやすい形で表示する。担当者が基本情報を目視でチェックし、エラー等がないことを確認したら(S4−6)、確認ボタン(図示せず)を押すことでデータ確認処理が終了する。
【0157】
制御部402は、業務進行テーブルの項目「ステップ3」の値「データ取込」を読み出し、さらに項目「データ形式」の値「会計データ」を読み出す。制御部402は顧問先Bから会計データを受信しているかをチェックし、電子メール等で会計データが受信していることを確認できたら(
図4のS4−2)、「電会計データを受信している」との通知を表示する。担当者は表示された通知を確認したら、確認ボタン(図示せず)を押すと、制御部402はアプリケーション情報テーブルを参照して会計データ入力のアプリが起動する。
【0158】
具体的には、確認ボタンが押されることで、制御部402はアプリケーション情報テーブルの項目「処理ステップ」の値が「データ取込」となる「アプリ名」と「データ形式」と「必要データ」を検索し、項目「アプリ名」の値である「会計データ入力」と項目「データ形式」の値である「会計データ」と項目「必要データ」の値である「会計データ」を取得する。項目「必要データ」の値が「会計データ」のため、「会計データ入力」のアプリを起動されたら、制御部402は顧問先から受信した会計データの取込処理を行なう。
【0159】
取り込んだ会計データは記憶部403へ顧問先毎に分類して記憶する(S4−3)。データの整合性や作業内容等の状態等についてデータチェックを行い(S4−5)、取込処理の完了とデータチェックの結果の通知を表示する(S4−6)。担当者は表示された通知を確認したら(S4−6)、確認ボタン(図示せず)を押すことでデータ取込処理が終了する。
【0160】
制御部402は、業務進行テーブルの項目「ステップ4」の値「帳表作成」を読み出し、アプリケーション情報テーブル(項目「アプリ名」は値「決算報告書作成」、項目「データ形式」は値「帳表データ」、項目「必要なデータ」は値「会計データ」)を参照し、「決算報告書作成」のアプリを起動する。「決算報告書作成」のアプリを起動されたら、制御部402は記憶部403に記憶した会計データを取り込むと、担当者は会計データを元に決算報告書である帳表データを生成する。
【0161】
生成した帳表データが記憶部403に記憶されると、制御部402は決算報告書の作成完了の通知を表示する。担当者は表示された通知を確認したら(S4−6)、確認ボタン(図示せず)を押すことで帳表作成処理が終了する。
【0162】
制御部402は、業務進行テーブルの項目「ステップ5」の値「申告書作成」を読み出し、アプリケーション情報テーブル(項目「アプリ名」は値「減価償却入力、事業概況説明書作成、勘定科目内訳書作成、法人税申告書作成」、項目「データ形式」は値「減価償却データ、事業概況説明書データ、勘定科目内訳書データ、法人税申告書データ」、項目「必要なデータ」は値「なし」)を参照し、「減価償却入力」と「事業概況説明書作成」と「勘定科目内訳書作成」と「法人税申告書作成」のアプリを起動する。
【0163】
「減価償却入力」のアプリを起動されたら、担当者Aは減価償却データを生成する。生成した減価償却データが記憶部403に記憶されると、制御部402は減価償却データの作成完了の通知を表示する。なお、減価償却データは申告書に添付す明細資料(例えば控除証明書等)である。
【0164】
「事業概況説明書作成」のアプリを起動されたら、担当者Aは事業概況説明書データを生成する。生成した事業概況説明書データが記憶部403に記憶されると、制御部402は事業概況説明書の作成完了の通知を表示する。なお、事業概況説明書データは申告書に添付する提出資料(例えば登記事項証明書や住民票等)である。
【0165】
「勘定科目内訳書作成」のアプリを起動されたら、担当者Aは勘定科目内訳書データを生成する。生成した勘定科目内訳書データが記憶部403に記憶されると、制御部402は勘定科目内訳書の作成完了の通知を表示する。なお、勘定科目内訳書データは申告書に添付する計算書類(例えば勘定科目内訳書等の各種内訳書や決算報告書等)である。
【0166】
「法人税申告書作成」のアプリを起動されたら、担当者Aは法人税申告書データを生成する。生成した法人税申告書データが記憶部403に記憶されると、制御部402は法人税申告書の作成完了の通知を表示する。担当者は表示された上記4つの通知を確認したら(S4−6)、4つの通知の確認ボタン(図示せず)を押す。制御部402が通知の確認ボタンが4つとも押されたことを検出することで申告書作成処理が終了する。
【0167】
制御部402は、業務進行テーブルの項目「ステップ6」の値「電子申告準備」を読み出し、アプリケーション情報テーブル(項目「アプリ名」は値「電子申告システム」、項目「データ形式」は値「申告データ」、項目「必要なデータ」は値「法人税申告書データ、減価償却データ、事業概況説明書データ、勘定科目内訳書データ、帳表データ」)を参照し、「電子申告システム」のアプリを起動する。
【0168】
「電子申告システム」のアプリを起動されたら、制御部402は記憶部403に記憶した法人税申告書データと減価償却データと事業概況説明書データ、と勘定科目内訳書データと帳表データを取り込むと、担当者は法人税申告書データと減価償却データと事業概況説明書データ、と勘定科目内訳書データと帳表データを元に電子申告用の申告データを生成する。
【0169】
生成した申告データが記憶部403に記憶されると、制御部402は申告データの作成完了の通知を表示する。担当者は表示された通知を確認したら(S4−6)、確認ボタン(図示せず)を押すと、制御部402は基本情報(項目「税理士名」)を参照して、承認用の端末に税理士へ申告データの署名依頼の通知を行なうことで電子申告準備処理が終了する。
【0170】
承認用の端末で税理士が署名依頼の通知を確認したら、制御部402は、業務進行テーブルの項目「ステップ7」の値「署名付与」を読み出し、アプリケーション情報テーブル(項目「アプリ名」は値「電子署名」、項目「データ形式」は値「署名済申告データ」、項目「必要なデータ」は値「申告データ」)を参照し、「電子署名」のアプリを起動する。
【0171】
「電子署名」のアプリを起動されたら、制御部402は記憶部403に記憶した申告データを取り込むと、税理士は申告データの内容を確認後、申告データに電子署名を行い、署名済申告データを生成する。署名済申告データが記憶部403に記憶されると、制御部402は署名済申告データの作成完了の通知を承認用の端末と担当者の端末に表示する。税理士は表示された通知を確認したら(S4−6)、確認ボタン(図示せず)を押すことで署名付与処理が終了する。
【0172】
担当者が署名済申告データの作成完了の通知を確認したら、制御部402は業務進行テーブルの項目「ステップ8」の値「提出」を読み出し、アプリケーション情報テーブル(項目「アプリ名」は値「電子申告システム」、項目「データ形式」は値「署名済申告データ」、項目「必要なデータ」は値「署名済申告データ」)を参照し、「電子申告システム」のアプリを起動する。
【0173】
「電子申告システム」のアプリを起動されたら、制御部402は記憶部403に記憶した署名済申告データを取り込むと、担当者は基本情報(項目「納税者」は値「B」、項目「組織情報」は値「法人」、「決算日」は値「○○年3月31日」、「税目」は値「法人税」、「納税先」は値「D税務署(URLを含む)」を、「税理士名」は値「S」)を参照して、署名済申告データに電子申告先情報(図示せず)を設定し、設定した電子申告先情報を表示する。
【0174】
具体的には制御部402は電子申告先情報に「納税者」と「処理年」と「税目」と「納付先」と「税理士」の項目からなり、項目「納税者」に値「B」を、項目「処理年」に値「○○年」(「○○年3月31日(決算日)」から生成)を、「税目」に値「法人税」を、「納税先」は値「D税務署(URLを含む)」を設定する。担当者Aが表示された電子申告先情報をチェック後、納税先に署名済申告データを提出し、納付先からの受信通知を受信していることを確認できたら、受信通知の受信済の通知を表示する。担当者は表示された通知を確認し、提出完了していることを確認したら(S4−6)、確認ボタン(図示せず)を押すことで提出処理が終了する。
【0175】
担当者Aに処理終了の通知を行っているが、担当者だけでなく、担当者の上司にも同時に通知してもよい。また、表示した通知を履歴として残し、後の工程(処理手順)で表示予定の通知や未確認の通知と一緒に工程順に並べて表示することで、アプリを起動しなくても通知履歴を確認するだけで現在の進捗状況を把握できる。具体的には、例えば工程が終了した通知をプログレスバーのように、処理の進行に合わせてバーが伸びるようにし、全ての工程が完了時にバーの長さが100%になるようにする。最初に担当者名(A)と対象と業務(電子申告業務)と進捗率(処理済の工程/全行程)と全ての工程の数だけ横長のバーをグレーアウト(無効化)の状態で表示しておき、1つの工程が終了(通知が表示)するたびにバーを伸ばしていく(有効化)ことで進捗状況をリアルタイムに視覚化することができる。
さらに、標準作業時間や実作業時間を表示してもよいし、月、週、日の予定作業量のバーを強調して実作業量と比較できるようにしてもよい。
【0176】
また、各ステップで担当者のアプリの操作の履歴とデータの処理の履歴を取っておき、各ステップでの処理時間(図示せず)を履歴と一緒にログ情報としてイベントログテーブル(
図3−2)に残す。イベントログテーブル(
図3−2)は「年月日」と「開始時刻」(図示せず)と「終了時刻」(図示せず)と「イベント内容」と「処理結果」(図示せず)と「アプリ名」(図示せず)と「データ形式」(図示せず)と「データID」(図示せず)と「担当者名」(図示せず)と「業務ID」(図示せず)と「処理ステップ」(図示せず)と「処理時間」(図示せず)の項目からなる。
【0177】
「年月日」と「開始時刻」と「終了時刻」は履歴の記録の開始日時と終了日時であり、「処理時間」が業務処理にかかった時間(処理時間は開始時間と終了時間から算出する)である。「イベント内容」は担当者のアプリの操作(例えば、顧問先Bの会社データ入力や顧問先Bの申告書データ作成の履歴であり、「処理結果」はデータの状態(アプリの処理結果)の履歴である。「処理ステップ」は担当者が履歴を取っている業務処理の処理手順であり、「アプリ名」は履歴を取っているアプリ名である。「データ形式」は履歴を取っているアプリが使用するデータの形式であり、「データID」は履歴を取っているアプリが処理しているデータを識別するものである。「業務フローID」は担当者が行う業務を識別するもので、「担当者名」は履歴を取っている業務処理を行なう担当者の名前を示す。
【0178】
また、AI等の学習モデルである分類器を記憶する記憶部403にある学習モデル記憶部(図示せず)を用意し、進捗管理学習モデルを用いたAIによる学習処理によって行ってもよい。
例えば、進捗管理学習モデルがイベントログテーブル(
図3−2)のログ情報を学習することで、各担当者のログ情報から最適な作業工数や作業の傾向(ミスしやすい作業やミスが多い作業等)を分析することで、担当者の作業工数の効率を高めることができる。
【0179】
具体的には、制御部402は担当者の職位(例えば、ベテラン、中堅、新人等)毎の業務処理手順との実作業時間を分析することで、ベテランの業務処理手順と作業時間を元に業務処理手順の標準化を行なうことができる。つまり、業務処理手順(処理項目の実行順序)と各処理項目の実行履歴(作業時間を含む)の組み合わせからトータルでの業務処理手順の作業時間が短くなる最適な組み合わせ(最適な処理項目の実行順序と各処理項目の作業時間(標準作業時間)の組み合わせ)が最も作業時間短くなるので1顧問先当たりの業務処理手順のトータルの作業工数と各処理項目あたりの作業工数を算出できる。
【0180】
また、標準作業時間に職位毎の熟練度係数(例えば、ベテランは0.8、中堅は1、新人は2)をかけることで、職位毎の標準作業時間(職位作業時間)を算出できるので、顧問先数と作業工数から必要な業務量を算出し、必要な業務量と担当者毎に担当者の力量に合わせた職位作業時間がスケジュール(表)に表示することができる。例えば、帳表作成の業務の標準作業時間が1.5時間とした場合に、担当者Aは中堅なので1.5時間、ベテランSは1.2時間(1.5時間×0.8)、新人Tは3時間(1.5時間×2)が職位毎の職位作業時間となる。担当者Aが昨日に帳表作成の業務に2時間かかっていることが履歴に残っているとすると、担当者Aの上司は担当者Aの業務の進捗が遅いことを客観的に把握できる。また、長期間各担当者の履歴を収集することで、得意な業務や苦手な業務等の担当者の傾向(得意な業務だと作業時間が短く、苦手な業務だと作業時間が長くなる)を上司が把握でき、担当者毎の指導に生かすことができるし、担当者毎の業務進捗の予定を可視化できる。
【0181】
税理士等の上司は役職(例えば、先生(有資格者)、番頭(責任者)、主任、一般、アルバイト等)によって、スケジュールの閲覧権限を設定する事で、役職が閲覧権限のある先生や番頭等は全ての担当者の情報が表示され、スケジュールに表示された必要な業務量と各担当者の職位作業時間から必要な担当者の数を算出でき、各担当者に適切な量の業務を割り当てることができる。例えば、繁忙期であれば処理優先で、担当者に得意な業務を割り当てるのに対し、閑散期は担当者のスキルアップ優先で、担当者が苦手な業務や新しい業務を割り当てたりする等の事務所の状況に応じて担当者の業務をスケジュールできる。
また、役職が閲覧権限のない主任、一般、アルバイト等は自分の情報のみがスケジュールに表示される。
【0182】
また、担当者がスケジュール表から月単位、週単位、日単位で最適な業務処理手順(作業手順)及び標準作業時間と実際の業務処理手順及び実作業時間を並べて表示に切り替えることで、担当者の進捗状況と作業効率を視覚化できる。また、担当者毎に時間がかかっている作業や間違った作業や効率の悪い作業等の問題のある作業を抽出する。例えば、担当者Aが帳表作成業務が苦手な業務だった場合に、抽出された作業を分析することで手順のどこにつまずいているかの原因が入力が遅いためなのか、処理手順を理解していないからなのか等がわかるので、上司は具体的な改善策を担当者に指導することができる。
【0183】
また、実際の業務処理手順で問題のある作業について強調したり、色を変えたりすることで、問題点を視覚化でき、さらに問題のある作業を選択することで、改善方法等(正しい手順やコツ等)を表示することで、担当者は自分で気づかない無駄な作業を客観的に把握でき、改善することができる。
【0184】
また、担当者が繰り返し作業ミスを行っている部分やミスしやすい作業(分析結果から全体的にミスの多い作業を抽出)については予め改善方法をガイド表示することで、ミスを事前に防止するようにしてもよい。
【0185】
また、問題のある作業や改善の数を毎日集計することで、担当者の仕事の取り組み姿勢を定量化でき、改善が少ない担当者には警告を表示することで、担当者の業務改善を促すことができる。
【0186】
このように、実施例6で記載されている業務処理手順は、作業手順と同一の意味を持つものであり、会計事務所の作業手順通りに円滑に進める支援をしているため、業務処理手順を実行(作業手順実行)する会計処理装置であって、具体的に作業手順実行装置や作業手順実行支援装置として読み替えることも可能である。
【0187】
本発明では、業務処理の処理手順をあらかじめ作業項目(業務処理)として設定する事で、作業項目の作業手順(業務処理の処理手順)を設定し終了時に通知する事で、業務を定型化することができる。また、業務処理の処理手順毎に担当者が意識せずに必要なアプリとデータを用意され、処理終了の通知を行なうことで、担当者がデータの転送や返却等の複雑な処理を意識せずにあたかも一筆書きのようにシステム化された進捗管理を行なうことができる。また、担当者の業務の作業を標準化することでき、改善状況も定量化できるので、スケジュールに合わせて最適な人数の担当者を割り当てができ、各担当者の進捗状況も一括で管理できる。
【0188】
以上、本発明は、上述した実施例に限定されるものではなく、例えば、正常に動作ができる前提で上述したものであり、本来はイリーガルな動作をした時の対処方法も考慮すべきものだが、様々な手法で回避できるため、詳細な説明は省略する。また、実施例に記載した効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施例に記載したものに限定されない。なお、上述した実施例は、適宜組み合わせて用いることもできるが、詳細な説明は省略する。
また、顧問先から受信したデータや資料を活用することで、顧問先における実務の省力化・精度向上、緊密な連携が出来るようになるため、入力作業を大幅に削減し、監査以降のよりサービス付加の高い業務に注力できる。 以上のようなメリットを持つ会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供するという効果を有すため、会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法等として有用である。