JP2002024515A - 売上情報管理システム - Google Patents

Abstract

(57)【要約】 【課題】 各国の売上情報の入力を現地通貨で行うこと
ができ、ユーザは短時間で必要な売上情報を入手できる
売上情報管理システムを提供すること 【解決手段】 海外の営業拠点２ａ，２ｂ，…から、売
上情報を現地通貨で受け取り、その現地通貨を換算部１
２にて基軸通貨（日本円）に換算する。換算は、予め記
憶された為替レートに従って実行する。基軸通貨での日
々の売上情報を用い、多次元データベース処理部１８が
複数の検索軸に従って各軸の積み上げ処理を行い、多次
元データベースを作成し保持する。サーバアプリケーシ
ョン１６は、この多次元データベースと、通貨レートマ
スタ１７をアクセスし、現地通貨に戻したり、戻した一
定の期間内の現地通貨の売上情報に対し同一の為替レー
トで再度基軸通貨に換算し、為替レートの影響を受けな
い推移情報を求める。ユーザからの要求に従い、予め用
意したデータから必要なものを抽出し出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、売上情報管理シ
ステムに関するものである。

【０００２】

【発明の背景】昨今の企業のグローバル化や、販売先
（顧客）の国際化にともない、事業の収益は、為替レー
トが無視できなくなっている。つまり、例えば日本に本
社のある会社がある商品を日本で生産し、世界各国に輸
出するような場合、製造原価が一定で、現地での販売価
格も一定だとしても、為替レートが変動すると、収益は
変動する。

【０００３】従って、本社で各国ごとの収支や、ある商
品，事業部が全世界でどのように収益をあげているかを
チェックする場合には、例えば、為替レートに基づいて
日本円に換算した値で評価することになる。よって、通
常は、各国の日々の売上データを取得するとともに、為
替レートに基づいて円に換算したデータをデータベース
に格納する。そして、このように１つの通貨で各国の売
上データを管理することにより、収益が上がっている国
や逆に収益が下がっている国を簡単に把握することがで
きる。また、このように為替レート換算をしてデータを
保管することは、会計処理の上で一般に行われることで
ある。

【０００４】しかしながら、上記のような会計処理上必
要なデータのみでは、正確な経営判断ができないことが
ある。すなわち、例えば、ある外国において、ある商品
が毎月同じ数量ずつ売れていた場合には、米国における
その商品についての売上金額は、毎月同じになる。この
とき、為替レートが変動すると、日本円に換算した場合
の売上金額は毎月変動することになる。また、仮にある
外国におけるある商品の売上数量が徐々に減少している
ような場合でも、為替レートが徐々に円安に移行してい
るような場合には、日本円に換算した売上金額は、横ば
いであったり、増加するようなことがある。

【０００５】このようなことは、経理上は問題がない
が、その商品の販売・生産計画などを立てる場合に問題
が生じる。すなわち、前者の場合には、安定して売れて
いるのにもかかわらず、その月によって販売数が変動し
ているように思え、売上額（販売数量）が減少した理由
を考え、対策を図ろうとする無駄な労力をかけてしまう
おそれがある。また、後者の場合には、本来はその商品
の販売数量が減ってきているにもかかわらず、売上が伸
びており、消費者に受け入れられているという誤認識を
してしまい、生産台数を増加して多くの在庫を抱えるお
それがある。

【０００６】このように、会計処理に必要なデータで
は、現地での実際の販売状況をつかむことができず、各
商品ごと，国ごと等のトレンド予測を正確に行うことが
できない。特に、扱い数量が少量であれば、例えば、現
地通貨のデータや、販売数量その他の必要なデータを全
て保存しておき、検討する際に保存したデータから必要
なものを抽出し、各種計算などして集計した集計表を生
成し出力すれば対応できる。しかし、世界各国に販売す
るような会社の場合、取扱商品も数千から数万種類に及
び、販売先の国数も数十ヶ国に及ぶことが多々ある。

【０００７】すると、必要なデータを全て保存するため
には、多くの記憶容量が必要となるばかりでなく、実際
に必要なデータを抽出するために検索処理をすると、サ
ーチ対象のデータ数が大量に存在するため、瞬時にデー
タを見ることができず、例えば、実行命令を与えてから
最終的に集計表が出力されるまでに数十分さらには１時
間以上もかかることがある。

【０００８】さらにまた、日本以外の国で、他国の売上
情報を見たいという要求がある。この場合には、自分の
国の通貨で見ることができると、直感的に理解し易いの
で好ましい。しかし、そのようにすると、各国間での為
替レートも記憶保持しなければならず、データ管理並び
に処理が煩雑となる。

【０００９】この発明は、世界各国での売上情報を現地
通貨で受け取り、総合的にデータ処理してデータベース
化することにより、そのデータベースを利用するユーザ
にとって、出力された売上情報が理解しやすく、しか
も、短時間で必要な情報を得ることのできる売上情報管
理システムを提供することを目的とする。

【００１０】

【課題を解決するための手段】この発明による売上情報
管理システムでは、現地通貨と基軸通貨との間の換算を
行う為替レートを記憶するレート記憶部と、受け取った
現地通貨での売上情報から、前記レート記憶部に記憶さ
れた為替レートを利用して基軸通貨での売上情報を算出
する手段と、前記算出された基軸通貨での売上情報に対
し、複数の検索軸に従ってデータの積み上げを行い、多
次元データベースを作成するデータベース作成手段と、
そのデータベース作成手段により作成された多次元デー
タベースに記憶されたデータに基づく売上情報を出力す
る出力手段とを備える。そして、前記データベース作成
手段は、所定のタイミングで予め実行し作成しておくよ
うにした。

