複数の機器間でデータをやり取りするデータ交換方法であって、一方の機器から他方の機器へ、やり取りするデータの桁数を問い合わせるステップと、前記桁数が前記他方の機器で使用するデータの桁数よりも大きい場合、前記他方の機器から前記一方の機器へ、当該他方の機器で使用するデータの桁数を送信するステップと、前記一方の機器にて、前記桁数を受信するステップと、前記受信した桁数を、前記他方の機器で使用するデータの桁数として登録するステップと、前記他方の機器から前記一方の機器へ、前記登録された桁数のデータを送信するステップと、前記一方の機器が前記送信されたデータを受信するステップと、を備えることを特徴とするデータ交換方法。請求項1に記載のデータ交換方法において、前記一方の機器の記憶部には、前記他方の機器で使用するデータの桁数とを備える変換テーブルが格納され、前記やり取りするデータの桁数を問い合わせるステップでは、前記変換テーブルを送信することで問い合わせを行い、前記登録するステップでは、前記受信した桁数を前記変換テーブルに登録することを特徴とするデータ交換方法。請求項2に記載のデータ交換方法において、前記記憶部は、前記一方の機器から、別の機器にデータを送信する時の桁数を備えた送信データテーブルを備え、前記一方の機器が前記送信されたデータを受信するステップは、複数のデータを受信し、前記一方の機器は、前記受信した複数のデータを集計するステップと、前記集計したデータを前記送信データテーブルの桁数のデータに変換し前記別の機器に当該データを送信するステップと、を更に備えることを特徴とするデータ交換方法。請求項1ないし3のいずれか一項に記載のデータ交換方法において、前記一方の機器は収入管理システムの機器であり、前記他方の機器は駅システムの機器であることを特徴とするデータ交換方法。他の機器との間でデータをやり取りする機器であって、他の機器へ、やり取りするデータの桁数を問い合わせ、前記他の機器にて使用するデータの桁数を受信する問い合わせ部通信部と、前記受信した桁数を、前記他の機器で使用するデータの桁数として登録する処理部と、前記他の機器から、前記桁数のデータを受信する受信部と、を備えることを特徴とする機器。請求項5に記載の機器において、前記機器は更に記憶部を備え、前記記憶部には、前記他の機器で使用するデータの桁数を備える変換テーブルが格納され、前記問い合わせ部通信部は、前記変換テーブルを前記他の機器に送信することで問い合わせを行うことを特徴とする機器。請求項6に記載の機器において、前記記憶部は、前記機器から、別の機器にデータを送信する時の桁数を備えた送信データテーブルを備え、前記データを前記送信データテーブルの桁数のデータに変換し前記別の機器に当該データを送信するデータ送信部とを更に備えることを特徴とする機器。現在の鉄道乗車は乗車券のIC化や取扱パターンの複雑化や詳細化により、システムで取り扱う収入データや乗車人員データなどのデータ量が大幅に増加する傾向にある。一方、これらを取り扱う収入管理システムでは、多種多様な駅務機器の増加やシステム開発のマルチベンダ化により外部接続システムとのデータ連携が複雑化しており、様々な種類の異なる桁数のデータを取り扱う必要がでてきている。しかしながら、収入管理システムでは駅システムや外部システムなど各接続先システムごとに取り扱うデータの種類や桁数が異なるため、それぞれ別のインタフェースを作成して取り扱う方式が一般的である。また、データに桁あふれが発生した場合は、それぞれの外部接続システムごとにインタフェースを変更して、桁あふれが発生しないように対応する方式が一般的であるが、複数の駅務機器や複数の外部接続システムのインタフェース変更や接続テストをやり直さなければならないことや、各駅のシステムに対してインタフェースを一斉に変更しなければならないなど、非常に困難を伴う。本発明では、収入系データの桁数を明示したインタフェースの変換テーブルを使用することにより、新旧インタフェースの桁数を判断して処理することで、旧インタフェースのデータであっても新インタフェースのデータであっても汎用的に取り扱うことができるようにし、桁あふれが発生した場合のインタフェース変更に柔軟に対応できるようにする。具体的には、取り扱う収入のデータ量が増加した場合にデータの桁数が不足する場合があるという問題に対し、駅システムと収入管理システムとで変換テーブルをやりとりして桁数が不足していた場合は桁数を追加する変換処理を行うことで、桁数の異なるインタフェースをもつ駅システムおよび外部システムとの収入データのやりとりを柔軟に行う方式に関するものである。本発明では、同じタイプの収入を扱うシステムであっても、変換テーブルをそれぞれ外部システムと収入管理システムとでやりとりして使用することで、例えばb駅の旧インタフェースのデータは従来の桁数として処理し、a駅の新インタフェースのデータは新たな桁数として処理することにより、他システムとのデータ連携において、旧インタフェースのデータも新インタフェースのデータも共通的に処理することができる。本発明により、乗車人員データや収入データなどが接続先システムごとに異なるインタフェースでデータ連携を行う場合にも、統一的に桁数を取り扱うことができる。また、桁あふれした場合のインタフェース変更にも柔軟に対応することができる。以下、図面を用いて本発明の実施の形態について説明する。図1は、本発明の実施の形態を表すシステム構成である。収入管理システム10は、外部のシステムと通信を行うためのインタフェース11、収入データの集計や変換などの演算処理を行うための処理部CPU12、収入データや収入集計データを保管するためのディスク記憶装置13、変換テーブルなどの一時記憶として使用するメモリ記憶装置14、を備える。ここで外部接続システムとは、収入管理システム以外のシステムを指し、その例としては、a駅の収入を取り扱うAシステム21や、人員を取り扱うBシステム22、b駅の収入を取り扱うCシステム23や、人員を取り扱うDシステム24などの駅システムがあり、また収入管理システムが作成した収入送信データおよび人員送信データを取り扱う外部システムであるEシステム25がある。なお、収入管理システムと外部システム駅システムを含むとの間の通信は、ネットワークを介して接続してもよいし、ケーブルで直接接続してもよい。図2から図9は、収入管理システムにおいて収入や人員の桁数を汎用的に取り扱うために備える情報のデータ形式である。図2は収入変換テーブルを示し、この収入変換テーブルには、システム種別、駅コード、インタフェース名称、桁数、インタフェース種別を格納する。図3は収入集計データを示し、この収入集計データには、システム種別、駅コード、収入データ、取扱種別などを格納する。図4は人員変換テーブルを示し、この人員変換テーブルには、システム種別、駅コード、インタフェース名称、桁数、インタフェース種別を格納する。図5は人員集計データを示し、この人員集計データには、システム種別、駅コード、人員データ、乗降種別などを格納する。図6は収入データを示し、収入データには、システム種別、駅コード、収入データ、桁数、取扱種別などを格納する。図7は人員データを示し、この人員データには、システム種別、駅コード、人員データ、桁数、乗降種別などを格納する。図8は収入送信データを示し、この収入送信データには、システム種別、駅コード、収入データ、桁数などを格納する。図9は人員送信データを示している。この人員送信データには、システム種別、駅コード、人員データ、桁数、乗降種別などを格納する。図10、図11は、駅システムが収入管理システムに送信する情報のデータ形式である。図10は収入データを示し、図11は人員データを示している。収入データは、システム種別、駅コード、収入データ、取扱種別を格納するが、収入データの桁数はもたない。人員データは、システム種別、駅コード、人員データ、乗降種別を格納するが、人員データの桁数はもたない。図12、図13は、外部システムが収入管理システムより受信する情報のデータ形式である。図12は、収入送信データを示し、図13は、人員送信データを示す。ここで、収入送信データは、システム種別、駅コード、収入データを格納するが、収入データの桁数はもたない。人員送信データは、システム種別、駅コード、人員データ、乗降種別を格納するが、人員データの桁数はもたない。図14、図15は、収入管理システムにおいて、駅システムから受信した収入データを集計して、外部システムに送信する場合の従来処理のフローである。駅システムでは、保存している収入データを、あらかじめインタフェースに定められた桁数のデータを収入管理システムに送信するステップ1001。収入管理システムでは、駅システムから収入データを受信しステップ1002、受信したデータがインタフェースに定められた正しい桁数であるかどうかをチェックするステップ1003。桁数が正しくない場合はエラーとして処理を終了する。桁数が正しい場合は、受信したデータを集計して収入集計データを作成するステップ1004。全収入データの集計処理が完了したらステップ1005、作成した収入集計データをあらかじめインタフェースに定められた桁数のデータで外部システムに送信するステップ1006。外部システムでは、収入集計データを受信するステップ1007。なお、人員データの場合も同様の処理となる。図16、図17、図18は、収入管理システムにおいて、駅システムから受信した収入データを集計して、外部システムに送信する処理において、一部の駅システムが桁あふれによりインタフェースを変更した場合に、桁数を柔軟に取り扱うための処理フローである。収入管理システムでは、あらかじめ収入変換テーブルとして駅コードとシステム種別ごとにインタフェース名称と収入データ桁数を登録しておく。また、収入管理システムでは、収入データを受信する相手先駅システムごとに、該当するシステム種別、駅コードの収入変換テーブルを送信するステップ2001複数の相手先があれば複数の変換テーブルを送信する。駅システムでは、駅システム側で取り扱う収入データの桁数が、収入管理システムから受信した収入変換テーブルの桁数よりも大きい桁あふれした場合、駅システム側の収入変換テーブルの桁数を変更駅システム側で取り扱う収入データの桁数までカウントアップして、収入管理システムに送信するステップ2003。収入管理システムでは、収入変換テーブルに駅システムから受信した桁数を変更カウントアップした収入変換テーブルのデータを追加しステップ2004、収入変化テーブルへのデータ追加が完了したら駅システムに通知するステップ2005。これで桁あふれを防止するための準備が完了したことになる。収入変換テーブルへのデータ追加が完了し、桁あふれを防止するための準備が完了た後に、駅システムから収入管理システムに収入データを送信するステップ2006。収入管理システムでは、駅システムが送信した収入データを受信しステップ2007、受信した収入データのシステム種別と駅コードから収入変換テーブルを参照して、収入データの桁数を取得するステップ2008。このとき、収入変換テーブルを使用することで変換処理のオーバヘッドが増加するが、変換テーブルをメモリ上に配置するなどの工夫によりオーバヘッドが大きくならないように対処する。次に収入データに収入変換テーブルから取得した桁数を登録するステップ2009。また、受信した複数の収入データを集計して、収入集計データを作成するステップ2010。このとき、収入集計データには他システムとやりとりするデータと比べて十分に大きい桁数をもたせるようにして桁あふれしないようにする。全収入データの集計処理が完了したらステップ2011、システム種別と駅コードから収入変換テーブルを参照して収入送信データの桁数を取得するステップ2012。実際の収入集計データの桁数が、収入変換テーブルから取得した収入送信データの桁数よりも大きい場合は桁あふれしているものと判断ステップ2013し、送信相手先の外部システムに該当するシステム種別、駅コードの収入変換テーブルの桁数を変更カウントアップして送信するステップ2014。外部システム側では、桁数が変更された収入変換テーブルを受信し、収入変換テーブルの変更を受信したことを収入管理システムに通知するステップ2015。実際の収入集計データの桁数が収入変換テーブルの桁数よりも小さい桁あふれしていない場合は、取得した桁数を収入集計データに登録し、収入送信データを作成しステップ2016、作成した収入送信データを外部システムに送信するステップ2017。外部システムで収入送信データを受信するステップ2018。なお、収入データのみでなく取り扱うデータが人員データの場合も同様の処理となる。なお、図16から図18の説明においては、2つの機器間で桁数の情報を通知し合う際に、収入変換テーブルを送信している形態を説明した。しかし、本発明はこれに限定されるものではなく、例えば、桁数のみの情報を送信してもよい。図19は、a駅のAシステムで桁あふれが発生した場合に、Aシステムの桁あふれ検知を契機に収入管理システム側と収入変換テーブルをやりとりし、a駅のAシステムは新インタフェースで異なる桁数の収入変換テーブルを使用して収入データを処理することが可能となる変換処理の例である。一方、b駅のAシステムは従来の桁数の収入データとして、旧インタフェースのままで処理することができるこの例では、収入管理システムが、全駅共通のAシステムとの収入データのやりとりを行うための収入変換テーブル旧インタフェースをもっている。a駅に対してAシステムとやりとりするために該当の収入変換テーブルを送信する。このときの収入変換テーブルの桁数を5桁とする。駅システム側では、a駅のAシステムで作成した収入データが収入管理システムから受信した旧インタフェースの桁数では不足する桁あふれため、収入変換テーブルの桁数を変更6桁して、収入管理システムに送信する。収入管理システムではa駅のAシステムで変更されたデータを収入変換テーブルに追加する。次に、収入管理システムではそれぞれ駅システムから収入データを受信すると、収入変換テーブルを参照して、a駅のAシステムは6桁の収入データと判断し、またb駅のAシステムは5桁の収入データと判断して、それぞれの収入データに桁数を登録する。a駅のAシステム、b駅のAシステムからそえぞれの収入データを集計して、収入集計データを作成する。外部システムへの送信についても同様に収入変換テーブルを参照して、送信先のシステムであるEシステムに7桁の収入データを送信すると判断し、実際の収入集計データが7桁以内におさまっているかどうかをチェックする。この例では7桁以内のため収入送信データを作成し、Eシステムに送信する。もし7桁以内におさまっていなければ、Eシステム送信用の収入変換テーブルの桁数を変更カウントアップし、Eシステムに送信する。本実施例によると、収入管理システムのデータ連携において、それぞれの駅システムや外部システムと収入変換テーブルの桁数をやりとりし、収入管理システムで変換処理を行うことで、収入データの桁数を従来よりも柔軟に処理できるようになる。これにより、桁あふれが発生した場合のインタフェース変更に対し、柔軟な処理が可能となる。また新旧混在のインタフェースも共通に処理することができる。さらに、収入変換テーブルに新たな種別を追加することにより、桁あふれに対する新旧インタフェースの対応のみでなく、異なる複数のインタフェースにも対応できるようになるなどの使い方も考えられる。なお、本実施例では、変換テーブルを使用した例を説明したが、本発明はそれに限定されるものではない。変換テーブルを使用した場合は、使用しない場合と比べて変換処理による実行性能へのオーバーヘッドがかかることがあるが、メモリDB化することにより、その影響を最低限に抑えられる。