【００１１】ここで、レート記憶部は、実施の形態で
は、レートマスタ１２ａに対応する。また、売上情報を
算出する手段は、換算部１２に対応する。また、出力手
段は、サーバアプリケーション１６に対応する。さら
に、データベース作成手段が実行する所定のタイミング
は、実施の形態では夜間である。もちろん、これの実施
例に限定されるものではなく、例えば、所定のタイミン
グは、最終的にユーザから各種データの検索・出力要求
が有る前に稼動し、多次元データベースを予め作成して
おければ良い。また、「基軸通貨」は、売上情報管理シ
ステムにおいて、各国から送られてくる売上情報に対し
て加算その他のデータ処理をする際に使用する単一の通
貨であり、現地通貨と基軸通貨は、為替レートに従って
換算処理される。

【００１２】この発明によれば、各国からは、現地通貨
でデータの入力ができ、システム内では、レート記憶部
に記憶した為替レートに従って換算処理して単一の通貨
で各売上情報を求める。よって、システム内での処理が
容易になる。また、予め多次元データベース化処理をし
ておくことで、ユーザが見たい検索条件の入力を受ける
と、多次元データベースから必要な検索軸に基づくデー
タを抽出することにより、短時間で必要なデータを出力
することができる。そして、売上情報を、多次元データ
ベースとして管理すようにしたことから、多岐にわたる
検索条件の要求に対しても対応することができる。

【００１３】また、前記データベース作成手段で作成さ
れた前記基軸通貨に基づく多次元データベースに記憶さ
れたデータに対し、前記為替レートを利用して各現地通
貨での売上情報を生成する現地通貨売上情報生成手段を
備え、前記出力手段は、前記基軸通貨での売上情報と、
前記現地通貨での売上情報のいずれも出力可能とするこ
とができる。現地通貨売上情報生成手段も、実施の形態
では、サーバアプリケーション１６内の一つの機能とし
て実現されている。なお、現地通貨売上情報生成手段で
使用する「前記為替レート」は、現地通貨と基軸通貨と
の間の換算処理を行うための為替レートを意味し、必ず
しも、「基軸通貨での売上情報を算出する手段」で使用
する為替レートと同一のレート記憶部内に格納されたも
のを使用する必要はない。実施の形態で示すように、レ
ートマスタ１３ａと通貨レートマスタ１７のように別々
の記憶部に格納したものを使用することもできる。もち
ろん、同一の記憶部に格納したものを共通して使用する
ようにしても良い。

【００１４】このようにすると、換算して求めた基軸通
貨に基づく売上情報は、為替レートを用いることによ
り、任意の現地通貨に戻すことができる。よって、使用
者は自国で使用する現地通貨で情報の入力を行い、各国
から収集され、統計された売上情報を見る場合にも、戻
し処理により自国の通貨で見ることができる。よって、
ユーザは、直感的に売上情報の内容を理解することがで
きる。

【００１５】そして、前記現地通貨売上情報生成手段
は、ユーザからの要求を受けて必要な基軸通貨での売上
情報に対して戻し処理を行うようにしてもよいし、多次
元データベース作成後に稼動し、予め前記現地通貨での
売上情報を作成し記憶保持するようにしてもよい。特に
後者のようにすると、ユーザからの要求に対して、迅速
に応答することができる。

【００１６】さらに、前記現地通貨売上情報生成手段に
より、売上のあった現地の通貨での売上情報に戻された
売上情報に基づいて、売上の推移情報を求める推移算出
手段を設けると好ましい。現地通貨に戻された売上推移
情報は、為替レートの変動文が含まれていない。従っ
て、その現地での売れ行き情報を知ることができる。

【００１７】さらにまた、前記推移算出手段は、基軸通
貨に換算した推移情報を得るに際し、１つの現地通貨に
使用する為替レートを１つに固定して求めるようにする
とよい。このようにすると、為替レートの影響を受けな
い現地での売上状況を、基軸通貨で知ることができる。

【００１８】そして、前記推移算出手段は、ユーザから
の要求を受けて必要な現地通貨での売上情報を読み出し
て実行するようにしても良いし、前記現地通貨売上情報
による前記現地通貨での売上情報の生成後に稼動し、予
め前記推移情報を作成し記憶保持するようにしてもよ
い。特に後者のようにすると、ユーザからの要求に対し
て、迅速に応答することができる。

【００１９】さらに、上記した各発明において、世界各
国に点在するクライアントとの間でデータの送受を可能
とするインタフェースを備え、前記出力手段は、前記ク
ライアントからの出力要求に従い、その出力要求に適合
するデータを抽出するとともに前記出力要求の有ったク
ライアントに向けて出力するようにするとよい。

【００２０】この発明の以上説明した構成要素は可能な
限り組み合わせることができる。この発明による売上情
報管理システムを構成する各手段を専用のハードウエア
回路によって実現することができるし、プログラムされ
たコンピュータによって実現することもできる。さらに
は、単一のコンピュータで構成してもよいし、複数のコ
ンピュータで実現し、それらを連携することにより構成
することもできる。

【００２１】

【発明の実施の形態】図１は、本発明の好適な一実施の
形態を示している。本形態では、本店１（この例では、
本店は日本に存在する）と、世界各国に営業拠点２ａ，
２ｂ，…（以下、各営業拠点を区別する必要がない場合
には、代表して符号「２」と記す）が存在し、それら本
店１並びに各営業拠点２から、日々、売上情報等が売上
情報管理システム１０に入力される。売上情報管理シス
テム１０では、受け取ったデータに基づき、必要なデー
タを生成してデータベース化し、各ユーザ、つまり、本
店１，各営業拠点２から、売上情報管理システム１０に
対してアクセスすると、必要な売上情報を取得すること
ができるようになっている。具体的には、以下の通りで
ある。

【００２２】まず、本店１，営業拠点２は、それぞれ、
個々に売上情報管理システム１０と接続され、データの
送受が行われる。この接続形態は、各種の通信回線を利
用したり、インターネットその他のネットワークを利用
してリアルタイムでデータ送信を行うことができる。ま
た、国際ＶＡＮなどを利用し、それぞれが所望のタイミ
ングでデータ通信を行うことにより、送信元から国際Ｖ
ＡＮに一旦データが格納され、送信先（受信側）がその
国際ＶＡＮからデータを受け取るようにしても良く、各
種の態様がとれる。

【００２３】そして、送信するデータのフォーマット，
プロトコルの共通化を図り、それ以外、つまり、本店１
や営業拠点２で取得したデータの利用や、売上情報管理
システム１０に送信するデータの生成や、そのデータを
含む売上その他の各国の国内管理システムは、本店１，
各営業拠点２の自由とした。これにより、各国ですでに
作成し、稼動しているシステムをそのまま使用するか、
一部の手直しをするだけで対応できるようになる。

【００２４】売上情報管理システム１０は、本システム
上で各種の売上情報を求める際に基準として使用する通
貨である基軸通貨に対する各国の現地通貨の実勢レート
を与える為替レート入力部１１と、本店１や営業拠点２
から現地通貨で送られてくるその国での売上情報を受け
取り、基軸通貨に換算する換算部１２と、それら為替レ
ート入力部１１，換算部１２で得られたデータを記憶す
るデータウェアハウス１３と、そのデータウェアハウス
１３に格納されたデータに基づいて、所定の演算処理を
し、必要なデータを生成するとともに記憶し、さらに本
店１や各営業拠点２からの要求に応じて必要なデータを
出力するアプリケーション１４を備えている。そして、
各処理部１１〜１４は、同一の装置内に組み込まれてい
ても良いし、別々の装置（サーバマシン等）で構成した
ものを例えばＬＡＮなどで接続するようにしても良い。

【００２５】為替レート入力部１１は、売上情報管理シ
ステム１０に設けられた入力装置、或いは本店１等から
与えられた実勢レートを、そのレートが適用される日
付，現地通貨と関連付けて、データを蓄積・収集するデ
ータウェアハウス１３のレートマスタ１３ａに格納する
（図２参照）。

【００２６】換算部１２は、営業拠点２からその日の売
上情報（現地通貨）を受け取ったならば、レートマスタ
１３ａから、基軸通貨に対する為替レートを取得し、レ
ート換算して基軸通貨での売上情報に変換し、データウ
ェアハウス１３の売上マスタ１３ｂに登録する。このと
き、売上マスタ１３ｂに登録する際のデータ構造として
は、売上の上がった国名，日付，商品情報，売上金額
（基軸通貨）を関連付けている。そして、商品情報とし
ては、商品名，その商品を扱う本店１内の統括事業部
名，事業部名，部名，課名，形式，商品コード等があ
る。なお、この商品情報は、例えば商品コードと、それ
に関連する各種情報を関連付けた商品情報テーブルを用
意しておき、営業拠点２等からは、商品情報に関しては
商品コードのみを受け取り、その受け取った商品コード
に基づき、上記商品情報テーブルから必要な商品情報を
読み出すようにしても良い。

【００２７】また、本形態では、営業拠点２等からの現
地通貨での売上情報を、変換部１２を経由し、基軸通貨
への変換後の売上情報をデータウェアハウス１３に格納
するようにしたが、本発明はこれに限ることはなく、ま
ず、現地通貨での売上情報をデータウェアハウス１３に
格納し、変換部１２は、データウェアハウス１３から必
要な情報を読み出し、為替レートで基軸通貨に変換後に
売上マスタ１３ｂに登録するようにしても良い。なお、
本形態のように、直接現地通貨での売上情報を変換部１
２で受けるようにした場合でも、現地通貨に基づく売上
情報をデータウェアハウス１３に格納するようにしても
もちろんよい。

【００２８】アプリケーション１４は、データウェアハ
ウス１３に格納されたデータ等を利用し、定型検索等を
行うためのもので、具体的には、図３に示すような構造
を採っている。すなわち、多次元データベースを作成す
るとともに、その作成結果を記憶保持する定型検索アプ
リケーション１５と、その定型検索アプリケーション１
５で作成された多次元データベースを利用し、さらに必
要なデータを演算して求めるサーバアプリケーション１
６を有している。そして、定型検索アプリケーション１
５内には、通貨レートマスタ１７と、多次元データベー
ス処理部１８を有している。

【００２９】まず、通貨レートマスタ１７は、データウ
ェアハウス１４内のレートマスタと同様に、各月，或い
は月日における基軸通貨（日本円）と、各国の現地通貨
との為替レート（実勢レート）を関連付けて記憶保持す
るものである。本形態では、常に基軸通貨を基準にして
各種のレート換算を行うため、保持するレートも基軸通
貨に対するもののみでよく、例えば、日本以外のある国
の現地通貨と、別の国の現地通貨との間の為替レートは
記憶しない。このようにすることにより、記憶保持する
データ数を大幅に削減できる。なお、日本以外の国の現
地通貨同士の比較は、一旦基軸通貨に変換した状態で行
うことにより対応できる。

【００３０】多次元データベース処理部１５は、多次元
データベースを作成するソフト（アプリケーション）
と、それにより作成された多次元データベースを記憶す
る記憶エリアとを有している。ここで、多次元データベ
ースは、多次元分析を行うために、データウェアハウス
１４から必要なデータをロードする際に、予め定義され
た検索軸の階層に従った積み上げ計算を同時に行うもの
である。換言すると、例えば、検索軸を商品単位とする
と、各商品ごとについて、基軸通貨である日本円での各
月（毎日）ごとの売上データを、営業拠点ごとに積み上
げるとともに、所定の期間ごとの合計値も算出する。

【００３１】つまり、概念的には、ある商品Ａについて
の積み上げを行った場合には、図４に示すように、その
商品についての各営業拠点ごとの基準通貨での売上が、
月単位（図示の例では便宜上月単位としているが、日々
の売上の場合もある）が、一覧表の形式で出力表示でき
るようにデータベース化する。なお、例えば一年ごと、
今期分の総計データも併せて持つようにしてもよい。ま
た、図示の例では、欧州，北米等のように広範囲な営業
拠点についてデータを示しているが、欧州の中でも、例
えば、ドイツ，フランス，イタリア…のように各国単位
の売上情報を求めるようにしてもよい。

【００３２】さらに、この例では、商品ごとについて説
明したが、同一シリーズの商品郡ごとに積み上げを行っ
たり、本店の事業部ごとに積み上げを行ったりする他、
各種の検索軸に基づいて予め該当するデータの積み上げ
を行い、データベース化する。このように検索軸が多数
に及ぶことから、多次元データベースと称する。

【００３３】なお、検索軸の一例を示すと、図５に示す
ように部門を基準とした階層では、第１階層である本店
並びに営業拠点のそれぞれの下に第２階層である統括事
業部があり、さらにその下に第３階層である事業部，第
４階層である部，第５階層である課を順次設置する。各
階層の関係の具体例を示すと、例えば本店（日本）の下
に、システム機器統括事業部，健康機器統括事業部，営
業統括事業部（第２階層）などがある。また欧州の下に
は、第２階層としてドイツ支店，フランス支店，イタリ
ア支店などがある。そして、システム機器統括事業部の
下には、第３階層してコントローラ事業部（ＡＢＣ事業
部），センサ事業部，…などがある。また、ドイツ支店
の下には、第３階層としてミュンヘン営業所，ベルリン
営業所などがある。さらに、他の統括事業部の下にも第
３階層の各事業部がある。

【００３４】一方、商品の階層としては、図６に示すよ
うに第１階層として担当事業部（例えば、ＡＢＣ事業
部）があり、第２階層としては商品群（例えばコントロ
ーラ：ＳＧ））があり、第３階層には商品名（商品Ａ，
商品Ｂ，商品Ｃ，…）があり、第４階層には各商品の形
式（例えば標準タイプ，高速タイプ，…）がある。

【００３５】そして、多次元データベース処理部１５
は、例えば毎日夜間の空き時間に稼動し、日々入力され
る売上情報に基づいて最新の多次元データベースを作成
し、記憶保持する。

【００３６】サーバアプリケーション１６は、基軸通貨
である日本円で生成された多次元データベースから、必
要な検索軸についてのデータを抽出するとともに、基軸
通貨で標記された売上データを現地通貨に換算する戻し
処理と、売上の推移情報の算出処理や、総売上データの
算出を行う。さらに、国内外のユーザ、つまり本店１や
営業拠点２からの要求に応じて、必要なデータを抽出す
るとともに、モニタに表示可能な状態で出力する機能も
有する。

【００３７】上記した戻し処理は、通貨レートマスタ１
７に格納された基軸通貨と現地通貨の為替レートに従っ
て算出する。すなわち、例えば、１９９９年の１２月の
為替レートが、１ドル（ＵＳ）が９８．５円（日本円）
で、図４に示すように、多次元データベースに格納され
た商品Ａの北米での売上金額が１５００円とする。する
と、サーバアプリケーション１６では、「１５００円÷
９８．５円」を実行し、１５．２ドルを得る。

【００３８】係る処理を、例えば、多次元データベース
で求められた全ての基軸通貨でのデータを、現地通貨に
戻す処理をすることにより、各現地通貨での多次元デー
タベースが構築される。つまり、実際の多次元データベ
ース処理は、基軸通貨に基づくデータに対して１回だけ
行って基軸通貨で表現される多次元データベースを作成
し、さらに、作成された多次元データベース中の基軸通
貨を、それぞれの現地通貨に戻し処理することにより、
簡単に各現地通貨での多次元データベースを作成するこ
とができる。

【００３９】各売上情報を自国の通貨で見た方が感覚的
に理解しやすい。そして、本形態によれば、上記戻し処
理を行うことにより、各国のユーザは、各検索軸に基づ
く売上データを自国の現地通貨で見ることができるの
で、使い勝手が良い。なお、この戻し処理は、多次元デ
ータベース処理部１５の実行に伴う多次元データベース
の生成後、予め全ての現地通貨に基づくデータベースを
作成していても良いし、基軸通貨以外でのデータ出力が
要求された際に、指示された検索軸に基づくデータを抽
出し、戻し処理を行うようにしてもよい。

【００４０】また、推移情報の作成は、一旦上記戻し処
理により売上の上がった国の現地通貨に戻し、その現地
通貨での推移情報（最新月の売上高を１００％とした場
合の過去の月ごとの売上の推移）を求める処理を実行す
る。さらに、基軸通貨への変換は、推移情報を比較する
各現地通貨での売上データに対し、予め定めた基軸通貨
への単一の為替レート（固定レート）に従ってレートの
換算処理を行うことにより、推移情報を見るための各月
ごとの売上高（日本円）を求め、さらに、最新月の売上
高を１００％とした場合の過去の月ごとの売上の推移情
報を求める。ここで、使用する単一の為替レートは、本
形態では、最新月の為替レートとしたが、予め固定した
ものでも良い。

【００４１】このようにすると、現地通貨での推移情報
はもちろんのこと、基軸通貨である日本円で換算した場
合の各月の売上も、単一の為替レートを用いることによ
り為替の変動の影響を受けない純粋な現地での売上の変
動を反映したデータとなる。つまり、現地での売れ筋商
品などのトレンド把握が正確に行える。

【００４２】なお、この推移情報の作成処理も、多次元
データベース処理部１５の実行に伴う多次元データベー
スの生成後、予め全ての現地通貨に基づくデータベース
を作成していても良いし、基軸通貨以外の国の推移情報
の出力が要求された際に、指示された検索軸に基づくデ
ータを抽出し、推移情報の作成処理を行うようにしても
よい。

【００４３】上記した戻し処理並びに推移情報の作成
と、その効果を具体例をあげつつ説明する。説明の便宜
上、北米の営業拠点２ｂと欧州の営業拠点２ａについて
売上情報があったものとする。そして、入力されたり、
算出されたりする各データは、図７に示すようなものが
あり、必ずしも全てのデータを算出したり、記憶する必
要はない。なお、図７に示す情報のうちの一部は、本形
態の効果を説明するために便宜的に示したものがある。
また、図７に示す各項目の具体的なデータの例として
は、例えば図８のようになる。そして、この例示したデ
ータは、実際には多次元データベースを構成するある検
索軸に従って積み上げされたデータの一部となる。

【００４４】内容を簡単に説明すると、図７に示すよう
に、まず、現地通貨は北米のドル（ＵＳＤ）と、欧州の
ユーロ（ＥＵＲ）となるので、それぞれの基軸通貨に対
する実勢レートは、実勢レートＵＳＤが「円／ドル」
（Ａ），実勢レートＥＵＲが「円／ユーロ」（Ｂ）とな
る。図８に示すように、この２つの実勢レートＡ，Ｂ
は、為替レート入力部１１から与えられ、データウェア
ハウス１３内のレートマスタ並びに定型検索アプリケー
ション１５内の通貨レートマスタ１７内に格納される。

【００４５】北米（ＵＳ）での売上（Ｃ）と、欧州（Ｅ
Ｐ）での売上（Ｇ）は、それぞれ現地通貨で売上実績と
して入力され、データウェアハウス１３に格納される。
そして、それら現地通貨の売上に、各実勢レートを掛け
ることにより、それぞれの日本円に換算した売上（Ｅ，
Ｆ）が求められる。この基軸通貨である日本円に換算し
た売上（Ｅ，Ｆ）に基づいて、多次元データベース処理
がなされ、データベースとして記憶保持される。つま
り、定型検索アプリケーション１４内には、上記した実
勢レート（Ａ，Ｂ）と、日本円換算売上（Ｅ，Ｆ）が記
憶保持されることになる。

【００４６】また、各売上の推移情報は、算出対象の各
月の売上を固定月の売上で割ることにより求められる。
現地通貨に基づく推移情報（Ｄ，Ｈ）と、基軸通貨であ
る日本円に換算した推移情報（Ｆ，Ｊ）がある。なお、
実際には、これら売上情報は、多次元データとして保存
される。

【００４７】なお、この推移情報を求める各月の基軸通
貨での売上は、それぞれ、その月の実勢レートで換算処
理した値であるので、為替変動の影響を受けたものであ
る。すなわち、例えば図８のＵＳでの売上（Ｃ）は、毎
月同一金額であるので、その売上の推移情報（Ｄ）も１
００％で一定となる。しかし、為替の変動により各月の
基軸通貨での換算売上が変動する（Ｅ）ので、その基軸
通貨での換算売上（Ｅ）も変動する。よって、各月の基
軸通貨での換算売上に基づく推移情報（Ｆ）も、変動す
る。つまり、本来は、現地での売上は一定であるにもか
かわらず、基軸通貨での換算売上に基づく推移情報
（Ｆ）を見てトレンドの評価を行うと売れ行きが変動
し、安定しない商品であると認定されてしまうおそれが
ある。

【００４８】逆に、欧州の場合には、現地での売上実績
（Ｇ）は変動しているにもかかわらず、基軸通貨での換
算売上に基づく推移情報（Ｊ）は、ほぼ一定の値をとり
（２０００年３月を除く）、安定した商品であるという
ように誤った認定が行われるおそれがある。しかも、例
えば２０００年３月では、現地での実際の売上が低下し
ているにもかかわらず、基軸通貨での換算売上に基づく
推移情報（Ｊ）では、逆に増加し、トレンド把握をした
場合には、人気が有って売れ筋商品になりつつあるなど
の誤認定をされるおそれがある。

【００４９】現地通貨通常戻し（Ｋ，Ｏ）は、ここで
は、推移情報を求めるために、売上の上がった国の現地
通貨での売上情報に戻す処理を行う。すなわち、北米の
営業拠点２ｂの売上実績（Ｃ）に基づく日本円換算売上
（Ｅ）に対しては、該当する月の対北米（アメリカ）の
実勢レートＵＳＤ（Ａ）で割る（Ｅ／Ａ）ことになる。
これにより、その月の実勢レートを用いて、現地通貨で
の売上を割った後、同一の実勢レートをさらに掛けるこ
とになるので、当然のことながら、通常戻し処理を行っ
て得られた各値（Ｋ，Ｏ）は、それぞれ元となる現地で
の売上（Ｃ，Ｇ）と同一の値となる。

【００５０】なお、この推移情報のためとは別に、各国
のユーザが、他の国の売上情報を見るために、基軸通貨
から所定の現地通貨に戻し処理することも有る。この場
合には、当然のことながら、実際に売上のあった地域と
の関連はなく、例えば、北米での売上実績に基づく日本
円換算売上（Ｅ）に対して、例えば実勢レートＥＵＲを
用いて戻し処理をすることも有る。

【００５１】また、推移情報は、各月の売上を固定月の
売上で割ることにより求めるので、現地通貨での推移情
報（Ｌ，Ｐ）は、現地通貨通常戻し処理をして得られた
各月の現地通貨での売上の推移情報は、現地での売上実
績の変動をそのまま表すことになる。つまり、北米の営
業拠点２ｂの場合（Ｌ）には１００％一定であり、欧州
の営業拠点２ａの場合（Ｐ）には、逆に変動しているこ
とがわかる。

【００５２】そして、本形態では、最終的には基軸通貨
でトレンド把握を正確に行うことを目的としているの
で、通常戻し処理をした各月の売上（Ｋ，Ｏ）に対し
て、同一の実勢レート（最新レート）を掛けることによ
り、為替レートの影響を受けない基軸通貨での換算売上
（Ｍ，Ｑ）が求められる。そして、この換算売上（Ｍ，
Ｑ）に基づく推移情報（Ｎ，Ｒ）を求めると、図８に示
すように、現地通貨の売上推移情報（Ｄ，Ｈ）と同様の
値を採ることができる。

【００５３】また、総売上は、各国の売上情報を基軸通
貨に換算して通貨を統一した後で加算することにより求
めることができるが、このとき、加算する各月の基軸通
貨での換算は、その月の実勢レートを用いる方法（Ｓ）
と、固定レート（最新月の為替レート）に基づいて各月
を再度演算処理する方法（Ｕ）がある。そして、各方法
（Ｓ，Ｕ）で求めた基軸通貨での換算値に基づいて、そ
れぞれ固定月（最新レート）で割ることにより求められ
る推移情報（Ｔ，Ｖ）は、それぞれ図示するようにな
る。図から明らかなように、最新固定レートで換算した
固定月（最新レート）で割ることにより求められる換算
値の推移情報（Ｖ）は現地で売れている場合には高い値
をとり、現地で売れ行きが悪い場合には低い値をとるよ
うになり、トレンド把握が容易にできる。

【００５４】つまり、データＮ，Ｒを見ることにより、
各国（営業拠点２ａ，２ｂ）ごとの、商品の売上状況の
把握（トレンド把握）を、為替変動の影響を受けること
なく正確に、しかも基軸通貨（日本円）に基づいて直感
的に理解することができる。また、同様に、データＵを
見ることにより、全世界の総トータルでのトレンド把握
を、為替変動の影響を受けずに行うことができる。もち
ろん、データＮ，Ｒ，Ｕを所望の通貨に換算することに
より、各自の使用する通貨に基づいて理解することがで
きる。

【００５５】次に、図９，図１０を用いながら、本シス
テムの処理の手順を説明する。まず、各営業拠点２や本
店１から、現地通貨での売上情報が入力されるので、そ
れを受け取るとともに、データウェアハウス１３内の所
定の記憶領域に格納する（ＳＴ１，ＳＴ３）。同様に、
為替レート（図７，図８の（Ａ），（Ｂ））が本店１等
から与えられるので、為替レート入力部１１を介して日
付と、使用国名と、為替レートを受け取り、データウェ
アハウス１３内に格納する（ＳＴ２，ＳＴ３）。

【００５６】そして、データウェアハウス１３では、日
々入力される各種のデータに対し、月日ごとの売上集計
を求めデータベース化する（ＳＴ４）。さらに、換算部
１２を用いて、現地通貨での売上を、基軸通貨である日
本円に換算し、保持する（ＳＴ５）。このようにして、
データウェアハウス１３には、各種の情報が収集・管理
される。

【００５７】次いで、定型検索アプリケーション１５で
は、データウェアハウス１３に格納された基軸通貨に対
する各通貨の実勢レート（Ａ），（Ｂ）を読み出し、通
貨レートマスタ１７にデータベース化して記憶保持され
る（ＳＴ６）。また、ステップ５で求めた換算値を用
い、基軸通貨での売上（Ｅ），（Ｉ）に基づいて多次元
データベース処理部１８を実行し、予め定めた各検索軸
についての積み上げを行い、多次元データベースを作成
する（ＳＴ７）。つまり、金銭に関しては、為替情報
（実勢レートＡ，Ｂ）と、基軸通貨での売上（Ｅ，Ｉ）
が、定型検索アプリケーション１５内に記憶保持され
る。もちろん、商品情報や、日付などの解析に必要な情
報も記憶保持される。

【００５８】さらに、サーバアプリケーションソフト１
６が、多次元データベースから必要な情報を抽出し、予
め決まった計算式を実行する（ＳＴ８）。つまり、上記
した現地通貨への戻し処理（Ｋ，Ｏの算出）や、固定の
為替レートに基づいて換算処理された日本円での売上
（Ｍ，Ｑ）や、その推移情報（Ｎ，Ｒ）の算出や、為替
変動の影響を加味した総売上データ（Ｓ）並びに為替変
動の影響を受けない総売上データ（Ｕ）及びそれらの推
移情報（Ｔ，Ｖ）の算出処理などを実行する。さらに
は、ステップ７で作成された多次元データベース中の各
基軸通貨による金額欄を、各現地通貨に戻す処理なども
ある。そして、上記のようにして求めることにより生成
されるデータを、多次元データベースの形式で記憶保持
する（ＳＴ９）。このステップ５から９の処理を、夜間
に行う。

【００５９】各営業拠点２や、本店１等のクライアント
からのデータ表示要求に従って、サーバアプリケーショ
ン１６は、多次元データベースを検索し、所定の検索軸
に従って格納されデータを抽出する（ＳＴ１０，ＳＴ１
１）。このとき、本形態では、予め多次元データベース
を作成し、表示すべきデータはすでに計算して記憶して
いるので、クライアントからの要求に際しては、条件に
合致する検索軸を抽出し、その検索軸についてのデータ
を読み出せば良いので、短時間で条件を抽出することが
できる。

【００６０】なお、クライアントからの入力要求は、例
えば図１１に示すような条件入力画面をクライアントの
モニタに表示し、空欄内に絞り込む条件の入力を待つ。
なお、図中「軸」は、検索軸の意味であり、「Ｄｉ
ｖ．」は「Ｄｉｖｉｓｉｏｎ：部門」，「Ｐｒｏｄ．」
は「Ｐｒｏｄｕｃｔ：製品（商品）」，「Ｃｕｓｔ．」
は「Ｃｕｓｔｏｍｅｒ：顧客」を意味し、択一的に選択
された検索軸に対し、部門，商品，…を指定することに
より所望の階層を指定することにより、それに属する商
品の売上情報が検索され表示されるようになる。

【００６１】また、部門は、検索軸の所定の階層を指定
するもので、空欄の場合には０階層、つまり、総てを表
示することになる。また、本形態では、各階層のそれぞ
れについて１文字ずつの記号を付し、その組み合わせに
より階層と場所を特定するようにしている。つまり、例
えば、部門階層における第１階層は、日本をＪ，欧州を
Ｅ，北米をＡ，東南アジアをＰ，中国をＣとし、第２階
層はシステム事業部をＳ，健康機器統括事業部をＫ…と
し、第３階層ではコントローラ事業部（ＡＢＣ事業部）
をＣ…などとする。そして、部門に「ＪＳ」としたなら
ば、第２階層まで指定し、日本のシステム機器統括事業
部に属する売上が検索される。そして、商品を指定しな
いと、総ての商品の合計売上データとなり、商品を指定
すると、その商品或いは商品群に付いてのデータが検索
されることになる。

【００６２】上記の検索処理の実行により、条件に合致
するデータを抽出したならば、その検索結果を表データ
化し、要求を受けたクライアントに対して表形式で出力
可能なデータを送信する。このデータを受け取ったクラ
イアント側では、モニタに出力表示する（ＳＴ１２，Ｓ
Ｔ１３）。

【００６３】一例を示すと、図１２に示すように、検索
軸を部門（Ｄｉｖ．）にし、部門をＪＳＣ（日本・シス
テム機器統括事業部・コントローラ事業部（図ではＡＢ
Ｃ事業部））の売上データで、しかも商品をＳＧとして
いるので、ＳＧシリーズに該当する商品の売上データが
検索され、表示される。このとき、通貨コードは、基軸
通貨（日本円：ＪＰＹ）が指定されているので、円ベー
スでの売上データが、図示するような形式で出力される
ことになる。

【００６４】また、検索軸を商品（Ｐｒｏｄ．）にし、
ある商品（Ａ）の営業拠点ごとのデータの表示要求（部
門の欄を入力せず）を受けると、図１３に示すような表
形式で出力することになる。また、図１２，図１３に示
すように、条件入力領域の右上に示す年月の欄へ登録す
る月日を替えることにより、最近のデータ（図１２）を
表示したり、過去のデータ（図１３）を表示することが
できる。さらに、図１４に示すように、通貨レートマス
タ１７に記憶された為替レート（図示の例では、米国ド
ルＵＳＤ）を表示させることもできる。

【００６５】また、具体的な図示は省略するが、基軸通
貨以外の各国の現地通貨に戻し処理したデータも表示さ
せることができる。さらにまた、推移情報も、図７，図
８に示すように、為替の影響を受けない推移情報（Ｌ，
Ｎ，Ｐ，Ｒ，Ｖ）と、為替の影響を受けた推移情報
（Ｄ，Ｆ，Ｈ，Ｊ，Ｔ）の両方のデータを算出して用意
しておくと、商品の売れ筋状況（現地での販売状況）な
どのトレンド把握をする場合には前者の推移情報を取得
し、経営分析をする場合には後者の推移情報を取得する
ことにより、判断に必要な情報を、短時間で得ることが
できる。

【００６６】

【発明の効果】以上のように、この発明では、世界各国
での売上情報の入力を現地通貨で行うことを許容し、シ
ステム内では、単一の基軸通貨に換算した状態で多次元
データベース化処理を行い、多次元データベースをあら
かじめ作成し、保存しておくようにしたため、そのデー
タベースを利用するユーザにとって、短時間で必要な情
報を得ることができる。

【図面の簡単な説明】

【図１】本発明の好適な一実施の形態を示すブロック図
である。

【図２】データウェアハウス１３内に記憶されるデータ
のデータ構造を示す図である。

【図３】本発明の好適な一実施の形態を示すより詳細な
ブロック図である。

【図４】作用を説明する図である。

【図５】検索軸の一例を示す図である。

【図６】検索軸の一例を示す図である。

【図７】作用を説明する図である。

【図８】作用を説明する図である。

【図９】動作を説明するフローチャートの一部である。

【図１０】動作を説明するフローチャートの一部であ
る。

【図１１】データ要求する際の入力画面の一例を示す図
である。

【図１２】検索結果（商品ごとの売上情報）の出力画面
の一例を示す図である。

【図１３】検索結果（営業拠点ごとの売上情報）の出力
画面の一例を示す図である。

【図１４】検索結果（為替レート）の出力画面の一例を
示す図である。

【符号の説明】

１ 本店 ２ａ，２ｂ，…営業拠点 １０ 売上情報管理システム １１ 為替レート入力部 １２ 換算部 １３ データウェアハウス １４ アプリケーション １５ 定型検索アプリケーション １６ サーバアプリケーション １７ 通貨レートマスタ １８ 多次元データベース処理部

Claims (7)

【特許請求の範囲】
1. 【請求項１】 現地通貨と基軸通貨との間の換算を行う
   為替レートを記憶するレート記憶部と、 受け取った現地通貨での売上情報から、前記レート記憶
   部に記憶された為替レートを利用して基軸通貨での売上
   情報を算出する手段と、 前記算出された基軸通貨での売上情報に対し、複数の検
   索軸に従ってデータの積み上げを行い、多次元データベ
   ースを作成するデータベース作成手段と、 そのデータベース作成手段により作成された多次元デー
   タベースに記憶されたデータに基づく売上情報を出力す
   る出力手段とを備え、 前記データベース作成手段は、所定のタイミングで予め
   実行し作成しておくことを特徴とする売上情報管理シス
   テム。
2. 【請求項２】 前記データベース作成手段で作成された
   前記基軸通貨に基づく多次元データベースに記憶された
   データに対し、前記為替レートを利用して各現地通貨で
   の売上情報を生成する現地通貨売上情報生成手段を備
   え、 前記出力手段は、前記基軸通貨での売上情報と、前記現
   地通貨での売上情報のいずれも出力可能としたことを特
   徴とする請求項１に記載の売上情報管理システム。
3. 【請求項３】 前記現地通貨売上情報生成手段は、前記
   多次元データベース作成後に稼動し、予め前記現地通貨
   での売上情報を作成し記憶保持するようにしたことを特
   徴とする請求項２に記載の売上情報管理システム。
4. 【請求項４】 前記現地通貨売上情報生成手段により、
   生成された売上のあった現地の現地通貨での売上情報に
   基づいて、売上の推移情報を求める推移算出手段を設け
   たことを特徴とする請求項２または３に記載の売上情報
   管理システム。
5. 【請求項５】 前記推移算出手段は、基軸通貨に換算し
   た推移情報を得るに際し、１つの現地通貨に使用する為
   替レートを１つに固定して求めるようにしたことを特徴
   とする請求項４に記載の売上情報管理システム。
6. 【請求項６】 前記推移算出手段は、前記現地通貨売上
   情報による前記現地通貨での売上情報の生成後に稼動
   し、予め前記推移情報を作成し記憶保持するようにした
   ことを特徴とする請求項４または５に記載の売上情報管
   理システム。
7. 【請求項７】 世界各国に点在するクライアントとの間
   でデータの送受を可能とするインタフェースを備え、 前記出力手段は、前記クライアントからの出力要求に従
   い、その出力要求に適合するデータを抽出するとともに
   前記出力要求の有ったクライアントに向けて出力するよ
   うにしたことを特徴とする請求項１〜６のいずれか１項
   に記載の売上情報管理システム。